OCC Bulletin 2008-16 | May 8, 2008

Information Security: Application Security

To

Chief Executive Officers of All National Banks, Federal Branches and Agencies, Technology Service Providers, Department and Division Heads, and All Examining Personnel

Purpose

This bulletin reminds national banks and their technology service providers that application security¹ is an important component of their information security program. All applications, whether internally developed, vendor-acquired,² or contracted for,³ 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.

Background

Banks rely on applications to ensure accurate, timely, and confidential processing of data. Vulnerabilities, particularly those associated with Web-based applications,⁴ 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 booklets⁵ 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.

Risk Management Considerations

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.⁶ 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:

Accessibility of the application via the Internet;
Whether the application provides the ability to process or provide access to sensitive data;
Source of application's development; such as, in-house, purchased, or contracted for;
Extent that secure practices are used in the application's development process;
Existence of an effective, recurring process to monitor, identify, and remediate or correct vulnerabilities; and
Existence of a periodic assurance process to validate independently the security of the application.

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,⁷ 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.⁸ 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:

Incorporating appropriate attack models⁹ in risk assessments to assist in determining the security and assurance requirements for the application.
Analyzing the environment in which the application will reside. As the environment changes, the security requirements and assurance needs for the application may also change. A bank's information security program should consider these control factors in assessing overall risk on an ongoing basis.
Ensuring that any open source application¹⁰ used by the bank is also subject to appropriate development and assurance processes.
Ensuring that appropriate personnel (i.e., management, developers, security, and auditors) are trained sufficiently to understand, and be aware of, risks associated with the bank's technology environment.
Engaging in periodic application testing or validation based on a current risk assessment to ensure the ongoing and appropriate protection of transactions and customer data. Testing considerations may include:
- Static, dynamic, and functional¹¹ evaluations, depending on the type and criticality of the application.
- Automated evaluations using commercial or freeware tools, as well as manual interaction to supplement application tools.
- Authenticated and non-authenticated user scenarios.
- Comprehensive testing in a simulated production environment including appropriate operating systems and associated databases. The weakest link in several connected components may expose the entire system to compromise.
- Implementation of lessons learned iteratively throughout the development and periodic testing processes.
- Identification and monitoring of bank-developed applications for vulnerabilities through an ongoing and defined process that includes appropriate communications and remediation.

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 OWASP¹² and CERT.¹³ The Department of Homeland Security¹⁴ as well the National Institute of Standards and Technology (NIST) SP 800-64¹⁵ 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,¹⁶ US-CERT,¹⁷ and any other groups that detect, analyze, and report vulnerabilities.

Additional Information

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

¹Application 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.

²Vendor-acquired software includes purchased "commercial off-the-shelf" (COTS) banking applications and those developed by a service provider or other vendor.

³Contracted software is defined as that which is written for a bank pursuant to a defined contractual arrangement.

⁴See Appendix A – Common Vulnerabilities in Web-Based Applications.

⁵The booklets that form the FFIEC IT Examination Handbook can be found at http://www.ffiec.gov/ffiecinfobase/index.html.

⁶12 CFR 30, Appendix B

⁷OCC 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.

⁸Vendor support should include any changes to applications necessitated by security updates to other required software, such as operating systems.

⁹"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.

¹⁰Issues 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.

¹¹Static 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.

¹²The Open Web Application Security Project, http://www.OWASP.org.

¹³CERT is located at Carnegie Mellon's Software Engineering Institute, http://www.cert.org.

¹⁴ https://buildsecurityin.us-cert.gov.

¹⁵ http://csrc.nist.gov/publications/nistpubs/800-64-Rev2/SP800-64-Revision2.pdf.

¹⁶ Financial Services Information Sharing and Analysis Center (http://www.fsisac.com).

¹⁷United States – Computer Emergency Response Team (http://www.us-cert.gov).

Appendix A

Common Vulnerabilities in Web-Based Applications¹⁸

Cross Site Scripting (XSS)	XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser that can hijack user sessions, deface Websites, possibly introduce worms, etc.
Injection Flaws	Injection flaws, particularly Structured Query Language (SQL) injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.
Malicious File Execution	Code vulnerable to remote file inclusion allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.
Insecure Direct Object Reference	A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.
Cross Site Request Forgery (CSRF)	A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.
Information Leakage and Improper Error Handling	Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.
Broken Authentication and Session Management	Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.
Insecure Cryptographic Storage	Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.
Insecure Communications	Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.
Failure to Restrict URL Access	Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

¹⁸ Source: OWASP http://www.owasp.org/index.php/Top_10_2007.

Appendix B

Considerations for Request for Information (RFI) and Request for Proposal (RFP) when Purchasing Application Software/Services

What are the vendor's risk-based processes for development and validation of the application security before, during, and after it is purchased?
What are the vendor's notification processes whenever security vulnerabilities are identified by the vendor, reported by customers, or others?
Will the vendor provide timely mitigation or remediation solutions to identified security vulnerabilities?
Does the vendor have an industry-recognized third party who conducts application vulnerability assessments on the application (including security)? If so, obtain the third party's name and determine how often the assessment is conducted, and:
- The date of the last time an application vulnerability assessment was conducted for the application;
- Whether the vendor is willing to share the results before the bank selects it as the chosen vendor;
- Whether the application has any known open vulnerabilities (including security) at the time of responding to the RFI/RFP. If so, is the vendor willing to share the nature of those vulnerabilities with the bank before selection of the product; and
- Whether the vendor is willing to share its secure coding processes and practices with the bank before execution of a contract.
If the vendor does not have a third party who conducts application vulnerability assessments (including security), can the vendor describe their internal methodology?
Is the vendor willing to conduct, or contract for, an assessment to provide assurance to the bank regarding the security of the application?
Where appropriate, the bank should include in the contract language about the need for current and ongoing application vulnerability assessments (including security) and who will conduct the assessments. Depending on the risk profile of the application, bank management may request the full vulnerability assessment report or a summary.

Topic(s):

Bank Information Technology (BIT)