CTI STIX Subcommittee

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

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 Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Same here On Friday, 27 May 2016, Jordan, Bret < bret.jordan@bluecoat.com > wrote: 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

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




 

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




 

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  

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  

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




 













 

Some context on organizations creating their own kill chain. There is a decent amount of adoption of the LM Kill Chain but many organizations decide to expand or provide a different variant of that concept. Some organizations do so in order to align with their internal terminology or processes. Others do so because they want more fidelity or have a separate usage. For example, I am aware of one government entity that has a hierarchal kill chain with many additional steps than the LM Kill Chain. The concept is that the analysts at the low levels can fill in the kill chain at a high fidelity, but then multiple high fidelity steps fall into 1 step in a lower fidelity version of the kill chain. The lower fidelity version can be used for presenting to those higher in command or for making decisions about actions to take or processes that need to be started. In another example, the LM kill chain is focused on net-defense and starts with Reconnaissance, other organizations may be looking at an attack from a different perspective and therefore may start at a different phase. All of this is to say that we need to be careful that providing too much structure leads to less adoption or stops the ability for analysts to continue to innovate. -Gary
Original Message----- From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Allan Thomson Sent: Wednesday, June 01, 2016 9:08 AM To: Terry MacDonald; Ted Bedwell (tebedwel) Cc: Wunder, John A.; Jordan, Bret; cti-stix@lists.oasis-open.org Subject: [Non-DoD Source] 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 <tel:+61-407-203-026> E: terry.macdonald@cosive.com < mailto:terry.macdonald@cosive.com > W: www.cosive.com < https://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 < https://gist.github.com/johnwunder/80f66746cc42134e6a42c98df6cdf18f > Thoughts? John

I agree with Gary here…organizations often create their own informal or formal kill chains, but by providing too much structure around them we in STIX can actually limit things and make it so they’re not able to define them how they want. For example, Mandiant’s “Attack Lifecycle” in their APT1 report has a cycle, but we weren’t able to capture that in the STIX 1.2 kill chain structure, so it was only a partial definition. Hierarchies, cycles, what else would we need to add? So IMO the structures are too fluid/differentiated for us to adequately capture as TLOs and instead we should just let people define them elsewhere and provide mechanisms to reference them. On 6/1/16, 9:17 AM, "Katz, Gary CTR DC3/DCCI" <Gary.Katz.ctr@dc3.mil> wrote: >Some context on organizations creating their own kill chain. > >There is a decent amount of adoption of the LM Kill Chain but many organizations decide to expand or provide a different variant of that concept. Some organizations do so in order to align with their internal terminology or processes. Others do so because they want more fidelity or have a separate usage. For example, I am aware of one government entity that has a hierarchal kill chain with many additional steps than the LM Kill Chain. The concept is that the analysts at the low levels can fill in the kill chain at a high fidelity, but then multiple high fidelity steps fall into 1 step in a lower fidelity version of the kill chain. The lower fidelity version can be used for presenting to those higher in command or for making decisions about actions to take or processes that need to be started. In another example, the LM kill chain is focused on net-defense and starts with Reconnaissance, other organizations may be looking at an attack from a different perspective and therefore may start at a different phase. > >All of this is to say that we need to be careful that providing too much structure leads to less adoption or stops the ability for analysts to continue to innovate. > >-Gary > >
Original Message----- >From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Allan Thomson >Sent: Wednesday, June 01, 2016 9:08 AM >To: Terry MacDonald; Ted Bedwell (tebedwel) >Cc: Wunder, John A.; Jordan, Bret; cti-stix@lists.oasis-open.org >Subject: [Non-DoD Source] 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 <tel:+61-407-203-026> > >E: terry.macdonald@cosive.com < mailto:terry.macdonald@cosive.com > > >W: www.cosive.com < https://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 < https://gist.github.com/johnwunder/80f66746cc42134e6a42c98df6cdf18f > > > > > Thoughts? > > > > John > > > > >

