[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?
>To be honest I probably prefer it if we changed the naming somewhat within the Observable space to highlight the differences a bit better.
I definitely agree. I thought that we had an issue already in the tracker for this but can’t seem to find it so maybe we forgot to put one in.
I would suggest Observation and Observable Pattern.
I think the term Pattern is too general as there are various forms of patterns including
kill chains or attack patterns as instances of activity patterns (I think this will become more clear during some of the abstraction we will likely be doing with some of the key constructs.
>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
BTW, this is how the model works today. Indicator/Observables are always observable patterns not instances. Observable instances only potentially exist in Indicators today if they are part of sightings. Once we break out sightings then there will be no observable instances anywhere within Indicator. One of the other issues on the table that I would support pursuing is to simplify the Indicator structure by removing the separate Observable property and simply defining a CybOX observable pattern as one form (the default form) of Test_Mechanism. This would make this issue of clarity on the observable instance vs observable pattern even simpler.
There is documentation here outlining where in the model observable instances are used and where observable patterns are used. As you suggest, I think it makes sense to label all the instance uses as Observation (rather than just generic Observable) and all observable pattern uses as Observable Pattern (rather than just generic Observable).
This would likely clear up much of the confusion between observable instances and observable patterns.
>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?
Yes. I think of Sighting as a type of relationship between an Observation and an Indicator with one fine point of nuance that brings into play my recent posts with Corey in regards to the distinction between the details of the Observation and the thing that was actually observed. When I say Observation everywhere above, I intend to mean a structure that supports both of these things. For a sighting I believe that details of an Observation are needed (though which may or may not be required is still up for debate) but that the details of the thing that was observed is definitely optional (useful but not needed in +1 type of sightings). We can get into the details of how this sort of relationship and others could be done when we dig into the relationship topic very soon.
Yay! It sounds like we may fully be on the same page after all. :-)
sean
From: Terry MacDonald <terry@soltra.com>
Date: Thursday, November 5, 2015 at 6:29 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? 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]
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>
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.
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.
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. 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.
sean |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]