OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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

Subject: Re: [cti] Re: [EXT] RE: [cti] Option 1 vs. Option 7 Powerpoint Example

What I have come to realize, in conjunction with what Allan is pointing out, is the fundamental disconnect between an event-based concern and a state-based concern is the following:

* an event-based system has no need to currently maintain the observed_data object* - it is likely currently thrown away. The observations inside are consumed for whatever purposes they are meant for, but the container is likely not preserved.

This is why this discussion I think is so hard to have. The relationships to objects inside an observable container, only make sense if the container is even thought as data that needs to be preserved at all - which implies it is conveying persistent state, not just events to be accumulated.

It's two totally different use cases.

Jason Keirstead
Lead Architect - IBM Security Connect

"Things may come to those who wait, but only the things left by those who hustle." - Unknown

From:        Bret Jordan <Bret_Jordan@symantec.com>
To:        "Kelley, Sarah E." <skelley@mitre.org>, Allan Thomson <athomson@lookingglasscyber.com>, Gary Jay Katz <gary.katz@FireEye.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date:        10/31/2018 04:22 PM
Subject:        [cti] Re: [EXT] RE: [cti] Option 1 vs. Option 7 Powerpoint Example
Sent by:        <cti@lists.oasis-open.org>


When I look at it, the problem I see / hear from Gary / Jeff / Sean / Sarah is that internal relationships on the observable container do not really work for what people need. Thus having external relationships and all their goodness is what people need.

You can do that in one of three ways.  

a) Make cyber observables top level objects (option 1 prime from previous discussions)
b) Provide some sort of deep referencing inside of Observed Data (people have consistently shot down this idea)
c) Try and pull out the relationships that really need to be external and leave the rest. (A combination of option 7 with some tweaks that John Wunder has brought up)

So options a, b, and c are technically all possible, though option b where you do deep referencing inside of an Observed Data is just awful and will probably be the no-end-to-pain.


From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Kelley, Sarah E. <skelley@mitre.org>
Wednesday, October 31, 2018 12:04:09 PM
Allan Thomson; Gary Jay Katz; cti@lists.oasis-open.org
[EXT] RE: [cti] Option 1 vs. Option 7 Powerpoint Example

Allan (and all),
I think this is a really profound realization. I have been coming at this with a âstate-basedâ idea, as in âgive me everything you know about Xâ. Having worked in a SOC, I also realize the use cases for âevent-basedâ data.  I, for one, would be curious about your possible ideas for being able to represent both.
Sarah Kelley
Lead Cybersecurity Engineer, T8B2
Defensive Operations
The MITRE Corporation

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Allan Thomson
Wednesday, October 31, 2018 10:44 AM
Gary Jay Katz <gary.katz@FireEye.com>; cti@lists.oasis-open.org
Re: [cti] Option 1 vs. Option 7 Powerpoint Example

Gary â thanks for sharing.
One of the things that Iâve realized as part of reviewing the use cases is the differences in how we talk about things.
Iâve come to the conclusion that we are talking about 2 different aspects of our problem set.
  1. Event-based
  2. State-based
From my perspective, Option 1 is really representing a state of entities and connectedness between those entities after multiple events have occurred.
Option 7 (current observed-data model) represents discrete individual events that would occur over time.
This would be similar to having a state-machine defined (I,.e. the resultant intel model) and then individual events (intel events) that cause you to update the state-model.
Think of the intel model as the campaigns, actors, email-addresses, ipsâ.etc.
Think of the events as changes to those intel objects (i.e. observed data model).
Conflating the 2 of these is not the solution.
The question is whether we are defining STIX to communicate event-based model or a state-based model.
I think we should consider the possibility that both are valid things to do and therefore we should consider how to approach using STIX to clearly articulate when we are
  1. Sending discrete events that have been observed at a specific time and any associated meta data to that event
  2. Sending a state model that represents the collective intelligence and associated relationships across that state built up over time
