Forensics

What is Forensics?

Forensics (digital forensic analysis) is the collection, preservation, examination and reporting of digital data from systems and networks, in a way that keeps the evidence intact, to establish the cause, scope and impact of a cyber incident. In OT environments it covers not only computers and log files but also PLCs, HMIs, project files and industrial network traffic. There, forensics helps to reconstruct attacks, to tell a malfunction from sabotage and to find the root cause, often while the plant has to keep running.

🧠 How does the forensic process work?

The US guideline NIST SP 800-86 (Guide to Integrating Forensic Techniques into Incident Response, August 2006) divides digital forensics into four phases. That breakdown is still widely used:

1. Collection - identifying and labelling sources and copying the data securely without altering the original: disk images, memory dumps, network captures and log files.
2. Examination - searching the collected data with automated and manual methods and extracting what matters, such as suspicious processes or traces of malware.
3. Analysis - placing events on a timeline and linking them across systems and layers (IT ↔ OT), for example suspicious network activity such as ARP poisoning or command-and-control, logins outside working hours, configuration changes and code downloads.
4. Reporting - recording who, what, where, when and how, which methods and tools were used, and which remediation and improvement measures are needed.

A core principle is the order of volatility from RFC 3227 (February 2002): collect first what disappears fastest. RAM, the ARP cache and running processes are lost on a restart; a hard disk or an archived backup is not.

🔄 What is the difference between forensics and incident response?

Forensics and incident response are often mentioned together as DFIR (Digital Forensics and Incident Response), but they have a different goal and a different pace.

In practice the two clash: operations want the plant back in service as soon as possible, the investigator wants to keep the system as it is. A good incident response plan defines in advance who makes that trade-off and which evidence must at least be preserved before recovery.

🏭 Why is forensics harder in OT than in IT?

In June 2022 NIST published NIST IR 8428, a DFIR framework specifically for operational technology. The report lists several properties that set OT forensics apart:

• Malfunction or attack? - technical faults are far more frequent than cyber attacks and start with the same symptoms. With TRITON (2017), the first unexpected safety shutdown was initially treated as a malfunction.
• Legacy and proprietary protocols - many controllers have little or no logging and run undocumented, proprietary firmware and protocols.
• Availability above all - switching a system off to take a disk image is often not an option.
• Online versus offline investigation - the behaviour of PLC logic and I/O signals is hard to understand offline; sometimes the running system has to be examined, under process safety supervision.
• Memory-only malware - OT systems are rarely rebooted, so malware that lives only in RAM survives there longer.
• Two disciplines - the investigation needs IT forensic skills as well as knowledge of the process and its control systems. Because real OT incidents are rare, you build that collaboration through simulations and tabletop exercises.

Stuxnet showed why an investigator must not blindly trust their own tooling: on the engineering station the malware replaced a Step 7 communication library and thereby hid its own code blocks in the PLC from the engineer.

🔧 Which sources does an OT forensic investigator examine?

For the network side, Wireshark is the standard tool; memory analysis often uses the open-source Volatility framework, and disk examination uses suites such as FTK and EnCase. There is no universal forensic tool for PLCs: hardware and firmware differ per manufacturer, so the compare function of the vendor’s engineering software is often the most important instrument.

🛠️ How do you approach OT forensics step by step?

NIST IR 8428 divides the process into six phases: routine, initial identification and reporting, technical event handling, cyber incident analysis and response, end of the cyber incident, and post-incident. In practice:

