Re: [cti-stix] Kill Chains in STIX

Terry – if common kill-chain is/was likely then why did organizations create their own versions? I don’t know the reasons for organizations creating their own but if one was enough then would they not have just adopted it?

I think STIX charter should focus on its original intent/charter and if the community wants a central registry of the objects you list below then that becomes a separate goal/charter item for another group.

I don’t believe STIX should burden itself with trying to standardize a kill-chain definition especially considering not all kill-chain definition authors are even involved in this community. So whatever would be standardized would likely not reflect the input of those authors.

allan

From: Terry MacDonald <terry.macdonald@cosive.com>
Date: Wednesday, June 1, 2016 at 3:32 AM
To: "Ted Bedwell (tebedwel)" <tebedwel@cisco.com>
Cc: "Wunder, John" <jwunder@mitre.org>, Allan Thomson <athomson@lookingglasscyber.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Kill Chains in STIX

I'm of the opinion that we should do Option 1. My reasoning is that it makes it easy for new people to add in additional kill chains and classification systems as they wish. I envisage Lockheed Martin providing a 'dictionary' series of killchain objects and killchain-phase objects to the public for others to use. These would be either downloadable off the Lockheed Martin TAXII server, or hosted at an OASIS registry TAXII Server, and would be automatically downloaded by STIX implementations (via their respective update mechanisms) to ensure that representations have the same object IDs that they all share.

Threatconnect/ActiveResponse.org could do the same with the diamond model, Gartner could do the same for their model, and we all would then be using the same objects, and bringing all the benefits that brings with graph based analysis.

I am coming around to the idea of us needing a central registry of common objects for a multitude of reasons, and that central registry makes it easier to implement Option 1. The entral registry of common objects would allow:

Controlled Vocabularies to be specified
Attack Pattern Objects to be created for each CAPEC entry so we can pivot from common object IDs
Allow for a common Vulnerability objects to be created for each CVE number that's issued
Allow for common Kill chain and Kill chain phase objects to be shared across platforms

and probably others I haven't thought of. I'm thinking its an idea we might need to entertain.....

Cheers

Terry MacDonald | Chief Product Officer

M: +61-407-203-026

E: terry.macdonald@cosive.com

W: www.cosive.com

On Wed, Jun 1, 2016 at 1:04 PM, Ted Bedwell (tebedwel) <tebedwel@cisco.com> wrote:

I think this approach is flexible enough to address the concerns of “Which kill chain do you mean?” while clearly articulating how to annotate the kill chain phases. If we don’t have some mechanism then we will see vendors being forced to define extensions to handle it.

$0.02

~ted

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Tuesday, May 31, 2016 at 9:49 AM
To: Allan Thomson <athomson@lookingglasscyber.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>

Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Kill Chains in STIX

Hey Allan,

I agree w/ you that we can’t standardize on a single kill chain. The idea behind the open vocabulary would be to let people use whichever kill chain they want to use, or multiple kill chains. For example, you could do something like this:

{

"type": "bundle",

"indicators": [

    {

      "type": "indicator",

      "id": "indicator--8445a039-6ba6-4e42-9011-467093d5b29e",

      "spec_version": "2.0",

      "created_time": "2016-05-27T15:47:14Z",

      "modified_time": "2016-05-27T15:47:14Z",

      "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",

      "revision": 1,

      "title": "Downloader URLs",

      "labels": ["malicious-activity"],

      "pattern": "url.value = 'http://example.com/download.exe'",

      "kill_chain_phases": [

        {

          "kill_chain_name": "lockheed-martin-cyber-kill-chain",

          "phase_name": "delivery"

        },

        {

          "kill_chain_name": "mandiant-cyber-attack-lifecycle",

          "phase_name": "initial-compromise"

        }

      ]

    }

]

}

So I definitely agree that while it would be great for us all to agree on a single kill chain to use it seems unrealistic. At the same time, people using the LMCO kill chain, the Mandiant kill chain, or the Gartner kill chain (or communities using a different one) should be able to use STIX to standardize on their use of it. So, to me, it seems like a good use case for an open vocab. We could help ensure standardization by extending our open vocab concept to have vocabs for common kill chains defined across the kill_chain_name and phase_name fields.

In terms of machine usage, I see it most often used for categorization and prioritization of other intelligence (indicators, malware, attack patterns, etc). Basically just a way of binning things…for example, MITRE uses it to categorize attack patterns in ATT&CK (https://attack.mitre.org/wiki/Main_Page).

John

From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Friday, May 27, 2016 at 4:27 PM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Kill Chains in STIX

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.

Regards

Allan

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Friday, May 27, 2016 at 9:41 AM
To: "Wunder, John" <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
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.

Thanks,

Bret

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

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."

On May 27, 2016, at 10:01, Wunder, John A. <jwunder@mitre.org> wrote:

Hey everyone,

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:

1.       Kill 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.

2.       Kill 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.

3.       We 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.

I mocked up some examples for options #1 and #2 here: https://gist.github.com/johnwunder/80f66746cc42134e6a42c98df6cdf18f

Thoughts?

John

cti-stix message