OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[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]
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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]