Firewall Needed Between AT and IT?

Regardless of where you draw the line in differentiating process automation from IT, the fact of life today is that these two domains are quickly evolving to where they need to interface with one another, including exchanging information and data. This is also apparent when reading and understanding the S-95 standard because it is clear that the different layers need to interact with one another.

Process automation and IT groups need to work together.

Joe Alford 
jmalford5@earthlink.net

A: Not an easy question to answer, and I expect that all companies will have their own view on this. The approach of my employer was to develop the "Converged Plantwide Ethernet Design and Implementation Guide," in conjunction with Cisco, to help define domains of responsibility between automation and IT. You can find the document at www.ab.com/networks/architectures2.html. It won't answer your question explicitly, but it might give you some food for thought.

Vivek Hajarnavis
vivek.hajarnavis@dunelm.org.uk

A: The design should segregate the process control network from the broader IT network. These networks should be separated logically and physically by a firewall. I have found that the best definition is that the IT domain ends at the firewall and the process control domain begins at the firewall. Administration of the IT devices is then the responsibility of the respective groups within their own domains.

However, having said this, we have also found that IT processes are much more tested and rigorous when it comes to administering IT infrastructure. They have years of experience behind their teams, and process control is quite immature in this space. One possible solution to to have a dedicated IT resource for the process control domain, somebody that can understand both points of view.

Emre Eren
emre.eren999@gmail.com

A: This has been the topic of Holy Wars between engineering and IT for as long as I can remember. We continue to move those lines within our plants as technology shifts back and forth. Recent technology involving the migration of SCADAs from PC workstations to virtual machines running on a server threatens to swing it back towards IT.

1. There needs to be a separation (whether this be a physical separation or using VLAN technology) of front-office machines from process-control machines. This is required to keep the patching and software upgrade activities from disrupting manufacturing activities. This also facilitates keeping the plant-floor machines from making connections to the outside world.
2. The operating system security models must allow technical users to have rights to run application software without compromising function.
3. The IT community has a lot of tools at its disposal. It is useful to maintain an architecture on the control side that can take advantage of those diagnostic aids. Islands of control networks, lack of managed switches, etc., can hamper troubleshooting efforts as control system become more and more dependent on network communications.

Joseph A. Ruder, PE, CA
Joseph.Ruder@purina.nestle.com

A: I do not know if there are regulations in place for such a thing, but I do know that usually there is a work around if companies have a standard operating procedure defined. IT and Automation work together to keep company asset working in good order. It is team work and has its own unique challenges. In today's complex systems, no one person can know it all.

In IT world it is referred as DMZ for demilitarized zone between business IT and SCADA IT. All SCADA/BPCS routers and switches are separate and independent.

Hiten A. Dalal, PE PMP
hiten_dalal@kindermorgan.com

A: It's not a black-and-white issue any more, as control systems are no longer isolated islands. Each company gets to decide for itself how to handle this issue. However, people obviously need to be "qualified" for what they are going to be doing. How will you train and qualify your IT people for working on the control system? The reverse is also true; how will you train and qualify your control people to work on IT systems?

Paul Gruhn, PE
pgruhn@sbcglobal.net

A: Process control (PC) doesn't belong in IT. Twenty years ago, some in management thought that computer engineers were the best fit for PC as the DCS started looking like a desktop computer. Of course this idea never really took off as PC is NOT about computer programming.

The database and algorithms running in a DCS are controlling a continuous process, there is no time for "your call is important to us, please remain in the line for our next available representative ..."

No IT group has PC expertise. How could they possibly support a plant shutdown due to a valve that is not responding after a "software or antivirus update"?

IT's place is to support PC, as far as I'm concerned.

Sigifredo Nino
sigifredo.nino@invensys.com

A: There is no absolute answer. The most common structure that has evolved is a specialized group in IT that has knowledge has knowledge of process control and automation and with background has moved into the IT group.