I think if we recognize that both models require something different and factor that into our STIX data model discussion then we might find a way to solve both.
I have some ideas but this email is already too long.
From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Gary Jay Katz <gary.katz@FireEye.com>
Wednesday, October 31, 2018 at 6:20 AM
cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
[cti] Option 1 vs. Option 7 Powerpoint Example

Thank you to everyone for taking time to discuss Option 1 and Option 7.  As usual, Jane did an excellent job capturing the discussion, including screen shots from the presentation.  John-Mark requested that I resend out the slides from yesterdayâs discussion with any updates, which I believe is valuable as it will allow us to continue the discussion over email.  As an update, I did include an optional Observed Data object in Option 1.  The inclusion of an Observed Data object would show that the producer directly observed the email with an attachment vs. indirectly having that information (ex. Gathered the information from external reporting).  
The purpose of this example is to show a very reasonable use-case for a cyber security analyst and discuss how that data can be represented in the STIX standard using either Option 1 or Option 7.  I have not created JSON versions of the example in both Option 1 and Option 7 form.  My assumption would be, to Allanâs point, that the Option 1 version is more verbose, although only slightly.  This does mean that the data size of the document is larger and to earlier points, in other use cases this difference can be even larger.  This example though highlights an even larger issue.  Option 7 does not allow some common useful relationships to be represented within the format.  Having relationships to show that a file found in an email, which analysis shows beacons to a C2 that resolved to a specific domain is not possible in Option 7.  The receiver must infer this information through 3 disjointed objects.  
Our greatest risk to adoption is not asking companies and organizations to update their STIX implementations to support Option 1 or the increase in data size for certain use cases.  Our greatest risk is having the trust of the userbase.  One day, far in the future (if we do our jobs well), analysts will not even be aware of STIX being used in the background to transfer their data.  Today though, they are paying attention, they will be asked by their leadership to look at the standard and provide their opinion on how valuable it is to adopt STIX, and analysts will not understand why they canât represent a file found in an email has a C2 beacon that resolves to a domain (or something similar).  The answer to just trust us that the receiver is going to auto-correlate that information back together, probably wonât fly.  
Some of these issues were masked by the limited use cases possible in STIX 2.0 and 2.1.  As the standard evolves to support Malware, Infrastructure and Incident objects these issues will become very pronounced.  We will continue to put band-aids on the standard as a result of the deficiency (ex. See the malware proposal submitted by Jeff Mates and I earlier this year).  Option 1 will resolve these deficiencies.  Will it take work and effort, yes, but that work and effort will only continue to grow the longer we wait.
Some Metrics on the two implementations of the use cases:
Option 1:
8 Objects (1 optional)  (2 SDOs, 6 SOOs)
5 Embedded refs (3 optional)
6 Relationships (6 SROs)
Option 7
15 Objects* (6 SDOs, 9 cyber observables)
5 Embedded refs (2 within Malware not shown)
2 Relationships (2 SROs) â Note some relationships in the example cannot be represented in this option
* Cyber Observables are not full objects in this option.  Therefore must be embedded in an SDO but are lighter objects that take less text to represent.
From: <cti@lists.oasis-open.org> on behalf of Jane Ginn <jg@ctin.us>
Tuesday, October 30, 2018 at 6:10 PM
cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
[cti] Groups - Weekly Working Call - Notes uploaded

Submitter's message

Here is the PDF of the notes from the Working Call. I included the figures in this version.

Best regards,

-- Ms. Jane Ginn

Document Name: Weekly Working Call - Notes

Discussed Option 1 and Option 7 for Cyber Observables

Download Latest Revision
Public Download Link

Submitter: Ms. Jane Ginn
: OASIS Cyber Threat Intelligence (CTI) TC
: Meeting Notes
Date submitted
: 2018-10-30 15:10:05

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. [attachment "image002.jpg" deleted by Jason Keirstead/CanEast/IBM]

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