An official website of the United States government
OCC Bulletin 2008-16
May 8, 2008
Share This Page:
Chief Executive Officers of All National Banks, Federal Branches and Agencies, Technology Service Providers, Department and Division Heads, and All Examining Personnel
This bulletin reminds national banks and their technology service providers that application security1 is an important component of their information security program. All applications, whether internally developed, vendor-acquired,2 or contracted for,3 should be subject to appropriate security risk assessment and mitigation processes. Vulnerabilities in applications (see Appendix A) increase operational and reputation risk as unplanned or unknown weaknesses may compromise the confidentiality, availability, and integrity of data. Although this guidance is focused on the risks and risk management techniques associated with Web-based applications, the principles are applicable to all types of software.
Banks rely on applications to ensure accurate, timely, and confidential processing of data. Vulnerabilities, particularly those associated with Web-based applications,4 are increasingly the focus of attacks from external and internal sources for the purposes of committing identity theft and other types of fraud.
Web-based applications are most frequently associated with Internet banking, cash management, and brokerage accounts; however, they also facilitate many other Web-accessible services. Web-based applications are being targeted for several reasons including: (a) easy Internet access by all: noncustomer, customer, employees, servicers, and vendors; (b) traditional network defenses (i.e., network firewalls, intrusion detection) may not detect or prohibit unauthorized activity; (c) a breached application may provide perpetrators unauthorized access to sensitive data that supports the application (e.g., customer databases, financial records) and; (d) known vulnerabilities due to weaknesses in application development and assurance processes.
Some application manufacturers mitigate application security risks by incorporating security into their development and assurance processes. Those processes include well-defined recurring action steps that identify and monitor vulnerabilities, notify users of vulnerabilities, and provide remediation or corrective measures. Applications developed internally, purchased, or contracted for may not be subject to similar risk mitigation measures and, therefore, may expose a bank to increased risks.
The FFIEC Information Technology Examination Handbook Information Security and Development and Acquisition booklets5 provide basic guidance regarding application security. This bulletin expands on existing guidance and emphasizes the need for comprehensive application development and assurance processes that integrate security for all applications.
As part of their information security program, national banks should ensure that all applications are developed and maintained in a manner that appropriately addresses risks to the confidentiality, availability, and integrity of data. National banks should include application security in their risk assessments, including those required by Interagency Guidelines Establishing Standards for Safeguarding Customer Information.6 The scope of a bank's application security efforts may vary depending on the size and complexity of the bank and the nature of its software applications.
Key factors that management should consider in their risk assessment of an application include:
Banks that purchase applications typically rely upon the vendors to provide secure applications. However, bank management remains responsible for ensuring that the application meets the bank's security requirements at acquisition and thereafter. As needed for purchased software, banks should expand their vendor management program to include application security considerations in their request for information (RFI) or request for proposal (RFP) process. An attestation from the vendor that their software development process follows secure development practices and is periodically tested may suffice for some applications. For applications that present higher risks,7 banks may require vendor evidence of adherence to sound processes and validation through third-party testing and/or audits. All applications purchased should be supported by appropriate vulnerability identification and remediation processes, including appropriate vendor support.8 Additionally, banks should ensure that their ongoing testing process (e.g., penetration, vulnerability assessment) includes purchased and contracted applications. Appendix B contains considerations when evaluating applications for purchase.
To ensure maximum effectiveness, banks that develop applications in-house should consider following an enterprise-wide effort that is coordinated across business lines and includes the following elements:
National banks are encouraged to leverage upon available resources to assist in risk identification and improve their application security practices. Software tools, industry resources, specific certifications, and education courses are available to provide assistance to enhance the bank's application development architecture; e.g., software development lifecycle and assurance processes. These resources are available through organizations such as OWASP12 and CERT.13 The Department of Homeland Security14 as well the National Institute of Standards and Technology (NIST) SP 800-6415 provide extensive resources to assist in applications security efforts.
Additionally, management should establish a mechanism to receive and respond appropriately to vulnerability reports from public and private sources, including reports from FS/ISAC,16 US-CERT,17 and any other groups that detect, analyze, and report vulnerabilities.
For questions regarding this bulletin, please contact the Bank Information Technology Division at (202) 649-6340.
Mark L. O'Dell
Deputy Comptroller for Operational Risk
1Application security, as used in this bulletin, refers to the creation, acquisition, and maintenance of software that is substantially free of vulnerabilities and that supports the products and services of a bank. Operating systems, generic office products, and other nonbanking software are not addressed by this bulletin.
2Vendor-acquired software includes purchased "commercial off-the-shelf" (COTS) banking applications and those developed by a service provider or other vendor.
3Contracted software is defined as that which is written for a bank pursuant to a defined contractual arrangement.
4See Appendix A – Common Vulnerabilities in Web-Based Applications.
5The booklets that form the FFIEC IT Examination Handbook can be found at http://www.ffiec.gov/ffiecinfobase/index.html.
612 CFR 30, Appendix B
7OCC Bulletin 2005-35, Interagency Guidance, "Authentication in an Internet Banking Environment (October 12, 2005), https://www.occ.gov/news-issuances/bulletins/2005/bulletin-2005-35a.pdf.
8Vendor support should include any changes to applications necessitated by security updates to other required software, such as operating systems.
9"Attack model" is sometimes referred to in current computer systems literature as "threat model." The attack model should address potential attacks on the entire system, including endpoints and end users who enter and/or retrieve information.
10Issues related to open source software are addressed in OCC Bulletin 2004-47, "Risk Management for the Use of Free and Open Source Software," October 27, 2004.
11Static testing is typically associated with code review during the development process, also known as "white box" testing. Dynamic review is performed while the code is being executed in either a lab or production environment, also known as "black box" testing. Functional testing validates what should occur given an input or action by the user.
12The Open Web Application Security Project, http://www.OWASP.org.
13CERT is located at Carnegie Mellon's Software Engineering Institute, http://www.cert.org.
16Financial Services Information Sharing and Analysis Center (http://www.fsisac.com).
17United States – Computer Emergency Response Team (http://www.us-cert.gov).
Common Vulnerabilities in Web-Based Applications18
Insecure Direct Object Reference
18 Source: OWASP http://www.owasp.org/index.php/Top_10_2007.
Considerations for Request for Information (RFI) and Request for Proposal (RFP) when Purchasing Application Software/Services