Re: [cti-stix] STIX Sightings

[Jerome Athias <athiasjerome@gmail.com>]

I have to admit that i am not following too much TAXII now. (flood of
emails, etc. well u know)
And sorry posting that in cti-stix, but while related to this current
topic, and also because John Doe introduced the notion of Broker, i
would recommend to have a look at the IETF SACM architecture:
https://datatracker.ietf.org/doc/draft-ietf-sacm-architecture/



2015-10-30 7:53 GMT+03:00 Jordan, Bret <bret.jordan@bluecoat.com>:
> Yes, I see this request / response going over the TAXII 2.0 channel
> structure.  Our design could handle this use case / work flow very easily.
> As it is really one of my core use cases I brought up in TAXII land long
> ago.  That is two network devices talking back and forth.  I just called
> dynamic data enrichment.  But it is effectively the same thing.
>
> Bret
>
> Sent from my Commodore 64
>
> On Oct 29, 2015, at 10:12 PM, Jerome Athias <athiasjerome@gmail.com> wrote:
>
> I do understand the use cases
> (Of course when i find a suspicious file, i will check its hash on
> virustotal before starting analyzing it)
> Now i would more imagine to send RFIs via TAXII. Where we could imagine an à
> la DNS architecture of TAXII servers. For that i would imagine an API for
> TAXII.
> And yes of course this API mechanism can only exists if it supports
> (understands) STIX/CybOX/MAEC...
>
>
> On Friday, 30 October 2015, Terry MacDonald <terry@soltra.com> wrote:
>>
>> I disagree here. I think it’s a STIX problem to solve, and here’s why….
>> (apologies for the length of the email!)
>>
>>
>>
>> PROBLEM:
>>
>>
>>
>> There is no real mechanism within STIX for a consumer of STIX data to ask
>> a question from the rest of the threat sharing community that they are part
>> of. This functionality is required if we are going to get good
>> multi-directional threat intelligence sharing happening.
>>
>>
>>
>> - A threat sharing community member has detected an IP address while doing
>> some local network hunting that seems to be malicious, but they are unsure
>> if it actually is. STIX needs to be able to allow the community member to
>> send out a 'does anyone have information they can share about this' STIX
>> request out to the entire community, and allow any other community member to
>> reply to the community member. The replies may be shared with the entire
>> community, or may be sent directly to the requester.
>>
>>
>>
>> This is different from the normal 'broadcast' style STIX message, where
>> the message is just sent to all parties and no replies are expected. With
>> STIX request/response there is a direct question/answer relationship
>> required.
>>
>>
>>
>> Please note this request/response is also different to TAXII Query, as the
>> question is being asked to all members of the channel, rather than just the
>> single TAXII server you are locally connecting to (which is IMHO more where
>> TAXII Query fits in).
>>
>>
>>
>> POTENTIAL ANSWER:
>>
>>
>>
>> Creating a STIX Request Package and a STIX Response Package seems to be a
>> good answer to this problem.
>>
>>
>>
>> As I see it, a sender would have two types of questions they would want
>> answered:
>>
>> - I have a 'thing' (e.g. IP address), and I to find more objects that are
>> related to this thing so I understand it better (crowdsourced responses)
>>
>> - I have a particular STIX object and I would like to get the latest
>> version of that object from the producer (particular object responses)
>>
>>
>>
>> For the crowdsourced responses option, the STIX Request Package would
>> contain a list of related STIX objects that the sender would like more
>> information about. The STIX Request Package could contain something as small
>> as a single IP address, or could contain a large slice of related data e.g.
>> a list of 5200 Observables, Indicators, TTPs, Campaigns and Threat Actors.
>> The STIX Request package would be sent to all recipients in the Threat
>> Sharing Group, and any/all of the Threat Sharing Group members would be able
>> to respond via a STIX Response package. STIX Responses from Threat Sharing
>> Group members would be able to be sent to all Threat Sharing Group members
>> (group reply) or sent directly back to the original STIX Request package
>> author as a direct response (private reply). The STI Responses need to be
>> able to say 'Yes, we've seen it, and we've included some objects that are
>> related to it', or 'No, we've not seen it'.
>>
>>
>>
>> For the particular object responses option, the STIX Request Package would
>> contain a list of STIX identifiers that the sender would like more
>> information about. The STIX Request Package would be sent directly to the
>> producer of the object being queried. ** This relies on the fact  that STIX
>> IDs include the producers namespace, that the namespace includes the domain
>> name of the Producer, and that the producer has the relevant TAXII
>> auto-discovery functionality enabled in their setup **. The producer would
>> then look at the STIX Request Package author to determine if the proiducer
>> wishes that information to be shared, and also check if the STIX Request
>> Package author has the correct permissions to have access to that data. If
>> they do then the data (or subset of the data) should be returned. This sort
>> of STIX Request Package would always be sent back original STIX Request
>> package author as a direct response (private reply).
>>
>>
>>
>> Having both these features would enable more question and answers to be
>> asked across threat sharing groups, meaning that Threat Analysts and
>> Incident Responders would have the ability to find out more about their own
>> particular use cases - hopefully improving the speed and effectiveness of
>> Incident Response.
>>
>>
>>
>> Cheers
>>
>>
>>
>> Terry MacDonald
>>
>> Senior STIX Subject Matter Expert
>>
>> SOLTRA | An FS-ISAC and DTCC Company
>>
>> +61 (407) 203 206 | terry@soltra.com
>>
>>
>>
>>
>>
>> From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
>> On Behalf Of Barnum, Sean D.
>> Sent: Friday, 30 October 2015 2:26 AM
>> To: Patrick Maroney <Pmaroney@Specere.org>; Aharon Chernin
>> <achernin@soltra.com>; Davidson II, Mark S <mdavidson@mitre.org>; Joep
>> Gommers <joep@eclecticiq.com>; Jonathan Bush (DTCC) <jbush@dtcc.com>;
>> cti-stix@lists.oasis-open.org
>> Subject: Re: [cti-stix] RE: STIX Sightings
>>
>>
>>
>> I agree that RFIs (or really Request/Response scenarios in general) should
>> be supported in the CTI ecosystem but think they are best addressed at the
>> TAXII level and not within STIX and/or CybOX.
>>
>> Let’s let STIX and CybOX focus on the information going back and forth and
>> not on the specifics of the process of how it goes back and forth.
>>
>>
>>
>> sean
>>
>>
>>
>> From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on
>> behalf of Patrick Maroney <Pmaroney@Specere.org>
>> Date: Thursday, October 29, 2015 at 11:22 AM
>> To: Aharon Chernin <achernin@soltra.com>, Mark Davidson
>> <mdavidson@mitre.org>, Joep Gommers <joep@eclecticiq.com>, "Jonathan Bush
>> (DTCC)" <jbush@dtcc.com>, "cti-stix@lists.oasis-open.org"
>> <cti-stix@lists.oasis-open.org>
>> Subject: Re: [cti-stix] RE: STIX Sightings
>>
>>
>>
>> Propose that (1) the CTI Standard should include support for and RFI
>> (Request For Information) mechanism and (2) this could just a
>> form/requirement of  a STIX Query Language.
>>
>> .
>>
>> Patrick Maroney
>>
>>
>>
>>
>>
>> From: "Chernin, Aharon" <achernin@soltra.com>
>> Date: Thursday, October 29, 2015 at 11:17 AM
>> To: Mark Davidson <mdavidson@mitre.org>, Joep Gommers
>> <joep@eclecticiq.com>, "Jonathan Bush (DTCC)" <jbush@dtcc.com>, Patrick
>> Maroney <Pmaroney@Specere.org>, "cti-stix@lists.oasis-open.org"
>> <cti-stix@lists.oasis-open.org>
>> Subject: Re: [cti-stix] RE: STIX Sightings
>>
>>
>>
>> I agree that a Sighting should just be a positive, “I saw this”. I’d love
>> to keep the complexity down here for our initial pass. I believe that
>> implementing a negative sighting is probably going to be orders of more
>> magnitude than a positive sighting for a tool vendor. A positive Sighting
>> can be sent as a TAXII client operation due to the limited number of them
>> that will be generated (ie. Not infinite) and the fact that no question is
>> being asked. However, if we have to ask someone “Have you saw this", we will
>> likely require the tool vendor implement a TAXII server to send these
>> negatives.
>>
>>
>>
>> TLDR
>>
>> Positive Sightings = STIX w/TAXII Client operation
>>
>> Negative Sightings = STIX w/TAXII Server
>>
>>
>>
>> What if we implement RFIs using TAXII 2 query instead? We could send a
>> TAXII query request asking if a particular observable has been seen.
>>
>>
>>
>> Aharon
>>
>>
>>
>> From: <cti-stix@lists.oasis-open.org> on behalf of "Davidson II, Mark S"
>> <mdavidson@mitre.org>
>> Date: Thursday, October 29, 2015 at 7:50 AM
>> To: Joep Gommers <joep@eclecticiq.com>, "Jonathan Bush (DTCC)"
>> <jbush@dtcc.com>, 'Patrick Maroney' <Pmaroney@Specere.org>,
>> "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
>> Subject: RE: [cti-stix] RE: STIX Sightings
>>
>>
>>
>> The Request/Response case and the negative sighting case seem to be
>> slightly different to me. For the request/response case, you have a request
>> and a specific response to that request. Some form of “empty” response in
>> that context could be sufficient for the “negative sighting” (vs. adding a
>> field to the data model).
>>
>>
>>
>> In terms of a sighting that was not requested (e.g., event-based
>> exchanges, like a sensor that sends sightings as they are seen), I don’t see
>> how a negative sighting would be useful, since there is an infinite number
>> of things that e.g., a sensor hasn’t seen at any given point in time.
>>
>>
>>
>> Based on the above, I see how the ability to say “I haven’t seen that”
>> makes sense, but I’m not sold that it needs to be accomplished with a field
>> in the sighting object.
>>
>>
>>
>> Thank you.
>>
>> -Mark
>>
>>
>>
>> From:cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
>> On Behalf Of Joep Gommers
>> Sent: Thursday, October 29, 2015 9:32 AM
>> To: Bush, Jonathan <jbush@dtcc.com>; 'Patrick Maroney'
>> <Pmaroney@Specere.org>; cti-stix@lists.oasis-open.org
>> Subject: Re: [cti-stix] RE: STIX Sightings
>>
>>
>>
>> +1 on what Patrick and Jonathan said
>>
>>
>>
>> From: "Bush, Jonathan" <jbush@dtcc.com>
>> Date: Thursday, October 29, 2015 at 2:30 PM
>> To: 'Patrick Maroney' <Pmaroney@Specere.org>,
>> "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, Joep
>> Gommers <joep@eclecticiq.com>
>> Subject: RE: [cti-stix] RE: STIX Sightings
>>
>>
>>
>> So from an implementation perspective (the part I was more eluding to
>> conversation on), we would need a “positive/negative” indicator as a
>> mandatory field, no?  Any other implementation implications?
>>
>>
>>
>> From: Patrick Maroney [mailto:Pmaroney@Specere.org]
>> Sent: Thursday, October 29, 2015 9:29 AM
>> To: cti-stix@lists.oasis-open.org; Bush, Jonathan; 'Joep Gommers'
>> Subject: Re: [cti-stix] RE: STIX Sightings
>>
>>
>>
>> Source:  RFI: Have you seen this?
>>
>> Recipient: No.
>>
>> ...Or more nuanced:
>>
>> Recipient: No I looked over this period of time using this method and have
>> this level of certainty we've not had anything matching this pattern.
>>
>> Patrick Maroney
>> President
>> Integrated Networking Technologies, Inc.
>> Desk: (856)983-0001
>> Cell: (609)841-5104
>> Email: pmaroney@specere.org
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 29, 2015 at 6:23 AM -0700, "Bush, Jonathan" <jbush@dtcc.com>
>> wrote:
>>
>> A “negative sighting”?  Mind = Blown!
>>
>>
>>
>> Can you talk about that some more?
>>
>>
>>
>> From:cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
>> On Behalf Of Joep Gommers
>> Sent: Thursday, October 29, 2015 5:39 AM
>> To: cti-stix@lists.oasis-open.org
>> Subject: [cti-stix] STIX Sightings
>>
>>
>>
>> Dear list,
>>
>>
>>
>> My view on sightings:
>>
>>
>>
>> Threat Intelligence is in part about moving unknown unknown’s to known
>> unknown, e.g. discovery new “threats” (ignoring for just a second the
>> analytical construct of it). Part moving these known unknown, to known
>> knowns, by understanding the problem well enough to meet stakeholder’s
>> information needs in whatever spectrum of deterrence, defeat or prevention
>> they are working. For example; the SOC (deter) requires indicator and
>> warning information, the IR teams (defeat) require ad-hoc intelligence
>> support and/or executives/commanders need strategic intelligence reports
>> (prevention).
>>
>>
>>
>> The emerging threat intelligence or threat management function in the
>> large enterprise and government institution revolves around Threat
>> Management. In effect some variation of the above process with the
>> additional strategic questions; are we “managing” / “in control” of the
>> threats we identified. This is done in part by validating if your
>> constituency is informed, effected and if – or to what extent – they have
>> deference, defeat or preventive measures in place.
>>
>>
>>
>> Sightings play a part in this process, by ensuring a Threat Management
>> capability can validate if – based on current information position – the
>> constituency is potentially effected or not. Further analysis will determine
>> if incident management is required to really judge if the organization is
>> affected or not and to what extent it is managed. For me this implies a
>> couple of things for STIX Sightings:
>>
>> ·         Sightings should be either positive (I’ve seen a potential
>> indication of a threat) or negative (I haven’t seen an indication)
>>
>> ·         Sightings are either produced by machines or by humans.
>>
>> ·         In the interplay between man and machine, it is not a given that
>> the machine is aware of every detail that can potentially be sighted (e.g. A
>> specific observable). Sometimes the interpretation of an analyst is required
>> to determine this. For example, a STIX indicator with nothing more then a
>> rough description could be enough for a human analyst to interpret and sight
>> it. Similarly, if a hypothesis is described in a report object, without any
>> further technical indication or observable information, it should allow for
>> human interpretation and potential sighting.
>>
>> ·         In conclusion; sightings should be thought of as MUCH wider then
>> observables and indicators. Surely into TTP, Exploit Targets, Incidents,
>> Reports, etc. In part because you can’t ASSUME that the full context is
>> available to be sighted.
>>
>> ·         Estimative language or estimative judgement in an important
>> construct to consider in the world of Sightings, Relationships and the
>> future of STIX. Human judgement allows for estimate judgement and machines
>> allow for probability based on pattern interpretation of STIX intelligence.
>>
>>
>>
>> Lastly, at EclecticIQ we’ve actually implemented a Sightings Object
>> alongside the world of STIX objects that behaves in much of the way I
>> describe above – with success.
>>
>>
>>
>> I’ll try and find time in the next two weeks to share more real-world
>> lessons learned to inform STIX 2.0.
>>
>>
>>
>> Best regards,
>>
>> Joep
>>
>>
>>
>>
>>
>>
>> DTCC DISCLAIMER: This email and any files transmitted with it are
>> confidential and intended solely for the use of the individual or entity to
>> whom they are addressed. If you have received this email in error, please
>> notify us immediately and delete the email and any attachments from your
>> system. The recipient should check this email and any attachments for the
>> presence of viruses.  The company accepts no liability for any damage caused
>> by any virus transmitted by this email.
>>
>>
>> DTCC DISCLAIMER: This email and any files transmitted with it are
>> confidential and intended solely for the use of the individual or entity to
>> whom they are addressed. If you have received this email in error, please
>> notify us immediately and delete the email and any attachments from your
>> system. The recipient should check this email and any attachments for the
>> presence of viruses.  The company accepts no liability for any damage caused
>> by any virus transmitted by this email.