OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-stix] Question on Sightings Proposal and Cybox Observations


I am not a fan of STIX Request and STIX Response messages...  Those seem like product / implementation things or protocol level things (aka TAXII).  STIX need to focus on documenting Cyber Threat Intelligence.  


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 Apr 4, 2016, at 22:42, Terry MacDonald <terry.macdonald@cosive.com> wrote:

Hi Jason,

I don't actually think the pattern would be shared directly within STIX, but that the workflow would actually follow a similar pattern as described below. I have tweaked the workflow descriptions you gave to reflect how I view the process to work. I would be interested in your comments and those of others.

1) My SOC needs to be able to tell my threat intelligence group “we are seeing X followed by Y followed by Z, this looks strange”
This is where we need to be able to send a series of linked observables as a strange ordered series of observed behaviours. I see this as where the STIX Observation object (or series of linked objects) will be used. This is potentially where the STIX request/response message type would come into play as well, as the STIX request could contain the observation objects and would also ask "we are seeing these... is anyone else seeing this?", but it would ask it only of the local threat intel group.

2) My threat intelligence group needs to be able to ask my ISAO “we are seeing X followed by Y followed by Z, are you seeing anything like this”
This step is where the threat intel group could check its own threat intelligence repository to see if they have any matching observables or matching indicators that could describe all or part of the observed behaviours. If they don't find anything, they would produce a STIX request message out to each different threat sharing group they are part of, asking if anyone has seen the observed events, and if so to please reply with more information. I see this as being a STIX request message per sharing group containing the observations, and a question type meaning 'has anyone seen these?"

3) Org 2 tells Org 1 via the ISAO “yes we are seeing that pattern as well, here's an indicator we created earlier and some more information about this
This is where the STIX response would be used. The STIX response could contain the Indicators that match the traffic, the threat actor involved in previous attacks, the malicious tools used, courses of action, the campaigns underway from that threat actor right now. In fact any STIX content that Org2 feels would be useful, and that they are willing to provide out to the whole trustgroup.

3b) The threat intel group analyses the results from Org 2 and determines it looks logical enough to give back to the SOC
The SOC receives a STIX response (matching the STIX request they sent earlier) from the threat intelligence team repository, and it contains some indicators to look for, as well as some more information about the threat actor that Org2 believes to be involved with this attack. The SOC now have additional indicators to look for and roll those out to their detective and protective controls.

4) Org 1 investigates the pattern and finds that it matches the observables they have exactly. Org 2  “+1” the pattern
This would be done within Org1 after they investigate the pattern, hand the details to the SOC and the SOC finds additional matches. This can be done in two ways in my mind:
  • Org 1 can generate an Opinion object which will allow them to say they 'strongly agree' with the content in the Org2 indicator object. This distribution of this Opinion object will increase the trust that others in the sharing groups have for that indicator, and effectively allows less skilled organizations to crowd source which objects are considered more 'truthful'.
  • Org 1 can also generate Sightings (in whatever form we decide) and can provide those back to Org2 to allow them to gain more insight. This will in turn allow for Org2 to refine their Indicators to improve the quality of the matching, and reduce the number of false positives.
5) Org 3 (and many other orgs) “+1” the pattern as well
This would be done within each Org after they investigate the pattern, and find additional matches. This can also be done in two ways:
  • Org X can generate an Opinion object which will allow them to say they 'strongly agree' with the content in the Org2 indicator object. This distribution of this Opinion object will increase the trust that others in the sharing groups have for that indicator, and effectively allows less skilled organizations to crowd source which objects are considered more 'truthful'.
  • Org X can also generate Sightings (in whatever form we decide) and can provide those back to Org2 to allow them to gain more insight. This will in turn allow for Org2 to refine their Indicators to improve the quality of the matching, and reduce the number of false positives.

I don't believe that we need to be able to distribute patterns outside of indicators in order to do this workflow, and I believe that we have the basic structures to do this if we added the Opinion object and added the STIX request/response message types..

-- 
Cheers

Terry MacDonald | Chief Product Officer

<cosive_mail_signature.png>



On 5 April 2016 at 06:11, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

I have a cross-cutting STIX and Cybox question, and answering it on Slack seems too difficult (bouncing between too many channels).

I have been reading through the STIX Sightings proposal and also the Cybox Observation proposal. I am not sure either of them take into account composite, behavioral use cases for sightings and observations.... but maybe I am simply misunderstanding.

Can someone explain how the below use cases can be done using the existing proposals? The main part I see the existing proposals falling down on are 1-3. I can't figure out how to communicate an observation of behavior, that is not an already existing indicator.

-

1) My SOC needs to be able to tell my threat intelligence group “we are seeing X followed by Y followed by Z, this looks strange”

2) My threat intelligence group needs to be able to ask my ISAO “we are seeing X followed by Y followed by Z, are you seeing anything like this”

3) Org 2 tells Org 1 via the ISAO “yes we are seeing that pattern as well, lets create an indicator for this pattern to publish to ISAO

4) A generalized indicator pattern is created and Org 1 and Org 2 both “+1” the pattern

5) Org 3 (and many other orgs) “+1” the pattern as well

-
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 



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]