I was not closely following ICS-CERT when the original document
was published. I did
run
into it a number of years later, but did not save a copy of the document
because it was clearly dated. This means that I do not have any reasonable
expectation that I can write about the changes in the document. That means that
I’ll have to deal with it only in its current form.
Real Brief Overview
Both the abstract and the Executive Summary from the actual
document provide describe the organization of the revised documents this way:
“Background and Overview” outlines
the current state of ICS cybersecurity and provides an overview of what defense
in depth means in a control system context;
“ICS Defense-in-Depth Strategies”
provides strategies for securing control system environments;
“Security Attacks” outlines how
threat actors could carry out attacks against critical infrastructures and the
potential impact to ICSs and networks; and
“Recommendations for Securing ICS”
provides resources for securing ICSs based on the current state-of-the-art
methods and lessons learned from ICS-CERT activities, national and
sector-specific standards for ICS security, and tools and services available
through ICS-CERT and others that can be used to improve the security posture of
ICS environments.
Remember the Objective of ICS Security
I’ll leave a review of the most of the technical aspects of
the document to those with the appropriate background in implementing
cybersecurity techniques. What I am more concerned about is what is lacking
from this discussion; an appreciation that industrial control systems are
really only potential targets of attack because of the industrial process which
they control. This document mentions this a couple of times in passing (for
instance in section 2.2.5 where it states “…or if the ICS controls a process
with potential human safety consequences, it may
require special consideration and additional controls.”),
but the document fails to address the consequence of this fact of life.
Specifically, it fails to address the fact that the first
step in any risk assessment of the security of an industrial control system
needs to start with a review of the process being controlled and the
consequences of a loss of control or even a loss of view of that process. The
level of risk for an ICS that controls the manufacture of widgets, is much less
than one that controls the use, storage or manufacture of toxic inhalation
hazard chemicals, which is different than one that controls high-speed
passenger rail traffic on a high-profile transportation corridor.
Failure to take into account the consequences of a successful
attack on a control system means that any cost/benefit analysis of the risk
versus the cost of ‘adequate security’ will be grossly misestimated. It is also
very likely to lead to a misunderstanding of which controls are actually
critical controls that may need additional security protections.
Safety Controls in Defense-in-Depth
The other area where a lack of appreciation of the actual purpose
of industrial control systems is found in the discussion of different types of
defenses that can be used in a defense-in-depth system. Where ever the loss of
control or loss of view of a process can lead to safety concerns for facility
personnel or, even more importantly, off-site personnel, an important part of
the defense-in-depth process has got to be safety controls that are not part of
the industrial control system that may be attacked.
The successful design, application and implementation of
these safety controls may go a long way to mitigate a successful attack on the
control system. A clear understanding of the design basis for the safety
controls and the degree of their integration with or in the industrial control
system is absolutely necessary for the proper assessment of the risk of a
successful attack on a control system and the proper design and implementation
of an effective defense-in-depth strategy.
Probably the most important safety control in many process
environments is the skill and knowledge of the operators that oversee the
functioning of the process being controlled by the industrial control system.
Ensuring that operators have skill and experience to identify non-standard
operating excursions (and the methods of identifying those excursions outside
of the possibly vulnerable control system) and the ability to assume enough
process control without using a compromised ICS to avoid the worst safety
consequences of loss of control via the ICS is another defense-in-depth
strategy that is missing from the discussion in this document.
Need to Expand the Parochial View of ICS Security
We must at all times remember that industrial control
systems (except in honey pots) do not exist in a vacuum. They exist to control
an actual physical process. An understanding of that process, and the
consequences of that process being upset, must inform all decisions about the
security of the industrial control system.
For example, if in a chemical manufacturing facility, we
only have one isolatable process that could have significant off-site
consequences if we lose control or view of the control system for that process,
we should certainly take a long, hard look at making a separate Cell Security
Zone (see page 19) for the devices monitoring and controlling that process to
build-in an additional layer in the defense of the devices controlling that
process.
Now I understand that ICS-CERT is first and foremost a
cybersecurity organization focused on industrial control systems. They do not
have the expertise in the wide variety of process that may be controlled by
such systems, so it is easy for them to overlook that additional level of
complexity in looking at cybersecurity for control systems. But, they really do
need to ensure that they learn the absolute necessity for including process
safety (consequence) analysis in any discussion of analyzing control system
security or designing an effective defense-in-depth cybersecurity plan.
Failure to include such process analysis will inevitably
mean that security controls will be focused on the wrong things, allowing an
attacker a better opportunity to create a successful attack. Or, maybe actually
inadvertently decrease the effectiveness of the safety controls and thus end up
making the process less safe. Either way, the affected organization could find
itself cybersecuritied into a reduced safety environment.
Posts