1. Record a baseline during routine operations - periodically store hashed copies of PLC programs, firmware versions, configurations and a normal picture of network traffic. What you do not collect before the incident, you will not have afterwards.
2. Synchronise time - without NTP or PTP, the clocks of PLCs, HMIs and servers drift apart and a timeline becomes almost impossible.
3. Decide whether it is a malfunction or an attack - let maintenance and OT engineers investigate the technical cause and escalate to the incident team when deviations cannot be explained.
4. Secure evidence in order of volatility - memory, network traffic and VPN logs first, then disks and archives. Work locally, document every action and calculate a hash (for example SHA-256) of every file.
5. Validate the project files - pull logic and firmware from the controllers and compare them with the validated copy. A difference is a strong lead, especially if it cannot be traced back to change management.
6. Analyse in a separate lab - examine copies offline, which removes time pressure and safety risks for the plant.
7. Report and improve - carry out a root cause analysis, map the findings to MITRE ATT&CK for ICS and TTPs, and feed the lessons into threat intelligence and threat hunting.

🔐 What requirements apply to forensic evidence?

• Integrity - the original stays untouched; examination is done on copies whose hash matches the source.
• Chain of custody - every handover of evidence is recorded: who, when, why. Without that chain, evidence is of little value to a court or an insurer.
• Standards - ISO/IEC 27037:2012 gives guidelines for the identification, collection, acquisition and preservation of digital evidence; ISO/IEC 27043:2015 describes the wider investigation process.
• Passive where possible - in a production environment, prefer passive methods such as network capture via a TAP. Active reading of controllers happens only in agreement with the person responsible for the process.
• Legal context - since 15 August 2026, the incident reporting obligation of the Dutch Cybersecurity Act requires essential and important entities to report significant incidents, with a final report within one month that covers, among other things, the type of threat or root cause. Without forensic investigation that report is hard to substantiate.

In practice, forensic investigation is linked to SIEM, SOAR and the CSIRT for your sector, and it requires close collaboration between IT, OT and security teams.

❓ Frequently asked questions

What does DFIR stand for?

DFIR stands for Digital Forensics and Incident Response: the combination of digital forensic investigation and incident handling. Incident response stops the attack and restores service, while forensics reconstructs what happened and preserves evidence. For OT environments, NIST IR 8428 from 2022 describes a DFIR framework that brings both together.

Can a PLC be forensically examined?

A PLC can be forensically examined, but not with standard IT tooling. The common approach is to read out the logic and firmware with the vendor’s engineering software, hash it and compare it with a validated copy. PLC memory analysis is possible but differs per manufacturer, because hardware and firmware are proprietary.

Should I switch off an infected OT system immediately?

Switching off an infected OT system immediately wipes its RAM and with it often the best forensic evidence. Preferably isolate the system from the network first and take a memory dump, unless process safety requires immediate intervention. The safety of people and plant always comes before gathering evidence.

Which tools are used for forensics in OT?

For forensics in OT you use Wireshark for network traffic and industrial protocols, Volatility for memory analysis and FTK or EnCase for disk examination. The PLC vendor’s engineering software is also indispensable for comparing logic. Logs from the SIEM, historian and VPN gateways complete the picture.

Why is time synchronisation important for forensics?

Time synchronisation is important for forensics because an investigator has to place events from PLCs, HMIs, firewalls and servers on a single timeline. If clocks are minutes apart, it is no longer possible to establish which action was the cause and which the effect. Synchronise all OT components with NTP or PTP for that reason.

When should I bring in an external forensic team?

Bring in an external forensic team when your own team lacks the knowledge or capacity, when evidence must stand up in court or when an insurer asks for it. Preferably arrange such a team contractually in advance, so it can start within hours. Choose a provider with proven OT experience, because IT forensic specialists do not always know industrial protocols and controllers.

📌 In summary

Forensics is the careful collection, preservation and analysis of digital evidence to reconstruct what happened during a cyber incident. In OT this requires a baseline in advance, time synchronisation, passive methods and knowledge of PLCs and industrial protocols.

Forensic investigation is the foundation for understanding cyber incidents in OT environments, such as an erroneous or malicious download to a PLC, a backdoor that gives an attacker persistence in a SCADA system, or ransomware in the OT zone. By preserving evidence properly and finding the root cause, you prevent recurrence and can substantiate your reports to the regulator and CSIRT, as part of your wider security strategy.