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] Working Call Recap


Arenât bundles designed to be thrown away? So if the information is only kept at the bundle level for how the identifier is generated, you would lose that information as soon as the bundle drops on the floor. You could never retransmit with that information (in the use case that you were passing along data you didnât create), and the consumer wouldnât be able to go back and reference it in the future.

 

Am I missing something?

 

Sarah Kelley

Lead Cybersecurity Engineer, T8B2

Defensive Operations

The MITRE Corporation

703-983-6242

skelley@mitre.org

cid:image006.png@01D0A90C.2B5B2680

 

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Sean Barnum
Sent: Wednesday, May 15, 2019 5:15 PM
To: Piazza, Rich <rpiazza@mitre.org>; Bret Jordan <Bret_Jordan@symantec.com>
Cc: cti@lists.oasis-open.org
Subject: Re: [cti] Re: [EXT] Re: [cti] Working Call Recap

 

I see two options.

 

  1. Make Bundles contain objects of only one id method approach. If you have objects of different approaches you would need to break them into separate bundles. This would address the question but could be kind of complex in some situations so would not be my preferred approach.
  2. Add id_method and id_method_details to Bundle but also leave them as optional on objects.
    1. This way the 99.9X% case (a producer sharing their own homogenous content) would simply assert the values at the Bundle level and it would apply to all content in the bundle.
    2. For the 00.0X% case where a Bundle could contain objects using multiple id approaches you would define the primary method on the Bundle and then the different method on the objects where it applies. So, if an object contained those properties it would override the assertion at the Bundle level. I think this is the best of all worlds. It is highly efficient. It very simply covers the large majority of cases and still provides a slightly more complex but very simple way of dealing with the minority case.

 

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: <cti@lists.oasis-open.org> on behalf of "Piazza, Rich" <rpiazza@mitre.org>
Date: Wednesday, May 15, 2019 at 3:56 PM
To: Bret Jordan <Bret_Jordan@symantec.com>, Sean Barnum <sean.barnum@FireEye.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Re: [EXT] Re: [cti] Working Call Recap

 

How do we handle bundles that contain SCOs with different methods of creating the UUID?

 

For instance - Iâm just passing on various SCOs I received from different producers, who used different methodsâ

 

From: <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Wednesday, May 15, 2019 at 3:50 PM
To: Sean Barnum <sean.barnum@fireeye.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Re: [EXT] Re: [cti] Working Call Recap

 

After talking with Sean on the phone about this, even though this is very late in the game, I think this really makes a lot of sense. I think if we would have thought about this during the Mini-Group we probably would have done this from the get go.

 

Basically, to be really clear, what he is proposing is that we move the id_method and id_method_details from individual SCOs to the Bundle.  

 

The pros I see are:

1) less bloat on the wire 

2) simplify some of the indicator text 

 

We can talk about this in next weekâs working call.  

 

Bret 

 

 

Sent from my Commodore 128D



PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050


On May 15, 2019, at 8:33 PM, Sean Barnum <sean.barnum@fireeye.com> wrote:

I have reviewed the changes highlighted below and added various comments in the doc.

I see that Bret has already accepted many of them.

 

There is one very major issue we have with a proposed change that would require id_method and id_method_details on EVERY SCO for a producer using a non-default approach for deterministic id generation.

This proposed change would require MASSIVE unnecessary bloat in STIX content as the same exact ~7 lines of JSON would need to be added to every SCO produced. Given the fact that we (and I am sure others) deal with SCOs on the scale of billions this proposed change would make STIX untenable as an option for us.

 

I would like to propose an alternate approach that I think achieves the intended purpose in a MUCH more efficient and unbloated fashion.

I propose that the id_method and id_method_details properties be added to the Bundle object and would assert the deterministic id method used for content within the bundle.

  • It would support the intended purpose under options 1-3
  • It would be far more efficient in that it would only be necessary to specify it a single time for a Bundle that could contain thousands of SCOs.
  • It would be clear and easy to understand.
  • It would allow us to simplify the language under the identifier section of the spec

 

 

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Tuesday, May 14, 2019 at 5:56 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Working Call Recap

 

All,

 

We had a good call today and were able to resolve some of the last few issues that were holding up the release of Working Draft 04.

 

Summary:

 

1) After editorial review we noticed that the language for identifiers would not allow two organizations to write code and produce the same deterministic ID.  So we needed to tighten down the language and define what an OASIS STIX 2 deterministic ID actually is. Prior to the call I worked with Allan, Trey, Rich P, and the MISP folks on an acceptable solution. We reviewed the changes on the working call and the changes are now in section 2.9.  Please review. 

 

2) On the Malware Analysis object we had a property called "analysis_environment" that was a dictionary that used a three value vocabulary.  This design no longer works since we do not have the cyber observable container anymore.  So we had to make a change. The consensus on the call was to use properties on the malware analysis object itself and remove the vocabulary.  Those changes have been made in suggestion mode in section 4.11.  Please review.

 

3) We also accepted small changes to the following sections;

 

a) 2.7 Hashes

b) 3.2 Spec Version

c) 10.13 Infrastructure Type Vocabulary

d) 4.3 Course of Action os_execution_envs

e) 4.13 Observed Data

f) 4.18 Vulnerability Relationships

 

 

Action Items:

 

i) Please make a final in depth review of COA and provide any description text changes you feel appropriate. 

ii) Review the changes to Malware Analysis 

iii) Review the changes to the identifier 

iv) Start making your top down full review of the documents

 

 

Schedule:

On the call we said we would give the TC one more week to review the changes to Malware Analysis and the identifier.  So depending on how next week's working call goes, we might be able to release Working Draft 04 next week. 

 

 

Thanks

Bret

 

 

 

 

 

 

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.

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]