[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Some thoughts on Sightings and conversations to date (Part #1): use cases for sightings
I think this misses an important point. Not all Sightings will have corresponding Indicators. In the current STIX model, yes, that is how they are related in the model. Which does often reflect how the ‘Monitoring’ part of Incident Response works. But in reality, when doing Incident Response ‘Hunting’, the work flow (in my experience) operates more like this:
· Go look in your logs and in your old network packet captures
· See something weird (in logs mainly)
· Try to work out if that weird thing is malicious
· Ask others for insight if you are unsure
· Only close the investigation if you are sure it is benign
This process doesn’t start with an Indicator. It starts with an Observed Instance of something, and can eventually arrive at an Indicator. It’s almost the reverse of monitoring. This Hunting workflow which is done today throughout the industry often does not use a STIX Indicator at all. Sometimes its just something non-standard that the Hunter notices. There is no particular pattern being looked for, rather it is the statistical outliers that the Hunter focuses on. It’s the ends of the bell curve.
This is part of the reason that I believe that a Sighting needs to be a completely independent top-level object from an Indicator. It can relate to an Indicator but only if there is one to relate to. It is quite plausible for a Sighting to be related to an Incident, and a Campaign, but still not have an Indicator. And I think that would be perfectly acceptable.
The Hunting workflow is also the reason that I want to see Indicator and Sighting completely split apart to become fully independent. I would like to see this:
· Sighting: ‘Contain’ only Observable instances. To ultimately be the place that Orgs describe the things they have observed as a fact (no assertion/guessing).
· Indicator: ‘Contain’ only Observable Patterns. To ultimately be the place that Orgs describe the things they believe indicate a particular scenario is occurring.
In this way, an Organization can:
1. describe the some weird traffic they are seeing
2. share that sighting with others (maybe as part of a STIX request package (see my other posts)).
3. A third party can then create an Indicator based on the sightings shared with the community
4. The Indicator can then be associated with the sightings that were seen previously.
Fully separating the objects allows Sightings to happen before the creation of an Indicator. It also allows an Indicator to happen before a Sighting. Or both happen independently, and be updated in the future. It makes the most sense in my mind.
The list of use cases in the use case list is all have the presupposition that the Sighting has an Indicator. This is just not the case all the time, and in my opinion limits the possibilities available to us if we used an independent Sighting object.
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | firstname.lastname@example.org
Putting on my expert hat rather than my co-chair hat, I thought I would offer a few thoughts on Sightings and some of the great conversation that has occurred so far on the list.
In an attempt to keep it as concise as I can I will break things up into a few separate posts each focused on one sub-topic and will try to keep things as “bulletized” as I can. :-)
I will also try to stay focused right now on issues specifically related to Sightings and leave to later some of the other topics (request/response, ID format, relationship object, etc.) that have branched out of the sightings discussions but are buried within the sightings threads.
So, the first sub-topic I wanted to comment on is around use cases for sightings.
There has been some very good points raised on this sub-topic. Thank you all for contributing.