What does a quality PLC program consist of? Is it all about documentation? Does it need to be easy to interpret, modify, or troubleshoot? A combination of these things?

This is part one of an ongoing series discussing the benefits of the Top 20 Secure PLC Coding Practices as applied to ICS/OT Cybersecurity in cyber-physical engineering.

As PLC programmers, we use a combination of tools to create a program. Typically, we start with a narrative and equipment specifications or drawings. Depending on the complexity of the program, there may be flow charts, discussions, an endless string of emails, and a dash of creativity involved. Eventually, we end up with a PLC program. During all this, we use vendor-specific programming software to complete the job. 

As we progress from program routine to program routine, from project to project – we often get used to using a certain PLC programming IDE. We start to consider things that can make our lives as programmers easier, and often find ways to manipulate the program to avoid interrupting the process while we fine-tune. Maybe there is a hard limit on how much pressure should be present on a boiler outlet line, but the engineering team has decided to determine the appropriate maximum value during commissioning based on the safe operation of the system as a whole. A common practice as an integrator may be to replace the constant value used as an input for the high pressure limit function block, and use a tag or variable in its place. After all, why not? With a variable, we can adjust the high pressure limit as needed without doing an offline build, or upload to the PLC. We often get used to a certain level of comfort while we’re within the confines of our programming software. At times, it may seem like a walled garden that’s beyond the reach of people that aren’t programmers. If you place a value into a tag in your program, and it’s not shown on the HMI or available on SCADA, its value is likely to remain the same until the next programmer connects to the processor with their IDE.
What if this weren’t the case? What if every variable in your PLC program could be manipulated in the same manner as setpoints on an HMI. Would you and your team program differently?

ICI is currently review the internal programming practices and philosophies that are used to integrate projects across the country. Using PLC Security’s Top 20 Secure PLC Coding Practices as a guideline, we’ve found numerous ways we can update our programming workflow, internal code and programming blocks to facilitate safer, and more secure installations both as a standard programming practice, and through enhanced programming offerings. During the review, we’ve also gained some valuable insight into the culture shift that needs to happen around industry recognized PLC programming practices. When you approach your logic with the idea that the program may not remain constant on a PLC processor once the programming laptop is disconnected, things begin to change.

Returning to the boiler example above, if a remote adversary were to gain access to the network, and they could update the high pressure variable by updating a modbus or Ethernet I/P address, would your operator know the boiler system was compromised? Would your firewall rules prevent this? Would your hardware safety devices ensure the operation returned to a safe state without equipment damage or risk to health and safety?

This example is by no means a comprehensive description of the ways a PLC could be compromised. Attackers may find a way to force a PLC to restart. Are we monitoring the time elapsed since the last PLC cold or warm reset? Adversaries may force inputs into an ON state. Are we alarming when forces are enabled on the PLC? What if that force was for a digital input from a global “alarm reset” button? Would your alarms still function if this was the case, or would the facility remain unprotected? How would you detect this?

There are a multitude of ways we can work toward a culture of secure PLC programming. We may use programming checksums to ensure an alarm is called out when the program in volatile memory doesn’t match the program stored on a flash card. We may create custom function blocks to ensure the state of the PLC’s inputs are consistent with what is physically plausible with the equipment it’s attached to. While many of our PLC’s may lack modern security features, many of them have tools that allow us to realize more secure programming. It’s up to us as programmers to use these tools to provide the ability to verify the integrity of our program.

It is ICI Electrical Engineering’s mission to secure Critical Infrastructure and enrich communities through the safe application of technology. Our ICS/OT Cybersecurity team works with management, operations, engineers, OEMs and integrators across Canada to improve the security stance of your operations and identify the risks and consequences of engineering designs. To discuss this and further topics around applying the Top 20 Secure PLC Coding Practices in your facilities, send us a message or contact me directly on Linkedin.