PLC Tutorials

#5 PLC Best Practices – Cryptographic and Checksum Integrity Checks

Use cryptographic hashes, or checksums if cryptographic hashes are unavailable, to check PLC code integrity and raise an alarm when they change.

Security ObjectiveTarget Group
Integrity of PLC logicProduct Supplier Integration / Maintenance Service Provider Asset Owner

Checksums

Where (cryptographic) hashes are not feasible, checksums may be an option. Some PLCs generate a unique Checksum when code is downloaded into the PLC Hardware.

The Checksum should be documented by the manufacturer / integrator after SAT and be part of warranty / service-conditions.

If the checksum feature is not natively available in the controller, this can also be generated in the EWS/HMI and probed e.g., once a day to compare with the hash of the original code in the PLC to verify that they are matching. While this won’t provide real time alerts, it’s good enough to track if anyone is attempting changes to the PLC code.

The checksum value can also be moved into a PLC register and configured for an alarm when it changes, the value can be sent to historians etc.

Hashes

PLC CPUs generally do not have the processing capacity to generate or check hashes while running. Attempting a hash might actually cause the PLC to crash.

But the PLC’s engineering software might be able to calculate hashes from the PLC code and save them either in the PLC or somewhere else in the control system.

Use Cryptographic checks for PLC

Example

PLC vendors that are known to have checksum features:

  • Siemens (see example)
  • Rockwell

Also, external software can be used for generating checksums:

  • Version dog
  • Asset Guardian
  • PAS

Siemens Implementation Example

Example for creating checksums in Siemens S7-1500 PLC:

GetChecksum-Function Block reads actual checksum and with a lightweight script the “SAT- Checksum” can be stored as reference.

A deviance from the Reference-Checksum can be stored with the Datalog-Function.

Rockwell Implementation Example

This is partial example of how an organization can develop a level of PLC program change detection capability within their ICS environment.

This example is specifically for a Rockwell Automation ControlLogix PLC and is not complete; however, it illustrates how to retrieve the PLC processor state into a register within the PLC.

Once in a register in the PLC, the organization can use it create a configuration change alarm for display on an HMI, transmit the raw state information to an HMI for trending and monitoring, or send it to a Historian for long term capture.

This practice provides an opportunity, using existing tools and capabilities, to gain situational awareness of when critical cyber assets change. It is up to the organization to complete the use of this example in a method that works best in their environment.

  1. From the Controller Properties Dialog Box, select the configure button on “Change to Detect”
  2. Within the selection window, choose all items to be monitored
  3. Create a Tag to receive the processor state information. This tag can be of type “LINT” or a 2-word array of type “DINT”
  4. Use the Get System Values (GSV) instruction to get the processor state information from memory and move it into a Tag that can be used in logic or read at the HMI

Why?

Beneficial for…?Why?
SecurityKnowing if PLC code was tampered with is essential for both noticing a compromise and verifying if a PLC is safe to operate after a potential compromise.
ReliabilityHashes or checksums can also be a means to verify if the PLC is (still) running code approved by the integrator/manufacturer.
Maintenance/

References

Standard / frameworkMapping
MITRE ATT&CK for ICSTactic: TA002 – Execution, TA010 – Impair Process Control
Technique: T0873 – Project File Infection, T0833 – Modify Control Logic
ISA 62443-3-3SR 3.4 : Software and information integrity
ISA 62443-4-2CR 3.4 : Software and information integrity
EDR 3.12 : Provisioning product supplier roots of trust
ISA 62443-4-1SI-1 : Security implementation review
SVV-1 Security requirements testing
MITRE CWECWE-345: Insufficient Verification of Data Authenticity
CWE-353: Missing Support for Integrity Check       
CWE-354: Improper Validation of Integrity Check Value

Source: PLC Security

You've successfully subscribed !

View Comments

  • This functionality is built-in to Mitsubishi Electric iQ-R series PLC's. The loaded firmware, parameterization, and programs/global tags can be monitored separately and in real-time using system memory of the CPU (SD2020-2025).

Share

Recent Articles

  • Control Systems

What is Open Telemetry? – Principles and Benefits

Open Telemetry is a framework for collecting data in cloud-native applications including tracing, metrics, and…

5 days ago
  • Common

Control of Pneumatic Cylinder and Motor

This article is about controlling the Pneumatic cylinder and Pneumatic motor in the assembly line…

1 week ago
  • PLC Tutorials

Network Switch Requirement in SCADA and DCS Architecture

In this post, we will learn the basic requirements for a network switch to be…

5 days ago
  • PLC Tutorials

PLC Panel and MCC Panel Interface Signals

The PLC panel and MCC panel interface signals are start, stop, run feedback, trip, local…

1 week ago
  • PLC Tutorials

Shutter Door Control using Motor and Limit Switches

 In this article, we are going to discuss about shutter door control using induction motor…

1 week ago
  • Electrical Basics

Electrical Drives – Modes, Types, Speed Control Applications

Electrical Drives control the motion of electric motors. Motion control is required in industrial and…

1 week ago