1 Introduction

The demand for reliable, valid, and secure PLC alarms has been a great concern since the 2000 Maroochy Shire cyber event, Australia [1,2,3]. In the Maroochy malicious attack, an insider was able to suppress the PLC alarms to prevent them from notifying operators and central servers of any threats or abnormalities.

By preventing outgoing alarms from being raised and reported, operators were fooled into believing that the system was running normally.

Though preventing alarms from being raised or being acted upon might not be considered as critical as other threats, it could risk critical devices or endanger human life [4].

Every PLC has a dedicated alarms code that is responsible for monitoring the status of the controlled devices and raising alarms to alert staff in case of any abnormalities or faults.

This paper focuses on identifying and detecting vulnerabilities within the PLC alarms code and introduce countermeasure techniques to enhance the validity and the reliability of the code. A real-time test bed was implemented in ladder logic that was able to detect code abnormalities and prevent possible exploitations.

The rest of the paper is arranged as follows: Sect. 2 provides a brief literature of the Roles of PLCs and other associated dependencies in monitoring faults and raising alarms. Section 3 provides details about alarms and their roles in ICS, structure and organizations of alarms, and the consequences of suppressed or deleted alarms. Section 4 describes a real-time testbed for PLC alarms code. The alarms code was introduced and developed to raise functioning alarms in case of faults detection, mimicking real life scenarios. The exploitation and attacks models are described in Sect. 5. Real-time countermeasure solutions that detected and prevented previously introduced threats are introduced and demonstrated in Sect. 6. A discussion of the results is provided in Sect. 7. General guideline to mitigate and reduce PLC alarms code vulnerabilities are discussed in Sect. 8. Finally, the conclusion is presented in Sect. 9.

2 Related work

Very little work has been done on topics related to vulnerabilities of PLC alarms code. The concerns of researchers have been mostly focused on vulnerabilities associated with general PLC code [5,6,7,8,9,10], non-code related or general alarms analysis and management [4, 11,12,13,14,15,16,17,18,19], ICS networks related [20,21,22,23,24,25], code intrusion and injection [10, 26,27,28,29], security credentials and accessibilities [30,31,32], and general recommendations or surveys [33, 34].

3 Roles of PLCs and their dependencies in alarms

Industrial control systems (ICS), typically, consist of PLCs, human machine interface (HMIs) devices, industrial networks, and field devices. Because of their important roles in monitoring alarms, the following is a brief explanation of each one of them:

3.1 PLCs’ role

PLCs are the main controllers of ICS. PLCs handle several programs that control and monitor other dependencies, activities, and process in a real-time manner. Among those programs, there are associated or dedicated codes to handle alarming messages. A PLC alarms code can be written in ladder logic, function block diagram (FBD), sequential function chart (SFC), or structured text (ST).

The role of a PLC alarms code is to raise alarms whenever faults or abnormalities are detected while monitoring field devices and operations. Once detected, the PLC alarms code sent raises alarms to HMIs to alert operators, see Fig. 1.

Fig. 1
figure 1

PLC flow in capturing and triggering alarms

Full size image

3.2 HMIs’ role

HMIs act like visual aids to operators where any alarming messages raised by a PLC alarms code would be displayed and acknowledged by the operators. HMIs could be considered like a GUI interface of a PLC to operators to check messages and perform manual activities. HMIs could be as simple as touchscreen panels or could be more complex such as server-based ones where they can handle statistical tools, logging capabilities, ladder logic code monitoring in addition to alarming messages and manual activities.

When it comes to monitoring messages, HMIs are slaves to PLCs since alarming message are controlled by PLC alarms code. If alarms within a PLC alarms code are suppressed, no messages would be displayed on HMIs.

3.3 Industrial networks’ role

Industrial networks (such as EtherNet/IP) enable real-time communication among I/O modules, HMIs, PLCs, and associated field devices. If the network is down or slow, that would affect displaying proper alarming messages handled by PLCs.

3.4 Field devices’ role

