cti-stix — archive

RE: [cti-stix] Kill Chains in STIX

From: John Wunder <[email protected]>
To: [email protected]
Date: Tue, 07 Jun 2016 12:21:00 -0000

I agree that we should consider vocabularies as case-sensitive from a spec perspective. I don’t even think we have to specify it, they’re different characters so unless we say it’s insensitive and define how that works then they’re just different characters. I just don’t think we should limit what tools can do with fields that just contain information (like `kill-chains`) and don’t have any spec-defined behavior. If some tools want to do matching and pivoting as if they were case-insensitive, I don’t think we can or should stop them. That said that’s only case sensitivity, the solution to me for the problem Terry noted is specifying our vocabulary for common kill chains, where we get to define it so we can follow our own naming and design rules and make it all lower case. John From: Jason Keirstead <[email protected]> Date: Tuesday, June 7, 2016 at 8:04 AM To: "Wunder, John A." <[email protected]> Cc: "Jordan, Bret" <[email protected]>, Terry MacDonald <[email protected]>, Rich Piazza <[email protected]>, Allan Thomson <[email protected]>, "[email protected]" <[email protected]>, "Ted Bedwell (tebedwel)" <[email protected]>, "Katz, Gary CTR DC3/DCCI" <[email protected]> Subject: Re: [cti-stix] Kill Chains in STIX " If implementations want to do a case-insensitive pivot they can " IMO this is a dangerous path to go down. Is "Reconnaissance" the same as "reconnaissance" - this is not an implementation detail, it is something we have to declare in the standard, otherwise we will not have interoperability. We have to specify in the standard if literals inside controlled vocabularies are case-sensitive or not, because it has implications for writing high-performance code. I would vastly prefer that the standard declares that vocabularies are case-sensitive. If vocabularies are case-insensitive it is a headache. Note that I am *not* saying that I think that we should mandate that entries all be lower-case - I am saying that we should mandate that the vocabulary is case-sensitive and compares should be done that way. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Wunder, John A." ---06/06/2016 06:31:41 PM---I would keep it as a SHOULD: a) That’s what we do everywhere else (controlled and open vocabul From: "Wunder, John A." <[email protected]> To: "Jordan, Bret" <[email protected]>, Terry MacDonald <[email protected]> Cc: "Piazza, Rich" <[email protected]>, Allan Thomson <[email protected]>, "[email protected]" <[email protected]>, "Ted Bedwell (tebedwel)" <[email protected]>, "Katz, Gary CTR DC3/DCCI" <[email protected]> Date: 06/06/2016 06:31 PM Subject: Re: [cti-stix] Kill Chains in STIX Sent by: <[email protected]> I would keep it as a SHOULD: a) That’s what we do everywhere else (controlled and open vocabularies) b) They’re just design patterns, IMO we shouldn’t enforce design patterns. If implementations want to do a case-insensitive pivot they can…I would see the broader problem being people name something “recon” and others use “reconnaissance”, which we can help solve with the open vocabulary. I’d see it as something that we release as a committee note after 2.0 is out. We can define some popular kill chains and what names you should use for them and their phases. FWIW I really like this new approach. I think it’s a good balance of capability while still getting us out of the business of defining such a widely varied construct structurally. John From: "Jordan, Bret" <[email protected]> Date: Friday, June 3, 2016 at 11:13 PM To: Terry MacDonald <[email protected]> Cc: Rich Piazza <[email protected]>, Allan Thomson <[email protected]>, "[email protected]" <[email protected]>, "Ted Bedwell (tebedwel)" <[email protected]>, "Wunder, John A." <[email protected]>, "Katz, Gary CTR DC3/DCCI" <[email protected]> Subject: Re: [cti-stix] Kill Chains in STIX That is a good point, we already have this statement in the Open Vocabulary section: SHOULD conform to the naming pattern defined for all literals contained in Section TODO: all lowercase, with dashes “-” to separate words. Is "should" sufficient... Or do we need to look at making it a "must". Personally I would be fine with making it a must. 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 Jun 3, 2016, at 18:46, Terry MacDonald < [email protected] > wrote: I'd this is the prevailing thought, then I'm fine with going down the open vocabularies path. It will mean that solutions will need to pivot 'outside' of the STIX model I.e. by creating their own nodes in their internal databases based on the common selected field values, rather than directly via the kill chain TLO id, but that's not a big problem. My only concern would be enabling the field values to match easily... In other words making them case insensitive for string matching purposes. Cheers Terry MacDonald Cosive On 4/06/2016 05:24, "Piazza, Rich" < [email protected] > wrote: 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 vocabs 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