Sharing data in the unified enterprise
December 2012, IT in Manufacturing
Ideally, manufacturing and mining enterprises are unified entities with business goals and priorities, which can only be realised through the efficiency and performance of their operational or wealth-creating processes. History bears ample witness to the foolishness of trying to divorce business from operational systems. So, when it comes to sharing information, it is clear that transparency is the key.
But transparency is vulnerable to risks and threats from both inside and outside the enterprise, which makes the provision of information to those who need it more challenging than ever – especially when considering the different needs of process control and enterprise networks.
Deon van Aardt, MD Invensys Wonderware Southern Africa.
Control system industry LAN security recommendations
The best practice recommendation for an industrial control system (ICS) is to separate the process control from the enterprise network, mainly because the nature of traffic on these two is different:
* Internet access, FTP, e-mail and remote access will typically be permitted on the enterprise network but not on the process control network.
* Rigorous change control procedures for network equipment, configuration and software changes may not be in place on the enterprise network.
* If process control network traffic is carried on the enterprise network, it could be intercepted. By having separate networks, security and performance problems on the enterprise network should not be able to affect the process control network.
However, practical considerations often mean that a connection is required between the networks. This connection is a significant security risk and careful consideration should be given to its design.
If the networks must be connected, it is strongly recommended that only a single connection is allowed and that the connection be through a firewall, or better yet, an active intrusion prevention (IPS) appliance. It is also important to establish a demilitarised zone (DMZ) for any data warehouse or data warehouse proxy (recommended for a very secure configuration).
A DMZ is a separate network segment that connects directly to the firewall. Servers containing data from the process control system, which need to be accessed from the enterprise network, are placed on this network segment. Only these systems should be accessible from the enterprise network. With any external connections, the minimum access should be permitted through the firewall. Only the ports required for specific communication should be opened to the external environment.
These are devices or systems that control the flow of traffic between networks employing differing security approaches. In most modern applications, firewalls and firewall environments are discussed in the context of Internet connectivity and the TCP/IP protocol suite.
Firewalls can be applied to network environments that have nothing to do with Internet connectivity. For example, many corporate enterprise networks use firewalls to restrict connectivity to and from internal networks servicing more sensitive functions such as those found in the accounting or personnel departments.
In an ICS environment, firewalls are most often deployed between the ICS domain and the corporate LAN. Properly configured, they can greatly restrict undesired access to and from control system host computers and controllers, thereby improving security. They can also potentially improve a control system’s responsiveness by removing non-essential traffic from the network.
Once the firewall is in place, the next problem is determining exactly what traffic should be allowed. Configuring the firewall to deny all except for pinholes absolutely required for business is every company’s basic premise, but the reality is much more complex. Exactly what does ‘absolutely required for business’ mean and what are the security consequences of allowing those pinholes?
Implementing an intermediate DMZ network is an acceptable approach to enabling communications between a process control network and a business domain network. The DMZ should be connected to the firewall so that specific (restricted) communication can take place only between the enterprise network and the DMZ and between the process control network and the DMZ so that the enterprise and process networks cannot communicate directly with one another. Data warehouse proxies are usually placed in this environment.
Defining the secure process control environment
Looking at what the control system is (what it does, what its intrinsic value is and what its requirements are), we can easily see that traditional IT security techniques imposed on the system impede operability and functionality. The cumulative effect is that continual problems arise in keeping the control system running reliably.
Standard IT security techniques and strategies are not only minimally effective, but can be reckless and dangerous when applied to control systems. This is because IT practitioners apply standard techniques and strategies in the production environment.
The machine functionality between a standard IT business network and a control system network is virtually 180° in opposition. Elements of the two network types look virtually identical, (machine hardware also looks identical when viewing from a high level), but that is where the similarity ends.
The functionality and operation between the two network types are different and not directly or desirably compatible without appropriate security and/or proxy interfaces.
When implementing security for the control system environment, the following should be determined:
* What the total environment accomplishes.
* How it accomplishes the tasks it is assigned.
* What might be done to protect the system, while assisting or improving system and process efficiency?
Defining the layered security model
Industry guidance and policies state that machines have to be buried in layers of security, and this statement is essentially correct. However, implementing traditional security guidance policies in a control system environment is difficult and ultimately counterproductive.
Current industry guidance shows several areas of high security with lessened security requirements in areas that might break the functionality of the system. This guidance is highly fragmented and completely discounts the operation of tile process control or scada system functionality in favour of a belief about what might be secure.
Additionally, there is one outstanding problem with this approach that makes it almost completely and uniformly undesirable and it is that control system networks are seldom laid out so neatly. Normally, parts of a control system may reside in a remote location across a sub-domain, an unsecured WAN or an Internet connection, which leaves it more vulnerable to attack and infection.
Therefore, a systemic approach should be used when reviewing process control networks and scada system environments. The ArchestrA secure architecture reference recommends layered security through multiple firewalls to multiple functional blocks as required. We can no longer look at individual machines needing a particular security profile without it affecting the entire enterprise. To accomplish adding security to such an environment, it is necessary to apply security as experts recommend, but with an additional requirement: only one point of ingress/egress to/from the control system.
Information is an enterprise-wide necessity which follows natural tiers of granularity. And so it makes sense to separate the real-time world of the production floor from the transactional environment of business processes because they each have their own and very different network and access needs. Today, we know a great deal about the structuring of firewalls and DMZs in such a way as to provide effective security while allowing the unimpeded flow of bidirectional information for effective decision support at all levels of the organisation.
For more information contact Jaco Markwat, Invensys Operations Management, +27 (0)11 607 8100, email@example.com, www.iom.invensys.co.za