cti-stix message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti-stix] Current thoughts on Event Object
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: Sarah Kelley <Sarah.Kelley@cisecurity.org>
- Date: Mon, 11 Sep 2017 14:43:27 +0000
For the record,
- I also agree / believe that Object
1 is a sighting of observed data
- I am in support of focus on Object
2/3
- I have not opinion as of yet if object
2 and 3 need to be separate objects. I think this will come out from the
discussion, if we get a consensus on this approach.
-
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:
Sarah Kelley <Sarah.Kelley@cisecurity.org>
To:
"cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>
Date:
09/11/2017 10:41 AM
Subject:
[cti-stix] Current
thoughts on Event Object
Sent by:
<cti-stix@lists.oasis-open.org>
CTI-TC,
I have made an attempt to summarize the
discussion to date surrounding the Event object. I have tried to use the
diagrams that we’ve been referencing that show several workflows and where
I see the various SDOs we have been discussing.
I think there are five separate things
that we’ve been talking about with regards to “Event”:
Object 1) Some sort of front end device
sensing something. You could call this an alert, an event, a log line,
etc.
Object 2) A somewhat more mature version
of the thing above. It may be one to one, but it may not be. There
may be many of Object #1 that make up one Object #2.
Object 3) A way to document an incident/investigation
that is either ongoing or concluded. This may (or may not) have come from
an evolution out of an Object 1 or 2. Likely, most IR tools will not use
Object 3 directly, so it should probably be a sort of summary object that
can allow the results of an IR investigation to be linked back to all the
related data (like Objects 1 and 2, but also Actors, malware, etc)
Object 4) Some sort of automated method
of reporting, for cases such as mandatory reporting (like to US CERT).
Object 5) A way to group a bunch of related
data together.
I see these as five distinct SDOs. Objects
1 and 2 are very similar, and could be represented by one SDO, but
if that was the case, then the SDO would need to have a relationship type
of “this arglebargle is one of many arglebargles that make up this larger
arglebargle”.
Object 1 has a lot of logistical overlap
with a Sighting. There would need to be some sort of deconfliction between
what properties were trying to be represented by Object 1 to make sure
it wasn’t just a duplicate of Sighting (which, by definition, is something
that was ‘seen’, just as Object 1 was described to be). This could also
just be an Observed Data object, if the it wasn’t actually “sighted”.
Object 2 is something that would likely
be looked at by a SOC analyst. It isn’t really something that involves
IR, but rather “is this thing my sensor generated good or bad?”
Object 3 is for your IR people or your
CERT.
Object 4 is likely distinct from the Report
object as we have it now, as it’s not likely to be in the same vein as
a ‘published report’, but rather, “Here are the series of questions
that US CERT makes me answer every time we have an ‘incident’”.
Object 5 is basically what MISP has been
asking for.
I believe Objects 1-3 roughly correlate
to the first three objects from the FireEye proposal of “Event”, “Alert”,
and “Investigation”. Object 5 is closer to their “Grouping” object.
All that being said, many of these tasks
are not currently done in STIX (if not most of them). In the diagram, we
have the TIP (in green) as being a separate object that lives alongside
the workflow, but isn’t really IN the workflow. That being said,
if we added objects 1, 2, 4, and 5, I think it could allow for easier data
flow into/out of a TIP. (I don’t think the IR object will ever be used
directly by the types of tools that produce that data, but maybe I’m wrong.)
Personally, I think the Event object as
it currently stands is somewhat of a combination of Object 2 and Object
3. If people agree that these are really separate objects, I think we could
scope out a few properties and turn the current Event object into Object
2 or Object 3 fairly easily (or easily split it into two objects). I think
Object 1 is out of scope for 2.1 (unless it’s already covered by sighting/Observed
Data). I think Object 4 is out of scope for 2.1. I think Object 5 will
be covered by the “collection vs. report” debate/object, for which we
should soon have a proposal.
Thoughts are appreciated.
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 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.
. . . . .
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]