Systems Development, Acquisition, and Maintenance

Action Summary

Software is the most important building block in a financial institution’s technology infrastructure.  Software should provide the security controls required by the institution, be protected from inappropriate use, and be maintained at a required level of trustworthiness.

Software Development and Acquisition

Financial institutions obtain software through self-development, contracted development, the purchase of pre-written code, or variations of those development and acquisition approaches.  The security issues associated with the approaches involve the security controls built into the code and the trustworthiness of the code that is placed into the financial institution’s environment.  The security features of the code can be assessed regardless of the means of development or acquisition.  The trustworthiness of the code, however, is ascertained differently depending on the availability of information necessary to perform an assessment.

Test data consisting of institution data or customer data frequently is used in development tests or certifications.  Appropriate risk mitigation techniques should be employed to protect that data from unauthorized disclosure.  As a general principal, the risk of disclosure should be no greater than in the production environment.  Techniques to achieve that goal can include altering the data so it is no longer identified with a customer and performing the test in an environment whose controls are as strong as those employed in the production environment.

Security Control Requirements

Financial institutions should develop security control requirements for new systems, system revisions, or new system acquisitions.  Management will define the security control requirements based on their risk assessment process evaluating the value of the information at risk and the potential impact of unauthorized access or damage.  Based on the risks posed by the system, management may use a defined methodology for determining security requirements, such as ISO 15408, the Common Criteria.  Management may also refer to published, widely recognized industry standards as a baseline for establishing their security requirements.  For example, for externally facing Web applications the Open Web Application Security Project (www.owasp.org) produces one commonly accepted guideline. A member of senior management should document acceptance of the security requirements for each new system or system acquisition, acceptance of tests against the requirements, and approval for implementing in a production environment.

Development projects should consider automated controls for incorporation into the application and the need to determine supporting manual controls.  Financial institutions can implement appropriate security controls with greater cost effectiveness by designing them into the original software rather than making subsequent changes after implementation.

The institution’s development, acquisition, and audit policies should include guidelines describing the involvement of internal audit in development or acquisition activities as a means of independently verifying the adequacy of the security requirements as they are developed and implemented.  For more information, refer to the “Development and Acquisition” and “Audit” booklets in the FFIEC IT Examination Handbook.

Development environments should be appropriately secured as a part of the overall institution environment.  Appropriate security generally is a function of the risks of information exposure and the risks that unexpected capabilities will be incorporated into projects delivered to the production environment.  Monitoring of the development environment can assist in assuring that the implemented controls are functioning properly.

Security Controls in Application Software

Application development should incorporate appropriate security controls, audit trails, and activity logs.  Typical application access controls are addressed in earlier sections.  Application security controls should also include validation controls for data entry and data processing.  Data entry validation controls include access controls over entry and changes to data, error checks, review of suspicious or unusual data, and dual entry or additional review and authorization for highly sensitive transactions or data.  Data processing controls include batch control totals, hash totals of data for comparison after processing, identification of any changes made to data outside the application (e.g., data-altering utilities), and job control checks to ensure programs run in correct sequence (see the “Operations” booklet in the FFIEC IT Examination Handbook for additional considerations).

Some applications will require the integration of additional authentication and encryption controls to ensure integrity and confidentiality of the data.  As customers and merchants originate an increasing number of transactions, authentication and encryption become increasingly important to ensure non-repudiation of transactions.

Remote access to applications by customers and others increases risks.  Steps to mitigate those risks include network, host, and application layer architecture considerations.   Network and host controls are necessary to mitigate the risk from potential flaws in applications.  Software trustworthiness is an important component in that consideration.  Additionally, ongoing risk assessments should consider the adequacy of application level controls in light of changing threat, network, and host environments.

Software Trustworthiness

Software can contain erroneous or intentional code that introduces covert channels, backdoors, and other security risks into systems and applications.  These hidden access points can provide unauthorized access to systems or data, unauthorized communications capabilities, and unauthorized abilities to change the software. Because those unauthorized abilities can circumvent the financial institution’s control structure, financial institutions should assess the trustworthiness of the software in their environments and implement appropriate controls to mitigate any unacceptable risk. The additional controls can exist at various levels, including the network, host, and application layers.

