Turn Controllers into Plants’ Bodyguards

Y’all better get used to this beauty: The PLC Security Project’s logo

We tried to turn PLCs, often regarded the achilles heel of automated plants, into the plants’ ubiquitous and unrelenting body guards, one in front of each (back) door.

Why do we need this list?

If the list achieves nothing else, it is supposed to establish a common understanding of what PLC security even means; what we can expect from a PLC that has been “programmed securely”.

What does the document contain?

  • guidance including background info and explanations,
  • examples for implementation (or what could happen if a practice is not implemented),
  • the practice’s “Why”, i.e. a list of benefits, which are always security, but a lot of the times a practice has reliability or maintenance benefits too, and
  • a list of references to standards or frameworks like MITRE ATT&CK for ICS, CWE, or several parts of the ISA-62443 series.

How do these practices improve security?

  • Integrity: This is a big one, and the single most popular security objective for practices on our list. Out of 20 practices, a solid 12 aim at integrity. Which is why we further distinguished them into practices improving integrity of PLC logic, integrity of PLC variables (including timers and counters), or integrity of I/O values.
  • Hardening: This includes everything that involves reducing complexity and thus the attack surface. Two practices fall into this category.
  • Resilience: Practices that ensure a PLC will run robustly in case of errors. Because we were very strict with practices belonging to that category, we only have one practice that has the primary purpose of increasing resilience.
  • Monitoring: This tag marks all practices that recommend monitoring certain values in the PLC that could indicate security problems. The interesting part is that most of these are not classic security monitoring, and all can be implemented directly within the PLC and sometimes HMI, using a PLC’s standard features and particularities. With five practices, this is the second-most popular category.

How were the Top 20 chosen?

Some practices are so basic. Why have you included them?

Case 1: Too basic for security people

  • First, they may feel basic for security experts, but maybe not for PLC programmers.
  • Second, just because the requirement seems basic, its implementation is not always as straightforward. A big portion of the practices rank around implementation guidance and examples.
  • Third, we wanted to spell out which “basic” security requirements a PLC code and configs can actually fulfill, and how.
    There are many myths around security requirements generally not being technically feasible on PLC’s, and while this is true for some, there are others that actually can be implemented.

Case 2: Too basic for PLC programmers

Case 3: Everyone does this anyway

  • Repeating the Top 20’s purpose from above: If the list achieves nothing else, it is supposed to establish a common understanding of what PLC security even means; what we expect from a PLC that has been “programmed securely”. So if there are things that everyone agrees are important for secure PLC coding, they totally belong on the list, no matter how basic.
  • The document is also meant to be a guidance for programmers just getting started on either PLC programming or security or both, and if there are security best practices everyone naturally adheres to, new programmers should have access to this wisdom.

Who did you have in mind while writing the document?

I want to contribute / I found a mistake.

Who is “we”?

What’s up next?

Download the latest Top 20 Secure PLC coding practices document at plc-security.com or follow our project’s twitter account, @secureplc.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store