Field devices (such as limit switches, actuators, drives, etc.) are controlled and monitored by PLCs via industrial networks [6]. If any is faulty the designated PLC would detect that, and an alarm would be raised by the PLC alarms program. However, no alarms would be raised or triggered, if the PLC alarms program gets compromised, which could lead to critical consequences.

The following are examples of some field devices with a brief description of each of them:

3.4.1 Sensors’ role

Sensors send the status of devices and instrumentations to PLCs. Even with highly reliable, thorough, and accurate sensors, any designated PLC alarms program would be not valid and reliable if its code gets compromised; where alarms could be suppressed, tampered with, or deleted.

3.4.2 Actuators and other devices’ role

They are devices that translate received output signals from PLCs into practical operations. Good examples of such devices are actuators, inverters, and servo motors. Most of the time, output commands from PLCs to such devices must also be monitored, so PLCs could verify, stop, or adjust any of their behaviors accordingly. In case of any errors or issues, the PLC through its alarms program would raise alarming messages to alert operators.

3.4.3 I/O modules’ role

I/O modules, such as ArmorBlocks and ArmorStratix, act like hubs that facilitate communications between PLCs and all other devices. They reduce labor costs, wiring, and maintenance costs. PLCs monitor and control all inputs and outputs PLCs through I/O modules; including feedback and status bits that are critical in any PLC alarms program.

4 PLC alarms overview

Alarms including faults, system errors, and warnings are essential indicators in protecting, maintaining, and enhancing automated systems. The alarms are simple to configure and develop in a PLC alarms code and HMIs. Despite their simplicity, they are critical, vital, and helpful in recovering from downtime or preventing damages [4]. Whenever there are any faults or abnormalities, alarms are raised or activated to protect devices and sent to HMIs to alert operators. To be useful and helpful, alarms should cover and monitor the status of all sensors, devices, I/O modules, and other dependencies that a PLC controls. Therefore, a PLC alarms code that handles alarms must be reliable, valid, and thorough. Thorough and reliable alarms would reduce maintenance costs, decrease troubleshooting time, and increase efficiency, and help in statics tools if logged [13].

The following are some useful information regarding the alarms raised by PLC alarms code:

4.1 Alarms levels

PLC alarms can be broken into several levels or groups:

  • System-stop alarms: these are raised whenever there are global, unsafe violations where more than one station is involved. For example: safety gates and perimeter E-Stops.

  • Station-stop alarms: these only stop a specific and certain devices or stations within a cell or a predefined zone.

  • Cycle-stop alarms: they are non-immediate stops that take effect once a cycle is done.

  • Warnings alarms: these are not designed to stop any system or devices but are used to initialize warnings in case of undesired conditions. Though these are not considered critical, they are helpful in predictive maintenance.

4.2 Alarms prioritization

Prioritizing alarms helps in preventing flooding the system with messages and reduce operators’ distractions. When an alarm is raised it indicates an abnormal state was detected by the PLC alarms code in a process, an operation, or a device. Since not all alarms carry the same weight, alarms prioritization must be taken into considerations to reduce distraction and accelerate maintenance response time, see Fig. 2.

Fig. 2
figure 2

Alarms priority based on criticality and time responses

Full size image

The prioritization of alarms is categorized as follows:

  • High Priority alarms: cause critical damage to living beings, environment, equipment, and huge economic losses. Such alarms must be given the highest attention and fastest response time by operators.

  • Medium Priority alarms: Are not as serious and critical as the previous ones. They might cause serious financial loss or deteriorate the life service of devices or equipment in the long or short run.

  • Low Priority alarms: minor financial impact, and less financial loss.

4.3 Supressed or tampered alarms consequences

If alarms within the PLC alarms code were to be suppressed or tampered with, they could cause the following:

  • Risk the safety of workers or even other living beings.

  • Impact the functionality and safety of devices.

  • Impact public and private facilities and infrastructure.

  • Impact the environment.

  • Increase maintenance costs and troubleshooting time.

  • Prevent addressing critical alarming messages.

5 A real-time testbed for PLC alarms code

