A wake-up call to banks on application security

The Office of the Comptroller of the Currency is part of the US Treasury Department, and is one of the regulatory bodies for US national banks. So when they speak, banks listen (to paraphrase an old E.F. Hutton advertisement).

In early May, the OCC released guidance to banks that they have to pay attention to application security. Kudos to C. Warren Axelrod who blogged about it last week.

Here's a few quotes from the OCC letter, which is addressed to "Chief Executive Officers of All National Banks, Federal Branches and Agencies, Technology Service Providers, Department and Division Heads, and All Examining Personnel":

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.

Among the questions they recommend asking for in an RFI/RFP:

• 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.

Their recommendations include "incorporating appropriate attack models [which they define as being equivalent to a threat model] in risk assessments" and using "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." They also recommend looking at open source applications from a security perspective.

Now if banks really do what the OCC is recommending, this may be a truly meaningful kick-in-the-pants to everyone to start paying attention to application security. I never thought I'd say it, but hooray for government bureaucracies!

[Edited 02 Jul to correct the link to the OCC page, which had moved.]