Introduction
As stated in a previous article, this year, I had the opportunity to talk on the Main Stage at s4, a 3 day conference, dedicated to ICS cybersecurity, held in Miami South Beach from April 19th to April 21st 2022 and organized by Dale Peterson.
This year’s theme was “No Limits!”. It gave me the idea of thinking about the future of ICS network architectures.
The video of the talk is now available on S4Events YouTube channel: link
So, it is the opportunity to give you more details on the presentation.
Genesis of the presentation
In my engagements at Wavestone, I work a lot on ICS cybersecurity within different companies. These past few years, my work assisting and supporting ICS CISOs focused more and more on network architectures. I have heard a lot these kinds of statements:
- “I need to send data to the Cloud to be able to optimize my production”
- “My plant is operated by an external partner, and I need to connect to its information system”
- “In my line of business, I am required legally and contractually to send this kind of industrial data to a third party”
There are more and more business needs requiring interconnections with the ICS that seem legitimate. Yet, how do we allow these interconnections in a secure way? And can we say yes to everything?
ICS cybersecurity requirements have always been the same. And in terms of network architecture, we always come to the Purdue Model, as well as the zones and conduits methodology. Traditionally there has been a rigidity to what a “secure” ICS architecture is. The Internet tends to be seen as the devil when we talk about ICS.
Well, “No Limits!” made me want to dream a little bit. What if I could start from scratch and build my dream architecture for ICS without any limit?
In my presentation, I compare and contrast the requirements and corresponding secure ICS network architecture of two very different businesses within the same company: power plants and solar/wind farms.
A Tale of Two (very different) Secure ICS architectures
Presentation of the use case
I have been working for companies that have a large variety of control systems:
- Historical businesses: power plants (nuclear, chemical), refineries
- New businesses: solar and wind farms
These various businesses can now be found within the same company.
For these companies, the existing ICS cybersecurity policy needs to be adapted to new usages and businesses. How can we define cybersecurity requirements/rules that would apply to the entire company?
In the presentation, I present in detail the two use cases.
The historical ICS secure architecture
First let’s consider the historical architecture. It follows the Purdue Model, with the good old ICS cybersecurity requirements:
- DMZ between IT and OT network, protected by firewalls (one firewall between OT and DMZ and one firewall between DMZ and IT)
- No direct communication between IT and OT networks
- Protocol break in the DMZ (use of relay servers)
- No local Internet access on the OT network (Internet access goes through the IT network)
When we try to apply the same architecture principles to the solar/wind farm use case, we end up with something that does not make sense:
- OT to OT communications going through the IT network
- Many DMZs and two firewall for each industrial site, even the ones with only a couple of assets on the network
The solar/wind farm secure architecture
So, we try something else and start from scratch. What if we could build a geographically distributed industrial network leveraging SD-WAN technology?
- OT network
- SD-WAN edge with next generation firewall at each location
- VPN IPSEC tunnels between sites
- Filtering rules through the VPN to allow only legitimate flows, such as Modbus for example
- Detection with IDS activation on firewalls
- DMZ in the Cloud
- Mainly a DMZ between the OT network and the Internet directly (we have Internet access without going through the IT network anymore)
- Several firewalls to protect the different zones
- Central services for the OT network
- Bastion for remote access
- Antivirus and update servers: they get their updates from the Internet directly (official websites) through URL whitelisting with proxies and then distribute updates to the OT network through the SD-WAN architecture
- IT network
- Interconnection through the Cloud only with another dedicated firewall
Here are the main differences with the previous architecture:
- We do not go through the IT network anymore to make industrial sites communicate with each other
- We have a DMZ between the OT network and the Internet directly
- We only need one global DMZ for the industrial network
However, be careful. This architecture is riskier than the historical one.
- Maintaining a good cybersecurity level is difficult. Errors can be observed with time on the SD-WAN. For example, we could expose a site directly on the Internet because of a misconfiguration of the SD-WAN edge
- Several requirements need to be respected to protect industrial assets:
- Communications must be controlled from end-to-end.
- Communications are secured based on level and business need: VPN IPSEC tunnels, network filtering, relays when needed, authentication, encryption, detection, etc.
Rigor is key with this architecture. And actually, what I like the most is the fact that cybersecurity basics need to be respected… finally!
ICS classification methodology
Now let’s go back to our initial objective: how can we formalize cybersecurity requirements for the entire company and differentiate ICS secure architectures?
Can we build something around risks?
I present an ICS classification methodology based on a standard risk-based approach:
- Impact: using the standard HSE impact scale of the company
- Likelihood: considering several factors, such as the functionality of the system or its connectivity
With the impact and the likelihood, we can place our system on a risk matrix which gives the classification of the system. In this example, we have 4 classes of ICS.
Then, I apply it to our two use cases. We end up with a different classification for our systems:
- Class 2 system for the solar/wind farm
- Limited impact (2) because there is no HSE risk
- Important likelihood (3) because of the high connectivity of the system
- Class 3 system for the power plant
- High impact (3) because of the HSE risk
- Low likelihood (2) because the system have limited interconnections
So, in our ICS cybersecurity policy, we can have different cybersecurity requirements depending on the classification of the system.
Takeaways
Several factors can be taken into account for an architecture decision:
- What does the control system do?
- What would be the impact of a cyberattack?
- What is the level of exposition of the system?
To conclude the presentation, I encourage companies to launch a taskforce to support projects and build secure architecture for new ICS usages. A good idea could be to build architecture patterns: identify several use cases for the company and build reference architectures based on risk analysis.
However, find the right balance: having different secure architectures for each of your use cases within the company is good, but only up to a certain level of manageability. Indeed, you will have to maintain all these architectures and solutions. So unfortunately, you cannot have as many architectures as control systems!
