Re: [cti-stix] Re: [EXT] [cti-stix] Way forward with the Event SDO

So, here is my stab at a more generalized version of the flow diagrams that attempts to take into account potential variations at various phases.

It identifies which flows we consider in/out of scope for CTI (vs native to cyber investigation) and identifies some of the key CTI content object types for various flows.

The net-net for our perspective on new objects that should be created within STIX is:

Leave Report object as is and do not change its semantics or structure. We believe that there is a need for this object as is.
Create a new Investigation object to capture CTI-relevant metadata details of an investigation (from Triage to Informal Investigation to Formal Investigation (IR)) as well as any CTI content derived from it. These objects are mutable and may evolve over the time of the investigation.
Create a new Alert object to capture details of a triggering event taking place including what triggered (indicator, signature, anomaly pattern, etc), what detected the triggering (e.g., which tool), and potentially what observables were observed that matched the triggering pattern. These objects are created at the time of triggering and are immutable after creation.
- Opinion objects may be asserted against the Alert objects to convey things like judgement whether the Alert is a false positive or true positive.
- Sighting objects may reference the Alert as what was seen as a sighting of an Indicator
Create a new Grouping object to support the conveying of any set of CTI content with some shared context (content related to some ThreatActor, content related to some Malware, etc.).
- This is specifically what the MISP players are asking for.
- This is needed independent of the Investigation object whose context is fixed to be a specific investigation.

I am attaching the diagram as .png but also as a graphML file in case anyone wants to play with it in an editor such as yEd.

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Friday, September 1, 2017 at 1:16 PM
To: Sean Barnum <sean.barnum@FireEye.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, Sarah Kelley <Sarah.Kelley@cisecurity.org>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Way forward with the Event SDO

Separate reply RE the sketchboard - As you mention, we want to "focus on the arrows". The first step in this process is to make sure we have everyone's workflow documented and sketched. So far we have captured three different flows, and then been able to combine two of them, to end up with two flows. But this is only based on input from 4 or 5 people. There are undoubtedly other flows that need to be captured.

Once everyone is agreed that we have captured the right flows, *then* we can start looking at all of the arrows in these flows (which is where data is flowing) and decide which ones we are prioritizing now. At that point, everyone should be very aligned as to what we are trying to do.

Lets try to ensure we have everyone's flows accurately captured first. Then we can discuss which arrows we want to target for 2.1 on a working call.

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security

Without data, all you are is just another person with an opinion - Unknown

__________________

Our main use case for the Event SDO and top priority is to be able to export the results of analytics done on raw observation data in any of our platforms, to other platforms (including other security analytics platforms, threat hunting platforms, IR platforms, other TIPs, and ticketing systems) for consumption, and when doing this to lose as little fidelity as possible on this analytic result.

That would be our #1 use case for this. It is somewhat aligned with what Bret has for #3 below, but not exactly.

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security

Without data, all you are is just another person with an opinion - Unknown

From: Sean Barnum <sean.barnum@FireEye.com>
To: Bret Jordan <Bret_Jordan@symantec.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 09/01/2017 11:34 AM
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Way forward with the Event SDO
Sent by: <cti-stix@lists.oasis-open.org>

Here would be our list.

Desired Goals for CTI treatment of cyber investigation information:

Near seamless transition of information (observables, identities, locations, etc.) from cyber investigation (digital forensics, malware analysis, IR, etc.) tools to CTI tools
Explicit provenance of information (from CTI to how it was derived to the investigation where the info came from to the information within the investigation to how the information was discovered/extracted/derived) for purposes of Confidence
Near seamless transition of CTI into cyber investigations for contextual correlation and understanding
Extract indicators from cyber investigations
Sightings referencing the Alert that represents the sighting (primarily internal use)
Automated COA prescription or even execution during Trigger/Triage based on Alerts (these may transition system, sub-organization or even organization boundaries)
Automated COA prescription or even execution during informal and formal investigation phases
Derive victim targeting from cross-investigation analysis
TTP trending from cross-investigation analysis
ThreatActor <-> TTP use temporal analysis from cross-investigation analysis
Incident summary reporting (e.g. US-CERT)