I agree. I believe using kill chains as a TLO would be overly complex. If we need that in the future we can add it. Bret Sent from my Commodore 64 > On Jun 1, 2016, at 6:32 AM, Wunder, John A. <jwunder@mitre.org> wrote: > > I agree with Gary here…organizations often create their own informal or formal kill chains, but by providing too much structure around them we in STIX can actually limit things and make it so they’re not able to define them how they want. For example, Mandiant’s “Attack Lifecycle” in their APT1 report has a cycle, but we weren’t able to capture that in the STIX 1.2 kill chain structure, so it was only a partial definition. Hierarchies, cycles, what else would we need to add? > > So IMO the structures are too fluid/differentiated for us to adequately capture as TLOs and instead we should just let people define them elsewhere and provide mechanisms to reference them. > >> On 6/1/16, 9:17 AM, "Katz, Gary CTR DC3/DCCI" <Gary.Katz.ctr@dc3.mil> wrote: >> >> Some context on organizations creating their own kill chain. >> >> There is a decent amount of adoption of the LM Kill Chain but many organizations decide to expand or provide a different variant of that concept. Some organizations do so in order to align with their internal terminology or processes. Others do so because they want more fidelity or have a separate usage. For example, I am aware of one government entity that has a hierarchal kill chain with many additional steps than the LM Kill Chain. The concept is that the analysts at the low levels can fill in the kill chain at a high fidelity, but then multiple high fidelity steps fall into 1 step in a lower fidelity version of the kill chain. The lower fidelity version can be used for presenting to those higher in command or for making decisions about actions to take or processes that need to be started. In another example, the LM kill chain is focused on net-defense and starts with Reconnaissance, other organizations may be looking at an attack from a different perspective and therefore may start at a different phase. >> >> All of this is to say that we need to be careful that providing too much structure leads to less adoption or stops the ability for analysts to continue to innovate. >> >> -Gary >> >>
Original Message----- >> From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Allan Thomson >> Sent: Wednesday, June 01, 2016 9:08 AM >> To: Terry MacDonald; Ted Bedwell (tebedwel) >> Cc: Wunder, John A.; Jordan, Bret; cti-stix@lists.oasis-open.org >> Subject: [Non-DoD Source] 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 <tel:+61-407-203-026> >> >> E: terry.macdonald@cosive.com < mailto:terry.macdonald@cosive.com > >> >> W: www.cosive.com < https://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 < https://gist.github.com/johnwunder/80f66746cc42134e6a42c98df6cdf18f > >> >> >> >> Thoughts? >> >> >> >> John >

