PaperlayerView exact revision on arXiv

Source-linked AI summary

Learning from Mutants: Using Code Mutation to Learn and Monitor Invariants of a Cyber-Physical System

Yuqi Chen, Christopher M. Poskitt, Jun Sun

arXiv:1801.00903v2cs.SEcs.CRcs.LG

TL;DR

Constructing CPS models useful for attack detection is difficult. The paper learns an invariant from normal and mutation-generated traces, validates it, and detects 47 of 55 network and code-modification attacks in the SWaT simulator.

  • Problem

    Constructing CPS models useful for detecting attacks is difficult because software control and physical behavior are tightly integrated.

    Source: §I · p. 1

  • Method

    The framework mutates PLC programs, learns an SVM-RBF model from traces, and validates it with cross-validation and statistical model checking.

    Source: §VI · pp. 10–11

  • Results

    47 of 55 network and code-modification attacks were detected; the eight missed attacks were code modifications with limited effects on water tank levels.

    Source: §VI · p. 11

  • Takeaways & Limitations

    The invariant suggests efficacy for monitoring attacks and physically attesting PLCs at runtime.

    Source: §VI · p. 11

    Because the dataset covers a single system, the results may not generalize to other CPSs.

    Source: F. Threats to Validity · p. 10

Abstract

from arXiv · show

Cyber-physical systems (CPS) consist of sensors, actuators, and controllers all communicating over a network; if any subset becomes compromised, an attacker could cause significant damage. With access to data logs and a model of the CPS, the physical effects of an attack could potentially be detected before any damage is done. Manually building a model that is accurate enough in practice, however, is extremely difficult. In this paper, we propose a novel approach for constructing models of CPS automatically, by applying supervised machine learning to data traces obtained after systematically seeding their software components with faults ("mutants"). We demonstrate the efficacy of this approach on the simulator of a real-world water purification plant, presenting a framework that automatically generates mutants, collects data traces, and learns an SVM-based model. Using cross-validation and statistical model checking, we show that the learnt model characterises an invariant physical property of the system. Furthermore, we demonstrate the usefulness of the invariant by subjecting the system to 55 network and code-modification attacks, and showing that it can detect 85% of them from the data logs generated at runtime.

I. INTRODUCTION

CPS attacks can cause physical damage, yet accurately modeling their intertwined software and physical behavior is extremely difficult. The paper proposes learning and checking CPS invariants from normal and mutation-generated traces, demonstrating the approach on the SWaT water-treatment simulator.

I. INTRODUCTION

  • Accurately reasoning about CPS behavior is difficult because software control is tightly integrated with continuous physical processes, making manual derivation of accurate models extremely difficult.Such models could let a supervisory system check traces for compromised behavior.Source: §I · p. 1
  • The approach learns invariant-characterizing models from normal and mutation-generated sensor traces, then uses statistical model checking to assess invariance and attack-detection applications.The SWaT framework automates mutant PLC generation, trace collection, and SVM learning.Source: §I · pp. 1–2
  • Compared with the earlier position-paper experiment, this work uses larger automatically generated datasets, kernel classifiers, systematic feature labeling, statistical model checking, and attack evaluation.Source: §I · p. 2

II. MOTIVATION AND OVERVIEW

  • The section introduces SWaT as the motivating case study and outlines how the learning approach applies to CPS.Source: §II · p. 2

A. Motivational Case Study: SWaT Testbed

  • SWaT is a scaled-down, fully operational raw-water purification plant with six cooperating treatment stages; undetected attacks could drive it toward damaging physical states such as empty or overflowing tanks.The paper focuses on water flow and tank-level invariants using the SWaT simulator.Source: A. Motivational Case Study: SWaT Testbed · pp. 2–3, §I · p. 2

B. Overview of Our Approach

The approach builds a CPS model from normal and mutation-generated traces, learns a classifier from paired sensor readings, and checks whether that classifier behaves as an invariant. A validated invariant can be queried against live data for attack detection or physical attestation.

