Implementing Security In Industrial Automation and Control Networks, Part I
| By: Kristin Lewotsky, Contributing Editor
Effective network security requires leveraging techniques like network segmentation, role-based control, and firmware-level implementations of security keys.
With each passing year, motion control systems become ever more networked. Ethernet IP, EtherCat, Profinet, Profibus…the protocols abound, but they all present the same challenge-how can users leverage the benefits of connectivity without making their industrial networks vulnerable? The answer used to be to unplug the phone line unless there was a fault that required allowing support technicians to communicate with the machine. Today, that solution is too simplistic and too limiting. The answer lies in a multi-pronged approach that begins with integrating security at the component level all the way up through system architecture. Let’s take a closer look.
Despite the fact that most computer users take security as a given, a surprising number of Internet-facing industrial controls systems are vulnerable to attacks. For proof, look no further than Shodan. Ostensibly designed by white-hat security experts to expose vulnerabilities, the site allows anyone, including malicious hackers, to execute a variety of searches such as seeking out for devices with "password" as security key, or networks that will authenticate any encrypted key of a certain size, no matter what the content. Take a quick tour around the site and you will be surprised at the types of systems unknowingly accessible to interlopers.
One of the first steps for end-users to follow in establishing a secure network is to work with the IT department. The process may generate conflict, however. Machines may entail service-level agreements that among other things allow outside vendors to access the equipment through the Internet. Meanwhile, in their desire to make the system secure in so far as possible, the IT department may want to wall off the machine or factory-floor network. "The reality is that neither thing is palatable," says Eric Cosman, Co-Chairman of the ISA-99 committee, which is developing a detailed standard for industrial automation and control systems (IACSs). "One extreme is open, unrestrictive conductivity because that's what the business needs to control costs and increase uptime. At the same time, that's fraught with peril. The other extreme is to cut the line and never allow anybody to connect to anything, but that's not going to work either, so the idea of security is how to find a balance that manages risk and business flexibility.”
From the point of view of component manufacturers, security management capabilities need to be built into the device from the very beginning. It seems like an obvious requirement, but it's one that is only now truly gaining widespread recognition. As the industry transitioned from custom components to commercial off-the-shelf (COTS) technology, system designers were quick to take advantage of the speed of integration and the economies of scale, but slower to identify the risks that the shift entailed. “We can operate much more efficiently by moving to COTS, but we need to understand that we are introducing some additional risks," says Kevin Staggs, Engineering Fellow at Honeywell ACS Laboratory. "In the past, with proprietary systems we could put the system in place and it worked until it died, basically. Now that we’re using technologies that require rigor to keep them secure, we have to realize that the threat landscape is always changing. We cannot just say on December 12, 2011 we installed the system and it is secure, because on December 13 when the Microsoft patches come out, the system is suddenly not as secure as it was the day before."
For best results, vendors need to define security requirements and have a security strategy in mind from the beginning. This allows them to incorporate techniques like least privilege, which involves designing a device so that users authorized to log into it can do only a specific subset of tasks and nothing more.
Passwords should be designed in at the firmware level. They should be changeable, ideally requiring the user to define them at start up rather than using a default password. Of course, changeable passwords create their own challenges. They must be stored in the firmware in some way, and in order to protect the device from attacks, that storage must be encrypted.
“Vendors and product developers need to follow good security practices from the ground up-security has to be something that you build in, not bolt on,” says Jim Gilsinn of the U.S. National Institute of Standards and Technology, slated to be Co-Chairman of the ISA-99 committee in 2012. Applying security at the component level after the fact may not be possible. Perhaps the devices don't use a general purpose operating system or the performance impact would impair operation of the device. “You're not really going to be able to throw Norton antivirus on a PLC or an I/O block or other small, dedicated hardware pieces of equipment. You can’t use some of the technology that exists in the IT world down at those levels so what you have to do is try to meet the spirit of what you're trying to do. You have to find another way to do that that makes sense for those types of components.”
The various aspects of components-level security risk can be subtle. Devices that communicate on the network in clear text, for example, are vulnerable to eavesdropping. An interloper can monitor the commands on the network, decoding what they mean. Even worse, they could modify them through a man-in-the-middle attack by intercepting and changing the commands going to the device. Clearly, security implementation needs to go beyond components.
Managing risk through network segmentation
Some of the network-level security solutions, such as firewalls, are obvious. Of course, as anyone who has ever used a firewall knows, they introduce delays. That may not be a big deal when you're waiting for a page to print on a home network, but for a 300-bottle-a-minute packaging line requiring milliseconds response times, the types of latencies introduced by a firewall can be unacceptable.
The solution is a hierarchical model that groups devices with similar performance requirements and response times into separate zones, which typically constitute a single network segment. Machine-control devices, for example would constitute one zone and the HMIs that oversee the control equipment would go into different zone.
“We segment networks into zones for a variety of reasons,” says Cosman. “One of them might be that the equipment has extremely tight performance tolerances and cannot handle virus protection and so forth. The programming/data does not change very often and we can control access to it very tightly using other approaches; therefore, we are going to put all of these devices under this set of restrictions into a zone and put a perimeter around and say, ‘We’re okay, we have reached an acceptable level of risk.’ Is it zero, no but it's an acceptable level of risk; there's no such thing as zero risk.”
Modular machinery and work cells lend themselves to this approach. If operations between modules do not need to be highly synchronized, it can simplify security implementation. “A lot of times in paper manufacturing and things like that, they will daisy chain the network together so there's really only one way in and one way out," says Gilsinn. “You have one point at the beginning of the line and one at the end of the line that you have to protect and the rest of it can remain relatively untouched. Doing that actually helps to limit the amount of overhead you've got to deal with for security.”
Ideally, devices need to be network segregated by firewalls or through very strict routing rules. With the right firewall, the system administrator can manage not just what devices can talk to what device on the network, but who can talk with which device by requiring authentication from user seeking to reach the device-level network.
This brings up the topic of role-based access. For any one piece of equipment, a number of different people with specific tasks will need access; for example, a machine operator, a maintenance tech, a system administrator, etc. Equipment designers must clearly define the access afforded to each role in order to permit effective security. Yes, giving maintenance staffers the ability to log into the machine network using a smart phone when they are off-site can help reduce downtime and maintenance costs, but it needs to be handled carefully. The idea would be that the maintenance technician or integrator would have to log into the system to authenticate them. Once they have proven their identity, they would be given a tunnel of access that only supports communication from their access device to the manufacturing network. The tunnel would not allow them to branch out further into the network or make additional changes.
Limiting access is particularly important given that sometimes the danger comes not from malicious attacks but from legitimate users. “When you start looking at cyber incidents over the last 10 years, the large majority of them are not intentional attacks, it's just people doing things that maybe they should know better than to do,” says Cosman. This adds a new layer of challenge to security-not just planning for attacks but managing the human factor. Today, in addition to a physical toolkit, a maintenance tech may well have a software toolkit on a USB stick, which can increase efficiency but also introduce potential vulnerabilities. "A lot of times, your security is focused on people-proofing the system to make it easy for people to do their job right and harder for them to do it wrong," he adds. "You can have all the protections in place-fancy firewalls, network segmentation --but if that device has a USB port on it and somebody picks up an infected USB stick from their buddy, it all goes out the window.”
Just as with the security system on your top floor or even home network, shop floor network security is a process, not an isolated action. It is not enough to implement it at the beginning; it needs to be maintained throughout the lifetime of the machine. Antivirus software needs to be updated; firewall logs need to be monitored. New components introduced into the system need to be integrated into the overall security implementation.
Most important of all, security needs to be addressed. “There's a perception that security is too complicated,” says Cosman. “I think the message people need to understand is that security is a specialty like a lot of specialties and just because you may not understand the nuances or you might consider it to be really arcane is not a reason to ignore it, you can't afford to.” At the same time, it's a matter of balance. "Ultimately, you have to go back to first principles: safety first, then reliable operation, and then finally, you have got to make money.”
In part two of this article, we will take a closer look at the ISA-99 standard and how it provides a framework for structuring and implementing secure IACSs.