Just about everything is available online these days—perhaps even your industrial control network. And that is a good thing. Companies are finding that connecting their controls to their enterprise networks opens a treasure trove of information. Management can mine the data for the real-time information that it needs to make competitive decisions. And equipment builders can peer into machinery to provide technical support and other services at unprecedented speeds.
“Leveraging Internet connectivity certainly has huge business benefits, but it has huge risks as well,” observes Dan Schaffer, business development manager for networking and security at Phoenix Contact USA (www.phoenixcontact.com). This connectivity also provides an opening for hackers, industrial spies and errant employees to gain unauthorized access to the nerve center of your operations.
“Having your control networks compromised can expose your trade secrets and put millions of dollars at risk,” Schaffer adds. But tools and techniques do exist for protecting legacy systems and securing valuable assets while allowing business-enhancing access.
In July 2007, the Stuxnet worm proved just how real this risk is. Since the attack, plants have been scrambling to secure their control networks. The problem is that much of the existing infrastructure was built before any- one decided to connect them to the Internet and enterprise networks. As a consequence, many control networks are not designed with cybersecurity in mind. Their designers had assumed that the “air gap” of not being connected to any outside source would continue and prevent unauthorized communications.
The air gap, however, rarely exists today (if at all). Instead, it has been bridged in various ways to take advantage of evolving technology.
“In the past, remote connections to PCs may have been of the simple, dial-up variety, connected only when needed,” says David McCarthy, president of TriCore. “Today, connections may be more open to the outside world via the Internet and are always on.” Shared media, wireless communications and mobile devices are other bridges that defeat the protection provided by the old air gap.
Yet another problem is the controllers themselves and the supporting electronics. “Depending on how old the installation is, the technology often lags by a decade or more,” explains Schaffer. It may offer very little flexibility for doing such things as sign-on authentication and encryption.
Because adding or expanding these features might require upgrades, Schaffer estimates that a newly installed network in a greenfield plant could be as much as an order of magnitude easier to secure than many legacy systems. “You’re designing in security from the ground up, as opposed to bolting it on after the fact,” he notes.
The long-term goal should be to equip the control devices on the network with the same kind of security built into desktop PCs and enterprise networks. “Even though control systems are running real- time operating systems, they still need the same types of protections that you have in the IT world,” says Alan Grau, president of Icon Labs (www.iconlabs.com). “They just need specialized implementations of that technology.”
Grau’s company specializes in bringing those same protections to the real-time operating systems in embedded devices and control systems. Icon Labs’ Floodgate Defender is an embedded firewall that performs static filtering, stateful packet inspection (SPI) and threshold-based filtering.
The software identifies which communiqués are authorized and allows the control system to accept only those that are. Not only does the system ignore all other communiqués, but it also reports any unauthorized attempts at communication to the enterprise system so the appropriate people can take action.
The software reverses the situation where a hacker can detect and communicate with devices without being seen. “Our approach hardens the device so that it’s invisible to hackers,” says Grau. “It connects the control network to the enterprise management system in a way that makes it visible to the corporation.”
So that control networks can enjoy the same protections found in the IT world and enterprise networks, automation vendors have also adapted the IT security technology for the plant floor. An example is the mGuard router from Phoenix Contact. “We’ve ruggedized tried and true technology that traditionally sits in 19-in. racks in air-conditioned data centers,” reports Schaffer. “We’ve widened the operating temperature range and made it resistant to shock, vibration, EMI and RF.”
Conduct a security audit
Whether securing an existing controls network requires you to upgrade devices, configure features that you already have, or do a mixture of both, experts recommend that you perform a security audit at the outset. This assessment should include a review of human factors, as well as the physical infrastructure.
“Do you have security policies in place, and are your personnel trained in them?” asks Grau. “How are your devices connected, and how do they talk to each other? What are your vulnerabilities?”
Answering these questions usually requires a bit of legwork, because the depth and breadth of an existing network is not always clear at first glance. For this reason, you will probably have to walk around the facility to identify all of the devices on the network and all of their connections to each other and the outside world. Tracing cables is a good idea, but not enough. You also have to be on the lookout for antennas and routers that might be tucked behind a bench or other structure.
“Once you identify everything that is connected to an antenna or a Cat. 5 cable, you also have to understand protocols,” says Ben Orchard, applications engineer at automation vendor Opto 22 (www.opto22.com). “Networking is not just about Ethernet, so don’t dismiss serial devices as you’re walking around.”
Another element of the security audit should be an analysis of the communications traffic flowing across the physical wires and Wi-Fi connections. Here, a helpful tool is software such as the open-source Wireshark protocol analyzer maintained by Riverbed Technology (www.riverbed.com). An array of filters in the software permits users to drill into the network and see the packets traveling through it.
Despite these abilities, this analyzer has its limitations. “You end up with thousands of packets, if not hundreds of thousands,” notes Orchard. “And it’s easy to miss devices that may be sleeping and awake only occasionally to transmit their information.”
For these reasons, Orchard recommends using Wireshark as one of several tools for keeping the network secure, using it periodically to “sniff ” the packet traffic to identify authorized and unauthorized users.
Develop a sound strategy
After conducting the initial audit to determine the scope and reach of a control network, the next step in securing it is to put together an action plan. “Typically, the plan should have a phased approach over time,” says Grau. “Start with making sure that your perimeter is secure and then divide your system into secure enclaves.”
To secure the perimeter, experts generally recommend installing a firewall at each connection that a control network has with the rest of the world, and setting the appropriate permissions for communications. An important part of establishing and securing this perimeter is to separate your control network from the corporate network. Depending on their size, some companies separate them by having two distinct physical networks that exchange information through firewalls.
Most end users want to do this without going through the trouble and expense of redesigning the architectures and using routers to break up existing broadcast domains into separate subnets. They tend to prefer instead to add security to the existng architecture. “These networks are typically designed with a flat, Layer 2 architecture,” notes Mike Werning, field engineer at Moxa (www.moxa.com), an industrial networking solutions provider. “In these cases, we segment the network without creating new Layer 3 subnets and recommend using a bridged firewall.”
Werning refers to this kind of firewall as “a bump in the wire” because the communications traffic within a domain simply flows through it, much like a filter in a line transporting a fluid. Both sides of the firewall are still part of the same broadcast domain. On the other hand, a routed firewall separates an architecture into subnets. “In this case, the device serves as a gateway that creates a separate broadcast domain on each side, which isolates Layer 2 broadcasts and multicasts,” he explains.
With the bridged-firewall and conduit approach, the goal is to segment the network into logical zones and then create conduits that connect those zones. In this scheme, each conduit has a bridged firewall and in some cases deep packet inspection to permit only authorized traffic to flow through it. “You don’t have to change the IP scheme,” says Werning. “It can still be a flat Layer 2, but all transactions go through the firewall.”
Establish lines of defense
The protected zones and a layered approach give a control network several lines of defense. Because the firewalls on the other conduits block access to the other zones, a security breach in one zone does not give unfettered access to the rest of the network. The defenses on the other zones buy you time to detect and defeat any attack or unauthorized activity.
An example is the databases and historians used by supervisory control and data acquisition (SCADA) systems. “A common attack is to infect the database through some sort of SQL injection and use that as a launching point to get into the rest of the control system,” offers Werning. “The security for each segment in the network can prevent the attack from spreading.”
Bridged firewalls are not the only tool for segmenting a legacy control network. Routers and routed firewalls can be good tools when establishing subnets makes sense. Virtual private networks (VPNs) are another tool, one that is typically used for securing remote sites. Installing a VPN gateway on the public side of the network provides the necessary encryption and authentication to allow technicians and automation access to collect data and perform upgrades remotely.
Another part of isolating the control network and establishing secure zones, enclaves and subnets is establishing the rules that firewalls and protocol filters use to restrict communications. This task should be implemented in stages, however. “If you try to do it all at once, you’re going to get frustrated and quit,” notes Phoenix Contact’s Schaffer.
You can establish rules that filter communications based on such things as logon IDs, source and destination Internet protocol (IP) and media access control (MAC) addresses, and even type of traffic. “For example, you could specify that a particular HMI and PLC are going to talk Modbus together and allow only that traffic between them,”says Schaffer. Or you could restrict the communications that a PLC has with a SCADA system or a historian.
Before restricting communications among devices, though, Schaffer recommends concentrating first on the access that people have. Although devices may have exploitable security weaknesses, human beings tend to be far more problematic than machines.
The more critical the enclave, the harder it should be to access. Securing its boundary may include erecting mechanical barriers to restrict physical access. For example, you may want to have a fence around a burner that is burning off some gas, in addition to requiring a strong level of user authentication. Other sensible physical barriers include such things as locking control cabinets and turning off unused ports.
“Many times, people worry about sophisticated hackers and nation-state actors,” says Schaffer. “They forget that about 80 percent of cyber incidents are unintentional from the inside. Somebody plugs a Windows laptop into a port that they shouldn’t and knocks out a control system or an HMI.”
Look layer by layer
According to McCarthy, any action plan for securing control networks should take three layers into consideration: the network, the server and workstation, and the application layers. He agrees with Orchard that, at the network layer, identifying each device takes some detective work. For McCarthy, though, the main challenge is to determine its current configuration and make the necessary modifications to secure it without disrupting other communications in the system.
A similar challenge exists at the second layer. “An issue with existing servers and workstations is installing operating-system patches, antivirus programs or other configuration changes without disrupting communications and operations in other areas of the control system,” says McCarthy. These disruptions have the potential for spilling beyond the server and workstation layer into the applications.
The third layer, the applications, presents its own challenges as well. HMIs and other devices, for example, often do not require operators to log in. “One of the first steps in securing any system is to provide and document the correct level of security for users based upon their needs,” says McCarthy. “This usually means operators, supervisors, maintenance all have different security privileges by class and unique login credentials per person.”
Security experts urge users to support their hierarchies and credentials with smart password policies. “Put a password on all of your critical devices,” says Schaffer. “It doesn’t have to be long or difficult to remember to be effective. Something like PM18iagQB! is a very strong 10-character password with letters, numbers and special characters. But when you know that it means ‘Peyton Manning 18 is a great Quarterback!’ it becomes very easy to remember, without using sticky notes on your monitor.”
Another smart password policy is to institute a timer that requires users to renew their authentication periodically, either after periods of inactivity or at some logical interval in the workflow. A smart password policy should also ensure that access privileges are curtailed promptly when employees leave the company and contracts with vendors expire.
Protect program files
Protecting program files for PLCs are another factor in the security equation for the application layer, a factor that is often overlooked. “Whether PLC program files are stored on a shared engineering server, a PC or a laptop, these files are often readily available to anyone who has access to these machines,” notes McCarthy. He suggests restricting access and tracking changes on a secured central server running software like FactoryTalk Asset Centre from Rockwell Automation (www.rockwellautomation.com).
Yet another factor in the security equation is data. McCarthy urges control engineers to take advantage of the security features on historians and relational database management systems. “This ranges from read-only access for specific pieces of data, all the way up to full system administration privileges to view and change everything,” he says.
Besides proper login credentials, McCarthy recommends establishing a procedure for maintaining the integrity of the data and tracking changes. If your data management system does not have change-tracking already built in, consider installing a third-party utility like Omni audit, he says.
Firewalls first
Some security experts believe that installing firewalls should be among the very first actions that users take when securing an existing control network. In fact, Orchard says that firewalls are so fundamental to securing any network that you should not wait to complete a security audit before taking this action. “A security audit can take days, or weeks or even months,” he explains. Because you should install a firewall anyway, doing so while the audit is underway is a prudent measure that upgrades security immediately.
Adding a second, temporary firewall can sometimes help you to gain control over unknowns. “If you’ve inherited an existing system,” suggests Orchard, “a good, immediate step may be to place a second firewall in front of the existing one so that you know exactly what’s going in and what’s going out.” It allows you to turn off login names and passwords for unknown users.
Consider turning off outgoing messages. Although firewalls most commonly block incoming communications, they can block outgoing traffic as well. “If some phone-home code is somehow triggered, then it has no chance of contacting the mother ship and uploading its payload,” explains Orchard.
Blocking outgoing traffic tends to be more practical in plants where the control and enterprise networks are already separate, according to Orchard. He, however, cautions users to weigh the potential for disrupting performance and safety before blocking all traffic, whether outbound, inbound or both. If the potential for disruptions is too great, he suggests logging traffic as an alternative.
