[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Working Call Recap
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.
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> 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]