Assessment of both self-developed and purchased software should consider the development process, the source code, and the history and reputation of the developers or vendors.   Generally speaking, software whose development process and source is available to the institution can be more effectively evaluated than other software.

Development Process

The development process provides important indicators of code trustworthiness.  The primary indicators are the extent to which security is incorporated within development and personnel processes, and the level of process maturity.  Specific features include:

• Establishment of security requirements, considering the current and expected threat, network, and host environments;
• Establishment of functional requirements and acceptance criteria;
• Use of secure coding standards;
• Tests and reviews for compliance with security requirements;
• Background checks on employees and code development and testing processes;
• Signed nondisclosure agreements to protect the financial institution’s rights to source code and customer data as appropriate;
• Restrictions on developer write-access to production source code and systems, and monitoring developer access to development systems; and,
• Physical security over developer work areas, including restrictions on media taken to and from the work area.

Process maturity is an important indicator because mature processes result in a more controlled code development.  For a greater discussion of development processes, see the “Development and Acquisition” booklet in the FFIEC IT Examination Handbook.

Source Code Review

Source code also provides indicators of code trustworthiness.  Code that has been subjected to independent security reviews is generally more trustworthy than code that has not.    Source code reviews can be automated or manual.  Automated reviews typically look for common coding errors that could have security implications, but can lack the detail of a manual review.  Manual reviews can be more detailed but may be unreliable due to the tedious nature of the task and the varying capabilities of the reviewers.  Taken together, both automated and manual code review can mitigate some risk from coding errors.  However, source code reviews cannot protect against the introduction of unexpected and unauthorized capabilities in the compiling or other manipulation of code. 

History and Reputation

Financial institutions that purchase pre-written software are frequently not provided the opportunity to evaluate the development process or the source code of the software they introduce into their environment.  In such situations, the institutions rely on the proxy of vendor history and reputation.  History and reputation are also important when code is developed by the institution’s employees.  Important indicators include:

• Vulnerability history of other software from the same source, including earlier versions of the software under consideration by the financial institution;
• Timeliness, thoroughness, and candidness of the response to security issues; and
• Quality and functionality of the corrective security patches.

Assessment Follow-up Actions

Should the assessment indicate the software is not sufficiently trustworthy to be implemented in the current environment, additional controls may be implemented at the host or network level.  Those controls generally limit access to the software and the host, limit the software’s access to other host and network resources, monitor the software’s actions on the host, or monitor network communications. 

Systems Maintenance

Financial institutions that introduce trustworthy systems into their environment should ensure that the systems retain that trustworthiness over time.

Essential control elements are the development of appropriately hardened systems, usage of standard builds, the appropriate updating of builds and deployed systems through patch management, and the controlled introduction of changes into the institution’s environment.

Hardening

Financial institutions use commercial off-the-shelf (COTS) software for operating systems and applications.  COTS systems generally provide more functions than are required for the specific purposes for which they are employed.  For example, a default installation of a server operating system may install mail, Web, and file-sharing services on a system whose sole function is a DNS server.  Unnecessary software and services represent a potential security weakness.  Their presence increases the potential number of discovered and undiscovered vulnerabilities present in the system.  Additionally, system administrators may not install patches or monitor the unused software and services to the same degree as operational software and services.  Protection against those risks begins when the systems are constructed and software installed through a process that is referred to as hardening a system. 

When deploying off-the-shelf software, management should harden the resulting system.  Hardening includes the following actions:

