Unmasking the Insider: Detecting Anomalies in TIA Portal Project History

TL;DR

Researchers have developed a new way to catch attackers in Industrial Control Systems (ICS) by looking at the "paper trail" of engineering software. By analyzing the history of Siemens TIA Portal projects, this study uses timestamps and memory size changes to identify malicious activity that network-based security often misses.

Background: The Blind Spot in Industrial Security

For a decade, the security community has obsessed over network traffic and sensor readings (Cyber-Physical attacks). However, the software used to configure these machines—the Totally Integrated Automation (TIA) Portal—remained a dark corner. Attackers like Stuxnet or Triton didn't just flood networks; they modified the very logic of the machines.

This paper identifies a critical gap: nobody was looking at the historical backups of these configuration files to see if a change actually made sense within the context of a factory's normal rhythm.

Problem: The Stealthy Saboteur

The authors define a "stealthy attack" as one that:

1. Matches legitimate timing: Changes made during working shifts to blend in with PLC programmers.
2. Matches legitimate sizes: Modifying only a few bytes of code to avoid triggering size-based alarms.

Current Intrusion Detection Systems (IDS) are often blind to these because, on the surface, the traffic looks like a standard authorized update.

Methodology: Levering Metadata as a Security Shield

The research utilizes a dataset from a German automotive manufacturer, spanning three years. They focused on two primary feature sets:

1. Temporal Fingerprinting

By studying when legitimate engineers actually work, the authors created clusters of "allowed" time windows for changes. For example, Function Blocks (FB) were typically modified between 8:00 AM and 9:00 PM. Any change at 3:00 AM becomes an immediate red flag.

2. Storage Footprint Analysis

Every time code is updated, the Load Memory (non-volatile) and Work Memory (volatile) requirements change. The authors developed a formula to calculate relative differences:

The System Architecture

The following diagram illustrates how different components of a TIA project (Program Blocks, Technology Parameters, etc.) were categorized for the study.

Experiments & Results

The authors tested their heuristics against three simulated attackers: the PLC Programmer (insider), the Backup Coordinator (privileged admin), and a General Attacker.

• The Single-Feature Performance: Using only timestamps was highly effective against the "Backup Coordinator" (AUC 0.999) because that attacker specifically worked late at night to avoid detection.
• The Power of Combination: Against the more sophisticated "PLC Programmer" scenario, combining time and size data increased the AUC by 32.7%.

Critical Insight: Why This Matters

The genius of this approach lies in its simplicity and "zero-day" potential. It doesn't need to know what a virus looks like. Instead, it learns the "behavioral rhythm" of the engineers.

Limitations

• Near Real-Time, Not Instant: Since this checks backups, it might only catch an attack hours or days after it occurred (e.g., when the daily backup is run).
• Reversible Changes: If an attacker changes a value and changes it back before the next backup, the system remains blind.

Conclusion

This work signals a shift toward holistic ICS defense. By treating engineering project history as a forensic goldmine, companies can catch saboteurs who have already bypassed the firewall. Future work will likely look into the actual code content (using NLP) to see not just when or how much code changed, but what the code is actually doing.