What has Ladder Logic got to do with CWE?

This article is an accompaniment to the Top 20 Secure PLC Coding Practices Project (plc-security.com - going live on June 15th)

If you ever implemented Ladder Logic in a PLC, or Function Blocks in a DCS, do you consider yourself a coder? Chances are, even if you started off with modern PLCs & Windows computers, you don't think of yourself as a coder because well, Ladder Logic isn’t like Python or Rust. And if your experience started with Single Loop Controllers, or going back further with electro-mechanical relay logic, annunciator panels etc., you are definitely not a coder in your mind.?We are process & controls engineers, not coders, you say! We build our programs based on PFD, P&ID, Control Narrative, Cause & Effect diagrams, HAZOP & Functional Safety etc., that you might conclude has nothing similar to those coders of web applications that dabble in the world of the OSI model.?But hear me out, PLC programming is coding. Even IEC 61131-3 says so. Maybe we 'troubleshoot' instead of 'debug', write 'logic' instead of 'algorithms', but we are coders in every sense.

Setting aside being pedantic, recognizing that we are coders has advantages. We can learn from IT coding best practices, customize them and add a few of our own to improve the security posture of the PLCs. Purdue Level 1 devices and protocols historically were not built with security in mind but that made them so much more vulnerable with all the increased connectivity, integration with the business network, and known/stealthy pathways to the internet. Then perhaps ‘coding’ PLCs with a focus on security might make their ‘insecure by design’ less of an issue.

Now, let’s say you have your hands on the Top 20 Secure PLC Coding Practices,

·????????If you read the list as a primarily IT person, many of the practices seem like common sense (e.g., modularize PLC code or validate inputs for physical plausibility), but how many years has SQL injection been OWASP #1 risk? Common sense doesn’t always mean the risk is widely understood, meaningfully addressed or accurately mitigated.

·????????If you read the same list as an ICS engineer, some of the practices might sound like they are finding fault (it’s so convenient to leave the PLC in PROGRAM mode because no one needs to put on coveralls and get to the hazardous area where the PLC is, but many cases of malicious writes could be avoided if a PLC is in RUN mode).

·????????And if you are an OT unicorn (ICS knowledge, IT skillset), then perhaps you are following all these practices already. Or perhaps you originated some of these yourself, and contributed to this list. Thank you from the rest of us that can formally use the list to ask vendors & integrators alike that they build the PLC logic with security in mind, to improve the system resilience and to be able to carry out effective incident response when the next OT specific attack is on.

You’ll see that the Top 20 list has both objectives and target groups, with benefits and examples. But I want to highlight the References section where the practices are mapped to ISA/IEC 62443 and MITRE Att&ck Framework, and thanks to the MITRE team’s direct involvement, to the CWE. That brings us the answer to our headline question. Since CWE is about both software & hardware, with “Weaknesses” defined as flaws, faults, bugs, or other errors in software or hardware implementation, code, design, or architecture that if left unaddressed could result in systems, networks, or hardware being vulnerable to attack, this is a perfect fit for what the Top 20 list is trying to achieve. We are coders, and the Top 20 project shows us what to consider in ICS coding, and while we are at it, might as well take advantage of all the community effort that is behind CWE!