[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 #3): what should sightings be asserted against?
Perhaps this is just a naming thing, but I would think that an observation and the thing observed are different and should not be combined. The observation is an “act” involving an observer. What is observed is some condition. The observer would observe some interesting condition, the observable thing in its context. So <Sam> observes that <node A is down> at <12:23 AM 11/3/2015>. That leaves the state of “Node A” independent of it being observed or not, or observed multiple times or by multiple parties.
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.
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.
<Observables>… weird stuff you saw …</Observables>
<Related_Observables>… weird stuff you saw …</Related_Observables>
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.
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.
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.
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | email@example.com
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.