Hi Sean,
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.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 |
From: [mailto:]
On Behalf Of Barnum, Sean D.
Sent: Wednesday, 4 November 2015 5:41 AM
To:
Subject: [cti-stix] Some thoughts on Sightings and conversations to date (Part #1): use cases for sightings
All,
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.
I would definitely agree with the assertions of many here that there are a range of relevant sighting use cases that differ in their level of detail on their context of use.
I agree with the importance of keeping these in mind for all sightings-related discussions.
I agree with Jon Baker’s distinction between internal tool alert type of sighting and org-to-org sightings reports. I also agree with his identification of “Aggregate Sightings Analysis” though
do think of that more as a secondary (though still important) use case of how you make use of sightings rather the primary use case of how sightings themselves are captured and conveyed.
It looks like a lot of the discussion so far from Bret, Jason and a couple of others has been focused on the lower level M2M alert type sightings which I certainly concur are very important but
I also agree with some others that we need to make sure we cover not only these but the higher-level org-to-org cases as well. I like Terry’s characterization that in the end most CTI is about H2M2M2H. There are certainly sub-use-cases in there that only fit
the middle M2M part but they should always be considered as part of the whole picture also involving people.
One of the considerations that I have seen touched upon in the conversations is which information in a sighting is relevant, should be required, should be optional, etc.
I think it is useful to note that over the last few years of talking about sightings with the STIX community I have repeatedly heard statements or assertions of the importance of varying levels
of detail for sightings in the real world typically based on differing capabilities of tooling to provide detail or sensitivities in sharing arrangements of how much detail to share. I have heard examples of needs to share the following variations of sightings
for example:
Indicator X was seen (anonymized source, no observable detail provided, no count provided)
Source 1 saw Indicator X (identified source, no observable detail provided, no count provided)
Source 1 saw Q instances of Indicator X (identified source, no observable detail provided, count provided). One thing to consider here is that there has not been consistent agreement on exactly
what a count represents.
Source 1 saw Indicator X at time Y (identified source, no observable detail provided except timing, no count provided)
Source 1 saw Observation Z matching Indicator X at time Y (identified source, observable detail provided, no count provided)
Source 1 saw Observation Z matching Indicator X at time Y as detected by Method R (identified source, observable detail provided, no count provided, technical source details provided)
The key variations that I see here are: source, count, observation details (what was actually seen), timing, and detection method details. What I have heard expressed is that real-world conditions
may involve sightings made up of different pieces under different contexts but that the only real hard requirement is identifying which Indicator is being sighted.
Basically, it becomes a tradeoff between as much detail as possible (better for consuming analysts) and as little detail as possible (easier for producers) all within the constraining contexts
of what level of detail the producer has available and what they are allowed to share.
In the interests in beginning to capture this more officially I have taken an initial stab at fleshing out the Sighting Reporting use cases on the
STIX use case wiki. These can obviously use more love but hopefully we can use the wiki as a consistent way to capture our consensus.
Indicator Sighting Reporting
Simple Indicator Sighting Reporting
(+1)
Anonymized Indicator Sighting Reporting
Indicator Sighting Reporting with Count
Indicator Sighting Reporting
with Specific Observation
sean