A ladder logic was developed as a real-time PLC alarms code that could be used as a test bed for several experiments.

5.1 Devices and software used

The following are the main devices and software used to implement the test bed:

  • PLC: Allen-Bradly/Rockwell GuardLogix5570 Safety Controller.

  • Software: Rockwell Logix Designer version 33 to develop, monitor, and edit the ladder logic code.

  • Allen-Bradley EtherNet/IP Network modules.

  • Allen-Bradley ArmorStratix module.

5.2 Developing alarms ladder logic code

A ladder logic code was designed to monitor faulty devices and operations. In the beginning a “Reset” setup code was implemented to clear non-retentive faults whenever it is needed. For instance, by pressing the associated HMI push button (HMI_PB_Reset) of PV01 group, all faults related to that group would be cleared and acknowledged as shown in Fig. 3. If faults were to be acknowledged but not cleared, then that would be a sign of a real-time faulty device that must be resolved. Typically, whenever a field device is faulted, it would be reported to the PLC alarms code where a designated alarm message or tag, such as “- PV01_Arrays_Faulted[0]0.0”, would be enabled, as shown in Fig. 4 and Fig. 5.

Fig. 3
figure 3

Faults reset setup to clear non-retentive alarms

Full size image
Fig. 4
figure 4

Alarms setup for every fault related to PV01 group

Full size image
Fig. 5
figure 5

Example of faults sent to HMI

Full size image

Overall, every detected fault would energize or raise an alarm bit, i.e., triggering an HMI message to be displayed, as shown in Fig. 6.

Fig. 6
figure 6

Monitoring all PV01 related faults

Full size image

Another optional method that relies on FBC (File Bit Comparison) was introduced, based on the previous code setup, see Fig. 5. By using FBC instruction, detecting the occurrence of faults would be easier.

6 Case study: introducing real-time attack techniques to exploit vulnerabilities

A case study based on the previously described test bed was introduced to expose vulnerabilities within the PLC alarms code using a variety of exploits. The main target was how to detect if any or all alarms within the PLC alarms code can be suppressed or modified.

Adversaries might suppress, delay, or delete alarms raised by a PLC code to evade detection to cause damage and disruption. Suppressed or inactive alarms prevent real-time notification messages which in turn could mislead operators, delay maintenance, increase financial loss, risk the safety of ICS systems, or even jeopardize human life. Bad code practices can also result in disruption to processes and cause damage.

The following is summary of the main vulnerabilities scenarios that might be exploited:

  • All devices are functioning properly and reporting all abnormalities to the designated PLC but their alarms within the PLC code are deactivated, deleted, or tampered with. So, the PLC would be getting all statuses of devices and operations, but alarms would not be raised. That would be a sign of suppressed alarms within the PLC code.

  • Alarms are getting delayed or skipped because of code modifications. That could reduce productivity, increase maintenance costs, or even risk the system.

  • Alarms are faked to deceive operators, risking the safety of the devices.

  • PLC alarms code is valid and legitimate, but not receiving any faults from faulty devices. This could be due to physical problems, networks issues, or wrong configurations.

To mimic a malicious code attack where hackers would exploit vulnerabilities of a running PLC alarms code, real-time exploitation techniques were introduced into our test bed and applied without stopping any process or recompiling any routine. The attack models were stealthy and ran without being detected or noticed.

The following are four real-time attack models used to exploit PLC alarms code:

6.1 Skipping or deleting alarms code

One of the techniques used in skipping some alarms or all alarms, was by embedding a “JMP” Jump instruction, named “LBL01” and “LBL” instructions, named “LBL01”. The CPU skipped scanning all alarms rungs (code lines) that are between “JMP” and “LBL” without energizing or raising any alarms bits within that range, see Fig. 7.

Fig. 7
figure 7

The logic code between “JMP” and “LBL” is skipped

Full size image

The logic would not know whether skipping a code using “JMP” was legal or not. Therefore, operators would not be notified, and the skipping would not be detected.

6.2 Slowing down the scan cycle of the PLC alarms code

