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] Current thoughts on Event Object


For clarity, to align the content of the email from me that hit the list this morning even though I sent it Friday (not sure what happened there), we believe these 5 objects are and should be distinct objects and align like this:

  1. We don’t think any new objects are required for Object 1. We agree that for STIX this could likely be covered by existing objects to convey this sort of observation.
  2. We believe Object 2 should be a new Alert object that is an immutable assertion that some observation (Object 1) is suspicious and why it is believed to be so. This is distinct from Object 1 and Object 3.
  3. We believe Object 3 should be a new Investigation object that is immutable, evolves over time, captures CTI-relevant metadata about a cyber investigation and references CTI-relevant content developed/derived from a cyber investigation.
  4. We believe Object 4 should be the existing Report object that is immutable and references CTI content and appropriate metadata to convey a “report”. We do not believe that the scope of this object should be broadly expanded to attempt to cover the general case of Object 5.
  5. We believe Object 5 should be a new Grouping object that is mutable, evolves over time (often via iterative exchange and enrichment among players) and references CTI content that shares some context. The share context could be a widely varied set of things. This sort of general exchange of contextual content is a very common use case.

 

We would suggest that at a high level Object 3 and Object 4 could be thought of as specialized derivations of the general Object 5 (they all convey a set of content with a shared context) but due to the specific semantic scoping of Object 3 (bound to the cyber investigation concept which is so fundamental to CTI) and the specific semantic scoping and immutability of Object 4, these derivations should be expressed as separate objects. The differences in semantic scoping will mean they involve different metadata, different usage models and flows, potentially different operational marking  and filtering requirements, and potentially differing decisions from implementers and users whether they choose to support 1, 2 or all three of these concepts/objects. Conflating them together would make all of these more difficult.

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: <cti-stix@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Date: Monday, September 11, 2017 at 9:48 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Current thoughts on Event Object

 

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.

. . . . .

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.


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