20) catch false positives for critical alerts

Identify critical alerts and program traps for those alerts. Set traps to track trigger conditions and alert states.


In most cases, alert states are Boolean (True, False) and triggered by specific conditions, as shown below. For example, the trigger bit for the Overpressure warning becomes TRUE if Condition 1, Condition 2, Condition n are TRUE.

To mask the attack, the adversary can suppress the alert trigger bit and cause a false negation (not firing).

A trap for false negatives (not triggers) keeps track of the conditions for the flip-flop bit and the negative flip-flop bit itself. This simple setup detects a false negative. See the following image:

In other cases, an attacker may deliberately cause false positives to weaken the operator’s attention.

Likewise, false positives can be detected by monitoring the warning trigger bit and fulfilling the trigger conditions. If the conditions are NOT met, but the trigger bit is active, a false trigger is detected, see the following image:

Examples of

Example 1: Siemens offers in its Siemens S7-1200 / 1500 products a web server with a wide range of functions, such as displaying PLC status, cycle time or recording volume. It also has the ability to view and modify data tables and variables. Web server access rights can be changed in the PLC hardware settings. In the event of incorrectly configured access rights, an attacker could gain access to PLC variables and data blocks. To create a false positive, the attacker selects the trigger bit and changes the state.

Example 2: In the Triton / Trisys / Hatman attack, the rogue code suppressed the alert state.

Example 3: A line injection attack can send a false positive alert to a high-level SCADA client.


Reduces false negatives or false positives for critical warning messages caused by an attacker obfuscating them (i.e., rogue code, bus injection, tampering with accessible PLC state tables on unsecured web servers).

About Secure PLC Programming

For many years, programmable logic controllers (PLCs) have been insecure in their architecture. Several years of debugging and applying IT best practices have resulted in secure protocols, encrypted communications, network segmentation, etc. However, to date, there has been little focus on using similar functions in a PLC (or SCADA / DC) for safety, or on how to program a PLC with safety in mind. This project, inspired by existing secure coding techniques for IT, fills this gap.

Who should read and implement secure PLC coding techniques?

These methods were written for engineers. The goal of this project is to provide guidance to engineers who create software to help improve the safety of industrial control systems. These methods use the functions originally available in the PLC. Practically no additional software or hardware is required to implement these methods. They can all fit into the normal PLC programming and operating workflow. The implementation of these methods requires not only experience in the field of safety, but also a good knowledge of the protected PLCs, their logic and basic processes.

What is the scope of this list / how do you define PLC programming?

To be within the scope of the Top 20 Safe PLC Coding Techniques list, the methods must include changes made directly to the PLC. What you see in this document are the top 20 choices from a wide variety of potential methods for secure PLC coding. There are also additional practice projects related to general architecture, HMI, or documentation. They do not fit within the scope of safe PLC programming, but may be included in a future PLC environmental safety list.

What are the benefits of applying the rules in this list?

There are undoubtedly security benefits of using these techniques — in general, they either reduce the number of vulnerabilities or allow for faster troubleshooting in the event of a security incident. However, many methods have additional benefits beyond security. Some also make PLC code more reliable, easier to debug and maintain, easier to communicate with, and possibly more compact. In addition, secure PLC coding techniques not only help users in the event of malicious attacks, but also make the PLC code more reliable to resist accidental misconfiguration or human error.


ProPoll project

A survey of specialists in the field of industrial automation has started, thanks to which we plan to get a general idea of ​​the state of the industry, as well as try to look into the future. Tell us about your experience, which will take you literally 5 minutes.

The results of the survey will be published in the telegram channel @pro_PLC at the end of December 2021. Please help in the dissemination of this survey, share the link in work and professional chats. https://forms.gle/VKNf21VCSPjSXGSa8


I invite everyone to telegram chat and telegram channel for specialists in the field of industrial automation. Here you can directly ask a very highly specialized question and even get an answer.

I am waiting for your opinion and experience regarding this item in the comments. There were a total of 20 items from “Top 20 Secure PLC Coding Practices”

PLC safety: 16-19) Track cycle times, memory consumption, log emergency situations

Similar Posts

Leave a Reply