Just to be clear, I very much believe that we need to provide a way to communicate information related to kill chain phases, it's used in too many organizations to not include, I just don't want to force people to use one kill chain over another.
Original Message----- From: Jordan, Bret [ mailto:bret.jordan@bluecoat.com ] Sent: Wednesday, June 01, 2016 11:48 AM To: Wunder, John A. Cc: Katz, Gary CTR DC3/DCCI; Allan Thomson; Terry MacDonald; Ted Bedwell (tebedwel); cti-stix@lists.oasis-open.org Subject: [Non-DoD Source] Re: [cti-stix] Kill Chains in STIX I agree. I believe using kill chains as a TLO would be overly complex. If we need that in the future we can add it. Bret Sent from my Commodore 64 > On Jun 1, 2016, at 6:32 AM, Wunder, John A. <jwunder@mitre.org> wrote: > > I agree with Gary here...organizations often create their own informal or formal kill chains, but by providing too much structure around them we in STIX can actually limit things and make it so they're not able to define them how they want. For example, Mandiant's "Attack Lifecycle" in their APT1 report has a cycle, but we weren't able to capture that in the STIX 1.2 kill chain structure, so it was only a partial definition. Hierarchies, cycles, what else would we need to add? > > So IMO the structures are too fluid/differentiated for us to adequately capture as TLOs and instead we should just let people define them elsewhere and provide mechanisms to reference them. > >> On 6/1/16, 9:17 AM, "Katz, Gary CTR DC3/DCCI" <Gary.Katz.ctr@dc3.mil> wrote: >> >> Some context on organizations creating their own kill chain. >> >> There is a decent amount of adoption of the LM Kill Chain but many organizations decide to expand or provide a different variant of that concept. Some organizations do so in order to align with their internal terminology or processes. Others do so because they want more fidelity or have a separate usage. For example, I am aware of one government entity that has a hierarchal kill chain with many additional steps than the LM Kill Chain. The concept is that the analysts at the low levels can fill in the kill chain at a high fidelity, but then multiple high fidelity steps fall into 1 step in a lower fidelity version of the kill chain. The lower fidelity version can be used for presenting to those higher in command or for making decisions about actions to take or processes that need to be started. In another example, the LM kill chain is focused on net-defense and starts with Reconnaissance, other organizations may be looking at an attack from a different perspective and therefore may start at a different phase. >> >> All of this is to say that we need to be careful that providing too much structure leads to less adoption or stops the ability for analysts to continue to innovate. >> >> -Gary >> >>
Original Message----- >> From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Allan Thomson >> Sent: Wednesday, June 01, 2016 9:08 AM >> To: Terry MacDonald; Ted Bedwell (tebedwel) >> Cc: Wunder, John A.; Jordan, Bret; cti-stix@lists.oasis-open.org >> Subject: [Non-DoD Source] 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 <tel:+61-407-203-026> >> >> E: terry.macdonald@cosive.com < mailto:terry.macdonald@cosive.com > >> >> W: www.cosive.com < https://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 < https://gist.github.com/johnwunder/80f66746cc42134e6a42c98df6cdf18f > >> >> >> >> Thoughts? >> >> >> >> John >

Does that mean you think we need kill chain & kill chain phase TLOs? Or do you think the controlled vocab style approach is sufficient? I see the difference as with the TLOs we’re able to define and represent the kill chains themselves in STIX, while with the CV-style approach we just reference the kill chains and phase names but don’t define them in STIX. On 6/1/16, 12:30 PM, "cti-stix@lists.oasis-open.org on behalf of Katz, Gary CTR DC3/DCCI" <cti-stix@lists.oasis-open.org on behalf of Gary.Katz.ctr@dc3.mil> wrote: >Just to be clear, I very much believe that we need to provide a way to communicate information related to kill chain phases, it's used in too many organizations to not include, I just don't want to force people to use one kill chain over another. > >
Original Message----- >From: Jordan, Bret [ mailto:bret.jordan@bluecoat.com ] >Sent: Wednesday, June 01, 2016 11:48 AM >To: Wunder, John A. >Cc: Katz, Gary CTR DC3/DCCI; Allan Thomson; Terry MacDonald; Ted Bedwell (tebedwel); cti-stix@lists.oasis-open.org >Subject: [Non-DoD Source] Re: [cti-stix] Kill Chains in STIX > >I agree. I believe using kill chains as a TLO would be overly complex. If we need that in the future we can add it. > >Bret > >Sent from my Commodore 64 > >> On Jun 1, 2016, at 6:32 AM, Wunder, John A. <jwunder@mitre.org> wrote: >> >> I agree with Gary here...organizations often create their own informal or formal kill chains, but by providing too much structure around them we in STIX can actually limit things and make it so they're not able to define them how they want. For example, Mandiant's "Attack Lifecycle" in their APT1 report has a cycle, but we weren't able to capture that in the STIX 1.2 kill chain structure, so it was only a partial definition. Hierarchies, cycles, what else would we need to add? >> >> So IMO the structures are too fluid/differentiated for us to adequately capture as TLOs and instead we should just let people define them elsewhere and provide mechanisms to reference them. >> >>> On 6/1/16, 9:17 AM, "Katz, Gary CTR DC3/DCCI" <Gary.Katz.ctr@dc3.mil> wrote: >>> >>> Some context on organizations creating their own kill chain. >>> >>> There is a decent amount of adoption of the LM Kill Chain but many organizations decide to expand or provide a different variant of that concept. Some organizations do so in order to align with their internal terminology or processes. Others do so because they want more fidelity or have a separate usage. For example, I am aware of one government entity that has a hierarchal kill chain with many additional steps than the LM Kill Chain. The concept is that the analysts at the low levels can fill in the kill chain at a high fidelity, but then multiple high fidelity steps fall into 1 step in a lower fidelity version of the kill chain. The lower fidelity version can be used for presenting to those higher in command or for making decisions about actions to take or processes that need to be started. In another example, the LM kill chain is focused on net-defense and starts with Reconnaissance, other organizations may be looking at an attack from a different perspective and therefore may start at a different phase. >>> >>> All of this is to say that we need to be careful that providing too much structure leads to less adoption or stops the ability for analysts to continue to innovate. >>> >>> -Gary >>> >>>
Original Message----- >>> From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Allan Thomson >>> Sent: Wednesday, June 01, 2016 9:08 AM >>> To: Terry MacDonald; Ted Bedwell (tebedwel) >>> Cc: Wunder, John A.; Jordan, Bret; cti-stix@lists.oasis-open.org >>> Subject: [Non-DoD Source] 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 <tel:+61-407-203-026> >>> >>> E: terry.macdonald@cosive.com < mailto:terry.macdonald@cosive.com > >>> >>> W: www.cosive.com < https://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 < https://gist.github.com/johnwunder/80f66746cc42134e6a42c98df6cdf18f > >>> >>> >>> >>> Thoughts? >>> >>> >>> >>> John >> > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >

