Beckhoff Energy data management
Industrial Ethernet Book Issue 68 / 36
Request Further Info   Print this Page   Send to a Friend  

Using ANSI/ISA-99 standards to improve control system security

Industrial plant operators today aim to increase productivity, reduce costs and share information in real time across many industrial and enterprise systems. Adding to these pressures is the growing fear of cyber attacks, noting that the Stuxnet worm was specifically designed to disrupt an industrial process. Operators are being asked to isolate automation systems just as ever greater interconnectedness is demanded. How to reconcile the two? Eric Byres explains how the 'zone and conduit' model included in the ANSI/ISA-99 security standards provides a framework for dealing with network security concerns about the next Son-of-Stuxnet worm.

AS CORPORATE NETWORKS have converged with industrial control system (ICS) networks, many proprietary networks were replaced with commercial-off-the-shelf equipment using Ethernet-TCP/IP technology - a shift that has greatly increased control system complexity and interconnectedness. As a result, they now have many of the same vulnerabilities that have plagued enterprise networks. In addition, the controllers are now subject to new threat sources that they were never designed to handle. The result has been a significant increase in plant disruptions and shut-downs.

The Repository for Industrial Security Incidents (RISI1) is the world's largest database of security incidents in control and SCADA systems. An analysis of the data from 1982 to 2010 found that the type of incidents affecting control systems breaks down as follows:

50% of incidents were accidental

30% of incidents were malware-based

11% of incidents were external attackers

9% of incidents were internal attackers.

Problems arise from three common sources:

i) Proliferation of 'soft' targets - SCADA and ICS devices (PLCs, DCS controllers, IEDs and RTUs etc) were primarily designed for reliability and real-time I/O, rather than robust and secure networking. Many ICS devices will crash if they receive malformed network traffic or even high loads of correctly-formed data. Also, Windows PCs in these networks often run for months without security or antivirus updates, and are susceptible to outdated malware.

Fig. 1. Possible pathways into the control system: Remote maintenance and diagnostics connections, historian and MES servers shared with business users, remote access modems, serial connections,wireless systems,mobile laptops, USB devices and data files.

ii) Multiple points of entry - Even without a direct connection to the Internet, modern control systems are accessed by numerous external sources (Fig. 1) - all a potential source of infection or attack. These include:

Remote maintenance/diagnostics connections

Historian and MES servers shared with business users

Remote access modems

Serial connections

Wireless systems

Mobile laptops

USB devices

Data files (e.g., pdf or PLC project files).

These pathways are underestimated and poorly documented by industrial system owners and operators. Says Sean McGurk, the Director of National Cybersecurity and Communications Integration Centre (NCCIC) at the US Department of Homeland Security: 'In our experience in conducting hundreds of vulnerability assessments in the private sector, in no case have we ever found the operations network, the SCADA system or energy management system separated from the enterprise network.

'On average, we see 11 direct connections between those networks. In extreme cases, we have identified up to 250 connections between the actual producing network and the enterprise network.'2

As the Stuxnet worm showed, these pathways can be readily exploited by malware and other disruptive elements. Stuxnet used at least eight different propagation mechanisms, including USB drives, PLC project files and print servers to work its way into the victim's control system.

iii) Poor internal network segmentation - Control networks are now more complex than ever, comprising often thousands of individual devices. Many such networks have virtually no segmentation, so problems originating in one part can quickly spread to other areas.

ANSI/ISA-99 security model

Given such concerns, what can be done to secure systems? It is unlikely that engineers will be able to significantly reduce the number of internal and external pathways into their facilities. Furthermore, modern IT technologies now demand a steady stream of electronic data onto the plant floor, posing a security risk.

There is limited opportunity to address soft target proliferation short term. Aggressive patching helps reduce the risk of exposed operating system vulnerabilities, but most plant operators are dependent on their ICS/SCADA equipment vendors to secure the controllers and ICS software products. Unfortunately, this has met with limited success. As of December 2011, the US ICS-CERT had published 137 advisories on control system products3 with known security vulnerabilities. Fewer than half of these had patches available at the close of the year.

