How Belden Horizon Stays Secure
How Belden Horizon Stays Secure
If your work environment has changed during the pandemic, you already know the nuts and bolts of remotely connecting to coworkers, equipment, and VPNs in order to still get the job done.
For industrial applications, that’s led to more companies needing a solution that’s stronger than, say, a home WiFi extender, and as secure as possible. We’ve been getting questions about how to use Belden Horizon™, so we put together a technical document with plenty of details about how the remote access service works. Below, see an excerpt about the security of the service. Download the full technical document here!
The Security Factor
Belden Horizon is a tool designed for OT professionals to help improve productivity when troubleshooting machines or a process, or to connect remote assets to a central SCADA system. Given the convergence of OT and IT networks, a secure remote connectivity solution is vital. Belden Horizon uses a multilayered, defense-in-depth approach (aligned with IEC62443) to security to ensure your system is always protected.
There are five layers of security. Let’s look at each one of these layers in more detail.
The outermost layer that needs to be secured is the Physical Device. There are two devices – the ICX35 cellular gateway and the PLX35 wired gateway. Device security includes digitally signed firmware and support for outbound connections only.
Digitally signed firmware means that the firmware file is verified to be from the right source before the device (or gateway) will accept the file. Any firmware change is logged so that it can be exported for future forensic use. The firmware itself is Linux OS-based and is field upgradeable. The firmware is a combination of off-the-shelf open source software and other applications to manage the device. These run continuously on the gateway. Compared to PC-based or server-based remote access solutions, device-based remote access offers a much smaller attack surface and is designed specifically for machine remote access.
The gateway only initiates outbound connections. The gateway does not accept inbound connection except for HTTP, HTTPS, EtherNet/IP™, and/or Modbus TCP messages. All of these can be disabled through the local user interface (UI) configuration. With correctly implemented DMZs (de-militarized zones), all inbound connections can be blocked. To use the gateway in Belden Horizon, we don’t need to accept any inbound connections.
The next layer to be secured is user access - an important security layer. This layer determines how the user accesses Belden Horizon. Since IT and OT networks are converged, the platform supports Active Directory via Single Sign-On (supports SAML 2.0) as one of the login types. Single Sign-On, or SSO, allows IT to add Belden Horizon access to an IT-controlled user list. This way, if a user is no longer with the organization and IT has revoked their login credentials, then the user’s access to Belden Horizon will also be revoked. For OT professionals, support for SSO means that they don’t need to create, save, and remember multiple usernames and passwords. All login activity is recorded in the activity log.
Additionally, the platform incorporates token-based two-factor authentication (2FA). This requires the user to register their Belden Horizon username on a standard authentication app (like the Google Authenticator) for a two-step verification of the user’s login credentials before accessing the platform.
Belden Horizon does support standard login whereby a user has to enter the username and password (simple or complex) with two-factor authentication by email. The login activity will be recorded in the activity log.
Next, device access has to be secure. This layer deals with users initiating a secure connection to the gateway once they are logged into the platform. Logging into Belden Horizon does not allow the user to access the end device like a PLC (programmable logic controller) or a HMI (human machine interface).
A user with administrative access can configure users to access specific projects and/or specific gateways in Belden Horizon. For example, a machine builder may want certain technicians to access projects specific to the customer they are servicing. Another example is an HVAC company with hundreds of gateways at different customer sites – they will want to only give their technicians access to gateways at customer sites for which they are responsible.
Belden Horizon also supports vLOTO™, or Virtual Lockout-Tagout, as part of the device access security layer. vLOTO allows plant personnel to directly approve or deny every remote access request. Multiple personnel can be configured as approvers. vLOTO™ greatly enhances the security of the remote access solution as it allows the end user to be part of the remote connectivity process. vLOTO allows the user to enable or deny remote access at any time – even if a remote user is connected.
For example, when a packaging machine goes down, the SI will have requested to connect to diagnose the issue. The plant supervisor must approve the request to remotely connect from the SI. As the SI is diagnosing the issue on the packaging machine, another major issue occurs on the plant floor and the plant supervisor has to revoke all remote access users for safety reasons. With vLOTO, the plant supervisor knows exactly who is remotely connected to their machines and is able to revoke their access quickly by logging on to their Belden Horizon account from any device. All vLOTO activity is logged, and is available to be exported and saved for future forensic use.
In addition, the device supports IP Allow lists, which indicate specific IPs that the user can connect to.
And, the last part of the device access security layer is connecting to the remote gateway. When the user connects to the remote gateway, an AES 256-bit encrypted tunnel is created between the user and the remote gateway via Belden Horizon.
The platform uses SSTP (Secure Socket Tunneling Protocol) to create the tunnel. SSTP uses port 443, so there is only one port to open and manage.
Dynamic Tunnel passwords are automatically generated - 32-byte one-time passwords per user connection and per gateway. The activity log records all tunneling events.
The next layer to be secured is all of the different data. As stated earlier, the connection between the remote user and the gateway is fully encrypted. Belden Horizon does not monitor, interpret, or store any user application data like a PLC program or a HMI file. Belden Horizon only knows how much data has gone through the tunnel – this determines the user’s VPN data usage. Belden Horizon subscriptions are based on VPN data usage. The communication between the microservices in the platform is end-to-end encrypted, even in AWS. The data at rest in the cloud is encrypted. The cloud security controls are reviewed monthly. To reiterate: Gateway connections to Belden Horizon are all outbound-only, and the gateway and cloud software is reviewed regularly by security researchers.
The final layer that has to be secure is the platform, Belden Horizon. The platform has to be secure and reliable. Belden Horizon leverages the power of AWS to enhance security and reliability. There are multiple regional tunnel servers located strategically around the globe to minimize latency when a remote user connects to a gateway. The tunnel servers are fully redundant: Belden Horizon supports a dedicated data plane for communications between gateways (used for PDN applications), and a control plane for device management and remote user connection.