Application Security Risk Management and the NIST Cybersecurity Framework

It’s finally here. v1.0 of the NIST Framework for Improving Critical Infrastructure Cybersecurity that started as Executive Order 13636 from President Obama was issued on February 12, 2014. A collaborative effort between government and private sector, the Framework is a result of months of hard work. Though the Framework has Critical Infrastructure (CI) in the title, that doesn’t mean that an organization has to run a nuclear power plant or manage a city water system to use it. The Framework can bring valuable guidance to all industries and organizations that depend on IT for their operations because it brings a common language and model to the process of managing cybersecurity risk.

Breaking down the Cybersecurity Framework

The Framework is composed of three parts:

Framework Core – Cybersecurity activities and outcomes divided into 5 Functions: Identify, Protect, Detect, Respond, Recover
Framework Profile – To help the company align activities with business requirements, risk tolerance and resources
Framework Implementation Tiers – Which help organizations categorize where they are with their approach

Building from those standards, guidelines, and practices, the Framework provides a common taxonomy and mechanism for organizations to:

Describe their current cybersecurity posture;
Describe their target state for cybersecurity;
Identify and prioritize opportunities for improvement within the context of a continuous and repeatable process;
Assess progress toward the target state;
Communicate among internal and external stakeholders about cybersecurity risk.

Risk Management

Managing cybersecurity risk isn’t about eliminating all risk. It is about determining and understanding the risk rating of events and putting the right processes or controls in place to manage them in accordance with the organization’s risk tolerance levels. It is an ongoing process, not a one-time event. And it requires an organization to understand what kind of events can have a negative impact on operations, how likely those events are to occur and what the impact would be to the service or business if a given event does occur.

As a fairly simple example, let’s look at a utility with a requirement for on-going remote access to a web-enabled ICS (industrial control system). The utility wants to understand the risk associated with a DDoS (distributed denial of service) attack. They do some research from external sources like ICS-CERT and review their own activity logs and determine that the likelihood of a DDoS attack against the remote access system is High. Since the remote access is required for on-going support of the ICS, they also deem the impact of interruption from the DDoS as High – and give that attack scenario a High risk ranking. The utility can then prioritize DDoS prevention as high priority activity for the company and assign resources or compensating controls, such as a DDoS protection service, accordingly.

As noted, the above example was fairly simple. This graphic from the Framework illustrates the information and decisions flows that are included in a complete risk management program. Note that the on-going nature of risk management is depicted by the movement in the arrows and that, in the implementation triangle, the organization will need to track progress and changes in assets, vulnerabilities and threats and feed that information back up to the business and risk decisions makers. For example, if a company is able to put a control in place that completely eliminates the likelihood of a DDoS attack being successful, they may change the likelihood ranking from High to Low.

Software Risk and the Framework

Software security is a critical component of cybersecurity. If the apps you’re running can be exploited, the services they’re running are at risk. And though there isn’t a special section devoted to applications or building software in the NIST Framework, software is mentioned a number of times and should be addressed as part of the broader cybersecurity program.

A good first step in understanding how the Framework can help inform and improve your existing application security program is to go through it with an application security focused lens. Let’s take a look at the first Function in the Framework Core: Identify (ID) and the ID Categories: Asset Management (ID.AM) and Risk Assessment (ID.RA) –

ID.AM contains the subcategories:

ID.AM-2: Software platforms and applications within the organization are inventoried
ID.AM-3: Organizational communication and data flows are mapped
ID.AM-5: Resources (e.g., hardware, devices, data, and software) are prioritized based on their classification, criticality, and business value

ID.RA contains the subcategories:

ID.RA-1: Asset vulnerabilities are identified and documented
ID.RA-5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk

There’s a lot in there that would map nicely to a risk-based software security program. One of the first steps in a risk-based software security program is to get a handle on what apps the company has. This sounds simple, but it can be hard to accomplish accurately and sometimes companies don’t both to do a thorough job of inventorying. But as the Framework details, inventorying the apps should be a first step.

Data flows are often associated with networks and the traffic and data that flow through them, but they are very important in application security and testing. Source code testing identifies the sources of data into an application and the sinks, or exits of data from, the application. If you’re adopting the framework, don’t forget to include data flows within and between applications themselves.

And the priority subcategory links right back into risk-based application security management. Classifying applications on criticality and business value can be brought to a deeper and more precise level when the threat model and vulnerability profile of that application is understood and validated with testing. For example, application testing can determine if sensitive or privacy related data is stored, processed or transmitted by the app. This information could change the classification rating. If an application is determined to be medium critical to operations, but there are a number of high severity vulnerabilities in the application that were discovered by testing, the resources to remediate that application may be prioritized over resources to fix a high criticality app with only one low severity vulnerability.

Risk-based application security management

These are just a few examples of how risk-based application security management intersects into the first function – Identify – in the Framework. There are many more intersection points.

Have you reviewed the framework through a software security lens? Will it change or influence how you manage your application security program?

What value can the NIST Framework for Improving Critical Infrastructure Cybersecurity bring to my industry and my organization from a software security perspective?

How do you know if the vendor providing hardware or software can be trusted? How do you know if their processes can be trusted to supply your organization with hardware and software that has not been maliciously tainted?

What is the importance of software security in supply chain management?

Who Should be Responsible for Application Security Testing?

Can “generated code” be tested?

How do we secure application vulnerabilities and code development, particularly for mobile and social applications that are built by business units or reside on the cloud?

As a CISO, how can I control my organization’s testing methodologies, change management and deployment processes, without compromising on quality and project timelines?
How Can I Secure Apps in the Cloud?

Will the legal landscape change if software vendors can be sued without damages or loss being proven?
The Legal Landscape: Can vendors be sued without damages? What the heck is PII?

What is PII – How much can the definition expand?
Mobile Apps: Which are More Secure Android or iOS?

Does IoT (Internet of Things) “change everything” for Application Security?

What is the difference between PCI DSS and PA DSS?