One of the comments/complaints I’ve heard often about the ISA/IEC 62443 series is that the definition of Security Levels (SLs) is too vague and can’t be used. Many of these comments come from people that are either safety engineers or have worked around inside and/or safety systems for long periods of time. Now that 62443-4-2 has been published and 62443-3-3 is being revised, I felt it would be a good idea to give some history behind the decisions made surrounding the SL language.
SL Definitions
The ISA/IEC 62443 series define SLs in terms of four
different levels (1, 2, 3 and 4), each with an increasing level of security. (SL 0 is implicitly defined as no specific
requirements or security protection necessary.)
The model for defining SLs depends on protecting against an increasingly
more complex threat and differs slightly depending on what type of SL it is
applied.
- SL 1 – Protection against casual or coincidental violation
- SL 2 – Protection against intentional violation using simple means with low resources, generic skills and low motivation
- SL 3 – Protection against intentional violation using sophisticated means with moderate resources, IACS specific skills and moderate motivation
- SL 4 – Protection against intentional violation using sophisticated means with extended resources, IACS specific skills and high motivation
These definitions were intentionally written vague in order
to be used in various instances without the need to change the overall format.
There are a few main points to consider with these definitions.
Risk Reduction Factors (RRFs) & Safety Integrity Levels (SILs)
NOTE: I’m not a safety engineer, so my explanation is
strictly from what I’ve learned from working alongside safety engineers and Google
searches. There are probably some mistakes
and oversimplifications in this section.
I include this information to help justify why we went the direction we
did when developing 62443-3-3.
When you look up “risk reduction”, many different topics come up, including, financial, medical, disaster, and safety. For industrial control systems (ICS), most professionals look to disaster recovery and safety when thinking about risk reduction. For safety systems, the level of risk reduction that a system needs to bring it to within a desired range is called the risk reduction factor and is measured by Safety Integrity Levels (SILs).
When the safety of a system is evaluated, a native risk factor is determined by using a Process Hazards Analysis (PHA). These techniques often use the results of a Hazards and Operability (HAZOP) study and/or a Failure Modes and Effects Analysis (FMEA) to determine the overall hazards associated with the process and its equipment. A HAZOP looks at the process itself and looks for ways in which the process can cause undesirable consequences and impacts. This allows designers focus on the areas of the process that may be riskier and helps to prioritize the mitigation efforts. A FMEA looks at the ways in which a system can fail and determine the potential consequences and impacts of that failure. They look at it from a feed forward point-of-view, meaning they look at initiating events and then look at the potential consequences and impacts of those specific initiating events.
From the PHA, an organization can determine the processes
and systems that may have a native risk that is outside a level that the
organization has deemed tolerable. If
that is the case, the organization needs to apply risk reduction measures to
bring it within a tolerable level. The
risk reduction factor (RRF) needed for the system is determined and a target
SIL is assigned based on whether the system runs continuously or only at select
times. SIL ratings are assigned a number
from 1 to 4 with 1 being the lowest RRF and 4 being the highest.
Risk Reduction Based vs. Attacker Based
One major thing to note about this discussion of safety
systems and all of the analysis and mitigation techniques revolve around accidental
and unintentional failures of a system.
They usually don’t consider the intentional circumvention of safety
systems or sabotage. In those cases, all
of the SIFs applied to a system may be useless to prevent a critical situation that
results in potential disastrous consequences and impacts.
This is where the application of risk reduction has a major
difference between safety and security.
Security, especially that for ICS, is mostly about preventing a
condition from arising that results from the accidental or intentional
circumvention of policies, procedures, practices, and technology.
Risk reduction, therefore, cannot be calculated completely quantitatively
for security. The mindset of an attacker
cannot be broken down into any mathematical formula that can then be used to
determine a strict order of magnitude type measurement of RRF. Antivirus companies, like Symantec, McAfee,
and TrendMicro, that operate in the information technology (IT) and business
environment have enough statistical sampling from their installed clients that
they can produce some level of approximation, however, it is highly biased by
their sample set. They give some
indication of trends in the overall IT/business attacker mindset and techniques,
but they cannot be used as direct input for risk calculations. When it comes to attackers in the ICS
environment, there is not enough statistical data for designers and defenders
to make any logical conclusions about motivation or specific techniques.
Writing the 62443-3-3 Standard
While writing the 62443-3-3 standard, we found that we
wanted some logical separation between different sets of requirements and also
wanted to be able to provide some justification as to why particular
requirements were placed in those different sets. We knew that we would never reach complete
agreement on which requirements belonged into which buckets, however we could
at least show that some thought went into the choices.
The four main groups that we chose were as follows:
- (Unintentional) Personnel violating policies,
procedures, and techniques inadvertently while trying to do their daily jobs.
- (Intentional) Generic business-style attackers,
script kiddies, bleadover from the business network, etc.
- (Intentional) Industrial aware attacker or
insider, but not someone with elevated privileges or detailed knowledge of the
systems.
- (Intentional) Industrial aware attacker or insider
with elevated privileges and detailed knowledge of the systems.
When we looked at the first level (SL 1), we generally thought
about well-meaning personnel that were trying to do their job in a way that
made sense to them. They may have
violated policies, procedures, or techniques, but it was not intentional. These may be cases like personnel posting the
password for the engineering workstation on the monitor or side stepping a
policy in order to get something done in a time critical situation. They may go against basic security
principles, but it is done with the intention of getting their normal job done.
The second level (SL 2) is the first where we thought about
intentional attacks. These would
generally not be directed ICS attacks, but would be the typical bleedover from
the business network. They would be
generic types of malware or Internet-based attackers that don’t have an
understanding of ICS and ICS-specific attacks.
For the most part, these types of attackers would be interested in using
the ICS system for some sort of financial gain, such as ransomware, botnet,
industrial espionage, etc.
The third level (SL 3) is where ICS-specific attacks first
appear. This type of attacker might be
someone that’s worked in the ICS environment or it might be an insider in an
organization that has access to some systems but not everything. The attacker in this case might be a
disgruntled employee or a competing organization that is trying to infiltrate
the systems. These would generally be
normal operations staff, not those with detailed knowledge of the systems and
defenses.
The fourth level (SL 4) is the highest level of
defense. This is the level where “Trust
No One” is the general rule of thumb.
The attacker in this case would have deep insider knowledge of the
systems and processes being utilized.
These would generally be engineering staff, system administrators, database
administrators, or other personnel with elevated privileges or extensive access.
While some may classify SL 4 as “nation state” defense or
being able to defend against “Stuxnet 2.0”, this would not really be the
case. In most cases, if a “nation state”
actually came after an organization, it is doubtful that the any level of
defense could completely eliminate the possibility of being penetrated. At best, your organization would hope that
they are able to detect the attacker’s presence and initiate some sort of
remediation effort prior to the attacker reaching their final objective,
whether that is collecting information or causing damage.
These four categories of attacker allowed us, as the writers
of the 62443-3-3 standard, to look through our set of requirements and decide
that one requirement was really trying to defend against a known insider versus
a general business virus. The levels
were never intended to have quantifiable, distinct, easily identifiable separations. They were not intended to be used as
absolute, set in stone values or to be used by themselves to define the security
applied to the system. They were only
intended to allow us, as the authors, to convey to the reader of the standard
some level of justification for why certain requirements ended up in the levels
they did.