|Great points Jason.... We all need to remember that in each Standard you can have separate Sub-Committees running a series of separate work products that include a series of separate working documents. |
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."
I just want to throw it out there that having separate working documents does not necessarily mean we have to have separate work products. Also, having separate work products and/or working documents, does not necessarily mean we either have to (or conversely, can not) have separate subcommittees that are maintaining those working documents and/or work products.
Tl;DR - People are confusing working documents, work products, and subcommittees too much in this thread. Lets be clear on what we're talking about.
I also agree Cybox should be a separate work product, because it has lots of usefulness outside of STIX (including the potential to create a common cyber-threat correlation language).
I am not in agreement however that CTI Common should be a separate work product (as on the ballot).
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
<graycol.gif>Paul Patrick ---03/17/2016 01:43:42 PM---+1 on the comments both by Sean and Jeff. Paul Patrick
From: Paul Patrick <firstname.lastname@example.org>
To: "email@example.com" <firstname.lastname@example.org>
Date: 03/17/2016 01:43 PM
Subject: Re: [cti] RE: Some additional thoughts on combining STIX and CybOX
Sent by: <email@example.com>
+1 on the comments both by Sean and Jeff.
On 3/17/16, 10:58 AM, "Mates, Jeffrey CIV DC3/DCCI" <firstname.lastname@example.org on behalf of Jeffrey.Mates@dc3.mil> wrote:
>I'm strongly in favor of keeping the two separate. Having separate documents makes it easier to deal with when switching between writing tools that deal with threat actor attribution instead of crimes that merely happen to involve computers.
>Jeffrey Mates, Civ DC3/DCCI
>Defense Cyber Crime Institute
>From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Barnum, Sean D.
>Sent: Thursday, March 17, 2016 10:52 AM
>Subject: [Non-DoD Source] [cti] Some additional thoughts on combining STIX and CybOX
>Several people have suggested that it would be more convenient to combine STIX and Cybox, characterizing it as a documentation issue where it would be easier to read a single document.
>Several people have explicitly stated that it is important technically that CybOX remain a separate standard to support diverse domain standards like STIX, MAEC, DFAX, etc in a focused and unbiased manner. They have also pointed out that it is a standards issue (different development groups/opinions, different conformance and different referencing) not simply a documentation issue.
>There are a lot of technical details that have been provided by numerous members of the community why STIX and CybOX should not be combined. I will not restate those here. Rather, I would just add to those details a simple statement on our responsibilities as a standards body.
>As a TC that took on responsibility for the maintenance and ongoing development of CybOX as an independent standards effort (specifically called out as such in the TC charter) we have a responsibility to continue to respect the purpose for CybOX and the community of efforts and players (including several within the TC) that depend on it as a separate standard focused on the facts of cyber observables.
>Does the TC technically have the authority to ignore the needs of this community of players and efforts and change CybOX into whatever it feels like? Yes.
>Is that a responsible or appropriate course of action? In my opinion, definitely not.
>In my opinion, it is not an appropriate standards decision to place personal opinions of convenience in form factor over directly expressed technical needs of the community.
>Thank you for considering my opinions.