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] Need for Investigation/Tag object?

Hi Terry,

Apologize for jumping in late. The email got buried and I just got to it. Thanks for putting together the use case. +1 on the cool ASCII art! 
The 'investigation’ object for grouping related information during the investigation process makes complete sense. In fact this was exactly what I was envisioning in my mind and I’m glad you called it out that way. This would help automate the journal entry process that analysts need to maintain on a day to day basis. I would like to add a few points here:
  1. Investigation is done during in the detection phase to determine if there has been a breach
  2. A series of Investigative actions are done during the incident response process to gather further information on the  affected assets such as WhoIs (the user for the asset), geolocation information, other assets of the user, who all did the asset communicate with etc. This information helps  determine the response actions needed.
  3. After incident response, some monitoring/investigation is done to determine if the response worked as desired before the incident is closed. 

The investigation activities during and post  IR could either be captured in the ‘investigation’ object or be used to enrich the incident  object. Thoughts?



From: <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <terry@soltra.com>
Date: Friday, October 30, 2015 at 3:22 PM
To: "Davidson II, Mark S" <mdavidson@mitre.org>, "Jane Ginn - jg@ctin.us" <jg@ctin.us>, "Sarah.Kelley@cisecurity.org" <Sarah.Kelley@cisecurity.org>, Jerome Athias <athiasjerome@gmail.com>, Bret Jordan <bret.jordan@bluecoat.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: RE: [cti-stix] Need for Investigation/Tag object?

Hi Mark,


Sure… although TBH I’m not that happy with the current STIX v2 Use Case structure on the wiki. To my mind it focuses on STIX and the ways it can be used, when we should actually be focussing on the way that Threat Intelligence can be used and documenting those use cases at the CTI TC level – then deriving STIX/TAXII/CybOX requirements from that as a separate step. But that’s a different discussion…..




STIX v2.0 Use Case: Performing an Investigation


Relevant to which SCs (STIX/TAXII/CybOX): STIX


Abstraction Level (High, Medium or Low): Yes?


Related Use Cases: Um?



Incident Handlers and Security Operations Centre monitoring staff are constantly looking for unusual/suspicious events. These suspicious events are ‘odd things that require further investigation’. A large percentage of the time the investigation shows that the events are false positives of some kind. A JPEG with a series of 0x9090909090 within it may trigger a rule looking for x86 NOOP slides. Multiple failed SSH attempts against your internal Cisco terminal server may in fact be a misconfigured script somewhere. Not everything is malicious.


Incident Handlers often operate with the following workflow (cool ASCII art!):  


event/alert raised -> investigation opened -> investigate/analyze -> official incident opened -> IR process



                                               false positive -> investigation closed


Often, as part of the ‘investigate/analyse’ step in the ASCII diagram above we ask threat sharing groups if they have information that may help us with our analysis. We try and find confirmation that something is bad is happening – something that will require us to wake up 10 people in the middle of the night to form the Virtual Incident Response Team. STIX would be SOOOOOO much more useful if we had the ability to request information about a sighting before we create an Incident and yet still allow us to ‘track’ it somehow without us needing to declare a full official ‘Incident’.


Incidents are only created when we have confirmed something is happening.


That’s where the investigation/tag object comes in. Being able to link the objects to the Investigation object would allow us to track the objects related to the investigation when we are unsure if they are malicious, and then easily create an Incident when we confirm that they are. This then also means that the Incident can have a 1:1 relationship with the official Incident in the Organizations ticketing system, making it far easier to integrate STIX Incidents with the corporate ticketing system in the long term.




In addition, while doing the daily hunting through proxy logs looking for weirdness, one could find a strange URL pattern that we’ve never seen before. It could easily be Symantec’s live update doing some weird liveupdate stuff, or it could be a new piece of malware. If we then search and find 25 other hosts on the internal network with the same pattern, we want a way to link those together. That’s where the investigation/tag object comes in. We could share out the examples of 25 URLs we’ve found to our community with a STIX request, and could receive 10 STIX responses back with more details about others who have experienced the same problem. They may have extra information about what they’ve found or not, but in either case that information then helps us with our investigation. They may even send us their own investigation object or Incident which can all help us in our investigation.


Stakeholders/Goals: To


         Stakeholder: Incident Handlers


o   Goal: Group together ‘possibly’ related STIX objects so that initial triage can be done.




         Depends on STIX v2 Sighting object



         Depends on proposed STIX v2 Request object

         Depends on proposed STIX v2 Response object

         Depends on STIX v2 Sighting object


Main Success Scenario:

         Incident Handlers are able to perform investigations and send out requests for more information about investigations before they turn into official Incidents.




Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com