It's a good question, and unfortunately not one that I have a clear response for. There's pros and cons to both approaches. CVs are obviously easier to represent and from a system perspective, it may be better to have the kill chain phase as a property of the indicator or observation rather than as something that it links to. On the flip-side kill chain and kill chain phase objects can provide more flexibility. I'd be interested in seeing a discussion on the approaches before providing a firm opinion.
Original Message----- From: Wunder, John A. [ mailto:jwunder@mitre.org ] Sent: Wednesday, June 01, 2016 12:35 PM To: Katz, Gary CTR DC3/DCCI; 'Jordan, Bret' Cc: Allan Thomson; Terry MacDonald; Ted Bedwell (tebedwel); cti-stix@lists.oasis-open.org Subject: [Non-DoD Source] Re: [cti-stix] Kill Chains in STIX Does that mean you think we need kill chain & kill chain phase TLOs? Or do you think the controlled vocab style approach is sufficient? I see the difference as with the TLOs we’re able to define and represent the kill chains themselves in STIX, while with the CV-style approach we just reference the kill chains and phase names but don’t define them in STIX. On 6/1/16, 12:30 PM, "cti-stix@lists.oasis-open.org on behalf of Katz, Gary CTR DC3/DCCI" <cti-stix@lists.oasis-open.org on behalf of Gary.Katz.ctr@dc3.mil> wrote: >Just to be clear, I very much believe that we need to provide a way to communicate information related to kill chain phases, it's used in too many organizations to not include, I just don't want to force people to use one kill chain over another. > >
Original Message----- >From: Jordan, Bret [ mailto:bret.jordan@bluecoat.com ] >Sent: Wednesday, June 01, 2016 11:48 AM >To: Wunder, John A. >Cc: Katz, Gary CTR DC3/DCCI; Allan Thomson; Terry MacDonald; Ted >Bedwell (tebedwel); cti-stix@lists.oasis-open.org >Subject: [Non-DoD Source] Re: [cti-stix] Kill Chains in STIX > >I agree. I believe using kill chains as a TLO would be overly complex. If we need that in the future we can add it. > >Bret > >Sent from my Commodore 64 > >> On Jun 1, 2016, at 6:32 AM, Wunder, John A. <jwunder@mitre.org> wrote: >> >> I agree with Gary here...organizations often create their own informal or formal kill chains, but by providing too much structure around them we in STIX can actually limit things and make it so they're not able to define them how they want. For example, Mandiant's "Attack Lifecycle" in their APT1 report has a cycle, but we weren't able to capture that in the STIX 1.2 kill chain structure, so it was only a partial definition. Hierarchies, cycles, what else would we need to add? >> >> So IMO the structures are too fluid/differentiated for us to adequately capture as TLOs and instead we should just let people define them elsewhere and provide mechanisms to reference them. >> >>> On 6/1/16, 9:17 AM, "Katz, Gary CTR DC3/DCCI" <Gary.Katz.ctr@dc3.mil> wrote: >>> >>> Some context on organizations creating their own kill chain. >>> >>> There is a decent amount of adoption of the LM Kill Chain but many organizations decide to expand or provide a different variant of that concept. Some organizations do so in order to align with their internal terminology or processes. Others do so because they want more fidelity or have a separate usage. For example, I am aware of one government entity that has a hierarchal kill chain with many additional steps than the LM Kill Chain. The concept is that the analysts at the low levels can fill in the kill chain at a high fidelity, but then multiple high fidelity steps fall into 1 step in a lower fidelity version of the kill chain. The lower fidelity version can be used for presenting to those higher in command or for making decisions about actions to take or processes that need to be started. In another example, the LM kill chain is focused on net-defense and starts with Reconnaissance, other organizations may be looking at an attack from a different perspective and therefore may start at a different phase. >>> >>> All of this is to say that we need to be careful that providing too much structure leads to less adoption or stops the ability for analysts to continue to innovate. >>> >>> -Gary >>> >>>
Original Message----- >>> From: cti-stix@lists.oasis-open.org >>> [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Allan Thomson >>> Sent: Wednesday, June 01, 2016 9:08 AM >>> To: Terry MacDonald; Ted Bedwell (tebedwel) >>> Cc: Wunder, John A.; Jordan, Bret; cti-stix@lists.oasis-open.org >>> Subject: [Non-DoD Source] 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 <tel:+61-407-203-026> >>> >>> E: terry.macdonald@cosive.com < mailto:terry.macdonald@cosive.com > >>> >>> W: www.cosive.com < https://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 >>> < https://gist.github.com/johnwunder/80f66746cc42134e6a42c98df6cdf18f >>> > >>> >>> >>> >>> Thoughts? >>> >>> >>> >>> John >> > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >

Hi everybody,
 
I thought I would make some comments on kill chains to get the discussion going :-)
 
