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:

  1. Framework Core – Cybersecurity activities and outcomes divided into 5 Functions: Identify, Protect, Detect, Respond, Recover
  2. Framework Profile – To help the company align activities with business requirements, risk tolerance and resources
  3. 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:

  1. Describe their current cybersecurity posture;
  2. Describe their target state for cybersecurity;
  3. Identify and prioritize opportunities for improvement within the context of a continuous and repeatable process;
  4. Assess progress toward the target state;
  5. 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?

How can we foster cooperation to help our Development and Security Teams work together?

How do I know my Cloud Service Provider (CSP) Applications are secure?

What can I do to help eradicate SQLi or at least reduce the incidence of SQLi vulns in our production applications?

Submit your questions via Twitter using #ThinkAppSec

More from Application Security

X-Force Identifies Vulnerability in IoT Platform

4 min read - The last decade has seen an explosion of IoT devices across a multitude of industries. With that rise has come the need for centralized systems to perform data collection and device management, commonly called IoT Platforms. One such platform, ThingsBoard, was the recent subject of research by IBM Security X-Force. While there has been a lot of discussion around the security of IoT devices themselves, there is far less conversation around the security of the platforms these devices connect with.…

4 min read

Patch Tuesday -> Exploit Wednesday: Pwning Windows Ancillary Function Driver for WinSock (afd.sys) in 24 Hours

12 min read - ‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.Figure 1 — Exploitation timelineHowever, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can…

12 min read

Backdoor Deployment and Ransomware: Top Threats Identified in X-Force Threat Intelligence Index 2023

4 min read - Deployment of backdoors was the number one action on objective taken by threat actors last year, according to the 2023 IBM Security X-Force Threat Intelligence Index — a comprehensive analysis of our research data collected throughout the year. Backdoor access is now among the hottest commodities on the dark web and can sell for thousands of dollars, compared to credit card data — which can go for as low as $10. On the dark web — a veritable eBay for…

4 min read

Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers

17 min read - Overview In this post, IBM Security X-Force Red offensive hackers analyze how attackers, with elevated privileges, can use their access to stage Windows Kernel post-exploitation capabilities. Over the last few years, public accounts have increasingly shown that less sophisticated attackers are using this technique to achieve their objectives. It is therefore important that we put a spotlight on this capability and learn more about its potential impact. Specifically, in this post, we will evaluate how Kernel post-exploitation can be used…

17 min read