Interested in linking to "Firewall Needed Between AT and IT?"?
You may use the Headline, Deck, Byline and URL of this article on your Web site. To link to this article, select and copy the HTML code below and paste it on your own Web site.
Many Level 3 (MES, MOM) and Level 2 (Control and DCS) systems have specific Windows requirements. Often they are not using the same version as the rest of the corporate systems. There may be operational requirements on the manufacturing software that prevents it from being upgraded at the same time as normal business IT software. Therefore, if IT has responsibility for managing all Windows systems and managing all networks, then there must be the specialized group in IT that has the policies and procedures in place to ensure that the critical systems remain operational and are not handled as other business systems.
If the industrial networks are segregated from the business networks (different domains), then the automation groups may have responsibility for the networks and servers in the automation systems. This works well until the domains must be merged (for common password and account support). Once everything moved to a single corporate domain, the IT department usually takes responsibility for loading the O/S and ensuring that it meets the corporate security requirements (right version, any anti-virus software, etc …).
There are no regulations that I am aware of in the United States. There are regulations that require that the O/S configuration is known and under control, but nothing that states which group is responsible.
In my opinion, the specialized group within IT is the best solution today. The worst is to have the Level 3 and Level 2 systems handled by the general IT group. They may upgrade or shut down the systems because of a lack of knowledge of the applications and their criticality to safety and operations. The second best solution is to have the automation group responsible for loading and maintaining the Level 3 and Level 2 systems. However, in this case, there must be close coordination with the IT group to understand their policy changes and how they will impact the manufacturing systems.
A: There are no standards and no hard and fast rules. Where enterprise IT leaves off and plant controls picks up varies greatly from company to company. There is always a turf war between IT and automation. "We get along great now that I run both departments," said a reader a few years ago in a poll.
This turf war is exacerbated when it comes to cybersecurity, patching and loading of software and updates. The reason for this is that IT and automation are diametrically opposed in their goals. The goal of IT is to protect the data in the servers, and they will cheerfully cut off all the peripherals to do that. The goal of automation is to keep the plant running, and they will cheerfully sacrifice the servers to be able to keep operating. See the problem? IT departments don't see why automated updating and patching can't be done at 6 p.m. every day, because it works in the business IT environment. They don't always realize that doing that risks shutting the plant down and perhaps doing it catastrophically.
If IT insists on enforcing enterprise-type upgrading and patching standards, you WILL have an accident, and it may well have fatalities. There is no reason, however, why you can't train IT personnel to use automation upgrading and patching rules instead. You will have to negotiate this. Once IT understands your needs, they should respond in the appropriate fashion.
A: This is, unfortunately, a controversy in several companies. It always seems to stem from the supposition that IT is responsible for all computers, regardless of application or location. That may once have made sense, but this is a controversy that should have disappeared long ago. Unfortunately, jurisdiction in a corporate environment, once established, doesn't change rapidly. The primary basis for assigning responsibility was once based on the use of a complex and expensive tool – the computer. However, jurisdiction needs to evolve because computers are now ubiquitous. They are everywhere, and almost all functions within a company usually rely on or involve a computer, no matter how tiny, in some way. The primary basis for assigning responsibility should now be based on the function of a device or system, whether it contains a computer or not.
Clearly, a control system involves many technologies and responsibilities requiring the knowledge and understanding of professionals educated in the many complexities and details of industrial control. Those people need to be held responsible for the behavior – all of the behavior – of the control system. The fact that it contains a computer is of no real importance – almost everything contains a computer.
IT should be responsible for centralized business systems, as well as the networking components that impact corporate and business-oriented systems. Also they should obviously be jointly responsible with control organizations for networking interfaces involving control systems, since networking impacts both. So the jurisdiction should be based on functional responsibility and interactions – not on whether a system or device contains a computer.
Lynn W. Craig
A: In our company, it is the controls group that takes care of the DCS, but the regulatory responsibility is not clearly defined. It is logical to have the control group be responsible for DCS, as it is connected to field instrumentation. Also P&IDs, cause and effects need to be built in DCS. Also, the instrument engineers are knowledgeable about measurement and control. In my view the same separation should continue.