Starting with STIX 1.x, Kill Chains and Kill Chain Phases were basically TTPs.  The properties of each are at http://stixproject.github.io/data-model/1.2/stixCommon/KillChainType/
and http://stixproject.github.io/data-model/1.2/stixCommon/KillChainPhaseType/ .  A kill chain was defined in a STIX document, and its
phases were referred to by other TLOs (Indicators).  Because there is no common repository of STIX objects (yet??), all producers would define common kill chains again and again.
 
It has been proposed that in STIX 2.0, we do not represent kill chains/kill chain phases using TLOs, but instead certain TLOs would have a field called “kill_chain_phases” (of type list of kill-chain-phase) to associate kill chain phases with the TLO (e.g.,
Attack_Pattern, Indicator?).
 
Here is the way the kill-chain-phase type would be specified.
 





Property Name
Type
Description


kill_chain_name (required)
string
The name of the kill chain. The suggested values for this field are in kill-chain-name-ov located in Vocabulary section.


phase_name (required)
string
The name of the phase in the kill chain. The suggested values for this field are in phase-name-ov located in Vocabulary section.


 
Kill-chain-name-ov and phase-name-ov will contain suggested values for well-established kill chains (LM, Mandiant, etc.).  Because both fields are filled with open vocabularies it is possible for producers to define their own kill chains.
 
