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?
- Which elements (and at what granularity) out of cyber investigations are relevant for CTI analysis/enrichment?
- The questions to ask are:
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
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.
. . . . .