In the third part of our analysis of the NIST Cybersecurity Framework for Improving Critical Infrastructure Cybersecurity (NIST CSF) we focus on the 98 “subcategories” of the Framework Core that provide most of its meat. The Subcategories identify various cyber security activities along with desired outcomes. Let’s look at some examples:
ID.AM-1: “Physical devices and systems within the organization are inventoried”
ID.GV-1: “Organizational information security policy is established”
PR.AT-1: “All users are informed and trained”
DE.CM-4: “Malicious code is detected”
This may lead the cursory reader to believe that the NIST CSF is some kind of performance-based tool which would, if applied properly, allow users to assess or even measure cyber security posture of a given facility within the critical infrastructure. However, nothing would be more of a misconception.
Making insecure configurations look ok
NIST doesn’t provide any kind of detail on what is really meant by and involved in the catchy phrases of the Subcategories, thereby omitting criteria that could be verified empirically. For example, what does a hardware inventory look like? What do information security policies look like? In real life, hardware inventories often are incomplete and outdated Excel spreadsheets, and information security policies are well-meaning documents from the IT department that are largely ignored on the plant floor because they can’t be applied anyway. The idea that “All users are informed and trained” may be reflected in some vague FUD-loaded reminder aimed at “raising cyber security awareness”, and even an outdated anti-virus software will certainly be able to “detect malware”. In all cases it would be legitimate to “check the box” and, at the end of the day, tell your boss that you comply with the NIST CSF. However it doesn’t solve any cyber security problem; it may make things rather worse because severely insecure configurations can be sold as CSF-conformant and thereby “ok”.
The predominant methodological problem with the CSF surfaces again: It introduces too much variability. If, for example, it is not specified what a hardware inventory should look like, then anything from a list of systems along with IP addresses written on a napkin, to a full-fledged CMDB qualifies to “check the box”. But performance-based criteria must not allow for such a wide interpretation, otherwise they are useless. It must be possible for independent observers to consistently establish if such criteria are met or not, and significantly different implementations (such as napkin sketch vs. CMDB) must result in a clear statement of compliance vs. non-compliance.
A closely related problem of similar proportions is that the CSF never tells potential users how to actually implement all those 98 activities in even one way that would match what was intended – placing the burden of proper implementation on the user. This user may now contract a consultant to figure out what an appropriate implementation would be for the 98 Subcategories or at least for the Profile (subset) that has been selected. No matter how good or bad the advice from that consultant may be, it can be predicted that different experts will arrive at different preferred solutions, thereby introducing one more measure of… variability.
RIPE to the Rescue
The good news is that over 80% of the NIST CSF Subcategories can be operationalized (i.e. turned into procedures the result of which can be objectively verified) for facilities where industrial control systems are at the center of cyber security activities. As a matter of fact, they are already operationalized within the RIPE Framework. Let’s highlight this for the Subcategory examples cited above:
ID.AM-1: Not only is RIPE very precise on what a hardware inventory should look like, it also comes with step-by-step instructions on how to build one.
ID.GV-1: the RIPE Framework includes a full set of policies and standard operating procedures for typical plant environments and their typical roles and responsibilities.
PR.AT-1: RIPE comes with a comprehensive training curriculum for all stakeholders.
DE.CM-4: RIPE includes multiple provisions for preventing and detecting unauthorized software (rather than malware).
There are multiple benefits in this practical approach:
- it is clear what the criterion (or desired result) looks like. Independent observers (auditors) will arrive at a consensus when looking at the same plant environment, and plant environments with different properties will lead to different assessments and metrics.
- A recipe on how to reach the end result is already included. No need to spend additional time and money on how to figure that out.
- RIPE is not an individualized solution but rather a generic framework that can be used by completely different organizations in different industries. RIPE users apply a unified method that provides them with comparable results and enables learning from the experiences of others, rather than having each organization re-invent the wheel.
The bottom line is that the RIPE Framework allows organizations to comply with the NIST CSF to over 80 percent, using standardized methods that allow for metrics and benchmarks. And different from the NIST CSF, RIPE is supported by a private company that is willing and able to help users with implementation issues in detail, and has every incentive to make the whole thing practical and useful.
What about the other 20% that you don’t find in RIPE?
You may now wonder what the remaining Subcategories are that are not covered in RIPE. Most of these refer to assessing and “managing” risk (Categories ID.RA and ID.RM). As most loyal blog readers know, RIPE doesn’t reflect on risk as there is no (zero) empirical evidence that would support the theory that the various risk and risk management approaches have been successful in cyber-physical environments.
Another five Subcategories not covered by RIPE are associated to considerations about the organization’s business environment (ID.BE). The reasoning behind including those in the NIST CSF is unclear as NIST constantly refers to the organization’s business needs, leaving it open as to why that business should even worry about larger-scale, emergent effects that financially and legally don’t effect it. A “sector specific risk analysis” (transcending the organization’s own risks) as expected in ID.RM-3 is obviously something of little appeal to any business, not to mention that NIST expects said business to elaborate on risks that are the responsibility of other companies (potentially competitors) and the government.
In the next and final part of our analysis we wrap up the main findings and compare the NIST CSF against RIPE.