BlogInfoSec.com

On May 8, 2008, the OCC (Office of the Comptroller of the Currency, part of the U.S. Department of the Treasury) issued Bulletin 2008-16, which you can find here.

As the OCC states, there have been prior mentions of application security by the FFIEC (of which OCC is a member), NIST and others. However, this is the first guidance, as far as I am aware, issued by a U.S. government regulator, which is specific to application security and is prescriptive to a relatively fine level of detail. Yes, the PCI DSS (Payment Card Industry Data Security Standard), issued and enforced by Visa, Mastercard, American Express, and others, emphasizes measures to achieve higher levels of application security, but these organizations are not government agencies and, although highly influential, do not carry the weight of the government.

Now back to the OCC Bulletin … It is gratifying to see that the OCC has acquired such a high level of knowledge and expertise in this space, as demonstrated by the content of Bulletin. For example, the OCC includes an Appendix containing the ten top vulnerabilities as posted by OWASP (Open Web Application Security Project).

As an aside, I have very high regard for OWASP, and have had some involvement with the organization. I have participated in meetings of the New York/New Jersey Chapter and am scheduled to be on a panel at their World Conference in New York on September 22-25, 2008. OWASP is essentially an all volunteer international organization that issues really great material for the practicing application security professional.

The OCC focuses on software which supports a bank’s products and services and which is developed internally or outsourced to a third-party developer subject to a defined contractual arrangement, as well as on COTS (commercial off-the-shelf) banking applications, with particular emphasis on Web-based applications. It explicitly excludes “operating systems, generic office products, and other nonbanking software …”

The OCC guidance recognizes the importance of reducing risks related to the security triad: confidentiality, availability and integrity. They say that the risk assessment should include the following key factors:

• Whether sensitive data can be accessed and processed through the application
• The nature of the developers of applications, such as internal staff, third parties, etc.
• The degree to which the SDLC incorporates security practices
• Whether there is a recurring process to find and fix vulnerabilities
• Whether there exists a process for periodic independent validation of application security

The guidance goes on to suggest the following be part of a risk assessment:

• Incorporating attack or threat models
• Monitoring and analyzing environments in which applications are deployed
• Subjecting open-source applications to the same development and assurance processes
• Performing periodic application testing and validation processes

This is all good stuff. It’s what many of us have been touting for years, but we have often been subjected to a whole lot of pushback. Now that a regulator is promoting these principles for achieving greater application security, it will be an easier sell to management, particularly in financial services. But even if you are in a different industry, many of the same factors and measures apply. Why not circulate the OCC Bulletin to your management as examples of practices that everyone should be following?

Bookmark this post

•Sphere: Related Content•  Print

Related Articles:

• Panel Discussion Participant: 5th Annual Cyber Security Executive Summit
• When you suspect their data was stolen
• Metrics Revisited – Application Security Metrics
• Where to find AJAX Security Issues
• Additional AJAX Security Research