HI Sean,
I see two potential approaches to this that likely make the most sense:
We keep the current models semantics of observation, observation within an incident, and sighting. These current semantics support the above three modes of observation.
We rename observable instance (observation) to sighting and add explicit properties to it to specify if it is “of interest” or just a basic observation and to specify that it is actually a sighting of a known
indicator (this could potentially be done with a separate relationship though I am unsure what that relationship would be called since the semantics that it would convey is “Sighting” but that term would already be in use for something else.
After your last email, and realizing more clearly the similarities between my mental model and the use of Observable Instances, I would
probably go with option 1 now too, but with separate naming to delineate the differences better.
[sean]I think this exposes one of the recognized confusion points with STIX that we have tried to address in the past but obviously have not been successful at.
The STIX Incident construct is not intended to have any formal association with the concept of an “official Incident”. An “official Incident” typically bears with it certain requirements for activity, resolution, reporting, etc.
The STIX Incident construct is simply a concept/construct for capturing "sets of related security events affecting an organization”. Its use
does not imply that the information captured within an Incident construct represents an “official Incident”. It may end up that way as you evolve through the activity flow shown in your diagram above but it does not have to. It can be used for just the Detection
& Analysis phase as well. Things that don’t pan out or prove to be benign may never become “official Incidents”.
It was recognized back in the beginning of STIX that this would likely be a point of confusion but nobody could come up with a more appropriate name for the
concept/construct other than Incident. ;-)
The sort of hunting use case you describe is intended to be supported with the Incident construct where you can initially just capture "something weird" that
was observed and whatever relevant context (other observables, characterization of the asset on which the observation occurred, possible interpretation of the weirdness, etc.) was available and appropriate. As the intel analysts, hunters or IR folks dig deeper
or receive information shared by others they would iteratively flesh out the Incident construct with what is known (other observations and relationships between them, TTP characterizations, asset characterizations, sources, timing, etc.). At some point it
may trigger an “official Incident” which can then simply occur within the same construct and flesh out further (including use of properties like Status, Time/Incident_Opened, etc.).
I suppose this is where my Incident Response background has coloured my interpretation of the STIX Model. In which case, how many other
users of STIX have this similar (mis)understanding? For me it was the IncidentStatusVocab that confirmed to me what I thought (
http://stixproject.github.io/data-model/1.2/stixVocabs/IncidentStatusVocab-1.0/ ).
All these options are one’s I would use after an Official CSIRT Incident is created.
I still wonder though if it is better to separate them out the pre-Incident Investigation from the Incident as I have suggested earlier
in my previous emails. The CIO of an Organizations might be more predisposed to allow the release of an Investigation Object rather than an Incident Object – with the connotations of a data-breach that the word Incident brings.
i.e.
-
Using an Investigation object to group things that might be related but aren’t exactly. This would act as a list of Investigations
currently taking place, allowing one to group Objects together (using the relationship object for the relationships) while you are still trying to work out what is actually really related. You can then share the Investigation Object and related data outside
the organization within a STIX Request and get a STIX Response back with more information about the Investigation. Then if the Incident Responder determines that there is enough evidence that the Incident is likely malicious then an Incident is created.
-
Using an Incident Object to only track ‘Official Incidents, so that anyone who receives one understands that it is something
where a formal investigation has (or had) been opened. This would enable Incident Response personnel to create a STIX Incident every time they create an Incident in their ticketing solution, allowing an easy 1:1 to match. In a sense the Incident Object would
be a recording of the end result of the Investigation
The other option is to thoroughly review the Incident Object to ensure it can cover the Investigation requirements as well.
I would be very interested in other people’s opinions on the suggestions above – do you see any value in using a separated Invesitgation->Incident
type flow or does the current Incident Object suffice?
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 5:54 AM
To: Terry MacDonald <
terry@soltra.com>;
cti-stix@lists.oasis-open.org Subject: Re: Some thoughts on Sightings and conversations to date (Part #2): the semantics of observation, indicator, incident, sightings, etc
Comments inline below.
First part is mostly a restatement of the same semantic clarification I have given in several other posts. I believe our difference is only in the term we
are using not in the actual use cases and information structures.
I think there are three different types of observations we need to be able to represent:
I saw something. Here is what I saw.
I saw something that I think is of interest. Here is what I saw.
I saw something that has been explicitly declared as of interest. Here is what I saw
I think representing all three is important and being able to explicitly distinguish between the three is as well.
I see two potential approaches to this that likely make the most sense:
We keep the current models semantics of observation, observation within an incident, and sighting. These current semantics support the above three modes of observation.
We rename observable instance (observation) to sighting and add explicit properties to it to specify if it is “of interest” or just a basic observation and to specify that it is actually a sighting of a known
indicator (this could potentially be done with a separate relationship though I am unsure what that relationship would be called since the semantics that it would convey is “Sighting” but that term would already be in use for something else.
I prefer option #1 for three main reasons:
If the model currently supports the use cases and information structures needed why mess with it just to relabel something
The current semantics have been part of the model since pretty much the beginning so why change the semantics of the terms when it may confuse people if we are not gaining any substantive expressive benefit.
The connotative use of the term “sighting” in English is inconsistent with use as simply observing something. It almost always is used to say that something was observed that was being looked for or identified
as being unusual. The American Heritage dictionary defines it as " The act of catching sight of something, especially something unusual or searched for: a sighting of a whale in the harbor; a reported sighting of a UFO.”
You would never say “I sighted a red Ford Mustang” unless someone had said to look for one. You would just say “I saw a red Ford Mustang” or would not comment on it at all.
The second part below is a BIG eye-popping Woah! for me on an apparent misunderstanding on the intent of the Incident concept/construct and an attempt to
provide brief clarification.
I intentionally tried not to drive too far down the rabbit hole explaining this here as it would become a VERY long email. I am happy to discuss this further verbally as folks feel necessary.
sean
From:
Terry MacDonald <
terry@soltra.com >
Date: Tuesday, November 3, 2015 at 7:54 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 #2): the semantics of observation, indicator, incident, sightings, etc
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.
[sean]I will not fully repeat here all that I have said in other responses but everything you are describing here is currently covered by the observable instance
(observation) concept/construct.
For your simple example above if you just wanted to represent the observation of the email you could do so with an observable instance (observation) like:
<observable>
<Object>
<Properties EmailMessageObjectType>
<Header>
<Subject>phishing</Subject>
<Sender>
me@evil.com</Sender >
<To>
you@victim.com</To >
</Header>
</Properties>
<Object>
</observable>
If you wanted to represent the actual event of the email being received and potentially the “additional context (temporal/information source/handling/etc.)
you could do that too within the Observable shown above. The only exception is that handling would be specified external to the Observable itself (e.g. at the Package level) as the Observable construct currently is defined directly as CybOX and does not have
the core construct properties that the other STIX top-level constructs do. This is an identified
issue (#160) and should be fixed in 2.0
It is still looking like the only difference in what we are talking about is the label applied to what is currently defined as an observable instance (observation).
§
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:
[sean]Woah! I am not sure where this interpretation came from. It looks like we need to add some more documentation I guess. If you were confused on this issue than others likely are
as well.
STIX is ABSOLUTELY designed to be used during Incident Response not just after.
The STIX Incident construct is designed to support and capture relevant information during the evolution of an incident response from capturing initial bits
(before it is an officially tracked incident) through exploration/investigation fleshing out as it goes, to tracking status and temporal milestones, through courses of action suggested and taken, to derivation of intelligence (indicators, TTPs, TA attribution
assertions, campagin relationship assertions, etc.) out of the incident response.
STIX is not focused only on sharing threat information. It is even more so focused on supporting analysis of threat information.
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.
[sean]I think this exposes one of the recognized confusion points with STIX that we have tried to address in the past but obviously have not been successful at.
The STIX Incident construct is not intended to have any formal association with the concept of an “official Incident”. An “official Incident” typically bears with it certain requirements for activity, resolution, reporting, etc.
The STIX Incident construct is simply a concept/construct for capturing "sets of related security events affecting an organization”. Its use
does not imply that the information captured within an Incident construct represents an “official Incident”. It may end up that way as you evolve through the activity flow shown in your diagram above but it does not have to. It can be used for just the Detection
& Analysis phase as well. Things that don’t pan out or prove to be benign may never become “official Incidents”.
It was recognized back in the beginning of STIX that this would likely be a point of confusion but nobody could come up with a more appropriate name for the
concept/construct other than Incident. ;-)
The sort of hunting use case you describe is intended to be supported with the Incident construct where you can initially just capture "something weird" that
was observed and whatever relevant context (other observables, characterization of the asset on which the observation occurred, possible interpretation of the weirdness, etc.) was available and appropriate. As the intel analysts, hunters or IR folks dig deeper
or receive information shared by others they would iteratively flesh out the Incident construct with what is known (other observations and relationships between them, TTP characterizations, asset characterizations, sources, timing, etc.). At some point it
may trigger an “official Incident” which can then simply occur within the same construct and flesh out further (including use of properties like Status, Time/Incident_Opened, etc.).
I apologize. I had no idea that this confusion was at play here. If you wish, I would be happy to have a one-on-one conversation to talk through details of
all of this that would be difficult to do via email.
It
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.
[sean]as described above, this is the explicit intent of the Incident concept/construct
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 .
[sean]If there are tweaks required to the Incident object to support its intent (and I fully imagine that there likely may be), I am all for identifying and resolving them.
·
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