Using ANSI/ISA-99 Standards for SCADA Security (plus White Paper)

Recently I wrote about one of the fundamentals of industrial cyber security, which is the concept of Defense in Depth.

Today I am going to write about another foundation concept, which goes hand-in-hand with Defense in Depth, and that is using ANSI/ISA-99 Standards to improve control system security.

Factors that have degraded Control Network Security

There are two opposing trends impacting control network design today:

  1. The trend toward greater “interconnectedness” of control systems with enterprise systems as organizations seek increased business productivity and as they increase the use of Ethernet-TCP/IP technology.
  2. The trend to isolate control networks as an attempt to block advanced malware threats such as Stuxnet.

How does a controls engineer deal with the conflicting requirements of more integration and more isolation?  My advice is to accept and plan for high integration with business systems, and to dismiss the idea that control systems can be isolated.

I am on the record as saying I don’t believe isolation really exists today, except, perhaps, if you are a highly defended nuclear facility. Rather, what Stuxnet showed us is that there are multiple pathways to the control system, and they don’t require a connection to the Internet.  This is discussed more in the White Paper you can download at the end of this document, or, for extensive details on this, see How Stuxnet Spreads.

If isolation is not an effective security measure, then how can you protect your control system? One way you can make significant improvements in your facility’s cyber security posture is to improve network segmentation.  Many control networks have remained “flat”, even though more and more devices have been connected to them.  Flat networks mean that a cyber intrusion or network incident that originates in one part of the network can quickly spread to other areas.

The “zone and conduit” model included in the ANSI/ISA-99 security standards provides a framework for network segmentation.

Zones and Conduits

ANSI/ISA-99 Standards introduce the concept of of “zones” and “conduits” as a way to segment and isolate the various sub-systems in a control system.

Figure 1: Security Zone Definition

A zone is defined as a grouping of logical or physical assets that share common security requirements based on factors such as criticality and consequence.

Equipment in a zone has a security level capability. If the capability level is not equal to or higher than the requirement level, then extra security measures, such as implementing additional technology or policies, must be taken.

Any communications between zones must be via a defined conduit.

Figure 2: Conduit Definition

Conduits control access to zones, resist Denial of Service (DoS) attacks or the transfer of malware, shield other network systems and protect the integrity and confidentiality of network traffic.

Typically, the controls on a conduit are intended to mitigate the difference between a zone’s security level capability and its security requirements. Focusing on conduit mitigations is typically far more cost effective than having to upgrade every device or computer in a zone to meet a requirement.

Defining the Security Zones

A zone might be a group of physical assets that have common security requirements.

Zone and conduit design starts with the facility or operation being analyzed to identify groups of devices that have common functionality and common security requirements. These groups are the zones that require protection.

For example, a facility might first be divided into operational areas, such as materials storage, processing, finishing, etc. Then within these areas it could be further divided into functional layers, such as Manufacturing Execution Systems (MES), Supervisory Systems (i.e. operator HMIs), primary control systems (e.g. DCS Controllers, RTUs and PLCs) and safety systems.

Each zone is defined with not only its boundaries, assets and risk analysis, but also its security capabilities. In other words, the security capability of a zone full of Windows 2008 servers is very different than that of a zone of Windows NT servers or a zone with PLCs. This security capability, along with the security risk faced by the zone, drives the security function requirements for conduits that connect the zone to other zones.

Defining the Security Conduits

Often it is easier and less expensive to secure a conduit than the assets at the end of it.

The next step is to discover the pathways in the system through which data is passed between these zones; these are the network “conduits”.

Each conduit should be defined in terms of the zones it connects, the technologies it utilizes, the protocols it transports and any security features it needs to offer its connected zones.

Typically, determining the information transfer requirements between zones over the network is straight forward. Tools like traffic flow analyzers or even simple protocol analyzers can show which systems are exchanging data and the services they are using.

It is also wise to look beyond the network, to determine the hidden traffic flows. For example, are files ever moved via USB drive between the lab and the primary control systems? Do people remotely connect to the RTUs using a dialup modem? These flows are easy to miss, but can result in serious security issues if not managed carefully.

Securing the Conduits

Once the conduits and their security requirements are defined, the final phase is to implement the appropriate security technologies.  There are two popular options for this stage:

1.     Industrial Firewalls

These devices control and monitor traffic to and from a zone. They:

  • compare the traffic passing through to a predefined security policy, discarding messages that do not meet the policy’s requirements
  • they are typically configured to pass only the minimum traffic that is required for correct system operation, blocking all other unnecessary traffic
  • filter out high risk traffic, such as programming commands or malformed messages that might be used by hackers to exploit a security hole in a product
  • are designed to be very engineer-friendly and are capable of detailed inspection of SCADA protocols such as DNP3, Ethernet/IP and Modbus/TCP

2.     VPNs (Virtual Private Networks)

These are networks that are layered onto a more general network using encryption technology to ensure “private” transmission of data and commands.