The gap analysis between using TLOs (assuming we would use the STIX 1.x model) and open vocabularies is:
 
Concept                 TLOs            open v ocabs
 
URI reference                   yes             not supported
Number of phases                yes             not supported
“Phase part of” relationship    yes             implicit
Hierarchical/Circular KCs       no              no
Defining new KCs                yes             yes, via open vocabularies
Ordinality of phases            yes             not supported
 
Questions:
 

Are the “not supported” concepts needed? There seems to be an assumption that doing any kind of analysis, like pivoting, can only be done with TLOs.  If this is your opinion, could you discuss your reasoning?? Other thoughts?
 
Rich
 

Original Message-----

From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Katz, Gary CTR DC3/DCCI

Sent: Wednesday, June 01, 2016 12:41 PM

To: Wunder, John A. <jwunder@mitre.org>; 'Jordan, Bret' <bret.jordan@bluecoat.com>

Cc: Allan Thomson <athomson@lookingglasscyber.com>; Terry MacDonald <terry.macdonald@cosive.com>; Ted Bedwell (tebedwel) <tebedwel@cisco.com>; cti-stix@lists.oasis-open.org

Subject: RE: [cti-stix] Kill Chains in STIX
 
It's a good question, and unfortunately not one that I have a clear response for.  There's pros and cons to both approaches.  CVs are obviously easier to represent and from a system perspective, it may be better to have the kill chain phase as a property
of the indicator or observation rather than as something that it links to.  On the flip-side kill chain and kill chain phase objects can provide more flexibility. 
 
I'd be interested in seeing a discussion on the approaches before providing a firm opinion.
 

Original Message-----
From: Wunder, John A. [ mailto:jwunder@mitre.org ]
Sent: Wednesday, June 01, 2016 12:35 PM
To: Katz, Gary CTR DC3/DCCI; 'Jordan, Bret'
Cc: Allan Thomson; Terry MacDonald; Ted Bedwell (tebedwel); cti-stix@lists.oasis-open.org
Subject: [Non-DoD Source] Re: [cti-stix] Kill Chains in STIX
 
Does that mean you think we need kill chain & kill chain phase TLOs? Or do you think the controlled vocab style approach is sufficient?
 
I see the difference as with the TLOs we’re able to define and represent the kill chains themselves in STIX, while with the CV-style approach we just reference the kill chains and phase names but don’t define them in STIX.
 
On 6/1/16, 12:30 PM, " cti-stix@lists.oasis-open.org on behalf of Katz, Gary CTR DC3/DCCI " < cti-stix@lists.oasis-open.org
on behalf of Gary.Katz.ctr@dc3.mil > wrote:
 
