Cyber Ransomware: Cyber Security's Nemesis & A Disappointing NIST Standard

Reports on cyber security incidents are becoming more common where leaked information or ransomware caused a major impact on an organization financially and/or disruptively (Maersk, Mondelez, etc.).

It’s quickly become a cyber attacker’s go-to method for malicious activities. Cyberattacks often leverage known vulnerabilities and exploits to take advantage of exposed systems.

Even with the rise in the numbers of attacks, and the likelihood of ransomware attacks continually increases, it’s not all doom and gloom. Risks can be reduced, and attackers will often focus on the paths of least resistance.

In fact, this NIST document outlines the challenges and potential solutions on how to manage such a disruptive event in accordance to the NIST Cyber Security Framework, and also refers to a number of NIST Special Publications (SP) that guide decision-making or internal governance and procedural questions.

Of course, there is always risk of knowledge gaps and enhanced techniques that bypass protections, but the real goal is to be able to respond and prevent (where possible) cyberattacks in a fashion that is consistent with your organization’s risk, security, and safety targets.

The NIST SP-1800-26 document is a long 562 pages of reading and cross-referencing related NIST publications, but in general, the process laid out across the collection of three volumes is as follows:

1. Use a risk analysis framework to define, analyze, score, and manage risks to an organization. This includes a variety of threats from malware, insider threats, vulnerabilities, and even the impacts of the eventual probability of a negative event.
2. Cross-reference a security control map that acts as a reference-able matrix to organize cyber security functions and sub-categories that support step one (the risk management & analysis process). It should look quite similar (or at least aligned) to those familiar with the NIST CSF five (pillars): Identify, Protect, Prevent, Respond, and Recover.
3. Define a high-level architecture to be used for implementation of a Detect & Respond procedure. This will contain block diagrams, flowcharts, technology capabilities, and interfaces for informational flows.  And with all of these elements, these should be tied into and aligned to your implementation of the NIST CSF wheel.
4. Define a security-characteristic analysis framework to understand the extent a project meets observable and verified objectives to detect and respond to disruptive events in different scenarios. Of course, with any analysis framework, defined outcomes and markers of success should be adequately described as a necessary component for each scenario.
5. Functionally evaluate any test plans using a consistent process that outlines both the requirements, areas of interest, process/procedure, expected results, actual results, and overall results/outcomes.
6. Implement validated test plans & technology. Better yet, this SP even contains a number of technology guidelines for securing your systems (e.g., securing Active Directory).

This document is a reasonable starting point for those wishing to kickstart a cyber security program to manage cyber threats. It is flexible enough to be of use in Operational Technology (OT) environments where there is focus on Safety-Reliability-Productivity when compared to the standard Information Technology (IT) triad of Confidentiality-Integrity-Availability (CIA).  Amidst the content, the overall process is sane, the examples decently useful, and the list of reference-able supplementary documents are invaluable.

Unfortunately, NIST has skewed too far from its objective of being vendor agnostic. It references several vendors and products too specifically, and also mentions that these technologies may not be appropriate for critical infrastructure and industrial control systems (ICS).

On the positive side, it demonstrates the ability to use a variety of technologies, integrations, asset management, and reporting to assist with your organization’s cyber security program.

And finally, this SP needs more guidance on how to create general ransomware security prescriptively, ready-to-use templates, and overlays/extra advice for OT environments (similar to SP-800-82r).

It should be noticed that any insights and artifacts require tailoring for each organization, technologies used, and supportive processes, but this would be far more valuable for asset owners looking to add security for ransomware-related cyber security threat scenarios. Hopefully follow-up documentation acknowledges these shortfalls.