WWHF2019: Architecting Secure ICS Environments
Update: Architecting Secure ICS Environments Slide Deck
On October 24, 2019 I delivered a talk at the Wild West Hackin’ Fest in Deadwood, South Dakota. This conference is primarily attended by information security professionals and businesses with information security teams interested in a hands-on experience. I felt it was an excellent opportunity to provide information about the challenges they will face when implementing and testing security in environments that contain Industrial Control System (ICS) technologies.
When I first started working within ICS environments people were talking about clear text protocols, insecure applications, and devices with a plethora of vulnerabilities. Over time I learned that this situation was common to ICS environments and that the issues were not going to be fixed overnight. In fact, these issues will generally persist until the process or implementation is replaced by a new solution. Even then, there will be instances of all of them in the new solution, depending on business and safety requirements. This might be a bit subjective as everything depends on the goals of the organization; but it is consistent across multiple ICS sectors. To make a difference in this field, I had to learn different ways to talk about these issues and provide constructive solutions that the teams I was working with would be comfortable considering and implementing.
After all, the worst-case scenario for an organization with business models dependent on ICS devices is not a clear text protocol or a vulnerable device. The worst-case scenario is that these devices are directly accessible from the corporate network.
I have been to several locations where the control networks were deployed in a manner that allowed any system on the enterprise network to directly communicate with control network resources: program logic controllers (PLC), human-machine interface (HMI) systems, and the master servers that support them. I have also been to locations where they thought there was isolation but there were holes in the implementation or there was no protection at all.
Improving security within these environments is not going to start by pointing out clear text protocols, insecure applications, or the vulnerable devices. The conversations need to start with how these resources are deployed and protected from interactions with assets that are not associated with the specific process. Process environments already have guidance for implementing process environments so that they are robust and safe. This was originally outlined in the ISA-95 standard. This standard defines levels to help implementers organize the deployment of the process’ devices and the supporting infrastructure. These levels are known as the Purdue Enterprise Reference Architecture, also referred to as the Purdue Model.
While ISA-95 provided guidance for effective process implementation it did not include security guidance. This situation was improved with the initiation of the ISA-99 standard, recently renamed to IEC/ISA 62443. This standard took the Purdue Model and leveraged the natural process boundaries, defined in each Purdue level, to implement security boundaries. Businesses implementing process environments understand this model and they are beginning to wrap their heads around how these things apply to the legacy and future processes. It is here that information security professionals need to focus as these are the techniques these businesses will use to address the clear text protocols, insecure applications, and vulnerable devices.
To help teams understand and plan new environments, or remediate current issues, the SANS team has developed the ICS410: ICS/SCADA Security Essentials course, of which I am an instructor. Within the course, to help students understand the Purdue model we use the following graphic: ICS410 Reference Architecture Model.
This graphic outlines each Purdue level and provides a brief description of the resource that will be deployed at that level. It also details the different enforcement zones and addresses issues such as remote access from the corporate network to the control network. The explanation of each level and enforcement boundaries is too long of a discussion for a simple blog post. But, I’m hoping security professionals and teams can see the approach outlined in the ISA/IEC 62443 a bit better. Using the “worst case” network as an example, here is how I see it updated using the ICS410 Reference Architecture Model.
The ultimate goal being an environment that reduces the impact of clear text protocols, insecure applications, and vulnerable devices to very specific areas. Each being protected from each other and thereby improving their robustness and availability.
Go forth and do good things,
Don C. Weber
Cutaway Security, LLC.
Email: don@cutawaysecurity.com
Website: https://www.cutawaysecurity.com
Twitter: https://twitter.com/cutaway
SANS Instructor: https://www.sans.org/instructors/don-c-weber