Tuesday, September 13, 2016

ICS-CERT Defense-in-Depth Paper Updated

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:

Unknown said...


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

/* Use this with templates/template-twocol.html */