Network security for automated production
By Frank Dickman
By Frank Dickman
Virus problems in the office network are merely inconvenient when compared to expensive virus disruptions and unwanted data traffic in a production network. In order to minimize the risk of disturbances and production downtime caused by unauthorized access or malware, one leading manufacturer decided to implement greater security precautions.
Decentralized security philosophy
The traditional office network solution, using virtual local area network segmentation with VLAN-compatible switches, was rejected by the manufacturer as being expensive, complex to implement, difficult to control, insufficiently secure and potentially unreliable in the harsh environment of the plant floor.
“We evaluated different firewall security products under two main criteria. Industrial suitability with, for example, an extended temperature range was particularly important to us. We also needed a solution that could be integrated into our automation component environment as flexibly as possible, and with a low level of complexity,” said Asmund Hey, head of automation technology for ZF Sachs Technical Services.
ZF Sachs, a German manufacturer of automotive parts, ultimately chose a small, industrial module called FL mGuard, from Phoenix Contact, created and developed by Innominate Security Technologies. The hardened product’s Linux-based system incorporates router and firewall capabilities, as well as encrypted VPN (virtual private network) tunnels, filtering incoming and outgoing traffic and other functions to provide layers of distributed “defence-in-depth,” economically and without disturbing production.
Sealing off the office network from the production network was carried out with individual industrial firewalls behind a production firewall to create a multi-layered defence architecture within which critical production lines and individual systems could be doubly safeguarded. Network traffic could be controlled and filtered with a greater degree of flexibility and lower investment/operating costs using distributed industrial firewalls rather than delicate IT network equipment.
A total of 40 decentralized machine networks were implemented, and each of these subnetworks was secured by an mGuard firewall. The automation technology and machine maintenance departments were responsible for the implementation, in co-ordination with the IT department. Along with the use of virus scanners in the production area, the most important measure became the segmentation of the production network into small and manageable machine networks. The assignment was conducted spatially based on building zones with additional Profinet components for individual installations.
Setting up decentralized firewalls
Implementation of the decentralized security architecture was based on a network structure plan. This describes the individual network segments and contains specifications concerning which device is attached to which port, as well as which IP addresses, MAC addresses, firmware version and product designations are given.
“To ensure that the decentralized architecture with 40 individual machine networks did not lead to greater configuration and operative effort, we first developed a basic set of common firewall rules for all subnetworks as an overriding control. The implementation was relatively simple,” Hey said.
For the rollout, the master parameters were read out from a memory chip upon startup and applied to the subnetwork. This meant that most of the requirements were already covered. Only individual rules had to be added for special cases (i.e., for controller access to office server shares).
A three-month introductory and learning phase followed startup, allowing any missing accesses or ports to be included.
“During this phase, we realized how important a careful network architecture plan is. The more time invested here, the smaller the correction effort will be later. We also discovered the advantages of central device management,” recalled Hey, in listing the most important experiences gained during the startup.
Meeting automation technology requirements
Various special requirements were desirable and taken into account in setting up the decentralized security architecture. The production facility with Profinet components needed to be sealed off from disturbances from the network. The “8HP” (a torque converter for eight-gear automatic transmissions) required TCP/IP communication on the level of Profinet protocols, so multiple IP addresses were managed and clear segmentation was provided for the fieldbus components.
As a jitter period of less than a microsecond was necessary for the response time behaviour of critical components, these were consistently sealed off from disturbances such as those caused by a typical IT network broadcast. A dedicated network segment was reserved for the 8HP. A further requirement was 1:1 NAT (network address translation) for DNC (distributed numerical control) machines. This concerned the software for the distribution of the DNC programs running in the office network. Since the mGuard components support 1:1 NAT, no adjustments to the internal address space of the machines were necessary for the software.
Setting up port forwarding was a further important requirement, as central databases had to be accessed from the outside in the plant stations. Strict outgoing rules were also necessary. The spatial separation of plants leads to a distribution of the software and process data, which must then be centrally merged again on a server. Access to the central server is enabled through rules in the central firewalls, but any other uncontrolled access is prevented.
Decentralized firewalls have demonstrated increased security
The mGuard security solution has been used at ZF Sachs for two years now. The decentralized firewalls in new plants and in plants with Profinet components are now equipped to protect against disturbances.
“The decentralized networks run smoothly. There is nothing that halts the automation technology, and operation continues largely without maintenance. We also successfully protected several older machines without virus protection from disturbances and attacks. Thanks to the segmentation, any virus brought in by a technician has not been able to spread into the network,” said Hey.
And he has evidence, as the virus problems continue to be present in the office area and in old machines without firewall protection. Hey emphasizes that a secure production flow is also guaranteed when other network components fail. If this is the case, the firewall protects the plants from disruptive broadcasts or defective packet transmissions.
“The experiences we’ve had with the launch, operation and the security standard attained through the decentralized firewalls have all been very good. This is probably also due to the excellent support provided by Innominate. The response times are short, and if we have ideas or improvement suggestions, these are normally included in one of the next versions,” he said in describing the collaboration.
Further improvements are underway
ZF Sachs is now is setting up a central administration for their machine networks. Goals include standardization, uniform configuration and easier administration. Innominate Device Manager (IDM) software is being introduced to provide status information of all mGuard components via central monitoring. New configurations or updates can then be distributed centrally from the IDM to individual or groups of firewalls using template and inheritance technology.
Another new project uses mGuard technology for remote maintenance access and internal design testing. The mGuard devices can provide secure remote maintenance access because their capability offers authentication and encrypted VPN connectivity with outside technicians, consultants and customers.
For information about current threats to networked industrial equipment, a comprehensive 18-page White Paper “Hacking the Industrial Network,” is available for download at www.innominate.com. An accessible discussion of “Post-Stuxnet Industrial Security” is also available.
Frank Dickman, BSMAE, RCDD, is an engineering consultant and former delegate to NEMA, TIA/EIA, ISO, CENELEC and the BICSI Codes & Standards Committees. He is a technical consultant to a number of leading data communications firms and is a recognized expert on U.S. and International physical infrastructure network standards. He can be reached at firstname.lastname@example.org.