VPN sessions tunnel across a transport network in an encapsulated format, making them “invisible” to devices that don’t have access to the VPN members’ secret “keys” or “certificates”. 

ANSI/ISA-99 and Defense in Depth

The zone and conduit approach helps implement a strategy of “defense in depth”, that is multiple layers of defense distributed throughout the control network.  This is a strategy that has been proven in the IT community.

I strongly recommend you become proficient with segmenting control networks for zones and conduits, and with appropriate industrial security solutions.  Doing so will greatly assist your organization to mitigate against threats from “interconnectedness” and “Son-of-Stuxnet” malware.

Is your network segmented with zones and conduits?  If not, do you think this is a good approach?  If it is, are there any tips you would like to share with others?  Let me know.

Related Content to Download

White Paper: "Using ANSI/ISA-99 Standards to Improve Control System Security"

Download this White Paper and learn about:

  • The ANSI/ISA-99 Zone and Security Model
  • A Real World Oil Refinery Example
  • Implementing Zones and Conduits with Industrial Security Appliances
  • Testing and Managing the Security Solution

Related Links


RSS Feed Subscribe to the "Practical SCADA Security" news feed

Author Eric Byres



It is a good method to document seurity and we (Honeywell) are using the method about a year now in our audits & assessment services and design methodology. A few comments:

When practizing the method in the field there are two bottleneks with the diagrams as used in the white paper:

- not easy to work with security sub-zones in this way
- the conduits are better drawn separately (we actually split the diagram, zones on the left / conduits on the right side) in the conduit diagram.

Within these zones and conduits we developed a methodology to show which security controls are used to protect the zone or conduit. (AV being a zone protection control, IPS being a conduit protection control) various different rules can be defined on inheriting security controls for a "true" sub-zone. This way of documenting the security is far better then the traditional network diagrams often seen today.

Apart from conduit analysis, we go one step deeper ... Channel analysis, the equivalence of the data flows in the white paper. With channel analysis (and the appropriate drawing techniques) we analyze access policies. Analyzing the protocols we can differentiate specific connection types which can conflict with access policies.... Maybe a bit mystic explained, but never the less in this area an additional step is necessary to use the methodology in the field.

As a point of discussion, I Consider the firewall as a zone protection ... It doesn't really protect the conduit (as for example an IPS or VPN does). But realize that with the next generation firewalls this difference is less clear.

In principle, I agree with "skoelemij" above, however, one point that may have been accidentally omitted, and is obviously missing is that Security Controls within a Zone, and even more importantly, at the Conduits between Zones must include the ability to not only "prevent" a cyber event, but also aide in its rapid "detection" and support the "mitigation" of both the source and the consequences of the source.

Honeywell is no different than most vendors, in that their strategy is often too heavily waited on preventing an event from occurring in the first place. The architectures that are implemented include significant strength and depth in trying to prevent the attack, but if the event should succeed, very little exists to actually detect this has occurred and aide in its isolation and removal.

Point in case ... vendors have not really embraced the concept of log consolidation and analysis. Any reasonably advanced cyber event aims to remove its tracks and the easiest way for this to occur is to modify system logs. I have yet to see an ICS vendor install, let alone, endorse the implementation of as a minimum, a SYSLOG infrastructure within the PCN Zone - ideally, a more comprehensive SIEM solution that can provide the essential correlation and rationalization of the events is also missing.

Examples usually add credibility, but take a look at their Control Firewall that is used to protect their Process Controller Sub-Zone (C300's) from their Supervisory Sub-Zone (HMI/Servers). [Emerson, Rockwell and others have similar devices, so this is not directly specifically at Honeywell] If there is an attempt to penetrate the Control Firewall via a denied service port, no alarm is generated and broadcast to a PCN Zone-wide event collection mechanism. For those nodes that can communicate events (like the network appliances), these events are not typically consolidated against all of the events that are generated within the PCN Zone, making it very difficult to pinpoint the exact actors within the Zone.

Segmentation is one of the strongest defenses an ICS architecture has in containing malware to specific Zones and Sub-Zones. Therefore, it should be equally important to include appropriate controls that address the complete lifecycle of an attack following initial exploitation and continuing through mitigation and restoration.

Honeywell supports the implementation of SIEM in control systems, actually they are not the only one to do so. The market changes rapidly in this respect, auditing / syslog / SIEM has been offered since 2011 and is in use.

I think the problem on modern scada/pcs/icss systems that has been designed and implemented in the late 90's is the fact that it is quite modern and new to change or modify its design as the investment is still not yet achieved. Also on the other hand, those systems are using the IT technology deeply (DCOM, OPC, TCP/IP , Routing...etc) and very heavily without well implementation or through knowldge and documentation which makes it very difficult to modify the design due to the wory of cost impact as well as production interuption.

Zone and Conduits is a good architecture but we need now to focus on methodology of implementation or integration on modern systems (systems design and implemented between (1990-2005).

Add new comment