Option 3 followed by Option 2.
The reason for preferring Option 3 is that there are multiple kill chains out there and which one is used by STIX will likely not be standardized. So if we choose a controlled vocab then
which kill chain definition are you going to use? Gartner? Lockheed-Martin?
My preference is to not burden MVP with this issue and consider it a future issue. If folks need kill-chain then I would suggest what does a machine or a human do with this information
where other TLOs already provide sufficient information to consider mitigation approaches.
That said, if someone can argue a compelling machine-to-machine reason to include kill chain information then I would prefer it to be a vocab not objects.
So definitely not Option 1.
"firstname.lastname@example.org" <email@example.com> on behalf of "Jordan, Bret" <firstname.lastname@example.org>
Date: Friday, May 27, 2016 at 9:41 AM
To: "Wunder, John" <email@example.com>
Cc: "firstname.lastname@example.org" <email@example.com>
Subject: Re: [cti-stix] Kill Chains in STIX
From your great examples, Option 1 represents a lot of bloat and will enable multiple people to define the same thing. I would be in favor of Option 2.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
One of the topics that has come up in the TTP/Malware conversation is kill chains. As a reminder, cyber kill chains are a phase-based model for describing the stages
of an attack. A good example is the Lockheed Martin kill chain.
In STIX 1.2, kill chains were represented as kind of a half-TLO: they were a part of TTP (defined either on a TTP object or in the TTPs list), but did have their
own IDs and could be referenced from other places.
In STIX 2.0, we have a couple options:
chains and kill chain phases could become top-level objects. You would use relationships to relate analysis objects (indicators, malware, attack patterns, etc.) to the kill chain phase objects that they can be considered a part of. References to kill chains
would require either either everyone knowing the IDs for the STIX objects or re-sharing kill chain definitions. In this option, STIX supports the structured representation of kill chains themselves.
chain phases are represented as a controlled vocabulary approach. Each object that needs to have kill chains just includes a field where you can list the kill chain phases that it’s a part of. References to kill chains wouldn’t use STIX IDs, they would use
names, so we could use something like open vocabularies to make sure people use the same terms for common kill chains/phases. In this option, STIX only supports representing names for kill chains…not full structured representations of the kill chains themselves.
don’t do kill chains, either for MVP or at all.
My preference is for #2. It’s very easy to implement so will encourage people to use kill chains (when necessary), and via the use of open vocabularies and standardized
terms we still enable pivoting and tracking across orgs/tools. It also seems like something that’s very useful for analysis and well-understood so we can be OK to add it for MVP.