• Determining the purpose of the system and minimum software and hardware requirements;
• Documenting the minimum hardware, software, and services to be included on the system;
• Installing the minimum hardware, software, and services necessary to meet the requirements using a documented installation procedure;
• Installing necessary patches;
• Installing the most secure and up-to-date versions of applications;
• Configuring privilege and access controls by first denying all, then granting back the minimum necessary to each user;
• Configuring security settings as appropriate, enabling allowed activity, and disallowing other activity;
• Enabling logging;
• Creating cryptographic hashes of key files;
• Archiving the configuration and checksums in secure storage prior to system deployment;
• Testing the system to ensure a secure configuration;
• Using secure replication procedures for additional, identically configured systems, making configuration changes on a case-by-case basis;
• Changing all default passwords; and
• Testing the resulting systems.

After deployment, COTS systems may need updating with current security patches.  Additionally, the systems should be periodically audited to ensure that the software present on the systems is authorized and properly configured.

Standard Builds

Consistency in system configuration makes security easier to implement and maintain.  Standard builds allow one documented configuration to be applied to multiple computers in a controlled manner.  One financial institution may have many standard builds. 

Through the use of standard builds, an institution simplifies

• Hardware and software inventories
• Updating and patching systems
• Restoring systems in the event of a disaster or outage
• Investigating anomalous activity
• Auditing configurations for conformance with the approved configuration.

An institution may not be able to meet all of its requirements from its standard builds. The use of a non-standard build is typically documented and approved, with appropriate changes made to patch management and disaster recovery plans.

Patch Management

Software support should incorporate a process to update and patch operating system and application software for new vulnerabilities.  Frequently, security vulnerabilities are discovered in operating systems and other software after deployment.  Vendors often issue software patches to correct those vulnerabilities.  Financial institutions should have an effective monitoring process to identify new vulnerabilities in their hardware and software.  Monitoring involves such actions as the receipt and analysis of vendor and governmental alerts and security mailing lists.  Once identified, secure installation of those patches requires a process for obtaining, testing, and installing the patch.

All patches are not equally important.  Financial institutions should have a process to evaluate the patches against the threat and network environment and to prioritize patch application across classes of computers.  Should the institution decide not to apply an otherwise important patch to any particular computer, the decision should be documented with appropriate conforming changes made to inventory records and disaster recovery plans.

Patches make direct changes to the software and configuration of each system to which they are applied.  They may degrade system performance, introduce new vulnerabilities, or reintroduce old vulnerabilities.  The following actions can help ensure patches do not compromise the security of systems:

• Obtain the patch from a known, trusted source
• Verify the integrity of the patch through such means as comparisons of cryptographic hashes to ensure the patch obtained is the correct, unaltered patch
• Apply the patch to an isolated test system and verify that the patch (1) is compatible with other software used on systems to which the patch will be applied, (2) does not alter the system’s security posture in unexpected ways, such as altering log settings, and (3) corrects the pertinent vulnerability
• Plan the patch roll-out to appropriately mitigate the risks to changing systems and address non-standard systems or systems with unique configuration considerations
• Use the change control process to update production systems:
  • Back up production systems prior to applying the patch
  • Apply the patch to production systems using secure methods, and update the cryptographic checksums of key files as well as that system’s software archive
  • Test the resulting system for known vulnerabilities
• Update standard builds
• Create and document an audit trail of all changes
• Seek additional expertise as necessary to maintain a secure computing environment

Controlled Changes to the Environment

Financial institutions should have an effective process to introduce application and system changes into their environments.  The process should encompass developing, implementing, and testing changes to both internally developed software and acquired software.  Weak procedures can corrupt applications and introduce new security vulnerabilities.  Control considerations relating to security include the following:

• Restricting changes to authorized users;
• Reviewing the impact changes will have on security controls;
• Identifying all system components that are affected by the changes;
• Ensuring the application or system owner has authorized changes in advance;
• Maintaining strict version control of all software updates; and
• Maintaining an audit trail of all changes

Changes to operating systems may degrade the efficiency and effectiveness of applications that rely on the operating system for interfaces to the network, other applications, or data.  Generally, management should implement an operating system change control process similar to the change control process used for application changes.  In addition, management should review application systems following operating system changes to protect against a potential compromise of security or operational integrity.  Isolated software libraries should be used for the creation and maintenance of software.  Typically, separate libraries exist for development, test, and production.