The NIST Cyber Security Framework Completely Misses the Mark

December 10, 2013

The National Institute of Standards and Technology (NIST) released a Preliminary Cyber Security Framework to help organizations build a holistic approach to cyber security. The framework is very broad, which on the surface is a boon for information security programs. In particular, the five core functions are a good way of ensuring a complete view of security: Identify, Protect, Detect, Respond, Recover. But, the devil is in the details — the Cyber Security Framework completely lacks any mention of application security. We predict that organizations will likewise adopt the framework with scant attention paid to secure software, which will lull them into a false sense of security.

Make no mistake about it, application security is critically important. The 2013 Verizon Data Breach Investigations Report (DBIR) indicates that 40% used malware and 52% of breaches used some form of hacking. In the case of malware, gone are the days where people download a malicious executable file and run in. Instead, infections take advantage of software vulnerabilities in end user systems such as browsers, operating systems, and desktop programs. In the case of hacking, the majority of vulnerabilities are software vulnerabilities, such as back-doors, susceptibility to brute force attacks, and SQL injection. Not integrating application security in custom development, and more importantly into the supply chain for procured software, is a major gap.

As with implementers of other broad frameworks such as NERC CIP, ISO 27001 and COBIT, we cannot have confidence that implementers will have a comprehensive application security program. An organization with hundreds of applications could reasonably conform to this cyber-security framework with absolutely no application security controls whatsoever — even if those applications are responsible for a large portion of the breaches. The absence or presence of application security controls will rest with the domain knowledge of whomever is assessing that organization for compliance. To put this in perspective, if the developers of want to adopt the Cyber Security Framework, they could possibly do so without any application security controls. This, despite the fact that is in itself a massive web application.

Clearly the framework’s authors were trying to stay focused on high level objectives, as opposed to frameworks like the Payment Card Industry Data Security Standard which are very perspective and specific with technical compliance requirements. You could argue that some parts of the framework such as “ID.RM-1: Risk management processes are managed and agreed to” ought to include application security. That particular section lists NIST SP 800–53 as an informative reference, which does cover application security explicitly. Yet there’s a big difference between an optional “informative reference” on a single line item and a top-level control that calls for application security controls. It makes sense for the framework to be focused on strategic outcomes, but not at the expense of potentially dangerous false negatives.

The Cyber Security Framework can make a significant impact on information security. The framework could, for example, make application security for both custom and procured software, a major piece of the “Protect” function. They could include references to holistic application security standards, such as the emerging ISO 27034. Imagine the cumulative impact if every implementor of the framework pushed comprehensive application security controls on to its supply chain. Many of the root cause vulnerabilities that enable security incidents could be significantly reduced at a lower cost, as proven by Microsoft through its SDL program. Not only would the organizations who implement the Cyber Security Framework benefit, but all users of the downstream vendors’ software will also have improved security postures. None of this will happen if application security is optional.

Previous Article
5 Common Linux Misconfigurations
5 Common Linux Misconfigurations

Over the numerous configuration reviews and pentest engagements that we have performed for our clients, we’...

Next Article
Business Logic Pitfalls in Trading Applications (Blog Series) — 2
Business Logic Pitfalls in Trading Applications (Blog Series) — 2

Hi there folks, Here is the second pitfall that we’ve seen in securities trading applications in capital ma...

Learn how you can use SD Elements to integrate security into software development.

Watch Video