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: Some thoughts on Sightings and conversations to date (Part #2): the semantics of observation, indicator, incident, sightings, etc


The second sightings sub-topic I wanted to comment on is around the semantics of observation, indicator, incident, sightings, etc.
On this one, I think there has been a lot of good conversation and for the most part I think we are all talking about a lot of the same use cases and capabilities but are often talking past each other on the terms we use for them.
Putting on my expert hat rather than my co-chair hat, I wanted to offer some thoughts on semantics including some clarifying comments on the intended semantics of the current STIX model which I have intimate knowledge of.

  • I would like to suggest that we focus primarily on the use cases we need to support and the information structures needed to support them rather than get caught up arguing over defining or redefining the semantics of terms currently in use.
  • Using Mark’s characterization of “sighting” that it looks like most folks generally accepted:
    • “<source> observed <x> instances of <object> at <location>, <time-range>, via <detection-method>” 
    • This is precisely what is intended in the current model’s concept of observation” (observable instance). It is not only the semantic intent of the above statement but also provides all of the information structures to fully describe it.
    • Using Cory’s characterization of the subclassing relationships (Observable->Observation->Sighting) we could then define a sighting as a particular observation where the observable properties match a particular observable pattern, in this case one defined as part of an Indicator
      • “<source> observed <x> instances of <object> at <location>, <time-range>, via <detection-method> which matched the pattern defined by <indicator>” 
  • I am not sure exactly what Terry means by "Observable Instances with extra context = Sightings
    • Terry, could you clarify for me? What sort of extra context? 
      • The intent of the current semantics in the STIX model is that if that extra context is its association of those observable instances matching a particular Indicator’s pattern than the set of observable instance and “extra context” would be a Sighting. Yes, that Sighting structure currently resides within the Indicator structure but that is an artifact of defining our model using schema rather than true modeling and it has always been envisioned that it would eventually be broken out separately as we are now discussing. 
      • The intent of the current semantics is that if that extra context were simply more details associating the observable instance with other information (other observable instances, particular victims/targets, assets, asserted TTPs or TAs, etc.) that in aggregate is asserted as of interest but no assertion that the observable instance actually indicates any particular TTP then this would be captured in an Incident. The Incident structure in STIX is defined at its most basic level as "sets of related security events affecting an organization”. Terry gave the following definition for sighting: "Sighting – One or more Observable instances combined with context, describing something ‘interesting’ that you have seen. I believe this sounds exactly like the current intended semantics for Incident.
    • Terry, is the “extra context” you are envisioning different than either of the above two cases? Do you feel that the Indicator or Incident structures provide inadequate capability to capture the “extra context” you are thinking of?
  • I personally believe there are valuable semantic differences between the concepts of observable instance, sighting and incident as currently captured in the STIX model. Conflating or redefining them seems risky and detrimental to me. 
    • I think the important question is can the current model support all of the relevant use cases?
      • If so, then why argue over a particular word. 
      • If not, then lets adjust and iterate.


sean


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