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

[Jerome Athias <athiasjerome@gmail.com>]

This makes sense for me.
I think Sean was suggesting to use somehow one (and only one)
Test_Mechanism construct.
While it could be discussed if it is better to call it Signature, or
Rule, or Pattern, or Test_Mechanism,
Test_Mechanism is ok for me and seems to be the most backward
compatible. (the ontological approach would quite easily deal with the
different names/words as just synonyms)

i.e.

CybOX Observable (instance) ->STIX Observation
CybOX Observable (pattern) -> STIX Test_Mechanism -> STIX Indicator

I think it helps clarifying a lot, and simplify the Sighting.
I could be interested by:
1) I have seen/found/observed malware007.exe (STIX Observation) on my
network: +1
2) I have seen/found/observed malware007.exe (STIX Observation) 45
times on my network: +1 (or +45?)
3) I have seen/found/observed (a hit/match of a connection to the
malicious IP from your watchlist) 8.8.8.8: +1
Here, imho, low value without context (e.g. TTP): was that connection
over DNS, NTP with 5Gb of traffic, a brute force on SSH...?
More value with a Sighting linked with Relationship, e.g.
Test_Mechanism context (8.8.8.8 - Relationship +1 - Data Exfiltration)
(here comes the Terrys's external Relationship construct)

So depending of the Observables types (and potentially their
composition :p), i could, imho, see an interest of a +1/+X on both:
STIX Observation
STIX Indicator
Then does not mean that it would have to be called Sighting for both.




2015-11-07 0:02 GMT+04:00 Terry MacDonald <terry@soltra.com>:
> Hi Sean,
>
>
>
>>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.
>
>
>
> I like Observation, but I would prefer the name we choose for the Pattern
> doesn’t have the word ‘Observable’ in it at all.  Could we instead use
> Signature?:
>
>
>
> Observation = Observable Instance
>
> Signature = Observable Pattern
>
>
>
> i.e.
>
> CybOX Observable->STIX Observation
> CybOX Observable -> STIX Signature -> STIX Indicator
>
> This seems pretty clear to me. And Signature isn’t used at present anywhere
> I could find. (We use ‘Test Mechanism’ for Snort/Yara rules).
>
>
>
> 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: Friday, 6 November 2015 12:29 PM
>
>
> 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?
>
>
>
>
>
>>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