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.