External vendor connections to your plant network are an often overlooked, high-level vulnerability.

External connections from industrial control systems (ICS) to third-party vendors are becoming much more common. Today, many manufacturers of distributed control systems (DCS) and package PLCs require connections to the ICS for monitoring and data collection or, in some cases, even the ability to remotely configure and connect to the control system. For some applications, the vendor connection may be a choice for the owner/operator of the ICS where, in exchange for allowing the connection, they may receive faster responses and support to troubleshoot issues. However, in other cases, particularly with package PLCs, the third party may require an ongoing connection with monitoring as part of the conditions for the unit warranty, offering little flexibility to the site owner.

External vendor connections, like any other connections to the ICS, provide an additional point of access that could lead to a compromise of the system. What makes vendor connections particularly difficult to control is that the vendor is responsible for securing the devices at their end of the connection, and it is often not possible to enforce the same level of security protections that are in place in the end-user network. 

Vendors make an attractive target for bad actors looking to maximize the “bang for their buck” when it comes to developing and deploying malware. In many cases, a single vendor system can be connected to hundreds of customers or more. The NotPetya and SolarWinds cybersecurity incidents are good examples of how compromising a single supply-chain source can have a multiplicative impact. To protect manufacturing networks from this exposure, you must always secure the connection and evaluate the trustworthiness of the vendor.

Secure the Connection

Although this sounds as if it should be an obvious step, it’s shocking to see how many manufacturing plants accept the typical monitoring and troubleshooting architecture of control system and packaged unit vendors without asking any cybersecurity related questions:

• How is my data encrypted in transit?

• What is done to protect the connection to my network from unauthorized access?

• What steps are taken to secure the network on the other side of my connection?

Any vendor that has a robust cybersecurity program in place should be able to easily provide answers to these questions before allowing an external connection.

The amount of security measures necessary to protect an external connection should be commensurate with the level of risk for that connection. The potential impacts of compromise for a read-only connection that collects data from a historian for monitoring purposes is very different from the level of risk for a read-write connection to the engineering workstation (or in some cases even the L1 controllers) for remote troubleshooting and support.

In a typical reference architecture shown in Figure 1, the vendor connection (red line) has a firewall to control communication between the vendor and the control system. While a single firewall may be adequate for monitoring applications, it often is not sufficient for read-write access from an external network. Ultimately, a cybersecurity risk assessment should be completed for each external connection to understand the potential cybersecurity impact and ensure that adequate protections are in place to achieve a sufficient level of risk.

Where possible, if an external vendor can make configuration changes remotely, it is often best to leverage the existing remote access structure already in place to ensure measures such as multi-factor authentication, change of protocols, and authentication measures (one for accessing the corporate network and a second for gaining access to the ICS network) are in place. If changing the architecture for the vendor connection is not an option, temporarily disconnecting external access for write connections by either physically unplugging the connection or logically disabling traffic when it is not in use can help provide an additional barrier of protection.

Whether the connection is used for monitoring only or troubleshooting, the data sent from the manufacturing network to the external network should always be encrypted. The easiest way is to allow only encrypted protocols through the vendor firewall. For some applications, encrypted protocols may not be available, e.g., only http is supported for the system historian. Alternative methods, such as establishing an encrypted VPN between the site network and the external network, can provide a practical means of securing the data.

Know Your Vendor

Even if the data in transit from the site to the vendor network is encrypted, if the vendor network itself is poorly protected, the data is still vulnerable. Vendors should have robust security programs in place for product development and for how they manage their systems and address vulnerabilities when they inevitably occur.

Manufacturers don’t always have the capacity to conduct a rigorous audit of each supplier, but including cybersecurity requirements and evaluations as part of the vendor selection process is an important first step. Additionally, selecting vendors that have been certified to international standards such as the ISA/IEC 62443 series provides a level of assurance for the maturity level (ISA/IEC 62443-4-1 and 2-4) for product developers and solution developers respectively, as well as for product/system specific security level capabilities (ISA/IEC 62443-4-2 and 3-3).

These standards have been globally adopted across multiple industries and provide a common language and set of requirements for comparing the security measures in place at different vendors and service providers. Specific requirements on the use of cryptography and data protection directly meet the requirements for securing data in transit and data at rest, while also demonstrating to vendors the use of these best practices. Additionally, vendors must demonstrate compliance to requirements for handling security incidents and vulnerabilities. This is important because when vulnerabilities and incidents inevitably occur, having a mature vulnerability management process can be the difference between catching a concern before it becomes readily exploited and conducting a post-incident analysis to understand what went wrong.

A secure external vendor connection relies on the manufacturer and vendor having adequate security protections and security programs in place. Understanding the potential risks of the connection and mapping the protections in place to the risk is a key step in ensuring that the data and critical operations are protected.

By Patrick O’Brien, exida

Patrick O’Brien is a Senior Safety and Cybersecurity Engineer at exida (exida.com) and a member of the ISA Global Cybersecurity Alliance (ISAGCA).

The post "Prioritize Vendor Cybersecurity" appeared first on Efficient Plant