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: [EXT] [cti] Option 1 vs. Option 7 Powerpoint Example


Gary,


I like the way you have phrased the issue in this email, and after talking with you and Jeff, I agree.  The needs for this that we have identified is just the tip of the iceberg.  Malware, Infrastructure, and Incident are going to need some way of connecting to individual cyber observables.  Without that, organizations will be forced to just do their own thing. 


We need to think long and hard about things like this: "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."


Or as Sarah brought up, Threat Actor X used this IP address with this Domain Name from Jan-2018 to Feb-2018 and registered that Domain Name in May 2017 using the email address foo@example.com. That domain name while attached to IP address 1 was used as a C2 location from 2016-2017 and the domain name while attached to IP address 2 was used as an exfil site from 2017-2018.


Bret


From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Gary Jay Katz <gary.katz@FireEye.com>
Sent: Wednesday, October 31, 2018 7:20:48 AM
To: cti@lists.oasis-open.org
Subject: [EXT] [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.

 

-Gary

 

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>
Date: Tuesday, October 30, 2018 at 6:10 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Groups - Weekly Working Call - Notes uploaded

 

Submitter's message
CTI TC:

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


Description
Discussed Option 1 and Option 7 for Cyber Observables
Download Latest Revision
Public Download Link


Submitter: Ms. Jane Ginn
Group: OASIS Cyber Threat Intelligence (CTI) TC
Folder: 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.


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