The good news is that engineers can address the third cause by implementing good network architectures. This article explains how to do this using the strategies outlined in ANSI/ISA- 99 Standards: Security for Industrial Automation and Control Systems.

ANSI/ISA-99 is a complete security life-cycle program for industrial automation and control systems. It comprises 11 standards and technical reports. Work products from the ISA99 committee are also submitted to the IEC as standards and specifications in the IEC 62443 series.

ANSI/ISA-99 introduces the concepts of 'zones' and 'conduits' as a way to segment and isolate the various sub-systems in a control system. A zone is defined (Fig. 2) as a grouping of logical or physical assets that share common security requirements based on factors including criticality and consequence.

Fig. 2. Security zone definition: 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 this is not equal to or higher than the requirement level, extra security measures must be taken.

Any communications between zones must be via a defined conduit. Conduits control access to zones, resist DoS attacks or the transfer of malware, shield other network systems and protect network traffic integrity and confidentiality. 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.

ANSI/ISA99 standards do not specify exactly how a company should define its zones or conduits. Instead, requirements are provided based on a company's assessment of its risk from cyber attack. Since risk is a function of the possibility of a cyber incident plus its consequences, the zones, conduits and protection needed will vary for each facility.

Figure 3 lists some of the sub-sections in ANSI/ISA99.02.01 that address network segmentation using zones and conduits.

Fig. 3. Conduit definition: Some of the sub-sections in the document ANSI/ISA99.02.01 that address network segmentation using zones and conduits.

Defining security zones

Zone and conduit design starts with the facility/operation being analysed to identify groups of devices having common functionality and security requirements. These are the zones requiring protection. For example, a facility might first be divided into operational areas. Then, it could be further divided into functional layers, such as MES, supervisory systems (i.e., HMIs), primary control systems (e.g., DCS controllers, RTUs and PLCs) and safety systems. Often models from other standards - such as ANSI/ISA-95.00.01-2000 or the Purdue manufacturing model - are used as a basis for this division. Vendor design documents can also be helpful.

Each zone can then be defined by zone characteristics (attributes). The following are recommended: zone description (name, definition, function); zone boundaries; typical assets/inventory; inheritance from other zones; zone risk assessment (security capabilities of zone assets, threats/vulnerabilities, consequences of a security breach, business criticality); security objectives and strategy; acceptable use policy, inter-zone connections (i.e., access requirements); and the change management process (see Fig. 4).

Fig. 4. This indicates the key zone and conduit requirements fromANSI/ISA-99.02.01.

Each zone is defined with not only its boundaries, assets and risk analysis, but also its security capabilities, so the security capabilities of a zone full of Windows 2008 servers is very different than of a zone of Windows NT servers or a zone with PLCs. This capability, along with the security risk faced by the zone, drives the security function requirements for conduits that connect the zone to others. The soon to be published ISA-62443.03.03 (99.03.03): Security for Industrial Automation and Control Systems: System Security Requirements and Security Assurance Levels helps users define these security capabilities and requirements.

Zones can also be defined according to a control asset's inherent security capabilities - eg: older PLCs having very weak authentication could be grouped into a zone that provides them with extra defences.

Defining security conduits

Next, discover the pathways through which data is passed between zones. These are the network 'conduits', and each should be defined in terms of the zones it connects, the technologies used, the protocols transported and any security features required for its connected zones. Again, see Fig. 4 on previous page. Determining the information transfer requirements between zones over the network is usually straightforward using traffic flow or simple protocol analysers.

Also, look beyond the network to determine hidden traffic flows - are files moved via USB drive? Do people remotely connect to the RTUs using a dialup modem? Such flows can result in serious security issues.

Data flow diagrams (Fig. 5) are useful for summarising the conduits and traffic flows they contain. Each zone can be represented by a node and each flow can be represented by a vector.

Fig. 5. A data flow diagram: This is an excellent tool to summarise conduits and the traffic flows they contain. Each zone can be represented by a node and each flow can be represented by a vector.

Once the conduits and their security requirements are defined, the final phase is to implement appropriate security technologies. Popular options include firewalls and VPNs. The whole zone and conduit approach implements the proven strategy of defence in depth - multiple layers of defence distributed throughout the control network.

