We Need a New Framework for Thinking About ICS and Critical Infrastructure Network Security
By Galina Antova and Eric Cosman
As it relates to threats targeting industrial control systems (ICS) and critical infrastructure networks, it should be completely clear that “the times – they are a changing.” We have entered a new era over the past 6 months – demonstrated by the collateral damage caused by WannaCry and NotPetya, and even more clearly by the deliberate and alarming targeting of the widely used Schneider Electric Triconex safety platform by the Triton malware.
As the times change on the threat end of the equation, change must happen on the security side – and it must happen immediately and ubiquitously. We’re standing at the edge of a very dangerous cliff and we’ve got to change our way of thinking about ICS security before our adversaries can push us over it.
It is time for us to consider a new approach to ICS security – to explore a new technical reference architecture. This is an exercise that requires involvement from multiple constituencies – ICS systems vendors, owners and operators, security teams, security companies, legislative/oversight bodies, et al. Given the complex and diverse ecosystem of players involved, we don’t suggest we have every answer, nor do we claim that what follows is the silver bullet. That said, we do believe that what we’re suggesting will be a good step – or even leap – forward.
Before we address thoughts on what to do, let’s make sure we understand where we’re coming from. We’re dealing with a space that has for far too long spoken of what is possible in terms of cyber threats – applying great imagination and some pretty spot on analysis of potential negative outcomes – while at the same time doing very little to evolve itself to counter those possibilities.
Until recently, the threats haven’t been large in number or quick in pace and those that have manifested have been isolated in terms of impact. As a result, cyber readiness for industrial systems has remained stagnant. That all needs to change – we can no longer rely on the warm and cozy feelings provided by “standards maturity” or “checkbox compliance” and we must recognize that from a technological perspective, we need to rapidly evolve as well.
There has been some good work in the standards environment recently. For example, IEC 62443-3-2 defines a risk management approach and brings safety and security together. And IEC 62443-4-1 defines secure product development, while the NIST Cybersecurity Framework and latest NERC CIP standard do a better job of defining outcomes, rather than prescribing specific technologies.
Standards have helped keep the domain from being completely exposed to the growing threat, but standards have by no means kept pace with threat actors. Standards development is painstakingly slow – and asset owner compliance is even slower. Threat actors can, and do, change tactics in weeks – whereas standards take years to develop and implement. Over reliance on standards and the “we’re secure” conclusion this overreliance produces is dangerous.
Further, from a technological perspective, industrial security is caught in old school ways of thinking – driven largely by the standards and a “this is how we did it previously, so it should work here” mindset.
Check in with any major asset owner/operator and you’re sure to find a technological stack that looks something like this:
● A “secure perimeter” – firewalls between IT/ICS networks and the DMZ
● A strategy of “security zones” within ICS networks – which has never really been implemented in most ICS environments which typically have flat networks because it was too difficult/expensive to segment
● Anti-virus protection on Windows endpoints – but traditional anti-virus is dead and the endpoints that this anti-virus is sitting on are running operating systems which are often so outdated that patches – in some cases (e.g., XP) – never come
● IDS systems in place which cannot recognize unknown threats
● Old school vulnerability scanning – dangerous because if you’re not careful, it crashes machines
We need a new framework for thinking about ICS and critical infrastructure network security.
First, we need to recognize that there is a new reality with respect to threat actors, and, as such, our pace of action and change will need to be much more rapid. We now have multiple, active nation-state/APT actors who are determined to conduct stealthy and targeted intrusions. They are actively intruding into the IT networks of their targets in order to find ways into the ICS side of the house. These adversaries will find the path of least resistance – and, when necessary, craft customized threats such as Triton or Industroyer to give them the advantage/outcomes they seek. We also have less sophisticated adversaries who now have access to a wide range of tools in the wild.
Let’s explore some of the important requirements for a new technical approach to ICS security – commandments of sorts:
● You can’t regularly take ICS process/production offline to implement and update security tools
● You can’t run active scanning tools that can crash industrial endpoints or load network traffic on fragile ICS networks
● You have to detect known and unknown threats
● You have to detect ICS-specific threats – there is a small but growing list of threats designed specifically for ICS
●&nbs
p;You have to detect vulnerabilities (CVEs) in the control systems – not just the Windows boxes
● You have to uncover network configuration issues that expose industrial systems
● You have to create segmentation inside your ICS network (e.g., IEC 62443 zones and conduits) and you need to know which ICS assets are talking to each other beforehand so you don’t break pathways and disrupt operational processes
● You have to control and manage remote access – stealing credentials from the IT side of the network and logging into the OT side is an important unchecked attack vector
From a technological perspective, the new ICS security reference architecture includes:
● Total visibility as a foundational element – tools that can show us the entire ICS network, including fieldbus and serial communication – the lowest layers of ICS networks
● We must create zones within the ICS network to contain lateral adversarial movement and keep breaches contained
● We need new passive threat detection technologies that can pinpoint anomalous behaviors and detect advanced threats (flying low/slow) without breaking things
● We have to detect ICS-specific threats – Triton and Industroyer reminded us that you don’t need to exploit ICS vulnerabilities, attackers can just implement the ICS protocol and most controllers will do what they are told without validation
● We have to lock down and closely manage remote access to ICS environments – secure remote access, password vaulting, session monitoring, etc. are key requirements
● IT/OT SOC integration must happen for threat visibility across the full enterprise – we must be able to plug ICS tools into traditional SOC tools such as SIEMs, analytics tools, etc.
The time for action is upon us and we can’t just indiscriminately drop old IT security controls onto ICS networks and hope to succeed. While a successful solution will naturally require equal parts well-trained people, new processes and technology, it will also require an updated reference architecture that is in line with the unique needs of the ICS environments and the modern threat landscape.
About the Co-Author: Eric Cosman possesses more than 35 years of experience in the management of process automation-related technology and solutions in the process industries. Since retiring as a Manufacturing and Engineering Fellow from the Dow Chemical Company, he has been the Principal Consultant at OIT Concepts LLC., providing consulting and guidance in areas such as industrial cybersecurity, system architecture definition and design, technology management and integration planning for manufacturing systems. He currently serves as the Co-Chair of the ISA99 committee on Industrial Automation and Control Systems security.
