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.