Encoding the cybox version might make things easier and allow CybOX to release more quickly. But it may also mean problems for interoperability. As saying you were STIX 2.0.0 compliant would not mean as much... You would have to stay STIX 2.0.0 and CybOX 3.0.0
Thanks,
Bret Bret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
Jordan, Bret wrote this message on Tue, May 17, 2016 at 21:49 +0000:After hearing what you all mentioned on the call this morning, I was thinking that something like this might be good????? I think it was Allan that suggested encoding the version in the key.
{ "type": "indicator", "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f", "created_time": "2016-04-06T20:03:48Z", "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff", "title": "Poison Ivy Malware", "description": "This file is part of Poison Ivy", "pattern": { "cybox-3.0.0": "file-object.hashes.md5 = '3773a88f65a5e780c8dff9cdc3a056f3'",
This should just be cybox... Unless we plan on supporting multiple versionof CybOX in a single STIX Standard, which I don't think we plan on doing. "snort-1.2.3": "something in snort syntax", "yara-4.6.7": "something in yara syntax"
I agree w/ encoding the version in the key.. This would make supportingmultiple version of snort/yara, etc more straight forward.On May 17, 2016, at 15:36, Katz, Gary CTR DC3/DCCI <Gary.Katz.ctr@dc3.mil> wrote:
I would vote for the other pattern types be MVP, agree with how Allan suggests to do it. Having other pattern types as an option will be most valuable in initial deployment since everyone is currently using other pattern types. Not having it in initial deployment will leave a negative-first-impression among users that we would have to later overcome.
-----Original Message----- From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Allan Thomson Sent: Tuesday, May 17, 2016 9:41 AM To: Jordan, Bret; cti-stix@lists.oasis-open.org Subject: [Non-DoD Source] Re: [cti-stix] Indicator TLO
Provided comments on the doc.
Regarding the question on non-cybox patterns. Suggest that this be a post-MVP capability. If others feel strongly that it should be included then we should add an attribute that identifies the pattern type (i.e. the language used) in addition to the pattern itself. Then make the pattern type a controlled vocab with cybox as the default value (and if not included).
allan
From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com> Date: Sunday, May 15, 2016 at 2:24 PM To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] Indicator TLO
All,
John and I were reviewing the Indicator TLO today and there are just a few open tasks remaining before it can be moved to the Review phase. Can we ask everyone to help us resolve these last few things? It would be nice to move this from Development to Review by end of week.
https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.8gcmzx50n1ri
Open Tasks
• What are the values for the Labels field? Is it a controlled vocab or just an array of strings?
• What is the Decay_Rate and is it MVP?
• Do we allow non-cybox patterns (test mechanisms, like yara, openIOC, snort)? And is it MVP?
• Clean up property descriptions
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
-- John-Mark
|