Re: Some thoughts on Sightings and conversations to date (Part #1): use cases for sightings

["Barnum, Sean D." <sbarnum@mitre.org>]

Terry, I think my Part #2 post on semantics covers and clarifies much of this I hope.

I think the use cases you describe here are supported by the current model. It is just the semantics you are using for Sighting and I am using for Sighting (based on the current model) that differ.

Comments inline below

Sean

From: Terry MacDonald <terry@soltra.com>
Date: Tuesday, November 3, 2015 at 6:58 PM
To: "Barnum, Sean D." <sbarnum@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: RE: Some thoughts on Sightings and conversations to date (Part #1): use cases for sightings

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

 

[sean]In the current model, this is intended to be handled using an Incident (some set of activity observed in an organization believed to be of security interest).

<Incident>

<Related_Observables>… weird stuff you saw …</Related_Observables>

</Incident>

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.

[sean]I absolutely agree with your characterization of a hunting workflow. The current Incident is designed to support that. Once the “weird” stuff is better understood and can be tied to specific TTP then an Indicator can be created, added to the Incident and then the Indicator alone or the refined Incident can be shared.

 

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.

[sean]I agree that they should be separate objects but where we disagree is on the semantics of Sighting. Even if they are separate objects the current model semantics (which I would agree with) are that a Sighting is always related to an Indicator. In the current model, the sort of observable instances (in absence of an Indicator) you refer to as Sightings are simply observations (observable instances) that can be conveyed on their own or within an Incident to provide surrounding context.

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.

[sean]The current model semantics (and I) would agree that you can have an Observation related to an Incident (see example above) and then that Incident can be related to a Campaign and still not have an Indicator. It does everything you are describing it just does not call it a Sighting. It calls it an observable instance (observation). The term Sighting is reserved for the semantically distinct concept of an observation that matches a specific identified pattern to look for.

I observe A

I observe B

<------------------------------ You tell me to be on the look out for X

I observe X

I tell you I sighted X  -------------------------->

 

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).

[sean]Something “observed as a fact (no assertion/guessing)” is the definition of an observable instance (observation) in the current model. As described in my other post, I do not see the value in redefining the semantics of terms if the concepts and structures are already there to support the identified use cases.

·         Indicator: ‘Contain’ only Observable Patterns. To ultimately be the place that Orgs describe the things they believe indicate a particular scenario is occurring.

[sean] This is exactly the intent of what Indicators are in the current model. Once we break out Sightings to a separate object rather than embedded within Indicator then it will only be what you describe here. No semantic redefinitions will be required.

 

In this way, an Organization can:

1.       describe the some weird traffic they are seeing

[sean]Yep. Can be done today.

2.       share that sighting with others (maybe as part of a STIX request package (see my other posts)).

[sean]Yep. Can be done today as explained above typically within an Incident but could be a standalone Observable within a Package. The only difference is your use of the term “sighting” here. The current model semantics refer to this as an observable instance (observation).

3.       A third party can then create an Indicator based on the sightings shared with the community

[sean]Yep. Can be done today. Again, the only difference is your use of the term “sighting” here. The current model semantics refer to these as observable instances (observations).

4.       The Indicator can then be associated with the sightings that were seen previously.

[sean]Yep. The previous observable instances (observations) could then be associated with the Indicator by asserting a Sighting relationship. Again, this maintains the important semantic distinction between just something that was observed and something that was observed that matched an identified pattern to look for.

 

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.

[sean]All of this is possible today it is just the use of the term sighting here that differs. What you call sightings here are called observable instances (observations) in the current model.

 

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.

[sean]I believe after reading through all of your use cases and usage descriptions that the current model and its semantics provide everything you are looking for (except for breaking out Sighting into a separate object which is what we are already planning on doing). I think the only difference is in the semantics of the term sighting. If you took all of the cases where you are describing what you are calling sightings where they are not associated with an Indicator and simply used the existing term observable instance (observation) I think you would be set.

If the model cannot support identified use cases then I am all for finding the gaps/issues and fixing them. I would just rather avoid arguing over the label to apply to an existing information structure.

 

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: Wednesday, 4 November 2015 5:41 AM
To: cti-stix@lists.oasis-open.org
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

1. Simple Indicator Sighting Reporting (+1)
2. Anonymized Indicator Sighting Reporting
3. Indicator Sighting Reporting with Count
4. Indicator Sighting Reporting with Specific Observation

 

sean