Hi Sean,
·
I am not sure exactly what Terry means by "Observable Instances with extra context = Sightings”.
o
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.
As mentioned in the reply to (Part #1) currently Sightings are the extra context regarding recorded
Sightings of an Indicator Pattern. I believe this is overly restrictive. When Hunting as part of general Incident Response duties, one often finds things unusual observations that require further analysis and investigation. These are noticed because they are
unusual, not because they match a particular Indicator.
I believe that we need to ‘extend’ the definition of Sighting to remove the restriction that a Sighting
needs to be an observation of an Indicator pattern, and allow a Sighting to be an Observation that is interesting enough in some way to capture. By Sighting I mean one or more related Observables pertaining to an individual event e.g. an email being received
with a subject of ‘phishing’, a sender of me@evil.com, and a recipient of
you@victim.com would be a single Sighting with three Observable Instances.
The "Observable Instances with extra context = Sightings” phrase meant to reflect the above description.
That a Sighting definition should be changed such that a Sighting is an Observable Instance with the additional context (temporal/information source/handling/etc) with enough flexibility to be used without the Indicator being required.
§
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.
This is not really what I meant. I think my description of Sighting above clarifies this option – although
it does bring up another point….
STIX is currently designed to be used after Incident Response has been completed.
Something along the lines of this:
I think we’re missing a trick! We should be involving STIX
during the Incident Response process. This is where a lot of my ideas are targeted – using STIX to enhance the way Incident Response is performed.
In a large number of Organizations an Incident is what happens when the Malicious behaviour has been
confirmed, and an official ‘Incident’ has been created. The official Incident Handling/Incident Response team is called out in the middle of the night to a meeting, and you begin the process of containment/eradication/recovery. An Incident is admitting that
‘Houston – we have a problem’.
As mentioned earlier, I think the Incident object is designed to track sightings/indicators/ttps/etc
that we assert to be related to that Organizational Incident. But I also think that this doesn’t cover the ‘Detection & Analaysis’ phase of the Incident Response process adequately. When performing IR, you are often trying to group together ‘possibly related’
things, as you struggle to form a hypothesis of what has happened. You often go through a multitude of different ideas of what happened until you find enough evidence to point to what actually did happen. STIX at present doesn’t seem to cope with this well.
I believe we need a way of tagging possibly related objects together, and relating them all to an Investigation.
We need to track the ideas as they change over time, and we need a way of being able to request information from third parties via STIX request/response to help inform the Investigation. This Investigation would just be a form of ‘grouping’ while we are working
out that we have a problem. The use of an Investigation name wouldn’t have the connotation for management that an Incident has actually been confirmed.
It may be that a few tweaks are required to the Incident object to support this scenario, and that
a separate Investigation Object would be counter-productive, but I wanted to put it out there to galvanize opinion one way or another
J.
·
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.
o
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.
I am fine with discussing these concept and redefining them if that helps people use STIX in a way that improves the effectiveness
of how Organizations defend themselves. As the STIX community and threat intel sharing industry have gained more experience and learnt more about how threat intel sharing works in the real world it is very important that the STIX standards discuss and if needed
reflect those requirements with changes. If we were going to make changes then STIX v2.0 is the best time 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: 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:50 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] 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:
o
“<source> observed <x> instances of <object> at <location>, <time-range>, via <detection-method>”
o
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.
o
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”.
o
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.
o
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.
o
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