A real-world example

A large refinery example shows how ISA-99 zones and conduits design techniques were used to create a security architecture and protect operations. The refinery company follows the concepts of ANSI/ISA-95.00.01- 2000 and ANSI/ISA-99.01.01-2007, dividing its process operations into Levels 0 - 4. Many operations require safety integrated systems (SIS). Some control areas are starting to use wireless technology. Finally, control system vendors and downstream customers must interface with the control systems.

The refinery high-level network diagram is shown in Figure 6. For simplicity, only two operations areas (Op #1 and Op #2) are shown, but in reality there are multiple operations, each having its own basic control, safety and HMI/supervisory systems. These connect to a common process information network, where historian and MES servers are accessible from both the enterprise and control networks. In addition, wireless sensors are being deployed throughout Op #2, and a remote access gateway is provided for remote maintenance.

Fig. 6. A high-level network diagram of the refinery: For simplicity, only two refinery operations areas (Op #1 and Op #2) are shown in this diagram.

The company then divided its systems into zones based on operational function, process level, security requirements and security capabilities (Fig. 7). All control functions belong to an overall Process Control Zone (A); within that there are Operational Zones (O1, O2 On) for each major operational unit. This way, security requirements for a particular operation can be

Fig. 7. Refinery zone diagram: Systems were divided into zones based on operational function, process level, security requirements and security capabilities.

Once defined, the zones needed to be described with the zone attributes as noted earlier. Figure 8 (on p19) shows an example zone definition for one of the safety area zones.

Following the initial analysis, the potential threat sources and consequences of an attack were identified and reviewed with the plant engineers. It was evident that the SIS in each operational unit should be located in its own zone (initially they were part of the basic control zone). To ensure continued safe plant operation, it was vital that the safety system could not be compromised from the plant control network. Later in the process, these were the first zones to be protected with security appliances on the conduits.


Zone Name: Unit 1 Hydrocracker Safety System

Definition of this Zone: This zone includes all safety integrity systems for the Unit 1 Hydrocracker.

Controlling Agency: Process Automation Department, SIS Team.

Zone Function: The systems in this zone provide safety functions to the Unit 1 Hydrocracker.

Zone Boundaries: The Safety Integrated System as defined by the Unit 1 Hydrocracker HAZOP.

Typical Assets: The Safety Integrated System controller, engineering station and communications hardware.

Inheritance: This zone inherits attributes from Zone C1 (Unit 1 Hydrocracker Basic Control System)

Zone Risk Assessment: This is a low to moderately secure zone with extreme consequences if breached.

a) Security Capabilities of Zone Assets: All assets are assumed to be incapable of withstanding low level attacks (i.e. those launched by unsophisticated attackers or malware) on their availability or confidentiality. This is a result of the protocols in use and system design. Assets are assumed to be capable of withstanding medium level attacks (i.e. those launched by moderately sophisticated attackers or malware) on their integrity.

b) Threats and Vulnerabilities: The vulnerabilities of this zone are assumed to be typical of legacy industrial control devices using Modbus for communications. The principal threats are:

a. Network-based Denial of Service to SIS communications.

b. Internal or External unauthorized access to the SIS engineering station.

c. Spoofing of MODBUS/TCP control commands.

d. Spoofing of MODBUS/TCP responses to the process system.

e. Reprogramming of safety functions.

c) Consequences of a Security Breach:

a. Loss of production >6 hrs from false trip of emergency shutdown system.

b. Loss of production <6 hrs due to loss of visibility to safety system.

c. Disabling/manipulation of emergency shutdown resulting in fatality or major community incident.

d Business Criticality: Extreme

Security Objective: To protect the integrity and availability of the Unit 1 Hydrocracker Safety System.

Acceptable Use Policy: I/O and Fieldbus communications is allowed to Zone P1 (Unit 1 Hydrocracker Process). Read access to published data is allowed to approved systems in the Zone C1 (Unit 1 Hydrocracker Basic Control System). All Write access to this zone is forbidden. All system management and programming functions shall be internal to this zone.

Inter-zone Connections: Conduits to this zone may be established from Zone C1 (Unit 1 Hydrocracker Basic Control System) and from Zone P1 (Unit 1 Hydrocracker Process).