B. Overview of Our Approach

  • The pipeline simulates normal and mutated CPS behavior, learns a classifier from features extracted from both trace sets, and uses statistical model checking to test invariance.If checking fails, the process restarts with different sampled data.Source: B. Overview of Our Approach · p. 3
  • Small syntactic mutations to PLC code generate abnormal traces, reflecting the assumption that attackers may make subtle cyber-part manipulations rather than tamper directly with the environment.Source: B. Overview of Our Approach · p. 3
  • Paired sensor readings at fixed intervals form feature vectors; abnormal traces are compared with normal traces from the same initial states, and indistinguishable traces are discarded.The resulting positive and negative vectors train a supervised classifier such as an SVM.Source: B. Overview of Our Approach · p. 3
  • Statistical model checking uses additional normal traces and statistical estimation or hypothesis testing to assess whether the classifier’s correctness probability exceeds a set threshold.Otherwise, the approach repeats with newly sampled data.Source: B. Overview of Our Approach · p. 3
  • A monitor can query live data against a learned invariant to detect manipulated network signals or support physical attestation of PLCs without modifying their firmware or hardware.The paper characterizes physical attestation as weaker but more lightweight than typical software- or hardware-based schemes.Source: B. Overview of Our Approach · pp. 3–4

III. IMPLEMENTING OUR APPROACH

The implementation applies the approach to the SWaT simulator, enabling automated experiments without risking damage to the testbed. Its first step selects physical starting conditions, collects normal traces, and generates abnormal traces by mutating PLC code.

III. IMPLEMENTING OUR APPROACH

  • The implementation describes trace generation, feature-vector collection, and classifier validation, using the SWaT simulator to automate experiments and avoid testbed damage or resource use.The authors note that testbed invariants could be pursued by rerunning trace collection or improving simulator fidelity.Source: §III · p. 4

A. First Step: Generating Mutants and Traces

  • Initial conditions should span sensor-range extremes and randomly selected combinations; SWaT runs log five tank levels every 5ms for 30 minutes from each configuration.Source: A. First Step: Generating Mutants and… · p. 4
  • Normal traces are collected by running the unaltered CPS from each initial physical configuration using the selected duration and logging interval.The SWaT framework runs original PLC programs for 30 minutes per configuration and stores the logs for later feature extraction.Source: A. First Step: Generating Mutants and… · p. 4
  • Abnormal traces come from small syntactic mutations, with the SWaT framework applying one mutation to a randomly selected PLC program in each mutant simulator.The six mutation operators replace Boolean or logical operators, arithmetic symbols, constants, or variables.Source: A. First Step: Generating Mutants and… · p. 4
  • Mutants that fail to compile are discarded; remaining mutants run from each initial state for 30 minutes while all tank levels are logged every 5ms.Source: A. First Step: Generating Mutants and… · p. 5

B. Second Step: Collecting Feature Vectors, Learning

The approach turns normal and mutant traces into labeled feature vectors for supervised learning. For SWaT, vectors pair tank levels across a fixed interval; ineffective mutations are filtered, and the classifier is trained on balanced data.

B. Second Step: Collecting Feature Vectors, Learning

  • SWaT feature vectors pair tank levels at one time with the same tanks’ levels after a fixed interval d.The interval is a multiple of the trace logging interval, capturing how tank levels evolve over time.Source: B. Second Step: Collecting Feature… · p. 5
  • Pairs from normal traces become positive examples; abnormal-trace pairs are retained as negative only when the unmodified simulator produces a distinguishable later state.Pairs with no detectable mutation effect are discarded; this filtering is straightforward because the SWaT simulator is deterministic.Source: B. Second Step: Collecting Feature… · pp. 5–6
  • The collected vectors are used to train a supervised classifier, with 70% reserved for training and the remainder held out for evaluation.For SWaT, the authors use SVM and compare linear, polynomial, and RBF classification functions.Source: B. Second Step: Collecting Feature… · p. 6
  • Negative feature vectors are undersampled to roughly match the number of positive vectors, addressing the imbalance between one normal simulator and potentially many mutants.The method partitions negatives into subsets and randomly selects one vector from each.Source: B. Second Step: Collecting Feature… · p. 6