We also had a few comments on the sketchboard content:

The two flows on the sketchboard don’t seem like use cases so much as specific implementation workflows supporting use cases. Things like open ticket/close ticket seem too specific for general use cases. Many orgs might follow a similar general flow but not specific elements of the flows depicted.
We suggest the key for STIX to focus on are the arrows to and from the green boxes. These represent CTI derived from and fed to cyber investigations which are clearly within scope for STIX. The light blue boxes and the pink boxes are the domain of cyber investigation and out of scope directly for STIX.
- The questions to ask are:
  - Which elements (and at what granularity) out of cyber investigations are relevant for CTI analysis/enrichment?
  - How to structure CTI information fed into cyber investigations such that it is as seamless as possible?

Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E: sean.barnum@fireeye.com

From: <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Thursday, August 31, 2017 at 3:55 PM
To: Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Re: [EXT] [cti-stix] Way forward with the Event SDO

My features / goals I would like out of this/these objects are:

1) Ability to do automated incident reporting to internal/external groups/organizations (think reporting to US-Cert). Information should be parsable by a computer and indexable

2) Ability to gather a bunch of post-IR reports and look for patterns of Threat Actor / Intrusion Set behavior.

A nice to have would be:

3) Ability for various SOC tools that do IR based ticketing / workflow to share information in STIX format.

Bret

From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Sent: Thursday, August 31, 2017 11:17:34 AM
To: cti-stix@lists.oasis-open.org
Subject: [EXT] [cti-stix] Way forward with the Event SDO

All,

Given some of the extremely prolific conversations that have happened recently (mostly on Slack, but also in email) about the Event SDO, we’re going to take a slightly different approach to this object.

It seems clear from the conversations that not everyone is in agreement on what we’re attempting to model, so trying to determine if the draft SDO we have will work poses a challenge. Many different stages or types of objects have been proposed, from an alert/event, to an investigation, to a collection/grouping, to a post-IR type reporting mechanism. That being said, we need to come to some sort of agreement on WHAT we’re trying to represent before we can determine if we’re doing in the right way.

The co-chairs believe it would be valuable to do a reset on this object. We should take a step back from where we have been and come to a better understanding of where we need to be. We are in no way going to throw out any of the work that has already been done. We want to have a focused conversation about what end-to-end work flows people are currently using that fall into this realm, starting from something as simple as a logline, and going to as far down the analysis and notification chain as we need to get. Once we have a better understanding of what people already do, and what workflows they are looking to use STIX to accomplish, we’ll have a much clearer picture about what objects we need to accomplish that. We may wind up needing a bunch of different objects, we may wind up being able to do it all in one. Some of these objects may wind up in STIX 2.1, some may be part of future releases. The point is that until we fully understand what people need and want, we can’t know for sure which it will be.

That being said, we are soliciting use cases.

What are you and your organizations trying to accomplish in this realm?
How does your workflow move?
What types of tools/devices/out-of-band methods do you currently use to accomplish it?
Which of those would you like to be able to do via STIX?

You are welcome to send your responses to the mailing list, but we would also like to encourage people to draw them in a tool that we already have going for this very purpose. You can find the drawing board here: https://sketchboard.me/NABpoAKZidJA#. If you would like to access this (and we highly encourage you to do so), you’ll need to email Jason Keirstead ( Jason.Keirstead@ca.ibm.com) with your gmail account and he can give you edit permissions.

I don’t want anyone to get discouraged by this email. As stated, we’re not planning to throw away any of the work we’ve already accomplished, and when all is said and done, we may discover that what we already have works perfectly. We just want to make sure we have given every workflow the consideration it deserves and that whatever we come up with will work for as many organizations as possible.

Thanks,

Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)
31 Tech Valley Drive
East Greenbush, NY 12061

sarah.kelley@cisecurity.org
518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org- 1-866-787-4722

This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

. . . . .

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

cti-stix message