Automation and Process Vulnerabilities in PLC’s and Controllers

There are three Stage 2: Technical Deep Dive Sessions on a new area in ICS security. So new that it doesn’t have a name yet, and perhaps one will be coined at S4x20. This new area is the security is related to the way a process is coded into the Level 1 device, most often a DCS controller or a PLC. Here are the sessions:

PLC Secure Coding Practices – Jake Brodsky

Secure coding practices in workstation and server applications are known to prevent easily identified vulnerabilities. This same issue exists for the people who write code for PLC’s and other Level 1 devices, and most who do PLC coding don’t understand the security ramifications. Like much of ICS / OT it is about 10 years behind good security coding practices in IT.

Jake will provide a top ten list of secure coding practices, such as using the internal PLC integrity features, as well as how to avoid bugs in the PLC code that could be exploited. These are practices for the OT staff to use to review the code with vulnerabilities that may be lurking in the PLC.

It’s funny that Jake is known in the ICS security community as one of the most conservative, not so fast advocates. And at S4x20 he is introducing something new to most of the ICS security community.

Top 10 Deeply Hidden OT Vulnerabilities – Mark Carrigan

Mark approaches this from the other side. What are the deficiencies in the design and implementation of the process that can be exploited to affect the process integrity or availability?

Dale has harped on for years about “insecure by design”. Mark says that many processes are ‘delicate by design’. Some, but not all of the delicacy Mark will discuss, is due to the lack of PLC/Controller security coding practices that Jake will introduce. Idiosyncrasies in the configuration schema that would allow a sophisticated attacker to shut down a control system and even cause physical damage.

The 10 ‘deep’ OT vulnerabilities come from a statistical analysis of 50,000 assets to identify common ‘delicate by design’ attributes that increase cybersecurity risk.

Critical Attack Flow Modeling – Bryan Singer

Bryan was one of the first, perhaps even the first going back to S4x13, to be giving talks and stressing the importance of understanding the cyber/physical connection. He has been preaching “this is an engineering problem, requiring an engineering solution”.

Bryan will present a new model leveraging cyber PHA, attack flow and threat modeling, and Safety Analysis Function Evaluation chart (SAFE), or Cause & Effect (C&E) Table defined in ISO 10418 to present a critical attack flow showing ease of access through the network to individual components such as valves, motors, or actuators, that will result in cyber physical failure. This exposes direct and measurable attack vectors, allowing engineers to properly select control strategies and engineered layers of protection efficiently throughout the environment.

This is more indirectly related to the other two sessions, but I expect the three sessions here will build on each other.