C. Third Step: Validating the Classifier

The classifier is checked for generalisation and for evidence that it acts as an invariant on the unmodified system. Statistical model checking estimates correctness probability rather than guaranteeing it.

C. Third Step: Validating the Classifier

  • The validation step combines k-fold cross-validation for generalisation with statistical model checking (SMC) for evidence that the classifier is an invariant.SMC tests whether the classifier correctly labels unmodified-system traces as normal with probability at least threshold θ.Source: C. Third Step: Validating the Classifier · pp. 6–7
  • SMC observes system traces and uses hypothesis testing to estimate whether the invariant condition holds, without requiring a system model.It estimates correctness probability rather than guaranteeing correctness outright.Source: C. Third Step: Validating the Classifier · pp. 6–7
  • For SWaT, validation uses positive vectors from traces generated at new initial configurations and applies SPRT with error bounds of 0.05.Further vectors from additional distinct configurations are sampled when needed; θ is set to the best classifier’s evaluation accuracy.Source: C. Third Step: Validating the Classifier · p. 7

IV. EVALUATION

The evaluation is organized around five research questions covering classifier choice, feature-vector timing, mutant count, invariant validation, and attack detection. Experiments are conducted on the SWaT simulator.

IV. EVALUATION

  • The evaluation asks whether the model is useful for detecting attacks that manipulate the network and PLC programs.This is the fifth research question, following the parameter studies and invariant assessment.Source: §IV · p. 7
  • The first three research questions examine classification function, feature-vector time interval, and the number of mutants used to generate abnormal traces.The best classifier from these studies is then assessed for invariant status and attack-detection usefulness.Source: §IV · p. 7
  • All reported experiments use the SWaT simulator and a framework using LIBSVM version 3.22.Source: §IV · p. 7

A. RQ1: What kind of classification function do we need?

The RBF classifier far outperforms the linear and polynomial alternatives, which the authors attribute to their limited expressiveness for the sensor relationships in the dataset. They select RBF for the subsequent evaluation.

A. RQ1: What kind of classification function do we need?

  • The comparison uses 1.68 × 10^6 feature vectors, split into 70% training and 30% testing after undersampling abnormal data.The dataset comes from 700 mutant simulators, 91 of which produced abnormal behaviour, across 20 initial configurations.Source: A. RQ1: What kind of classification… · p. 7
  • Classifier performance is reported using held-out accuracy, five-fold cross-validation accuracy, sensitivity, and specificity.Higher percentages are better for all four measures.Source: A. RQ1: What kind of classification… · p. 7
  • RBF far outperforms the linear and polynomial classifiers, which score around 60 to 70% across the reported measures.The authors attribute the simpler classifiers’ weaker performance to complicated correlations among SWaT sensor readings and choose RBF.Source: A. RQ1: What kind of classification… · p. 7

B. RQ2: How large should the time interval in feature vectors be?

Accuracy stabilizes by about 150 ms, and the authors select 250 ms because it has very slightly the best accuracy. Longer intervals make abnormal behavior more observable but risk detecting it too late.

B. RQ2: How large should the time interval in feature vectors be?

C. RQ3: How many mutants do we need?

Accuracy and cross-validation accuracy begin stabilizing in the 90s from 500 mutants onward; the authors choose 600 mutants as their standard.

C. RQ3: How many mutants do we need?

D. RQ4: Is our model a physical invariant of the system?

Statistical model checking provides evidence that the learned classifier is a physical invariant of the SWaT simulator. The invariant detected the network attacks described in the evaluation and 32 of 40 code-modification mutants, with detection tied to unusual physical behavior.

