SYSTEMS DEVELOPMENT, ACQUISITION, AND MAINTENANCE
S OFTWARE D EVELOPMENT AND A CQUISITION
Financial institutions obtain software through self-development, contracted development, the purchase of pre-written code, or variations of those development and acquisition ap-proaches. The security issues associated with the approaches involve the security con-trols built into the code and the trustworthiness of the code that is placed into the finan-cial institution’s environment. The security features of the code can be assessed regard-less of the means of development or acquisition. The trustworthiness of the code, how-ever, 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 pro-tect 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
FFIEC IT Examination Handbook P a g e 6 3
the test in an environment whose controls are as strong as those employed in the produc-tion environment.
Security Control Requirements
Financial institutions should develop security control requirements for new systems, sys-tem revisions, or new syssys-tem acquisitions. Management will define the security control requirements based on their risk assessment process evaluating the value of the informa-tion 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.23 Management may also refer to published, widely recognized industry standards as a baseline for establish-ing their security requirements. For example, for externally facestablish-ing Web applications the Open Web Application Security Project (www.owasp.org) produces one commonly ac-cepted 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 ap-plication 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 implementa-tion.
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 Ac-quisition” and “Audit” booklets in the FFIEC IT Examination Handbook.
Development environments should be appropriately secured as a part of the overall insti-tution environment. Appropriate security generally is a function of the risks of informa-tion 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 ad-ditional review and authorization for highly sensitive transactions or data. Data
23 See http://www.commoncriteriaportal.org
FFIEC IT Examination Handbook P a g e 6 4
ing controls include batch control totals, hash totals of data for comparison after process-ing, 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 considera-tions).
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 ap-plications. 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, back-doors, and other security risks into systems and applications. These hidden access points can provide unauthorized access to systems or data, unauthorized communications capa-bilities, 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 develop-ment process, the source code, and the history and reputation of the developers or ven-dors. 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 ex-pected 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;
FFIEC IT Examination Handbook P a g e 6 5
Background checks on employees and code development and testing proc-esses;
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 sys-tems, and monitoring developer access to development systems; and,
Physical security over developer work areas, including restrictions on me-dia taken to and from the work area.
Process maturity is an important indicator because mature processes result in a more con-trolled 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 sub-jected 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 unex-pected 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 insti-tution;
Timeliness, thoroughness, and candidness of the response to security is-sues; 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 imple-mented in the current environment, additional controls may be impleimple-mented at the host or network level. Those controls generally limit access to the software and the host, limit
FFIEC IT Examination Handbook P a g e 6 6
the software’s access to other host and network resources, monitor the software’s actions on the host, or monitor network communications.