Agnostic Approach to Securing ICS/OT (SCADA) Systems
ICS/OT devices are typically designed, installed and maintained by people with little IT or Cybersecurity training/experience. Many of these devices have lifespans of more than 20 years. For most of these systems Availability and Integrity are far more important than Confidentiality. These devices may have severe real-world impacts if something goes wrong.
In the past there were two approaches to securing these systems, physical network isolation or expensive vendor specific solutions. Our customer, Public Works Department (PWD) at Marine Corps Base Camp Lejeune, didn’t have the option of a physically isolated network and we had to develop a solution that worked with existing as well as new ICS/OT systems.
Securely hosting ICS/OT (SCADA) systems on existing business networks is challenge for Cybersecurity personnel. In order to better utilize resources and increase visibility of these systems, ICS/OT personnel must be able to access these systems and installing a physically isolated network for them is expensive and not practical for larger environments.
In today’s Cybersecurity world, many customers are looking for the magic bullet or quick fix and with something as diverse and complicated as ICS/OT, there is no one product or software that will properly secure ICS/OT systems. Only a secure architecture and design will work for a requirement as difficult and diverse as securely hosting ICS/OT systems.
RPI Group “flipped the script” and actually made Cybersecurity an enabler instead of a hinderance to operations. We enabled the customer to make decisions based on which ICS/OT devices best support their mission and budget and not be dependent on a specific vendor security solution. In order to do this, we developed a vendor and network agnostic approach employing cryptographic isolation and ICS/OT specific firewalls that not only secures the ICS/OT systems, but decouples Cybersecurity from their operational requirements which empowered the customer to use existing ICS/OT devices while allowing for the opportunity to purchase more secure devices in the future.
Technical overview of the solution
We start with the assumption that all ICS/OT is “bad” (insecure) and we have to mitigate their vulnerabilities by isolating them from the business network and install a firewall in between the ICS/OT devices and the servers in the data center. Inside the buildings you can support any ICS/OT system and this solution begins at the point that the building system attaches to the business network. The building specific ICS/OT systems are hosted on RFC1918 IP addresses and the encrypt/decrypt device is the connection point to the base/hosted network.
The building specific encrypt/decrypt devices are configured to create a VPN hub-and-spoke network to an ICS/OT specific firewall. This encrypt/decrypt device can be any FIPS 140-2 approved, OSI Layer 3 (IPSec) solution. We started with Raspberry Pis running a stripped-down CENTOS configured with OpenSSL, Strongswan, and IPTables. Other systems use already-installed Cisco switches with FIPS validated IPSec cards, and others will use small firewall devices. The final decision on which device is to be used is based on the customer’s budget, operational requirements, and supportability. It is truly vendor neutral, we only establish the security parameters and allow the individual programs to determine what works best for them. These devices are installed in the building network closets and will be the connection point to the base/hosted network.
The firewalls can be any DoD approved firewalls and they are configured for only the specific ICS/OT system they are securing; the firewall can be hardware based or virtualized in the Hyperconverged environment. Once again, the solution is vendor agnostic, as long as the firewall meets the minimum-security standards defined in the accreditation package, the individual administrators can use whatever works best for them.
We chose Nutanix as our Hyperconverged environment because of the performance and reliability that platform provides us, but any virtualized or even hardware-based servers will work. One reason we went with a virtualized environment is to better facilitate future migration to consolidated data centers or even a Cloud based solution in the future.