[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] STIX Sightings
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]