Before Choosing Your ICS/OT Security Framework, Know the Fundamentals
by Curtis Blount, CSO
We recently completed an engagement where our NetRadar suite client argued the use of the NIST Cyber Security Framework (NIST CSF) as a baseline for ICS/OT cybersecurity risk management. The statement was “NIST CSF is crap.” To be clear, InsightCyber does use NIST CSF as a baseline and we are completely agnostic when it comes risk assessments. We base our selection on the client’s usage and preferences.
During the conversation, I countered that all security frameworks have benefits as well as drawbacks. By drawbacks, I’m referring to the fact that some frameworks are designed for a specific purpose. For example, PCI-DSS which focuses on credit card processing, has a foundation with NIST as security framework.
Security frameworks can be very complex. ISO 27001, for example, is complicated to implement from an operational perspective. The main drawback is that many of the security frameworks are IT related and not specific to Industrial Control Systems and Operational Technology (ICS/OT). (Hence, InsightCyber's hybrid risk assessment approach.)
The counterpoint to the customer's argument was that ISA/IEC 62443 is a “better standard” than NIST CSF. I explained that NIST CSF isn’t a standard. With ISA/IEC 62443, there are three parts:
The first series of documents are defined as policies and procedures,
The second series is for ICS/OT System Integrators,
While the third series contains standards for ICS/OT equipment manufactures.
It should be noted that within the ICS/IEC 62443 series of documents ISA-62443-2-1, ISA-62443-2-2, ISA-62443-2-3 and ISA-62443-2-4 all reference security in some form or fashion (last updated in 2009).
The bottom line is that ISA/IEC 62443 has some very good security baselines if you are in the Integration or ICS/OT manufacturing space. However, it can’t be used as a baseline for cybersecurity.
Let’s just say that we agreed to disagree. The client wasn’t incorrect in using ISA-62443. The use of ISA-62443 was just used in the wrong context.
The Right Choice for ICS/OT
This is one of the fundamental problems when addressing cyber security within ICS/OT processes and trying to adopt “IT” into ICS/OT. There are fundamental differences between a framework, a standard and a methodology. Frameworks and standards are typically used interchangeably. However, they are completely different.
So, when someone argues the point about one thing being better over the other, the context of the definition is never added to the equation.
A framework is a guide on how to achieve a certain goal. In context, a framework is a loose guideline that defines the main structure of cybersecurity. However, it doesn’t dictate how to do certain things.A framework is not a step-by-step recipe, in that it doesn’t tell you what tools and processes to rely on.
Standards dictate how to achieve goals, using frameworks as a baseline.
With frameworks and standards, the combination of the two provides structure, standards, tools and controls. That’s a methodology.
Let’s try an example:
Framework: There should be segmentation between networks..
Standard: A Cisco firewall (with a set configuration model) will be used for segmentation.
Methodology: The following procedures represent the controls to satisfy the requirement: The Cisco firewall will be managed by X and all logs will be stored for Y number of days; Only the following Corporate vLANS are allowed access to the Production Control environment; Logging of access must follow company access policy.
You get the idea.
When discussing cyber security for ICS/OT, the differences between frameworks and standards becomes extremely important. ICS/OT organizations need to adopt a cybersecurity framework to help buildout cybersecurity architecture and standards that will eventually lead to a robust methodology for ICS/OT cybersecurity Controls.
As we guide you through your NetRadar deployment, we'll help you navigate the minefield of all of these different facets.