ATLANTA – SECURITYWEEK 2023 ICS CYBERSECURITY CONFERENCE – A new project aims to make it easier for PLC programmers to implement secure coding practices by analyzing and cataloging useful files and functions from each PLC vendor.
The new project was presented on Tuesday at SecurityWeek’s ICS Cybersecurity Conference in Atlanta by David Formby, CEO and CTO of Fortiphyd Logic, a company that specializes in endpoint detection for programmable logic controllers (PLCs) and virtual industrial control systems (ICS) security training labs.
The project builds on the ‘Top 20 Secure PLC Coding Practices’, whose goal is to provide PLC programmers with guidelines for improving security.
Some of these practices apply to all PLCs, regardless of vendor. This includes modularizing code, leaving operational logic directly in the PLC, assigning registers by function, using correlation and input plausibility checks, monitoring PLC uptime, trapping false negatives/positives, restricting third-party data interfaces, defining a safe start state in case of a restart, and validating timers, paired input/output, and indirections.
However, some secure PLC coding practices are different for each vendor and it can be difficult to identify relevant documentation. The goal of the Fortiphyd Logic project is to provide the information needed for vendor-specific practices in an easy-to-digest format.
The information is provided in a table format and includes the product name and model, whether required functionality is supported, and the file or function that enables access to the required data.
One secure PLC coding recommendation whose implementation is different for each vendor involves tracking the device’s operating mode. PLCs can have various modes, such as ‘run’, ‘program’, ‘test’ and ‘debug’. It’s easier for an attacker to hack a PLC that is not in ‘run’ mode, which is why it’s important that PLCs are not left in ‘program’, ‘test’ and ‘debug’ modes. In addition, mode changes should be monitored in order to detect a potential attack.
However, monitoring mode changes is done differently for each PLC, Formby pointed out. For instance, in the case of Rockwell Automation PLCs, the data can be obtained through the ‘GSV(ControllerDevice.Status)’ instruction or from a status file, while in the case of Siemens PLCs this can be achieved using the ‘GET_DIAG’ function.
Another vendor-specific secure PLC coding practice involves monitoring flags that indicate various errors and faults, which can be triggered by malicious attacks. However, PLCs from each vendor have different errors and faults and there are different ways of reading them, Formby explained.
Attackers targeting PLCs can make changes to the PLC logic and some controllers have checksums that enable users to detect changes in logic. Monitoring checksums can be useful for detecting attacks, but different vendors have different functions for achieving this and in some cases checksum monitoring is not supported at all.
Other examples of vendor-specific PLC secure coding practices covered by Fortiphyd Logic’s new project include monitoring cycle times, hard stops, and memory usage, as well as the detection of unused software.
For the time being, the new project, hosted on GitHub, only provides information for products made by Schneider Electric, Siemens and Rockwell Automation, but information will be added for other vendors as well, with the goal being to cover all PLC vendors. Anyone can contribute to the project.
Fortiphyd Logic has also created a custom module for the top 20 secure PLC coding practices for CISA’s Cyber Security Evaluation Tool (CSET), which provides a series of requirement questionnaires to help organizations assess their security posture.
Related: Omron Patches PLC, Engineering Software Flaws Discovered During ICS Malware Analysis
Related: Critical Vulnerabilities Allow Hackers to Take Full Control of Wago PLCs
