Today the DHS ICS-CERT published a notice on their web site
that they have updated one of their Reference Practice documents; “Improving
Industrial Control System Cybersecurity with Defense-in-Depth Strategies”.
The original document was written in 2009 and this update reflects (according
to the official abstract)
changes in control systems management, security practices, and change management
within the ICS community.
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.
1 comment:
Patrick,
I'm glad you took the time to do a critical review and address your observations of the report content. I've worked in operations, ICS design engineering (nuclear, electrical, some water...) and ICS cybersecurity (in that order..) my whole career (40 years) and understand your concerns. My first thought is that we tried to adequately cover the risk analysis considerations of cyber security in the ICS business context at a fairly high level since there are other reference materials that more adequately address the details of analysis and calculation of risk appetite by business, but we added the ICS security concerns as many businesses don't adequately factor in ICS cybersecurity weakness/risk/consequence in that analysis.
What we chose to present and believe, is that the business risk appetite is up to business to determine, our job is to present them with understanding of the defense in depth concept to ICS cybersecurity, and provide some guidance on how best practices can be applied to improve security posture.
Concerning safety systems, I agree wholeheartedly with your thoughts on isolation and resilience measures, and it sounds like a good topic to provide additional material in the next update.
I've been involved in the cyber assessment efforts with vendor ICS and with private and public sector ICS systems for 13 years and the material presented in the report provide a good overview at a level that can be understood by people working in all sectors, which is the goal of this effort. We have had chemical sector ICS expertise on our team as well as ONG, water and Electric sector, so we do understand these concepts, however a document intended to cover all ICS will not cover all of the details of each sector, expecially the complexities.
I would ask that you don't recommend "throwing the baby out with the bath water" in your thoughts about this material, but I do respect your thoughts and experience. I have seen safety system components communicating over ICS network links in multiple sector installations. The recommendation is that safety systems are isolated, i.e. not connected to the ICS networks. Some applications will pass certain health and status bits from the safety system controllers to the local controllers in a one-way communication. If the Recommended Secure Architecture did not adequately reflect that then it needs to be fixed.
Having been an operator I appreciate your valuation of the operations staff as the first line of defense and the team also believes that people are the most important... and variable element of security. We may call on you to review the next revision because your insights are helpful.
Again... thanks,
Dave Kuipers
Post a Comment