Over the years, programmable logic controllers (PLC) have been insecure by default. Security good practices have been created and adopted for IT which can be seen in OWASP’s Top Ten Vulnerabilities list and Secure Coding Practices report. However, until recently there has not been an emphasis on the different features in PLCs or SCADA for security or how engineers can program PLCs more securely.  

Most organization’s PLCs were not connected to the internet or anything outside their industrial control systems or other PLCs. However, the new mindset of  Industry 4.0 of the ongoing automation of traditional manufacturing and industrial practice has created more security risks and threats for OT networks. 

Until now most security research that had to do with PLCs was more focused on how to exploit PLCs and how to alter the industrial processes. Luckily insecure PLCs haven’t been highlighted as the key reason for the most recent cyberattacks on industrial organizations. The more common IT threats have been the heart of attacks with targeted ransomware attacks as seen in the Colonial Pipeline attack. Despite only attacking the IT network, the company shut down its OT networks and operations which control its pipelines and distribute fuel as a precaution which resulted in a temporary gas shortage in the United States.  

Another example of a recent breach where OT networks were threatened is the water plant in the city of Oldsmar, Fla. This attack showed the potential risks of a cyberattack and the lack of secure programming practices of PLCs could lead to a physical outcome, in this case, poisoning drinking water. These examples are proof that improved and more secure PLCs will lead to becoming the biggest benefit in preventing a process from getting into a bad state.

Top 20 Secure PLC Coding Practices

As our good friend, Jake Brodsky said in his recent S4x20 talk on Secure Coding Practices for PLC's, “No one learns secure PLC coding at school.” The idea that engineers were expected to come out of college knowing the best practices for programming PCLs is a misconception in the industry. According to Jake, there is a massive knowledge gap for the typical engineer who is tasked with programming PLCs which is resulting in more troubles for different ICS security businesses.

The eye-opening talk was the initial spark to create the Secure PLC Programming Practices Project by Jake Brodsky, Dale Peterson, Sarah Fluchs and Vivek Ponnada and is hosted by the ISA (International Society of Automation) Global Cybersecurity Alliance. This new security initiative offers a free downloadable 44-page document that outlines the 20 best practices for engineers that program industrial controls and help improve the security of their systems. Little or no additional software tools or hardware are needed to implement them. They can fit into normal PLC programming and operating workflows. 

These are tips and tricks for catching and avoiding problems during the whole lifecycle of the PLC and the application. One of the main goals of this initiative is that PLC vendors will start to integrate or provide templates with their product training to help customers employ these practices when programming their devices.

Here are the key best practices from the list that we feel relate the most to OT security:

Validate and Alert For Paired Inputs/Outputs

If you have paired signals, ensure that both signals are not asserted together. Alarm the operator when input/output states occur that are physically not feasible. Consider making paired signals independent or adding delay timers when toggling outputs could be damaging to actuators (for example, asserting forward and reverse together)

This is important for security reasons because if PLC programs do not account for what is going to happen if both paired input signals are asserted at the same time it could result in the PLCs becoming a good attack vector for cyber criminals. By ensuring that both signals are not asserted together it will help to avoid an attack scenario where physical damage can be done.

Leave Operational Logic in the PLC Wherever Feasible

HMIs provide some level of coding capabilities, originally aimed to help operators enhance visualization and alarming. However, the HMI doesn't get enough updates to do totallizing or integration. There is also a latency between HMI and PLC which may interfere with the accuracy of such efforts. Furthermore, an HMI will restart far more often than most PLC equipment. It makes sense to keep such accumulators/counters/integrators/elapsed-time counters and so forth there. The HMI can always receive totalizers/counts from a PLC. Thus the operational logic program should rather stay in the PLC to remain complete and auditable.

This practice is beneficial for security because it allows consistency in verifying code changes. HMI coding has its change control apart from PLC, generally not with the same rigor which does not allow system owners to have a complete view and even losing important considerations. HMI’s do not include “forced signals” or changed value lists as PLCs or SCADAs.

Restrict Third-Party Data Interfaces

To strengthen the security of PLCs, it’s highly recommended to restrict the type of connections and available data for 3rd party interfaces. The different connections and data interfaces should be specifically defined and restricted for third parties to be allowed to have read and write capabilities for the required data transfer.

This practice limits the different exposures to 3rd party networks and equipment while authenticating external devices to prevent spoofing. Additionally, it limits the ability for intentional or unintentional modifications or access from 3rd party locations or equipment.

Trap False Negatives and False Positives for Critical Alerts

OT teams should identify the critical alerts and program a trap for those alerts. Most critical alerts for PLCs tend to occur when they are triggered by different conditions.  In some cases, an adversary will attack OT devices by suppressing the alert trigger which could cause a false-negative or false-positive alert. By setting up a trap to monitor the different triggers of alerts it will allow OT teams to detect the alert state for any deviation. A PLC can react much faster than an HMI and can be far more sensitive to these triggers.

By detecting and mitigating false negative or false positives of critical alerts caused by an adversary attack on OT equipment it will allow OT security teams to have a better understanding if their PLC is accessible and being tampered with.

Define a Safe Process State in Case of a PLC Restart

By commanding a PLC to restart in the middle of a working process, there shouldn’t be any issues when it comes to disruption to the process.  Make sure that the process it controls is restart-safe. If it is not practical to configure the PLC to restart-safely, you should define safe process state alerts to ensure that the Standard Operating Procedures (SOP) have clear instructions for setting the manual controls so that the PLC will start up the process properly.

By defining a safe process state it eliminates potential unexpected behavior. The most basic attack vector for a PLC is to force it to crash or restart it. For many PLCs, it is not that hard to do, because many PLCs cannot cope well with unexpected inputs or too much traffic.  For example, the SCADafence research team found a remote CPU DoS vulnerability in Mitsubishi Electric iQ-R Series. This would allow an attacker to send a short burst of specially crafted packets over the MELSOFT UDP protocol on port 5006, which causes the PLC’s CPU to get into fault mode, causing a hardware failure. The PLC then becomes unresponsive and requires a manual restart to recover. This may be uncommon, but it is a basic attack vector if we take into account the malicious behavior of an attacker.

Using The Top 20 Secure PLC Coding Practices

In summary, at least half of these programming recommendations can be summarized as “Validate your inputs.” Many PLC programmers just assume that something physical doesn’t need to be validated. But it is possible to force inputs and it is possible for an HMI to push invalid data to a PLC. Plan for it.  

The Top 20 Secure PLC Programming Practices is a great best practices guide that is the work of hundreds of PLC programmers, engineers, and security experts. This is a must-read for every OT security professional and PLC programmer, it is a specific guideline for coding a programmed PLC to help avoid a potential cyber-physical attack.

You can download the Top 20 Secure PLC coding practices document at www.plc-security.com.