Implementing Security In Industrial Automation and Control Networks, Part II
The ISA-99 standard provides a security framework for industrial automation and control systems (IACS).
By: Kristin Lewotsky, Contributing Editor
Part one of this article discussed network security techniques like network segmentation, role-based control, and firmware-level implementations of security keys. In part two, we review ISA-99, a security standard designed for industrial automation and control systems (IACS).
Networking can bring big benefits to industrial systems, including simplifying maintenance, enhancing troubleshooting, and providing data that can enhance process control and supply-chain management. These capabilities come at a price, however. Linking the factory floor to a larger network not only exposes the shop floor network to risk, it can eventually make the entire enterprise vulnerable to attack. Increased concerns about the vulnerabilities of industrial automation and control systems (IACS) have led to the development of the ISA-99 standards.
The goal of security is to minimize risk. We can define risk as the product of threat, vulnerability, and consequence. Avoiding risk ought to be straightforward, given the amount of security software available, but in the case of industrial applications it can be challenging. Part of the problem is that the objectives of industrial networks differ significantly from those of general-purpose computer systems. For general-purpose IT systems, confidentiality is the number one priority, followed by integrity and availability. The priorities of an industrial network are the exact opposite: availability is paramount, followed by integrity and then confidentiality. As a result, the usual tools may not work. “It's harder to apply general-purpose IT practices [to industrial systems], so you have to figure out what works to meet the spirit of what's intended," says Jim Gilsinn, Co-Chairman of the ISA99 committee. "One of the things that we really try to emphasize in ISA99 is that safety and overall performance requirements a lot of times trump security. What you have to do is work on compensating controls or at least on understanding the limitations of your system."
ISA-99 provides a framework for establishing IACS security from a component level on up to an enterprise level. The effort involves multiple layers of standards, from concepts and models to specific security requirements for IACS (see figure 1).
The standards furthest along and most germane include:
The first two of these have been released and the third has been approved by the committee and is under revision to address comments received. Drafts are under development for several other of the elements of the work plan.
The overall security problem can be considered as encompassing three primary components: people, process, and technology. The ISA-99.01.01 standard establishes basic language and concepts, as well as laying out requirements such as reference architectures and installation inventories. The ISA-99.02.01 standard focuses primarily on the process of developing an effective security program, along with addressing the people factor to some degree. Standards in the ISA-99.03.xx and ISA-99.04.xx series address the technology side of the problem from the standpoint of systems-level and component-level requirements.
The ISA-99 standards essentially view industrial or manufacturing enterprise systems at three basic levels: the shop floor level, which involves discrete manufacturing of the type that leverages motion control; manufacturing operations management, which involves the computers that coordinate manufacturing activities; and top-level systems such as enterprise resource planning, supply-chain management, and business-analytics software. ISA-99 concerns itself exclusively with the bottom two layers. Even then, its scope is broad, but that's necessary to effectively protect the discrete manufacturing level. It doesn't matter if a machine controller, for example, is protected if the system that gives the controller instructions becomes compromised.
The ISA-99 standard uses a five-level reference model, adapted from ISA-95 (see figure 2):
Level 0: equipment under control
When it comes to security, one size does not fit all. Each of the levels features a range of operating characteristics, performance requirements, and vulnerabilities. A smart component may not be smart enough to handle antivirus software, for example, but then again, it may not need to. This is where the concept of network segmentation comes in, in the form of zones. The idea is that you cannot treat the entire network the same because the risk profile for each individual element differs. The standard calls for the data environment to be divided into zones (see sidebar), treating each set of elements differently depending on requirements such as operational needs, safety concerns, etc. Data exchanged among zones passes through a conduit; typically, a firewall.
In the reference model, Levels 0 through III represent the various levels of the IACS. Level I represents devices with real-time operating systems and dedicated function boxes. Typically, data passing from the Level I devices to the rest of the network is considered non-transactional, which means that the devices receiving the data do not confirm that the transaction has occurred.
At the HMI level, the Level II network, data may be saved but it tends to be segregated within a manufacturing cell. PCs running on Linux and Windows operating systems typically reside at Level II. Level III, the operations management level, is where individual cells begin to be integrated together. Level III represents manufacturing execution systems. Level IV represents a point at which communications leave the IACS and progress out into the network to interface with enterprise-resource-planning applications like SAP.
Control techniques and security issues evolve in the structure as the levels increase. Levels 0 and I, for example, feature technologies like PLCs, I/O blocks, and safety systems, which tend to be application-specific rather than built around general-purpose operating systems. At Level II, HMIs may be built around PCs, but overall tend to focus more on dedicated control. Level III and Level IV systems can incorporate modified general-purpose computers, allowing users to apply more conventional security measures, so long as they do it with care. "You always have to pay attention to the real-time nature of control, and the performances and the safety implications, the consequences of what might go wrong if this data is changed or if the system is compromised," Gilsinn points out.
Maintaining a secure environment with Level I and II presents one type of challenge. Integrating it with the top floor networks introduces a whole different level of vulnerability. Depending on the size of the company, the top floor network may support hundreds or maybe even thousands of users. As they browse the network, they potentially make the shop floor network vulnerable unnecessarily. Here, too, setting up zones with conduits can ultimately protect the shop floor network. Ultimately, though, ensuring security requires communication with the IT department.
“One of the themes that runs through the standard is collaboration and cooperation between the controls people and IT people," says Eric Cosman, Co-Chairman of the ISA-99 committee. "It all comes back to that fundamental dialogue between the security expert who understands threats and vulnerability and the asset owners, who understand consequence. Threat is the most difficult to grasp because it's changing so fast, so if you really want to understand risk, you have to get those people talking to each other.”
Part of the discussion needs to focus on a major priority of IACS—performance. One of the fundamental principles of ISA-99 is that security should not adversely affect performance, at least not to an excessive degree. There will, of course, always be some degree of impact, but the collaboration will help strike a balance. The important thing is to address the issue from the very beginning. "Security is not something you can layer on after the fact because when you do that, you run the risk of impacting performance because [the security measures] are being mandated by people who don't understand the underlying process that they’re trying to secure," says Eric Cosman. A directive from corporate IT that all PCs must have virus protection, for example, could shut down the production floor unnecessarily, purely from a lack of understanding. “A machine may run with such tight tolerances that the extra latency of antivirus protection will cause it to fail, but guess what, maybe it doesn't need virus protection if we have put a compensating control in place," says Cosman. "One of those compensating controls may be that we are going to wall the components off in such a way that the likelihood of them getting a virus is miniscule. Now we don't have to worry about virus protection in those components."
In an attempt to simplify the process of developing security, the committee is currently developing a document that outlines how the standards go together. “One of the ideas we've had is to come up with a document that lays out how people at different levels of the food chain may need to look at this document series and work through some of the basic concepts like security assurance levels and how they flow from policies and procedures down to technical implementation," says Gilsinn. “What do you need for your security system? Once you get your security system in place, how do you evaluate it to determine whether it is meeting your needs? The document is intended to give end users an idea of how one document works with another, and to give integrators or vendors a better understanding of how their equipment matches up with the requirements of the end users who come to them wanting to implement the standard."
Speaking of vendors, the standard will eventually set out guidelines for vendor certification, not just from the standpoint of the vendors themselves and their security program but at a device level. "We have a standard that is effectively similar to the Microsoft security development lifecycle," says Gilsinn. The lifecycle model includes an assessment phase, a development and implementation phase, and a maintenance phase.
At the end of the day, the question of security comes back to the priority list: availability and integrity followed by confidentiality. Protecting industrial networks and the equipment they control requires striking a balance between security and performance. As the ISA-99 standards effort proceeds, finding that balance and protecting the system should become easier and easier with every passing year.
Want to monitor the standards effort more closely or even get involved? Join the committee—it's free and you will get updates on all meetings and progress.