>Just to be clear, I very much believe that we need to provide a way to communicate information related to kill chain phases, it's used in too many organizations to not include, I just don't want to force people to use one kill chain over another.
>
>
Original Message-----
>From: Jordan, Bret [ mailto:bret.jordan@bluecoat.com ]
>Sent: Wednesday, June 01, 2016 11:48 AM
>To: Wunder, John A.
>Cc: Katz, Gary CTR DC3/DCCI; Allan Thomson; Terry MacDonald; Ted
>Bedwell (tebedwel); cti-stix@lists.oasis-open.org
>Subject: [Non-DoD Source] Re: [cti-stix] Kill Chains in STIX
>
>I agree.  I believe using kill chains as a TLO would be overly complex.  If we need that in the future we can add it.
>
>Bret
>
>Sent from my Commodore 64
>
>> On Jun 1, 2016, at 6:32 AM, Wunder, John A. < jwunder@mitre.org > wrote:
>>
>> I agree with Gary here...organizations often create their own informal or formal kill chains, but by providing too much structure around them we in STIX can actually limit things and make it so they're not able to define them how they want. For example,
Mandiant's "Attack Lifecycle" in their APT1 report has a cycle, but we weren't able to capture that in the STIX 1.2 kill chain structure, so it was only a partial definition. Hierarchies, cycles, what else would we need to add?
>>
>> So IMO the structures are too fluid/differentiated for us to adequately capture as TLOs and instead we should just let people define them elsewhere and provide mechanisms to reference them.
>>
>>> On 6/1/16, 9:17 AM, "Katz, Gary CTR DC3/DCCI" < Gary.Katz.ctr@dc3.mil > wrote:
>>>
>>> Some context on organizations creating their own kill chain.
>>>
>>> There is a decent amount of adoption of the LM Kill Chain but many organizations decide to expand or provide a different variant of that concept.  Some organizations do so in order to align with their internal terminology or processes.  Others do so
because they want more fidelity or have a separate usage.  For example, I am aware of one government entity that has a hierarchal kill chain with many additional steps than the LM Kill Chain.  The concept is that the analysts at the low levels  can fill in
the kill chain at a high fidelity, but then multiple high fidelity steps fall into 1 step in a lower fidelity version of the kill chain.  The lower fidelity version can be used for presenting to those higher in command or for making decisions about actions
to take or processes that need to be started.  In another example, the LM kill chain is focused on net-defense and starts with Reconnaissance, other organizations may be looking at an attack from a different perspective and therefore may start at a different
phase.
>>>
>>> All of this is to say that we need to be careful that providing too much structure leads to less adoption or stops the ability for analysts to continue to innovate.
>>>
>>> -Gary
>>>
>>>
Original Message-----
>>> From: cti-stix@lists.oasis-open.org
>>> [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Allan Thomson
>>> Sent: Wednesday, June 01, 2016 9:08 AM
>>> To: Terry MacDonald; Ted Bedwell (tebedwel)
>>> Cc: Wunder, John A.; Jordan, Bret; cti-stix@lists.oasis-open.org
>>> Subject: [Non-DoD Source] 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 < tel:+61-407-203-026 >
>>>
>>> E: terry.macdonald@cosive.com < mailto:terry.macdonald@cosive.com >
>>>
>>> W: www.cosive.com < https://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
>>> < https://gist.github.com/johnwunder/80f66746cc42134e6a42c98df6cdf18f
>>> >
>>>
>>>            
>>>
>>>            Thoughts?
>>>
>>>            
>>>
>>>            John
>>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
 
 

(late :p) I concur that a central registry approach would guarantee some level of Interoperability, while "open custom free-to-put-anything-in vocabularies" would not benefit The Community. "Vendors" could come with (and push for) their own Controlled Vocabularies (for review, extension, improvement...) but a standard must not be created to accommodate existing products or marketing leitmotiv. As an alien... I hope that "the transition of the -IANA- function to the global multi-stakeholder community" [1] could favorite (and hopefully simplify) this approach. (No Interoperability; No Automation; No Optimization; No High Maturity) [1]  https://www.ourinternet.org/report 2016-06-01 13:32 GMT+03:00 Terry MacDonald < terry.macdonald@cosive.com > : <snip> 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 central 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

For reference regarding IANA Namespace/Registry (Ref. Controlled Vocabularies) https://tools.ietf.org/html/rfc5226 2016-07-01 17:20 GMT+03:00 Jerome Athias < athiasjerome@gmail.com > : (late :p) I concur that a central registry approach would guarantee some level of Interoperability, while "open custom free-to-put-anything-in vocabularies" would not benefit The Community. "Vendors" could come with (and push for) their own Controlled Vocabularies (for review, extension, improvement...) but a standard must not be created to accommodate existing products or marketing leitmotiv. As an alien... I hope that "the transition of the -IANA- function to the global multi-stakeholder community" [1] could favorite (and hopefully simplify) this approach. (No Interoperability; No Automation; No Optimization; No High Maturity) [1]  https://www.ourinternet.org/report 2016-06-01 13:32 GMT+03:00 Terry MacDonald < terry.macdonald@cosive.com > : <snip> 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 central 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