Slowing down the scan time of the PLC alarms code means that the code was modified either by adding more code elements or suspicious loops. Some embedded finite loops would significantly slow down logic response for highly critical situations, or they might lead to a faulty PLC scenario.

To slow down a scan time, a single “FOR” instruction was embedded to call another routine several times, looping for.

500 times, see Fig. 8. Once the looping started, the scanning of the logic code was slowed down and then the PLC was faulted. When the number of loops was reduced to 300, the scanning of the logic was slower than normal but without faulting the PLC.

Fig. 8
figure 8

Embedding a “FOR” to slow the scanning time of the code

Full size image

The PLC was not able to detect or report to the operator any slower scanning of the PLC alarms code.

6.3 Deactivating or suppressing alarms

In this test, the alarms were suppressed when a single Boolean instruction, “Always_OFF”, that was set to false (zero) was embedded before the energizing the alarms, as shown in Fig. 9.

Fig. 9
figure 9

Faults were deactivated when ANDed with a false bit

Full size image

When the “Always_OFF” bit was ANDed with any precondition instructions, like “SysReady”, the rung condition-out result was false i.e., all its output coils de-energized.

In other words, whenever the result of the rung-condition-in was false, the result of the rung-condition-out was false as well, i.e., suppressing all associated alarms, as shown in Fig. 10.

Fig. 10
figure 10

Suppressed or Deenergized faults means values are set to zero

Full size image

The PLC in this scenario would not detect any abnormal code behavior because all syntaxes and code elements are legal.

6.4 Faking alarms

The alarms in this scenario were faked rather than being skipped or deleted. Faking alarms would be difficult to detect.

To counter such scenario, a flash bit called “Flash” was created based on the code of couple timers, as shown in Fig. 11. The “Flash” bit acted like a fluctuating false that occurred every predefined duration (toggled ON/OFF every few seconds). The “Flash” bit was placed before energizing alarms to fool the operators that alarms were active and occurring occasionally in a normal way, see Fig. 12.

Fig. 11
figure 11

Create a flashing bit using timer on delay instructions

Full size image
Fig. 12
figure 12

Misleading diagnostics by adding a flashing bit

Full size image

7 Countermeasures

The following are the real-time methods that were implemented to detect and prevent the attack models introduced in previously:

7.1 Method 1: a scan time countermeasure against skipped or deleted code attack

7.1.1 Scan time overview

The scan time of a code is the amount of time the CPU would take to scan the code within a scan cycle. Since the scan time value would be affected by any code modifications, storing a scan time value (or average of several one) and using it as a reference point would be a reliable and effective approach.

To do that a ladder logic code was developed and embedded within the PLC alarms code to capture the scan time value of the running PLC alarms code under normal conditions.

The average of several one was computed and stored as a reference point. It was proven that whenever portion of the code was skipped, the scan time was faster than the average, and vice versa.

By using comparison instructions further logic scanning would be stopped and staff would be warned whenever a scan time value is not within the range of the average one.

7.1.2 Developing scan time code

It turned out that capturing the scan time of the PLC alarms code or any other specific routine is not a direct built-in feature in Rockwell PLCs. Built-in timer instructions were not applicable when capturing microseconds intervals. To circumvent that, a “WallClockTime” object of a GSV (Get System Value) instruction was used, see Fig. 13.

Fig. 13
figure 13

Capturing a starting point of a scan time

Full size image

The “WallClockTime” is an ongoing global timer that provides timestamps scheduled by the controller. A “WallClockTime” object was added to the beginning of PLC alarms code to timestamp the starting point of every initial scanning of the code. Then the captured timestamp value was stored into “_PLC_Time[0]” array, as shown in Fig. 13.

Another “WallClockTime” object was added by the end of the code to capture its timestamp. That captured time value was stored into “_PLC_TimeNext[0]”. By subtracting the values of the two arrays, “_PLC_Time[0]” and “_PLC_TimeNext[0]”, we were able to get the time that the CPU took to scan the PLC alarms code within one cycle. The scan time captured was stored into “PLC_TimeResult[0]”, as shown in Fig. 14. As the CPU keeps scanning the code, a new scan time value was captured with some marginal variances.

