Making automation systems secure remains a large concern for both process manufacturers and automation suppliers. I touched earlier this week on the work of the ISA99 standards effort to address this concern in a collaborative way.
I came across a video in an Intech magazine post, Security top of mind. It features an interview between Intech editor and Talk to Me blog author, Greg Hale, and the supplier’s security expert at their user meeting.
The interview delves into a number of these concerns such as emerging government regulations, the similarities of process safety and security, and learning curves faced by automation professionals.
One thing that caught my attention was the part of the control system and its role living on the IT network. I asked Emerson’s Bob Huba, whom you may recall from a number of cyber-security related posts. He acknowledges the importance of the connection of the control system with the plant local network. Business decisions, which impact the profitability of the process manufacturer, require the information contained within the control system.
Bob felt it should be stressed that control systems have unique needs and should be treated differently to accommodate these needs. This is often a source of great friction between those responsible for the support of the control and automation systems and those responsible for the plant network, firewalls and servers. It’s because the functions look at the world from very different perspectives.
One behavior that he finds particularly troublesome is the idea of treating the control system as just an extension of the enterprise local area network (LAN). By this Bob means the idea that you can just drop a router between the enterprise LAN and the control LAN and then connect all of the Enterprise-level network management applications directly to the devices in the control LAN. This just seems like a great way to open the control LAN to all sorts of security issues.
He suggests that all communications from a control network should terminate at the boundary of the control system and then have to be re-established in the boundary device to continue to the external destination. And this ought to be carried through to the DMZ where the communications again are terminated in the DMZ and are re-established to connect to the full enterprise LAN. There ought to be no direct communications between a control system LAN and an enterprise LAN – for any reason. This includes VLAN tunneling from the enterprise LAN to the control system. Preventing any direct communications from the enterprise LAN is one of the keys to a secure system.
From the automation point of view, robust operation and availability is paramount. For the IT organization, being current on the latest patches, virus scan data files, etc. is critical. Even simple things such as screen saver locks can trigger quite opposing views. For example, if an operator gets locked out and can’t immediately address a plant alarm condition, the results can be very different than if an accounts payable professional gets locked out from their workstation.
As mentioned in the video, for some process manufacturers the ultimate “ownership” of the automation system may be with the Chief Information Officer, but it’s important to recognize the unique requirements and develop the security policies to recognize this uniqueness. Developing a single policy without recognizing the very different role the control system has from the rest of the plant IT infrastructure may lead to operational problems.
One interesting note as I write this post is that my “Security and Patch Manager” window appeared and said it had new patches for me (which elicited my, “Oh Joy!” response.) I would bet at most process manufacturers’ control rooms that this window does not appear on the control system operator screens, at least without the control system administrator giving it the OK to be there.