pith. sign in

arxiv: 1907.00199 · v1 · pith:RLFMXOX4new · submitted 2019-06-29 · 💻 cs.CR

Incidents Are Meant for Learning, Not Repeating: Sharing Knowledge About Security Incidents in Cyber-Physical Systems

Pith reviewed 2026-05-25 13:00 UTC · model grok-4.3

classification 💻 cs.CR
keywords cyber-physical systemssecurity incidentsincident patternsknowledge sharingsmart buildingsincident extractioninstantiation
0
0 comments X

The pith

Abstract incident patterns let organizations share CPS security knowledge across systems without exposing sensitive assets.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper establishes that security incidents in cyber-physical systems recur and that representing them as abstract patterns capturing characteristics such as activities and exploited vulnerabilities enables safer sharing. These patterns are general enough to apply to different systems while avoiding disclosure of an organization's specific resources. Automated extraction turns a concrete incident instance into such a pattern, and automated instantiation applies the pattern to other systems. Demonstrated in smart buildings with evaluation on correctness, scalability, and performance using scenarios inspired by real incidents, the approach supports better preparedness to prevent or investigate future events.

Core claim

Incident patterns are a more abstract representation of specific incident instances that capture characteristics such as incident activities or vulnerabilities exploited by offenders. They are general enough to be applicable to various cyber-physical systems different from the one in which the incident occurred and avoid disclosing potentially sensitive information about an organization's assets and resources. An automated technique extracts an incident pattern from a specific incident instance, and another instantiates incident patterns to specific systems, with feasibility shown in the smart buildings domain.

What carries the argument

Incident patterns, abstract representations of incident characteristics that enable reuse across systems.

If this is right

  • Organizations can apply patterns from one incident to prevent or investigate similar incidents in other cyber-physical systems.
  • Knowledge sharing becomes possible without the risk of disclosing specific assets or resources.
  • Automated extraction and instantiation reduce the manual work needed to transfer incident knowledge.
  • Evaluation in smart buildings shows the approach handles substantive scenarios with measurable correctness and performance.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • A library of such patterns could support community-level learning across critical infrastructure sectors.
  • The patterns might integrate with monitoring tools to flag potential recurrences in real time.
  • Extending the extraction and instantiation methods to additional CPS domains such as transportation or industrial control would test broader transferability.

Load-bearing premise

That the automated extraction and instantiation techniques can produce patterns that remain useful for preventing or investigating incidents when applied to different cyber-physical systems.

What would settle it

A case where instantiating a pattern extracted from one smart building incident into a different building produces no matching activities or vulnerabilities that actually occur would show the patterns do not transfer usefully.

Figures

Figures reproduced from arXiv: 1907.00199 by Bashar Nuseibeh, Deepak Mehta, Faeq Alrimawi, Liliana Pasquale, Nobukazu Yoshioka.