Fig. 14
figure 14

Capturing the scan time by the end of the routine

Full size image

To get more accurate result with less discrepancies (such as clock latency), several more scan time values were captured at several instances and stored within a group of arrays, from [0] to [9], as shown in Fig. 15. That was done by using a “FIFO” instruction, see Fig. 16. The average of those stored values of each scan time was calculated using “CPT” (Compute) instruction, and the result was stored in “ScanAverage” array, as shown in Fig. 17.

Fig. 15
figure 15

Capturing several values of the scan time

Full size image
Fig. 16
figure 16

Using a “FIFO" to capture several values the scan time

Full size image
Fig. 17
figure 17

Getting the average time of ten scan time values

Full size image

The code is scalable and could get more enhanced if more reliable and accurate value of the scan time. For instance, by capturing and storing more scan time values during longer duration with different event the average would be accurate.

7.1.3 Using scan time to detect skipped or deleted alarms code

This method was introduced and tested to detect skipped or deleted alarms by checking and validating every scan time per PLC cycle. When a newly captured scan time was less than that of the reference scan average value, then the PLC stopped further code scanning (stop further code execution) and warn operators. After skipping all rungs related to alarms, a new scan time value was captured, “_PLC_TimeResult[0]”. As expected, the scan time was tremendously less than that of the original average value, “ScanAverage[0]” (23 microseconds compared to about 592 microseconds). Several new scan values of the modified code were, as shown in Fig. 18. Then the average of those values was computed and stored in “ScanCurrentAvg[0]” to get a more accurate and stable value, see Fig. 19. By comparing the newly calculated average, “ScanCurrentAvg[0]”, to that of the reference a discrepancy was detected and a warning message, “Warn_HMI_User” bit, was raised to alert operators, as shown in Fig. 20.

Fig. 18
figure 18

Capturing scan time values after logic was skipped

Full size image
Fig. 19
figure 19

The new scan time average of the modified code

Full size image
Fig. 20
figure 20

Preventing further logic scanning

Full size image

The result of the comparison was also used as a precondition to stop further logic scanning, see Fig. 20.

7.2 Method 2: a scan time countermeasure against slower code scan cycle attack

Since embedding more code or finite loops was not detected by the PLC, as demonstrated in the earlier attack model, a real-time countermeasure technique based on a scan time implementation was introduced. The PLC cycle would take more time to finish scanning the embedded code, i.e., increasing the scan time duration.

When “For” instruction (with 300 steps) was embedded within the PLC alarms code, the scan time trap was able to detect that attack based on its scan time duration. Figure 21 shows that the new scan value was above 230,000 ms, significantly greater than that of the normal average value which was around 592 ms. For reliability, several scan time values were captured and stored, as shown in Fig. 22. Then the average of those was computed and stored in the array named “ScanCurrentAvg[0]”, as shown in Fig. 23.

Fig. 21
figure 21

The scan time was significantly increase after inserting “For” loop instruction

Full size image
Fig. 22
figure 22

Several scans time values were captured and stored

Full size image
Fig. 23
figure 23

The average scan time was computed

Full size image

Similar to the previous comparison code setup and techniques introduced in Sect. 7.1, once an abnormal scan time was detected, further logic scanning would not be allowed, and a warning message was sent to operators, as shown in Figs. 24 and 25.

Fig. 24
figure 24

Preventing further logic scanning and alerting staff

Full size image
Fig. 25
figure 25

Another way to prevent further logic scanning using “JMP” instruction to skip certain code

Full size image

7.3 Method 3: a heartbeat bit countermeasure against inactive or suppressed alarms attack

A heartbeat code was developed to verify the validity and the real-time status of alarms. The alarms would be considered invalid if all faults were idle (all ON or all OFF) within a predefined duration of time. The resultant of the faults of each group was tied to a Boolean bit, such as “GroupAlarms05”.

