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


Just a quick comment:  The state/status of "Investigating" is an extremely powerful construct.  It provides for early warning and crowd sourcing/community collaboration on leading threats.  It merely conveys that "We" think this could be something of concern to the community and  that we're taking seriously.  In a mature community these are indeed serious threats 80-90% of the time.  To some of the other points, it really depends on the community/use cases.  For the active CND/CNO community "Investigating" is an invaluable concept.

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org




On Wed, Nov 11, 2015 at 10:23 PM -0800, "Jane Ginn - jg@ctin.us" <jg@ctin.us> wrote:

Terry, Sean and All:

I never interpreted the use of STIX constructs as ex post facto, after a formal Incident Response... .mainly because I come from the Hunter mindset, so my conceptual model is a continuum to begin with. But, because of my formal training the use of the term "Incident" did convey a certain spot on that continuum that might coincide with a set of formal actions after the results of a hunting expedition had been elevated. So I can see how it might cause some confusion for the IR community of interest.

I'm inclined to go with the arguments for adding an Investigation construct, for this, and many other reasons.

Jane Ginn, MSIA, MRP
Cyber Threat Intelligence Network, Inc.
jg@ctin.us



-------- Original Message --------
From: Terry MacDonald <terry@soltra.com>
Sent: Friday, November 6, 2015 12:54 PM
To: "Barnum, Sean D." <sbarnum@mitre.org>,"cti-stix@lists.oasis-open.org " <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] RE: Some thoughts on Sightings and conversations to date (Part #2): the semantics of observation, indicator, incident, sightings, etc

HI Sean,

 

I see two potential approaches to this that likely make the most sense:

  1. We keep the current models semantics of observation, observation within an incident, and sighting. These current semantics support the above three modes of observation.
  2. 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:

  1. We keep the current models semantics of observation, observation within an incident, and sighting. These current semantics support the above three modes of observation.
  2. 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:

  1. If the model currently supports the use cases and information structures needed why mess with it just to relabel something
  2. 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.
  3. 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: sighting of a whale in the harbor; areported 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:

https://s3.amazonaws.com/media-p.slid.es/uploads/394276/images/1883569/NIST-incident-response-lifecycle.jpg

 

 

[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



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