D. RQ4: Is our model a physical invariant of the system?

  • Across five distinct normal initial configurations, the classifier passed statistical model checking at θ = 91.04% without requiring traces from additional configurations.The authors interpret these passes as evidence—not proof—that the classifier is an invariant of the SWaT simulator.Source: D. RQ4: Is our model a physical… · p. 8

E. RQ5: Is our model useful for detecting attacks?

  • All implemented network attacks were detected; slow-ramp attacks #3 and #7 reached about 60% initially, then 99.83% and 99.72% after physical effects began.Attacks were deemed detected when accuracy exceeded 85%.Source: Table V · p. 9, E. RQ5: Is our model useful for… · p. 9
  • The invariant may help monitor network attacks when they cause unusual physical behavior, in combination with defenses such as communication-link integrity checks.For code modifications, the proposed physical attestation is likewise based on detecting unexpected system-state changes.Source: E. RQ5: Is our model useful for… · p. 10
  • 32 of 40 randomly generated code-modification mutants were detected; the remaining traces were judged too similar to normal behavior.The mutants each applied a single PLC-program mutation, and the authors note that a more realistic attestation benchmark remains future work.Source: E. RQ5: Is our model useful for… · p. 10

F. Threats to Validity

The evaluation is bounded by one simulator, fixed initial configurations, and randomly generated code-modification attacks. The authors note that these choices may limit generalization and leave some behaviors or attacker strategies untested.

F. Threats to Validity

  • Results may not generalize beyond the single SWaT simulator used in the evaluation.The paper identifies other CPSs as outside the demonstrated scope.Source: F. Threats to Validity · p. 10
  • Fixed initial configurations may omit rare normal behaviors, causing misclassification during training or validation.The authors say such behaviors may be classified incorrectly by the invariant or missed in statistical model checking traces.Source: F. Threats to Validity · p. 10
  • Randomly generated code modifications may not represent attacks designed by an attacker who knows the system.The paper therefore limits the reach of its findings for real, knowledge-informed code attacks.Source: F. Threats to Validity · p. 10

V. RELATED WORK

Prior CPS work includes anomaly detection, manually derived physical invariants, and formal verification that depends on sufficiently accurate models. This paper applies supervised learning to traces from mutated PLC programs and reports attack detection on the SWaT simulator, while identifying evaluation and deployment directions for future work.

V. RELATED WORK

  • Prior anomaly-detection approaches often require knowledge of system internals, while this technique aims to construct models systematically without that prior knowledge.The paper also notes that manual physical invariants rely on physics and domain expertise and may miss patterns in sensor data.Source: §V · p. 10
  • Earlier SWaT work used unsupervised learning on the testbed attack log, but a direct comparison with this simulator evaluation is not possible.The authors hypothesize that supervised learning may yield higher sensitivity, but say a proper comparison is needed to confirm or refute that expectation.Source: §V · p. 10
  • Mutation-based test generation has also been applied to hybrid-system specifications rather than PLC programs, using discrete tests and qualitative reasoning about continuous behavior.The paper distinguishes this work from its own mutations of PLC code.Source: §V · p. 10
  • Formal verification can provide strong behavioral guarantees, but requires sufficiently accurate controller and ODE models.The paper lists model checking, SMT solving, concolic testing, runtime model validation, and theorem proving among established techniques.Source: §V · p. 10

VI. CONCLUSION

  • The approach learns CPS invariants with supervised machine learning on traces from systematically mutated PLC programs.The framework generates mutant programs, traces, and feature vectors, then uses SVM-RBF and validates the model with cross-validation and statistical model checking.Source: §VI · pp. 10–11
  • 47 of 55 network and code-modification attacks were detected; the eight missed attacks were code modifications with limited effects on water tank levels.The authors present this as evidence for monitoring attacks and physically attesting PLCs at runtime.Source: §VI · p. 11
  • Future work targets simpler invariants, less collected data, other CPS testbeds, and direct comparison with unsupervised approaches.The authors propose focusing mutation operators on PLC code more likely to produce useful abnormal traces.Source: §VI · p. 11
Loading 1801.00903v2…