When “GroupAlarms05” had its status idle for 3,600,000 ms, the heartbeat bit, “Heartbeat_OK”, was disabled, as shown in Fig. 26 and Fig. 27. A dead or disabled heartbeat bit was then used to stop further logic scanning and to warn operators.

Fig. 26
figure 26

Heartbeat setup based on alarms within a group

Full size image
Fig. 27
figure 27

Heartbeat setup based on groups of alarms

Full size image

7.4 Method 4: a physical plausibility check to detect faked alarms attack

To detect faked alarms or unnoticed malfunctioning devices, a physical verification of all critical devices and instruments involved must be conducted. A physical plausibility check should be performed to validate whether the alarms are matching real-time status and behavior of field devices.

The following are some of the techniques that should be followed to properly validate the process of verification:

7.4.1 Validate a device operation based on a predefined duration

Validation of the operation of devices and instruments must be based on predefined duration. The operation time of a device should be compared to a predefined or to a previously computed average while physically operating or checking the device. It is not enough to check, for instance, that a locking pin is extending without comparing its operation duration to a specific predefined time. If the behavior of an instrument or a device is taking more than its predefined duration, then the operators should be alerted, and any associated alarms should be raised.

7.4.2 Validate PLC outputs

There should be a handshaking validation between a PLC and the controlled devices (such as actuators) through their statuses. A PLC should validate that an output is sent to the proper designated device by getting the proper expected feedback before running further code. In the absence of a device feedback or proper acknowledgment, associated alarms must be raised. For instance, when a PLC sends a program number to a robot, the robot must send back a matching program number. If both program numbers are not matching, then the PLC should alert the operators and stop executing the rest of related code.

7.4.3 Validate PLC inputs

Validate the inputs of sensors and other monitored devices based on their proper physical operations. For instance, a clamp should indicate an exclusive status which is either “OPEN” or “CLOSED”, neither in between nor none. If the hardware indicates that both are active “TRUE” or both are “FALSE”, an alarm should be reported.

7.4.4 Validate coils or commands

Validate there is no conflict among PLC commands (such as energized coils or outputs) that work in pairs. A conveyor, for instance, should not get a request to move forward and backward at the same time. A pin, for instance, should not be commanded to extend and retract at the same time. Such invalid conflict should be monitored, logged, and prevented.

8 Results and discussion

The main contribution of this paper are the solutions that can be applied to mitigate real attacks on PLC alarms. It was shown how the ladder logic code of alarms could be compromised even though all other field devices, including HMIs, were properly functioning, leading to serious damage. Four attack models within the PLC alarms code were introduced and exploited PLC alarms code. Each one of the attacks relied on modifying the ladder logic of the PLC alarms code by embedding instructions that adversely affected the behavior of the alarms. Real-time countermeasures were deployed and successfully detected and prevented those introduced attacks.

To analyze and verify our previously calculated scan time values, real-time trends that captured and analyzed real-time scan time values were introduced and demonstrated using an experimental test bed.

Each trend captured more than 50 real-time values of the PLC alarms code scan time, “_PLC_TimeNext[0]”. The values were captured and analyzed during a 2 ms interval.

Under normal condition, attacks free scenarios, the values of the captured scan time in our test bed were between 469 and 606 microseconds, as shown in Fig. 28. All those captured values were close to the average that was calculated previously, about 592 microseconds, see Fig. 17.

Fig. 28
figure 28

Capturing several scan-time values under normal conditions

Full size image

Similarly, when the skipping code attack was introduced the scan time value was significantly reduced. The trend diagram provided in Fig. 29 showed that the real-time values of the scan time were within the range of 20 and 23 microseconds. That was close to the average scan computed earlier, see Fig. 19.

Fig. 29
figure 29

Scan-time values during the skipping code attack scenario

Full size image

Regarding the slow scan time attack, the captured real-time values of the scan time was between 1361 and 2700 microseconds, as shown in Fig. 30. That was significantly more than the normal average scan and close to the abnormal average that was computed earlier, see Fig. 23. Similar scan time measurements can be extracted from any PLC alarm code and analyzed to monitor the alarms code behavior.