From: Davidson II, Mark S [mailto:mdavidson@mitre.org]
Sent: Friday, 30 October 2015 10:24 PM
To: Jane Ginn - jg@ctin.us <jg@ctin.us>; Terry MacDonald <terry@soltra.com>; Sarah.Kelley@cisecurity.org; Jerome Athias <athiasjerome@gmail.com>; Bret Jordan <bret.jordan@bluecoat.com>
Cc: cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Need for Investigation/Tag object?


Terry, Jane, (and perhaps Jyoti),


Would you be able to describe the use case a little more? I’m thinking along the lines of what’s been started on the STIX use cases wiki [1] – nominally including a description and a main success scenario. That would help me understand who takes which actions when and in what order, which in turn would help me form an opinion about how well proposed solutions meet the use case.


At the data model level, this sounds like a possible use of a top level relationship object. Just throwing something against the wall here (I’m not a cyber analyst and I don’t play one on TV), but could this use case be accomplished by relating multiple objects to a campaign with a low confidence?


Thank you.



[1] https://github.com/STIXProject/use-cases/wiki


From:cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jane Ginn - jg@ctin.us
Sent: Thursday, October 29, 2015 4:53 PM
To: terry@soltra.com; Sarah.Kelley@cisecurity.org; Jerome Athias <athiasjerome@gmail.com>; Bret Jordan <bret.jordan@bluecoat.com>
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Need for Investigation/Tag object?


Terry & All:

This is an actual Use Case that I've seen operationally in one of the ISAOs I participate in. It is not theoretical. .. and the real-time nature of this helps the non-targeted members of the ISAO to take proactive actions in response to what is known (shared) about the Threat Actor, the IoCs, and the TTPs. Offensive countermeasures in action.

I could see this Use Case evolving into a very important one for driving adoption of threat intel platforms... especially if the CybOX objects are extracted, used in other tools for enrichment, then reconstructed as STIX again. Thus later permutation aligns with the Use Case Jyoti introduced in the CybOX Subcommittee call today.

Jane Ginn, MSIA, MRP
Cyber Threat Intelligence Network, Inc.

-------- Original Message --------
From: Terry MacDonald <terry@soltra.com>
Sent: Tuesday, October 27, 2015 01:03 PM
To: Sarah Kelley <Sarah.Kelley@cisecurity.org>,Unknown Unknown <athiasjerome@gmail.com>,"Jordan, Bret" <bret.jordan@bluecoat.com>
Subject: [cti-stix] Need for Investigation/Tag object?
CC: "Baker, Jon" <bakerj@mitre.org>,"Jonathan Bush (DTCC)" <jbush@dtcc.com>,Cory Casanave <cory-c@modeldriven.com>,"cti-stix@lists.oasis-open.org " <cti-stix@lists.oasis-open.org>

Hi All,


Sarah’s email below reminded me of some thoughts that have been bubbling around for a while.


I think there is a need for us to support describing and sharing Threat intelligence while it is still under investigation. Historically STIX has been used by Organizations who are generally sharing information about attacks after they have finished. It seems to me that we are rapidly moving towards an automated future where Organizations are sharing information about attacks while they are happening. This change is a subtle one, but one that has implications for STIX.


At present we have no way for an Organizations to temporarily ‘group’ different STIX objects together. When one is conducting an investigation into a series of suspicious events prompted by your Organization’s monitoring processes, we often want to tag/relate these events together, without actually creating an official ‘Incident’ (as we’re not sure anything has actually happened yet). The Incident object is where one would put the information when it is confirmed there is a problem, but I believe we at least need a way of ‘tagging’ and ‘grouping’ potentially related items together.


Does anyone else see the need for something like this?




Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com



From: Sarah Kelley [mailto:Sarah.Kelley@cisecurity.org]
Sent: Tuesday, 27 October 2015 10:18 PM
To: Unknown Unknown <athiasjerome@gmail.com>; Jordan, Bret <bret.jordan@bluecoat.com>
Cc: Terry MacDonald <terry@soltra.com>; Baker, Jon <bakerj@mitre.org>; Jonathan Bush (DTCC) <jbush@dtcc.com>; Cory Casanave <cory-c@modeldriven.com>; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Conceptul model for sighting


I am a huge proponent of letting (almost) anything link to anything. In fact, limiting what can have an association/link/relationship with what is my current biggest frustration with Stix (we use workarounds to get around this limitation). 


I would add the possible use cases:


My org observed 3 instances of this threat actor hitting our network

My org observed 12 instances of the Poison Ivy TTP on our network

Or even (though weaker):

My org was hit by this particular campaign 27 times




Sarah Kelley

Senior CERT Analyst

Center for Internet Security (CIS)

Integrated Intelligence Center (IIC)

Multi-State Information Sharing and Analysis Center (MS-ISAC)

1-866-787-4722 (7×24 SOC)

Follow us @CISecurity


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