Not Supporting Stix is a Mistake

[brettforbes]

Hi, I am real impressed with your initiative. I have wondered for some time why cyber-security doesn't capture temporal sequences, and thereby ignores tools such as process mining. Anyway, I really like how you are using the ATT&CK classification, and mapping it to a flow chart. This is brilliant.

The massive, missing piece in this repo is that this is useless for any using Stix-centric tools. Like most doing ATT&CK-centric development. I follow the advice of the MITRE people, and use their method to load data, as shown here (https://github.com/mitre-attack/attack-stix-data/blob/master/USAGE.md). This uses the OASIS Stix2 python library to load the ATT&CK objects in Stix format, and apparently this is the approach recommended by MITRE. Thus I have built an open source, bi-directional STIX <-> TypeDB ORM on this OASIS STix2 library.

Yet i find that this worthy extension to MITRE does not support Stix, and pursues an independent RDF/OWL schema. Now, i am happy to develop an equivalent TypeQL schema and rule set for Vaticle TypeDB, this seems trivial, and is frankly better than rdf/owl (my opinion). But there is no point doing so, because I cannot map the Attack-flow to my existing Stix schema, so its an information island.

In short, without a valid intersection with Stix, this repo unfortunately does seem like a white elephant.

Let me know when this changes, as I can start adding your stuff in immediately. Process mining is a missing piece, so temporal evaluation is critical.

Keep going, please get Stix2 interface sorted

Note that there is some inconsistencies with the temporal sequencing implied by your example Tesla diagram, and your data model. So, at the moment only the action has a timestamp, yet its consequences do not. One can have a temporal sequence diagram with annotations, like your green boxes, yet it seems like the temporal nature is not fully specified. Consider annotating assets with a consequential time at which they were exposed, and also considering extending it to a start and end time, where if there is only one value available, it is deemed the start time

[mehaase]

Thanks for the positive feedback. We are underway on a major update to Attack Flow that will address some of the limitations regarding STIX 2.

Process mining is a missing piece, so temporal evaluation is critical.

Can you elaborate on process mining and temporal evaluation? I'm not familiar with that terminology.

[brettforbes]

Cyber attacks are a temporal process, so they happen over time with multiple steps, and they are different to normal use case temporal processes.

The question that should be asked, is how should we analyse sequential temporal sequences with the following requirements?:

1. There is a log with activities that have timestamps, either one or two timestamps depending on fidelity
2. The activities all come from a set, and different sessions may take different pathways through the activity stack
3. The beginning and end activities are the same, or are inserted
4. I have many good traces, and very few bad, so i want conformance checking

The major field that has sprung up in the last decade to solve this problem is called Process Mining (http://www.processmining.org/). It is astonishing to me that cyber security ignores this analysis, and does not capture temporal sequences properly.

[mehaase]

Hi @brettforbes, Attack Flow v2 was released last week. The new specification is a STIX 2.1 extension, which I believe resolves your concerns around STIX support.

[brettforbes]

nice work @mehaase

[mehaase]

Thank you! I'll close this now.