Figure 1
Figure 1. Figure 1: The ACME Company Motivating Example. Upon the discovery of the incident, security administra￾tors wrote a report describing how the incident occurred. Afterwards, to assess whether similar incidents activities can manifest in the other buildings, security administrators have to identify existing vulnerabilities brought by cyber and physical components in those buildings. This may require to examine the phy… view at source ↗
Figure 2
Figure 2. Figure 2: Our approach for sharing incident knowledge [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 4
Figure 4. Figure 4: For example, sl1 and toilet are instances of SmartLight and Room, respectively. To model the structure of a CPS, the meta-model also repre￾sents containment and connectivity relations between compo￾nents. The containedAssets relation denotes the Asset(s) con￾tained in a PhysicalAsset. The containedDigitalAssets relation denotes the DigitalAsset(s) contained in another DigitalAsset. For example, as shown in… view at source ↗
Figure 3
Figure 3. Figure 3: Smart Building meta-model (simplified). sl3, the fireAlarm, the server and the hvac are contained in the serverRoom. Connection represents connectivity between two components (asset1 and asset2) and can be described by a type (e.g., wired). Digital connectivity between assets (e.g., through a network) is expressed as a DigitalConnection, while physical connectivity between assets (e.g., two rooms are conne… view at source ↗
Figure 4
Figure 4. Figure 4: Research Center instance (simplified). To specify the dynamic behaviour of a CPS, the meta￾model allows representing Actions. For example, Actions can represent a person entering a room or connecting his/her laptop to a computing device via the bus network. An Action is expressed as a re-writing rule where a portion of the system matching a pre-condition is re-written with the sub-system represented in the… view at source ↗
Figure 5
Figure 5. Figure 5: Incident meta-model (simplified). B. Modeling Incidents We take inspiration from Crime Scripts to model security incidents. Crime Scripts are used in criminology to describe the sequence of activities of physical crimes [16]. Despite their adoption for understanding the incident commission process and identifying incident prevention techniques, there exists no model that can be used to represent and proces… view at source ↗
Figure 6
Figure 6. Figure 6: Incident instance model of the Research Center incident. [PITH_FULL_IMAGE:figures/full_fig_p006_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: A potential incident pattern model extracted from the incident instance model. [PITH_FULL_IMAGE:figures/full_fig_p006_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Mapping the system actions “connect Laptop to BusNetwork physically” and “connect ComputingDevice via [PITH_FULL_IMAGE:figures/full_fig_p007_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Merging the incident instance activities ”connect laptop [PITH_FULL_IMAGE:figures/full_fig_p007_9.png] view at source ↗
Figure 11
Figure 11. Figure 11: “connect digitally to computingDevice” activity pat [PITH_FULL_IMAGE:figures/full_fig_p009_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: An instantiation of incident pattern activities in a LTS. [PITH_FULL_IMAGE:figures/full_fig_p010_12.png] view at source ↗
Figure 14
Figure 14. Figure 14: Execution time of instantiating incident pattern activ [PITH_FULL_IMAGE:figures/full_fig_p012_14.png] view at source ↗
Figure 13
Figure 13. Figure 13: Execution time of incident pattern activities measured [PITH_FULL_IMAGE:figures/full_fig_p012_13.png] view at source ↗
read the original abstract

Cyber-physical systems (CPSs) are part of most critical infrastructures such as industrial automation and transportation systems. Thus, security incidents targeting CPSs can have disruptive consequences to assets and people. As prior incidents tend to re-occur, sharing knowledge about these incidents can help organizations be more prepared to prevent, mitigate or investigate future incidents. This paper proposes a novel approach to enable representation and sharing of knowledge about CPS incidents across different organizations. To support sharing, we represent incident knowledge (incident patterns) capturing incident characteristics that can manifest again, such as incident activities or vulnerabilities exploited by offenders. Incident patterns are a more abstract representation of specific incident instances and, thus, are general enough to be applicable to various systems - different than the one in which the incident occurred. They can also avoid disclosing potentially sensitive information about an organization's assets and resources. We provide an automated technique to extract an incident pattern from a specific incident instance. To understand how an incident pattern can manifest again in other cyber-physical systems, we also provide an automated technique to instantiate incident patterns to specific systems. We demonstrate the feasibility of our approach in the application domain of smart buildings. We evaluate correctness, scalability, and performance using two substantive scenarios inspired by real-world systems and incidents.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper proposes representing CPS security incidents as abstract 'incident patterns' that capture recurring characteristics (e.g., activities, exploited vulnerabilities) to enable knowledge sharing across organizations without disclosing sensitive asset details. It introduces automated extraction of patterns from specific incident instances and automated instantiation of patterns into target systems, claiming these patterns are general enough to apply to systems different from the incident's origin. Feasibility is demonstrated via evaluation of correctness, scalability, and performance on two scenarios in the smart-buildings domain.

Significance. If the extraction and instantiation techniques can be shown to produce patterns that remain actionable for prevention and investigation when transferred across distinct CPS classes, the work would provide a practical mechanism for collaborative defense in critical infrastructure. The emphasis on abstraction to support sharing while preserving confidentiality addresses a real operational barrier; however, the current evaluation does not yet establish this cross-class utility.

major comments (2)
  1. [Evaluation] Evaluation section (and abstract): the central claim that patterns 'are general enough to be applicable to various systems—different than the one in which the incident occurred' is load-bearing for the sharing argument, yet all experiments remain inside the single smart-buildings domain using two scenarios. No instantiation of a pattern extracted from one CPS class (e.g., building automation) into another class (e.g., industrial control or transportation) is reported, leaving the cross-domain usefulness untested.
  2. [Instantiation technique] § on automated instantiation technique: the description of how an extracted pattern is mapped to a concrete system model does not include any quantitative measure of how much domain-specific adaptation is still required; without such a metric it is difficult to assess whether the resulting instantiated scenario remains useful for prevention or investigation in a genuinely different CPS.
minor comments (2)
  1. [Evaluation] The two scenarios are described as 'inspired by real-world systems and incidents' but no explicit mapping to the source incidents or citation of the original reports is provided; adding such references would strengthen reproducibility.
  2. [Approach overview] Notation for pattern elements (activities, vulnerabilities, etc.) is introduced without a consolidated table; a single summary table would improve readability.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback. We address each major comment below and outline revisions to strengthen the manuscript.

read point-by-point responses
  1. Referee: [Evaluation] Evaluation section (and abstract): the central claim that patterns 'are general enough to be applicable to various systems—different than the one in which the incident occurred' is load-bearing for the sharing argument, yet all experiments remain inside the single smart-buildings domain using two scenarios. No instantiation of a pattern extracted from one CPS class (e.g., building automation) into another class (e.g., industrial control or transportation) is reported, leaving the cross-domain usefulness untested.

    Authors: We agree that the evaluation is limited to two scenarios within the smart-buildings domain and does not demonstrate cross-class transfer (e.g., building automation to industrial control). The abstract nature of the patterns is intended to support broader applicability, but the empirical validation remains domain-specific. In revision we will update the abstract, introduction, and evaluation section to qualify the generality claim, explicitly note the evaluated scope, and add a limitations subsection discussing cross-class transfer potential and requirements for future validation. revision: yes

  2. Referee: [Instantiation technique] § on automated instantiation technique: the description of how an extracted pattern is mapped to a concrete system model does not include any quantitative measure of how much domain-specific adaptation is still required; without such a metric it is difficult to assess whether the resulting instantiated scenario remains useful for prevention or investigation in a genuinely different CPS.

    Authors: The instantiation technique performs automated matching against the target system model, but some domain knowledge may still be needed for edge cases. The original manuscript does not quantify adaptation effort. We will revise the instantiation section to include a quantitative metric (e.g., fraction of pattern elements mapped automatically versus those requiring manual or domain-specific adjustment) and report these values for the evaluated scenarios. revision: yes

Circularity Check

0 steps flagged

No significant circularity; derivation self-contained

full rationale

The paper proposes novel automated extraction and instantiation techniques for incident patterns, presented as independent methods evaluated for feasibility, correctness, scalability, and performance within the smart-building domain using two scenarios. No load-bearing self-citations, self-definitional reductions, or fitted inputs renamed as predictions are identifiable from the provided text. The central claims rest on the definition and demonstration of the new techniques rather than reducing to prior inputs or self-referential fitting by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

Based solely on the abstract, no specific free parameters, axioms, or invented entities are described.

pith-pipeline@v0.9.0 · 5775 in / 988 out tokens · 33879 ms · 2026-05-25T13:00:30.529074+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

28 extracted references · 28 canonical work pages

  1. [1]

    CPS Foundations,

    E. A. Lee, “CPS Foundations,” in Proc. of 47th ACM/IEEE Design Automation Conference, 2010, pp. 737–742

  2. [2]

    Loukas, Cyber-physical Attacks: A Growing Invisible Threat

    G. Loukas, Cyber-physical Attacks: A Growing Invisible Threat . Butterworth-Heinemann, 2015

  3. [3]

    Analysis of the Cyber Attack on the Ukrainian Power Grid,

    R. M. Lee, M. J. Assante, and T. Conway, “Analysis of the Cyber Attack on the Ukrainian Power Grid,” Electricity Information Sharing and Analysis Center (E-ISAC) , 2016

  4. [4]

    German Steel Mill Cyber Attack,

    ——, “German Steel Mill Cyber Attack,” Industrial Control Systems , vol. 30, p. 62, 2014

  5. [5]

    Challenges for Securing Cyber Physical Systems,

    A. Cardenas, S. Amin, B. Sinopoli, A. Giani, A. Perrig, S. Sastry et al., “Challenges for Securing Cyber Physical Systems,” in Workshop on Future Directions in Cyber-Physical Systems Security , vol. 5, 2009

  6. [6]

    SP 800-61 rev. 1. Computer Security Incident Handling Guide,

    K. A. Scarfone, T. Grance, and K. Masone, “SP 800-61 rev. 1. Computer Security Incident Handling Guide,” 2012

  7. [7]

    IT Security Incident Response: Current State, Emerg- ing Problems, and New Approaches,

    T. Schreck, “IT Security Incident Response: Current State, Emerg- ing Problems, and New Approaches,” Ph.D. dissertation, Friedrich- Alexander-University Erlangen-Nuremberg (FAU), 2018

  8. [8]

    Communication Systems for Building Automation and Control,

    W. Kastner, G. Neugschwandtner, S. Soucek, and H. M. Newman, “Communication Systems for Building Automation and Control,” Pro- ceedings of the IEEE , vol. 93, no. 6, pp. 1178–1203, 2005

  9. [9]

    Security in Building Automation Systems - A First Analysis,

    T. Mundt and P. Wickboldt, “Security in Building Automation Systems - A First Analysis,” in Proc. of the 2016 International Conference On Cyber Security And Protection Of Digital Services (Cyber Security) , 2016, pp. 1–8

  10. [10]

    IoT Reality: Smart Devices, Dumb Defaults,

    B. Krebs, “IoT Reality: Smart Devices, Dumb Defaults,” https: //krebsonsecurity.com/2016/02/iot-reality-smart-devices-dumb-defaults, 2016

  11. [11]

    Incident Response Teams–Challenges in Supporting the Organisational Security Function,

    A. Ahmad, J. Hadgkiss, and A. B. Ruighaver, “Incident Response Teams–Challenges in Supporting the Organisational Security Function,” Computers & Security , vol. 31, no. 5, pp. 643–652, 2012

  12. [12]

    Handbook for Computer Security Incident Response Teams (csirts),

    M. J. West-Brown, D. Stikvoort, K.-P. Kossakowski, G. Killcrece, and R. Ruefle, “Handbook for Computer Security Incident Response Teams (csirts),” Carnegie-mellon univ pittsburgh pa software engineering inst, Tech. Rep., 2003

  13. [13]

    Natural Language Processing of Incident and Accident Reports: Application to Risk Management in Civil Aviation,

    N. Tulechki, “Natural Language Processing of Incident and Accident Reports: Application to Risk Management in Civil Aviation,” Ph.D. dissertation, Universit´e Toulouse le Mirail-Toulouse II, 2015

  14. [14]

    I’ve Seen This Before: Sharing Cyber-Physical Incident Knowledge,

    F. Alrimawi, L. Pasquale, D. Mehta, and B. Nuseibeh, “I’ve Seen This Before: Sharing Cyber-Physical Incident Knowledge,” in Proc. of the 1st International Workshop on Security Awareness from Design to Deployment, SEAD@ICSE 2018, Gothenburg, Sweden, May 27, 2018 , 2018, pp. 33–40. 14

  15. [15]

    Pure bigraphs: Structure and dynamics,

    R. Milner, “Pure bigraphs: Structure and dynamics,” Information and computation, vol. 204, no. 1, pp. 60–122, 2006

  16. [16]

    Crimes as scripts,

    D. Cornish, “Crimes as scripts,” in Proceedings of the inter. seminar on env. criminology and crime analysis . Tallahassee: Florida Criminal Justice Executive Institute, 1994, pp. 30–45

  17. [17]

    Common Attack Pattern Enumeration & Classification

    MITRE Corporation, “Common Attack Pattern Enumeration & Classification.” [Online]. Available: http://capec.mitre.org/

  18. [18]

    Choco Solver

    C. Prud’homme and J.-G. Fages, “Choco Solver.” [Online]. Available: http://www.choco-solver.org/

  19. [19]

    A CSP implementation of the bigraph embedding problem,

    M. Miculan and M. Peressotti, “A CSP implementation of the bigraph embedding problem,” dec 2014

  20. [20]

    ClaSP: An efficient algorithm for mining frequent closed sequences,

    A. Gomariz, M. Campos, R. Marin, and B. Goethals, “ClaSP: An efficient algorithm for mining frequent closed sequences,” in Pacific- Asia Conference on Knowledge Discovery and Data Mining . Springer Berlin Heidelberg, 2013, pp. 50–61

  21. [21]

    An Empirical Evaluation of the Effectiveness of Attack Graphs and Fault Trees in Cyber-Attack Perception,

    H. S. Lallie, K. Debattista, and J. Bal, “An Empirical Evaluation of the Effectiveness of Attack Graphs and Fault Trees in Cyber-Attack Perception,” IEEE Transactions on Information Forensics and Security , pp. 1–1, 2017

  22. [22]

    A language for describing attacks on cyber-physical systems,

    M. Yampolskiy, P. Horv ´ath, X. D. Koutsoukos, Y . Xue, and J. Szti- panovits, “A language for describing attacks on cyber-physical systems,” International Journal of Critical Infrastructure Protection , vol. 8, pp. 40–52, jan 2015

  23. [23]

    A framework for modeling cyber-physical switching attacks in smart grid,

    S. Liu, S. Mashayekh, D. Kundur, T. Zourntos, and K. Butler-Purry, “A framework for modeling cyber-physical switching attacks in smart grid,” IEEE Transactions on Emerging Topics in Computing , vol. 1, no. 2, pp. 273–285, 2013

  24. [24]

    Using hybrid attack graphs to model cyber-physical attacks in the Smart Grid,

    P. J. Hawrylak, M. Haney, M. Papa, and J. Hale, “Using hybrid attack graphs to model cyber-physical attacks in the Smart Grid,” in 5th ISRCS, 2012, pp. 161–164

  25. [25]

    Using computed similarity of distinctive digital traces to evaluate non-obvious links and repetitions in cyber- investigations,

    T. Boll ´e and E. Casey, “Using computed similarity of distinctive digital traces to evaluate non-obvious links and repetitions in cyber- investigations,” Digital Investigation, vol. 24, pp. S2–S9, mar 2018

  26. [26]

    Standardizing Cyber Threat Intelligence Information with the Structured Threat Information eXpression ( STIX ),

    Mitre, “Standardizing Cyber Threat Intelligence Information with the Structured Threat Information eXpression ( STIX ),” MITRE Corpora- tion, vol. 11, pp. 1–22, 2012

  27. [27]

    Introduction to TAXII

    OASIS Open, “Introduction to TAXII.” [Online]. Available: https: //oasis-open.github.io/cti-documentation/taxii/intro

  28. [28]

    A ten step process for forensic readiness,

    R. Rowlingson, “A ten step process for forensic readiness,” International Journal of Digital Evidence , vol. 2, no. 3, pp. 1–28, 2004