[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] RE: STIX Sightings
|
I’m with Terry that this is a STIX use-case as much as a TAXII use-case to facilitate.
1) If I look at our own customers and prospects (noting we’ve already implemented this process/entity) its not a given TAXII is even available in the ecosystem or possible to be implemented. STIX threat models (e.g. Information about threats and security
information that inform the threat model) should be able to be informed by non TAXII transport mechanisms.
2) It has nothing to do with transportation, its purely a threat model information position. Just like the incident object, it describes contextual information (to what extent something was effected or not, how it was resolved or not, etc.) to threat information
in order to inform the entire set of stakeholders relevant for a threat intelligence model as we try and describe in STIX. Although the whole request/answer chain (like tasking) should not be in the model, the resulting information position should in our opinion.
J-
From: Terry MacDonald <terry@soltra.com>
Date: Thursday, October 29, 2015 at 10:45 PM To: "Barnum, Sean D." <sbarnum@mitre.org>, 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" <cti-stix@lists.oasis-open.org> Subject: RE: [cti-stix] RE: STIX Sightings 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. 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> 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> 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> 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 +1 on what Patrick and Jonathan said From:
"Bush, Jonathan" <jbush@dtcc.com> 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]
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
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 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]