Fig. 30
figure 30

Capturing several scan-time values when slow code attack was introduced

Full size image

9 General PLC alarms code guidelines

9.1 PLC alarms code best practices

For safer systems and better troubleshooting and recovering, it is recommended that PLC alarms code follow these code practices:

  • Alarms code must reside in dedicated and separated PLC routines to make it easier to authenticate, analyze, and troubleshoot.

  • Raised alarms bits by PLC code must stay set (latched) once they are triggered and only cleared (reset) if faults are resolved and acknowledged by operators.

  • Raised alarms must be logged into arrays within PLCs and sent instantly to designated HMIs where they would be clearly displayed and logged.

  • Validate alarms raised within PLC alarms code with those displayed on HMIs. In some scenarios, a PLC could be triggering the proper messages on its side, but an HMI messaged could be misconfigured.

  • Each alarm configured within the PLC alarms code must have a unique ID or identifier, so it can be properly initialized, set, and tracked. The identifier is a unique fault code that must be considered when implementing the alarms within the PLC code. Each alarm must be clearly displayed on any associated HMIs with its ID and proper descriptive message.

  • Alarms within PLC alarms code must have standards that define naming conventions, tags, and data types.

  • Alarms could be more useful if they are time stamped which would help in knowing the initial root cause of the problem.

  • PLC alarms code should be password protected.

  • A comparison of the PLC alarms code must be performed with a previously validated file should be performed every time the checksum of the PLC is changed.

  • Raising the same alarm (output) in more than one place within the PLC code should be avoided, especially those are OTE (Output Energize) based.

  • Empty branches must not be allowed.

  • Forcing tag values should be avoided since forced bits could be hard to track.

  • Avoid any racing scenarios within the PLC alarms code. Racing occurs when two routines or set of operands of logic are racing against each other.

9.2 Other suggested techniques

9.2.1 A mirror PLC for alarms

In some critical scenarios, adding a duplicate or a mirror PLC would be an effective use of redundancy. The redundant PLC can be used as an external backup for alarms, safety, and other critical routines. The access to a mirror PLC should be very limited and restrained. A mirror PLC can be used also as a real-time reference in checking if there are any code modifications within the primary PLC. If any discrepancies are found, then the operators must be alerted. Also, having a backup PLC would make compromising the code harder on hackers.

9.2.2 Effective usage of HMIs and logs

It would more effective if PLC alarms, abnormal scenarios, scan time values, PLC cycles, etc. are sent and displayed on HMIs. Those charts would and logged information would be used in trends and statistical charts.

9.2.3 Alarms test mode

Enhance PLC alarms code to handle an automatic alarms test mode (ATM) where operators can run it to verify all alarms. When ATM is enabled, the PLC would raise every alarm in a sequential manner and display all of them on the designated HMI. If an alarm is not raised on the HMI, then operators should be alerted.

10 Conclusion

The real-time test bed introduced in this paper exposed some vulnerabilities of the ladder logic code responsible of raising alarm messages, i.e., PLC alarms code.

Four real-time attack techniques were introduced and applied within the PLC alarms code while the PLC was in “RUN” mode. None of the attacks stopped or interrupted the PLC, other ladder logic code, or got detected. All of the attacks could be used to cause serious damage to a PLC based ICS. The attacks were based on different ladder logic scenarios and techniques.

It was proven that the PLC was defenseless in detecting or preventing any of those embedded attacks.

Several effective countermeasure solutions against the described attacks were introduced: scan time code, heartbeat code, and verification guidelines of alarms and designated physical devices.

One of the challenges we faced in this experiment was in capturing the scan time of a fast cycle. The built-in timer instruction provided by Rockwell software were not capable in capturing time intervals within microseconds. To bypass that problem a “WallClockTime” object was used.

As future work, we are working on enhancing and expanding the countermeasure solutions to cover more PLC code scenarios rather than limiting them to PLC alarms code.