Programmable Logic Controllers (PLC) and Safety Instrumented Systems (SIS) Controllers have historically included an external switch, generally in the form of a key, to perform maintenance and troubleshooting. The key switch has become commonplace for automation engineers and technicians who maintain and support these systems and understand the importance of the little switch in overall device operation and affects the underlying process.
However, aside from control system and automation support roles, the position of these switches was relatively unknown or largely unconsidered to operational personnel. This mantra continued until 2017, when the XENOTIME activity group compromised Schneider Electric’s Triconex SIS controller. The TRISIS malware deployed to the SIS controller was made possible due to the controller(s) key switch in “Program” mode, which allowed open access for project file uploads and downloads from a compromised engineering workstation. Had the key switch been in “Run” mode, the TRISIS malware attack would not have been successful.
Knowing the current state of the key switch and being able to detect when the position is changed is now the number two recommendation from Top 20 Secure PLC Coding Practices. While the Dragos Platform can detect key state changes, these PLC coding practices add an additional level of internal device detections, specifically for engineers and technicians.
Nuances of Key Switch Positions
As discussed in the Triconix TriStation manual, Triconix uses four different key switch positions to allow for various operational modes and settings for different scenarios:
- RUN—Normal operation with read-only capability. The main processors execute the previously loaded control program. Attempts to modify program variables by TriStation, Modbus masters, or external hosts are rejected. However, a control program may call gated access functions to enable external host writes during a designated window of time.
- PROGRAM—For program loading and checkout. Allows control of the Tricon system from the TriStation platform, including Download All and Download Change. It also allows writes to program variables by external hosts.
- STOP—Stops reading inputs, forces non-retentive digital and analog outputs to 0, and halts the control program. (Retentive outputs retain the value they had before the key switch was turned to STOP.) The STOP setting can be used for installation and service of process-related equipment but is not required for service of the Tricon.
- REMOTE—Allows writes to program variables by TriStation and external hosts. (Download All and Download Change by TriStation are not allowed.) Modification of program logic is not allowed.
Understanding the nuances of the Triconix Controller helps to know which positions should be used during normal operation. For example, Remote doesn’t mean that a project file can be uploaded or downloaded, but the controller will accept program writes from an external source, which can be abused.
Other controller manufacturers, such as Rockwell, use a key switch for the Logix line of PLCs. The ControlLogix PLC key switch has three physical positions but has five total modes of operation. The key switch positions include “Run,” “Remote,” and “Program.” Within the “Remote” position, an individual using Rockwell Studio on an engineering workstation can change the mode to “Remote Run,” “Remote Program,” or “Remote Test.”
Details of these settings by Rockwell are given below:
- Run mode—The controller is actively controlling the process/machine. Projects cannot be edited in the Logix Designer application when in Run mode.
- Remote Run mode—This mode is identical to Run mode, except you can edit the project online and change the controller mode through the Logix Designer application.
- Remote Program mode—This mode functions like Program mode, except you can change the controller mode through the Logix Designer application.
- Remote Test mode—This controller mode executes code, but I/O is not controlled. You can edit the project online and change the controller mode through the Logix Designer application. Output modules are commanded to their Program mode state (on, off, or hold).
- Program mode—This controller mode does not execute code or control I/O, but editing operations are available. Output modules are commanded to their last state (On, Off, or Hold). In this position, controller modes cannot be changed through the Logix Designer application.
Again, as noted in the Rockwell documentation: “Moving the key switch from Run to Remote leaves the controller in the Remote Run mode, while moving the switch from Program to Remote leaves the controller in the Remote Program mode. You cannot choose Remote Test mode by the key switch alone; it is only available via the Logix Designer application.” This little detail causes lots of confusion for technicians unfamiliar with the underlying operation, switching from program to remote, and expecting the PLC code to execute automatically. The key must be changed to Run and then back to Remote for code execution without logging in through Logix Designer and manually making the mode change.
Detecting Status of the PLC Key Switch
Some vendors have leveraged PLC data acquisition for some time through exposed logic instructions, as is the case on Rockwell PLCs, which detects the status of the key switch through the mode variable.
Engineers must start including logic from the design of the project software to inform operations when specific actions are happening, like the position of the key switch. If operators can monitor these actions on the HMI, they could act to immediately inform appropriate staff that somebody could be modifying the PLC logic. Having operations as part of the detection helps to anticipate responses and actions before the logic could even be downloaded to the PLC.
Another advantage of creating detection logic on the PLC is that all the resources are integrated directly from the CPU. There is no need to use additional resources like new interfaces or special software than the project already has. This detection logic lacks complexity, which does not cause any issue on the PLC performance, testing, and development.
When creating these detection functions, engineers should consider embedding them in a function block and adding a special security routine. By doing this, the integrity of the blocks is enhanced by block password protection. In the case of Rockwell, the logic cannot be manipulated while the PLC is running. These and other programming practices will be discussed in upcoming blogs.
Developing Key Switch Change Logic Using an Allen Bradley PLC
As discussed, Allen Bradley PLCs have the capability to monitor the health of the controller by providing an immense amount of internal status data. A Get System Value (GSV) instruction is required to pull the information from the controller and create a combination of the status bits of the controller device object, which reflect the key switch position.
Alarms are then configured as self-clearing or retentive on the HMI side. Alarm settings and configuration should be discussed with the operations team and be evaluated according to the necessities of the underlying process, remembering not all alarms are critical or cause processes stoppage.
The intention of the function is to send the relevant states that are considered alarms to the HMI, as well as the health status of the key when in Run Position is detected, as shown in Figure 1.
It is essential not to cause alert fatigue on the HMI with extra alarms/information that operations will disregard. The fewer alarms with relevant information, the better the response on the operation side. The alarms proposed on the logic are:
Program: This means PLC execution is stopped, and PLC editing functionality is available. The status is also raised when the mode is in “Remote Program.” With either status, there is a risk that the logic can be changed. Figure 2 displays the program mode status detection logic discussed.
Remote: This means PLC is running with remote online editing or download capabilities. This state is the most vulnerable since the PLC can be controlling live operations, and disruption to the system could occur without any notice. Figure 3 illustrates the logic to detect Remote mode.
The logic also contains the status data pulled from the GSV instruction, with the intention to have the code incapsulated within a Function Block. It is worth mentioning that the logic proposed can be used in older PLC firmware versions such as RSLogix V20, leading to the most recent versions. These examples are not part of a new enhancement on the controller but for engineers to exploit the significant capabilities that modern PLC controllers bring to the table.
What If the Function Is Disabled?
To be sure, any logic can be tampered with and disabled. This raises the question: could the Add On (the function block encapsulating the code) be deactivated by an adversary? Perhaps yes. However, one way to notify operations of this potential malicious activity is to use the EnableIn parameter of the Add On as an alarm. The parameter can also be used to lock other devices if the process and operations allow it. For this case, no extra logic is required since the tag is part of the embedded logic.
Disadvantage?
A potential disadvantage is that the key switch must be initialized for the Add On to start detecting data. Therefore, additional logic should be included on the function to flag an alarm and block initial movements after a download or implement policies where the contractors or engineers initialize the switch after a full download.
Key Switch Function Using RSLinx & Predefined Attributes
Allen Bradley also leverages diagnostics variables identified as predefined attributes, which are recognized as @. These tags are pushed through RSLinx to detect the status of the PLC. There are implementation differences, however, such as changes to the PLC logic and HMI if Factory Talk is not being used. Figure 5 shows the list of the Predefined attributes that RSLinx obtains from the PLC.
If the connection with the HMI is FactoryTalk, the communication between them is directly done through FactoryTalk Linx, and the tags are located on the Diagnostics tags of the PLC. On the other hand, if the HMI is a different brand than Rockwell, this connection must be made using a DDE or OPC classic (OPC DA) communication topic through an OPC Server, such as RSLinx classic. For instance, if Wonderware Intouch HMI is being used, a DDE topic is needed for connectivity. However, the use of RSLinx classic is not recommended for applications with high volume data transmission. Further information regarding RSLinx products can be referenced in this online article.
As an example, @Mode is the predefined attribute that can be used to display the multistate key switch status in string format. This forces users to create custom code on the HMI side by developing scripts and/or macros to generate an alarm when remote and program mode is detected. As a best practice from both an engineering and security perspective, using code on the HMI should be minimized. Scripts and macros are easier to reach on an HMI project than PLC logic, and they are also easier to manipulate from an adversary or internal entities without raising alarms on the system.
Figure 6 shows monitoring the key switch from a Wonderware client HMI. A combination of PLC logic and RSLinx predefined attributes is being used to generate an alarm and status. Additionally, the Predefined attribute is leveraged to display the position of the key using character values. In this example, the alarms are configured as self-clearing, and the communication between Wonderware Intouch and PLC is done using a DDE Topic.
Figure 7 is an example of monitoring the key switch using PLC logic and the predefined attributes on a Factory talk Client HMI. In this example, the communication is done natively using FactoryTalk Linx, and the alarms are configured as retentive.
Conclusion
It is essential for technicians and engineers who develop PLC programs to be aware of the existent risks when key switch monitoring is not established. Engineers should learn the inherent capabilities that PLCs and their communications can bring to help monitor the key state for Security Operation Center (SOC) teams and operations at the plant floor using devices from Levels 1 and 2 of the Purdue Model. By doing this, operations are immediately aware of their critical device status and do not have to wait on IT/OT SOC teams to notify them of adversarial behaviors. Because operations know the status of plant maintenance windows, they can anticipate actions and alert incident response teams when critical PLC key switches are placed out of the healthy state during operation.
Although multiple detection options exist, which appear easy to implement, it is crucial that engineers always analyze pros and cons, and try to implement, when possible, the functions in the PLC. Furthermore, these functions should be applied in a dedicated security routine, which is separate from the control routines. Having the functions in the PLC avoids dependence on additional communication software and logic development external to the PLC, such as within an HMI.
In upcoming blogs, we will explore additional PLC functions and the specific advantages of using the Dragos Platform to monitor and detect malicious behaviors interacting with these critical OT devices.
Ready to put your insights into action?
Take the next steps and contact our team today.