Re: [cti-stix] RE: Some thoughts on Sightings and conversations to date (Part #3): what should sightings be asserted against?

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

@Terry I know we had this conversation in Slack but for the benefit of the trail

My concern with this idea is it doesn't enable the entire original use case - a way to send a quick "+1" for a previously created definition.

- Someone sends me a pre-created indicator pattern - an exact pattern of some kind ("IP in this list")
- I see a match to that exact pattern
- I emit a "+1 I saw it", in a simple, compact fashion.

I do understand the use case you are trying to capture here, and it makes sense (you want to emit not just "I saw it" but "I saw this sub-pattern", for example, "I saw this IP from the list". 

My concern is, this is no longer a simple "+1". It is going to make the sighting a much more complicated structure than the original intent. 

I still think we need a compact, simple way to say "+1" on a pre-created definition, without having to compute a matching sub-pattern. In the case of a complex indicator where many different things have to match all at the same time, it doesn't make sense to re-emit them all just to have a "+1", it will bloat the message.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown

Terry MacDonald ---2015/11/05 07:29:17 PM---Hi Sean, I’ve come to the same conclusion. It does appear to be largely a difference in terminology.

From:        Terry MacDonald <terry@soltra.com>
To:        "Barnum, Sean D." <sbarnum@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date:        2015/11/05 07:29 PM
Subject:        [cti-stix] RE: Some thoughts on Sightings and conversations to date (Part #3): what should sightings be asserted against?
Sent by:        <cti-stix@lists.oasis-open.org>

---

Hi Sean,
 
I’ve come to the same conclusion. It does appear to be largely a difference in terminology.
 
I like Corey’s suggestions of abstraction. In the current model the “superset of your assertion above” is Observation (observable instance) rather than a redefining of the semantics of the term Sighting.
Basically the abstraction is Observable->Observation (observable instance)->Sighting.
 
The thing that prompted me down the path I was headed was the wish to separate the Observable Instances from the Observable Patterns more distinctively. When I was first learning STIX it took me a solid 6 months before I realized that Observables had pattern and instance flavors. I really would like a greater distinction between the two.
 
Would this line of thinking then mean that we can remove Observable Instances from being allowed within Indicators? 
 
i.e.
CybOX Observable->STIX Observation (observable instance only)
CybOX Observable -> STIX Observable pattern (only) -> STIX Indicator
 
And then will we use a top-level relationship with a relationship type of ‘Sighting’ to link the Observations with the Indicator if we wish to show that relationship?
 
To be honest I probably prefer it if we changed the naming somewhat within the Observable space to highlight the differences a bit better. It could help new people learning about STIX if:
 
Observable Instance became an Observation Object
Observable Pattern became a Pattern Object
 
Then we could say:
CybOX Observable used in STIX Observation 
CybOX Observable used in STIX Pattern used in STIX Indicator
 
That seems clearer to me….interested in others thoughts.
 
The use cases sound exactly the same to me. It is only the difference in the term used that makes them different as far as I can see.
 
Upon reflection I concur to a major extent. I still stand by the fact that we need to record the things ‘we see observe’ independently from the things ‘we are looking for’, hence my suggestion for using a relationship to indicate a Sighting of the Indicator. 
 
In a way using a relationship simplifies the model as the relationship object then becomes single standard simplified way to show a relationship exists. This arguably makes implementing this easier in code as there is ‘only one way to do it’…
 
Cheers
 
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | terry@soltra.com 
 
 
From: Barnum, Sean D. [mailto:sbarnum@mitre.org] 
Sent: Thursday, 5 November 2015 4:05 AM
To: Terry MacDonald <terry@soltra.com>; cti-stix@lists.oasis-open.org
Subject: Re: Some thoughts on Sightings and conversations to date (Part #3): what should sightings be asserted against?
 
Terry, 
 
It sounds to me like we agree almost completely on the use cases and information structure capabilities here.
It looks like our only real difference is which information structures we are applying which labels to.
The current model has a concept/construct called observable instance (observation) that looks to be the exact thing that you are applying the label “Sighting” to.
The current model has a concept/construct called Sighting that is a subset of the observable instance (observation) concept/construct with the additional constraint that the observation represents a match to an Indicator. I have not seen you this subset use case with a distinct label but rather flatten these two layers together. Do you recognize the distinction? Do you have a way to represent it? I personally think that this distinction is relevant.
 
More comments inline below.
 
From: Terry MacDonald <terry@soltra.com>
Date: Tuesday, November 3, 2015 at 8:10 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 #3): what should sightings be asserted against?

• The key here is that an assertion that something has been “sighted” is basically a statement that some particular observable characteristics have been seen.

I disagree with this statement. I assert that a Sighting is that something worthy of documenting has been seen. In my opinion this is a superset of your assertion above. Your statement precludes the ability for someone to record the unusual things they have found during an ‘Hunting Expedition’, which in turn stops them using STIX to ask others for more information about those unusual things.
 
[sean]I don’t think it precludes this at all. It is simply different semantics being used for sighting and observable instance (observation). Someone can very easily “record the unusual things they have found during an ‘Hunting Expedition’” using an observable instance (observation) either standalone in a package or within an Incident if conveying further context is desired.
<STIX_Package>
<Observables>… weird stuff you saw …</Observables>
</STIX_Package>
 
<Incident>
<Related_Observables>… weird stuff you saw …</Related_Observables>
</Incident>
 
I like Corey’s suggestions of abstraction. In the current model the “superset of your assertion above” is Observation (observable instance) rather than a redefining of the semantics of the term Sighting.
Basically the abstraction is Observable->Observation (observable instance)->Sighting.
 
The use cases sound exactly the same to me. It is only the difference in the term used that makes them different as far as I can see.

• Other constructs (TTPs, TAs, etc) may be associated with particular observable characteristics that may indicate their presence but a “sighting” is not of them directly but rather of observable characteristics that lead you to believe that it is that other thing (TTP, TA, etc.) that you have seen. The TTPs or TAs were not observed, evidence of their presence or identity were what was actually observed.

This presupposes that you know what the Sighting relates to. If all that you know is that ‘there is something weird here and I need to ask others if they are also seeing it’ then there is no Indicator at play. Someone may reply with their own Indicator to TTP or other object that they have asserted is related to what you have seen, but for that initial observation and request for help there is no related Indicator.
 
[sean]At the end here you said “but for that initial observation and request for help there is no related Indicator”. Here you are using the semantics of the existing model, the term “observation". It is an observation (observable instance) that conveys that “there is something weird here”. I would certainly agree that every Indicator starts with an observation (observable instance) of “there is something weird here”. These initial observations typically originate from incident response/investigation, malware analysis, digital forensics or hunting. At some point when the “weird” observation is understood to be evidence of a particular TTP then an observable pattern can be derived from the observable instance (observation) and an Indicator can be defined using the pattern. Any future observations of that Indicator would then be Sightings of it.
 
I really do think that 98% of the disagreement in this thread comes down to the fact that the concept/construct that you are referring to as Sighting is currently called an observable instance (observation) in the current model. It looks like they are the exact same thing. I don’t think we are disagreeing at all on the sorts of activities and information involved. We are simply applying a different label to the concept/construct. And the current model already uses the term Sighting to apply to a subset of observable instance (observation). I would propose that the distinction represented by the subsetting is semantically important.

• This is not to say that it is not of use to make assertions that things like TTPs or TAs have been “seen” but for these situations, I believe it would be more appropriate to assert the derived “sighting” as an analytic assertion (currently being referred to in list threads as investigation/tagging) rather than as a hard sighting.

I believe that the idea of an independent Sighting object can work for both the ‘derived’ sighting and the hard sighting as you describe above. If we are using top-level relationship objects, then we would be able to relate the Indicators to the Sightings once we eventually discover the underlying Indicators that the Sightings relate to. We can also just have independent Sightings where there is no Indicator relationship. This would potentially aid in discovery of Indicators and new previously undiscovered APT style attacks where members of a threat sharing group share the ‘odd’ traffic they have found. This may prompt recognize commonality across multiple different Organizations that may help DFIR staff discover new previously undiscovered malware.
IMHO independent Sightings objects are a pre-requisite for this occurring. 
 
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:54 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Some thoughts on Sightings and conversations to date (Part #3): what should sightings be asserted against?
 
The third sightings sub-topic I wanted to comment on is around the question of whether sightings should be only against Indicators or also to any other constructs.
I think there has been a range of comments on this one including opinions ranging from sightings of anything to sightings of observable instances to sightings of just indicators.
Again, putting on my expert hat rather than my co-chair hat, I wanted to offer some thoughts on this including some clarifying comments on the intended semantics and structure of the current STIX model which I have intimate knowledge of.

• I would agree with the few folks who posted espousing the opinion that sightings should only be for Indicators.
  • I think a good deal of this comes down to the intended semantics of the model (partially described in my previous post) and the nature of the information domain that the model intends to support. The model strives to clearly delineate key relevant concepts such as Threat Actors (who), TTP (how), incidents (what, where, when), Indicators (clues of evidence to look for), etc. I believe this delineation, the semantics of each concept and the semantics of the relationships between them are all very important to support effective threat information analysis and sharing.
  • The key here is that an assertion that something has been “sighted” is basically a statement that some particular observable characteristics have been seen. The part of the model that characterizes particular observable characteristics that might be seen and what that means is Indicator.
    • Other constructs (TTPs, TAs, etc) may be associated with particular observable characteristics that may indicate their presence but a “sighting” is not of them directly but rather of observable characteristics that lead you to believe that it is that other thing (TTP, TA, etc.) that you have seen. The TTPs or TAs were not observed, evidence of their presence or identity were what was actually observed.
    • We should also remember that the confidence in assertions that particular observable characteristics identify specific TTPs or TAs are almost never 100%. That is why the STIX model provides Confidence constructs for Indicators and any other assertion of relationship. Different observable characteristics may be associated with the same TTP or TA with differing levels of confidence. Because of this it is more appropriate that assertions of sightings are made against the observable patterns (indicators) they actually match rather than skipping right past all the important context (including confidence) and asserting a direct sighting against the higher-order construct.
    • If you have the higher-order construct (TTP, TA, etc.) along with Indicators associating observable characteristics with them and sightings reports on those indicators your graph includes clear paths between the sighting and the higher-order construct but it also maintains the integrity and pivotability of all the context in between.
  • This is not to say that it is not of use to make assertions that things like TTPs or TAs have been “seen” but for these situations, I believe it would be more appropriate to assert the derived “sighting” as an analytic assertion (currently being referred to in list threads as investigation/tagging) rather than as a hard sighting.
• Aharon gave the following example to argue against sightings being against Indicators and instead be against Observable instances: "You have 100 indicators with the same observable. Your IDS fires off an alert for that observable. Which of the 100 indicators would you sight?"
  • In my opinion this example actually argues strongly FOR sightings being against Indicators and not just a restatement of observable instances.
  • If the indicators all define the same observable pattern then what is the difference between them?
    • I would propose that in the real world different indicators within the set of 100 would be defining different contexts for observation of the pattern (e.g. one asserting it indicates the presence of certain malware, another associating it with infrastructure used by a particular actor, another combining it with other observables to indicate something with higher confidence, etc.). Different parties may all be telling you to look for something “bad” but they may have differing contexts and level of knowledge about why it is “bad”.
    • If all you are saying is that an observable instance was seen without associating it to the relevant Indicators then you are losing all of this context.
    • If you see an observable instance that matches the observable pattern defined in 100 indicators then you “sight” all of them.
    • The consumer of this sighting (whether internal or extra-org) can then utilize the various contexts (within the indicators) that the sightings convey.

sean