Security Strategy: All connections to this zone must be controlled using type S conduits.Access to these systems must be approved by the Controlling Agency.

Change Management Process: All changes to this zone or any of its connecting conduits must follow the approved change management process of its corresponding Controlling Agency (see above). This includes, but is not limited to, the installation or replacement of equipment, modification of security policy, and exceptions to security policy or existing practices.

Fig. 8. Example of a zone definition document for the Safety Zone.

With zones defined, the next stage was conduit definitions. For all connections between two zones, a conduit was defined. Figure 9 (on p20) shows a simplified diagram of the network conduits. Non-network conduits should also be documented (eg: information transfers by USB drives between zones, or dial up modems).

Fig. 9. Defined conduits in the refinery: For all connections between two zones, a conduit was defined. This is a record of approved connections and data flows (channels in ANSI/ISA-99) between zones.

Implementing zones/conduits

The final stage is to select technologies to secure the conduits and zones. Some industrial security appliances are engineered specifically to support this defence in depth strategy, and are ideal for ANSI/ISA-99 zones and conduits deployment.

On start-up, any industrial security appliance should be 'plug and protect' ready. Some can be fine-tuned by installing firmware modules that implement security features, such as firewall, asset management, VPN and content inspection of particular protocols such as Modbus or OPC (Fig. 10 on p20).

Fig. 10. Securing the conduits and zones with firewalls and VPNs: A firewall simplies building intrinsically secure networks since it automatically blocks and reports any traffic for which there is no 'allow' rule

In an ANSI/ISA-99 zones and conduits deployment, industrial security appliances can be installed in each conduit identified - then a firewall module can be activated in each appliance to allow filtering of all traffic passing through that conduit. The firewall simplifies building intrinsically secure networks because it automatically blocks and reports any traffic for which there is no 'allow' rule.

Testing and managing

The next stage is to test the architecture and implementation. This includes not only making sure the deployment blocks attack, but also ensuring that the operation of the industrial process is not adversely affected by the security deployment. Ideally, the industrial firewall's configuration tools should be designed to match the needs of control engineers responsible for configuration and testing. Good security tools make it very easy not only to configure firewall rules, but also to test them before they are implemented. This is essential for safe deployment of a firewall or VPN in control networks.

One solution is a 'Test' mode that transparently bridges all traffic through the firewall, but reports any traffic that would have been blocked if the firewall rules had been active. This allows interactive editing and testing of network rules using real network traffic, but with no risk of accidently shutting down the plant. When no more blocked traffic alarms are generated, engineers can then safely switch the security appliance to operational mode.

The final stage is to manage the system on an ongoing basis. Ideally, the multiple industrial security appliances should be managed from a single management console application.

In summary

The ANSI/ISA-99 Standards provide a framework for companies to achieve and maintain security improvements through a life cycle that integrates design, implementation, monitoring and continuous improvement. System integrators and control engineers who become proficient with segmenting control networks for zones and conduits, and who gain expertise with appropriate industrial security solutions, will be able to mitigate cyber security threats that arise from both the push for productivity and Son-of-Stuxnet malware.


White paper on the penetration of control systems by Stuxnet:

ANSI/ISA-99.00.01-2007 Security for Industrial Automation and Control Systems Part 1: Terminology, Concepts, and Models

ANSI/ISA-99.02.01-2009-Security for Industrial Automation and Control Systems: Establishing an Industrial Automation and Control Systems Security Program


2. The Subcommittee on National Security, Homeland Defence, and Foreign Operations May 25, 2011 hearing. 58:30 -- 59:00


Eric Byres is CTO and VP of engineering at Tofino Security Product Group, Belden Inc.
Source: Industrial Ethernet Book Issue 68 / 36
Request Further Info    Print this Page    Send to a Friend  


Analog Devices: Time Sensitive Networking
ICDC: Your best ODM partner
DINSpace fiber optic and Cat 6 patch panels

Get Social with us:

© 2010-2019 Published by IEB Media GbR · Last Update: 24.04.2019 · 38 User online · Privacy Policy · Contact Us