Building secure software for operational technologies applications with forensics readiness in mind

In April 2024, the Dragos firm reported on the Froosty Goop malware, which targets the Modbus protocol, an Operational Technology (OT) protocol. It disrupted the ENCO controllers of a heating system in the Ukranian city of Lviv, causing a loss of heat in 600 buildings in January. No one died, but this kind of attack may have severe consequences if not properly addressed: securing OT applications is critical!

Operational technology

OT refers to hardware and software systems used to monitor and control physical devices, processes, and events in industrial and critical infrastructure environments.

It’s used in various sectors, for instance manufacturing, energy, utilities (public services), transportation, and healthcare.

A necessary distinction to operate here is between OT and IT (Information Technology) Basically: IT deals with an organization’s front-end informational activity while OT focuses on the back-end production (machines).

We have many components part of OT such as:

• Industrial Control Systems (ICS) an umbrella term for various control systems, used in industrial production.
• ICS encompasses Supervisory Control and Data Acquisition (SCADA), systems used to control and monitor industrial processes, often over large geographical areas.
• Distributed Control Systems (DCS) used within a single manufacturing plant or over a wide geographical area.
• More low level we can find Programmable Logic Controllers (PLCs), which are specialized computers used to control machinery and industrial processes.
• Various sensors and actuators, Human Machine Interfaces for operators.
• And many more

Building secure software for OT

It’s important to acknowledge that security is a process, not an end.

A possible definition can be:

Secure software refers to software that is designed and developed with security in mind, aiming to protect against unauthorized access, use, disclosure, disruption, modification, or destruction. The goal is to minimize vulnerabilities and ensure that the software can continuously withstand and respond to security threats.

More concretely, if you want to build secure software, you can follow the framework enacted by the US National Institute of Standards and Technology (NIST). NIST is behind many tech standards, including cryptographic algorithms, so they can be trusted.

They suggest to first:

• prepare your organization (defining requirements, implementing roles, preparing software environments)
• then to protect the software (prevent tampering, secure repositories, etc)
• a core component is of course to produce well-secured software (design, review, test, reuse existing secure code)
• and finally how to respond to vulnerabilities (identify, prioritize, remedy, analyze root cause).

Secure coding

To produce well-secured software, it’s important to secure your code.

Secure coding consists in following standards and guidelines to prevent common vulnerabilities, for instance SQL injection for databases, and cross-site scripting (XSS), which are more tailored to the web, as well as buffer overflows, which are also be interesting in our context (OT).

A buffer overflow happens when process attempts to store data beyond a fixed-length buffer. Remember that, in many programming languages, you need to allocate memory, which is stored in arrays with a limited size by default. So, if you try to fit too much in your buffer, your program will not work as intended. In an OT context, an attacker can overpass the safety values of industrial machines, and/or execute payloads.

The idea behind a payload is to encapsulate a program that will get executed without the usual security checks, because it comes from this unsecured buffer. It can lead to remote control, disruption, or destruction. Disruption is what happened with Froosty Goop.

Threat modeling

Another part of producing secure software that I wanted to present today is threat modeling.

Threat modeling consists in identifying potential threats and vulnerabilities early in the development process and designing mitigations for them.

Threat modeling is important to tailor your security to the level of risks, and provide appropriate answers. We have many ways to model threat in computer security, but I’ll simply hint at a tried and test methodology: attack trees.

You need to follow this series of steps: 0. before starting, define adversaries (are you an amateur website eventually targeted by ransomware, or a critical infrastructure targeted by state-level actors?)

1. the first step is to evaluate your potential vulnerabilities based on the goals of the adversary, and map them in a tree. Here I sketched a simple one for our running example (see slides).
2. but not all nodes are as likely, in our case a physical breach can be deemed unlikely, unlike a remote attack.
3. so we prune and only keep the viable attack vectors
4. you then need to devise countermeasures for the remaining attack, which can be in our case either 1) disconnecting the heating plant entirely, or 2) maintaining an updated security routine on a set of well-defined access points + MFA.
5. the first solution may be effective, but it comes with significant drawbacks, so it may be more suitable to go for the second one.

An important question remains: who performed the attack? And how can we know for sure? The cybersecurity firm mentioned some IP tracing back to Moscow, but no official attribution (perhaps were they fake?). And can we trace back the process of the attack, in order to better defend the next ones?

Making OT forensics-ready

Forensics historically refers to the scientific investigation for criminal cases, think Sherlock Holmes basically! It collects fingerprints, DNA, model ballistics, etc. But now the term has acquired a broader meaning, and we notably use it in a digital context for cyberattacks.

A possible definition is the ability of an organization to efficiently and effectively collect, preserve, and analyze digital evidence in the event of a security incident or breach.

I will now briefly present two important aspects of forensics, although many more exist.

Logging/monitoring

To ‘create’ your evidence, it’s common to log what’s happening on your system, logging which is also used for debugging. Here you want to capture detailed information about system activities, including user actions, network traffic, and system events.

Having a monitoring solution enables a faster assessment of a situation. Here, you use centralized solutions to aggregate and correlate logs from multiple sources, making it easier to detect and investigate incidents.

But how can we be sure of what we find? Indeed, clever attacks can also tamper with the logs if the attacker gain sufficient access!

Data integrity

Which is why we want to have data integrity, which basically means maintaining the accuracy of data, as a way to defend against tampering. We typically use cryptographic hashes to detect whether data has been modified. What a cryptographic hash is is beyond our scope today, but remember that if you hash a value, for instance a log, you’ll always get the same hash. If you change the log a little, the hash will be entirely different. But given a hash you should not be able to know what produced it, making it very hard to forge, and a good way to make sure that the data has not been modified (otherwise you’ll get a different hash).

You can also leverage digital signatures, as well as secure ledgers to store your logs.

Here, the idea is to implement mechanisms to preserve log data and other evidence for two main goals: • Prevent attackers from covering their tracks • Help make the evidence admissible in a legal procedure

Conclusion

Although we touched upon several concepts, it is far from being exhaustive, it was rather an introduction to the topic. There are many more things to consider for secure OT software! For instance: network security, incident response planning… And so is forensics-readiness! Such as compliance, internal training…

Going further

We usually think of technology as the only link to fix in the security chain, although it is not the weakest in practice! Humans usually are, they can make the rest of the effort pointless. You can have the security in the word, it doesn’t matter if you can ask the password.

We also need to think about human factors in security, which can for instance in an OT context span the following questions:

• How do we make secure solutions more usable?
• How do we ensure acceptance?
• How do we train staff for incident response? etc.