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] Some additional thoughts on combining STIX and CybOX


I would also like to see a response to Bret’s request. I have called out the same question in my CTI Common ballot comment and it has gone unanswered so far. From my internet searches, it would appear that Eoghan and Sean are among the DFAX leads [1][2][3]. Surely you would be the ones best able to articulate and provide evidence for the claims you are making?

Personally, my opinion about document organization is going to be most impacted by a clear articulation of technical facts. What I’ve seen so far is essentially a threat: “if the CTI TC does not meet the demands of DFAX then DFAX will stop using CybOX”. Quite frankly, I don’t think our choices should be held hostage by a nebulous downstream “community" whose arguments have so far been hand-wave requirements.

To the DFAX community: The CTI TC has been very patient and willing to hear your arguments. Instead of articulating them, you have threatened to break off. I am sorry it is coming to this, but I would like to issue a challenge: please clearly articulate your technical requirements or withdraw them as requirements. This topic has circulated on the list long enough when we should be spending time making progress on STIX, TAXII, and CybOX.

Thank you.
-Mark

[3] https://github.com/DFAX/dfax (Last update: August 2015)

From: <cti@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Friday, March 18, 2016 at 11:23 AM
To: "Casey, Eoghan CIV DC3/DCCI" <Eoghan.Casey@dc3.mil>
Cc: "Wunder, John A." <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Some additional thoughts on combining STIX and CybOX

This should make it easier for DFAX as you would not need to bring along the extra STIX specific baggage.  Please give specifics of how John's proposal would hinder DFAX so we can take that in to consideration.  


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." 

On Mar 18, 2016, at 07:55, Casey, Eoghan CIV DC3/DCCI <Eoghan.Casey@dc3.mil> wrote:

John,

DFAX depends on the rich and flexible relationship _expression_ enabled by the current architecture of CybOX and CTI Common.

The proposals to merge CybOX+STIX, or merge CTI Common into STIX, is causing the DFAX community to consider separating from CTI/CybOX.

This causes similar issues with the connections between MAEC and CybOX. Currently, MAEC is dependent on CybOX. The proposed mergers would make MAEC unnecessarily tightly coupled with STIX.

If anyone in this group is interested in joining the DFAX development that is breaking off, please let me know.

Eoghan Casey
Chief Scientist
Defense Cyber Crime Center (DC3)
410-694-4329
Eoghan.Casey@dc3.mil

-----Original Message-----
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Wunder, John A.
Sent: Thursday, March 17, 2016 5:24 PM
To: cti@lists.oasis-open.org
Subject: [Non-DoD Source] Re: [cti] RE: Some additional thoughts on combining STIX and CybOX

Hey everyone,

I'm probably one of those people Sean is referring to who suggested that STIX and CybOX be merged…I’ve certainly thrown it around before in my head and in a few sidebar conversations. I’m a strong believer in keeping an open mind and making sure to consider all options, even those that seem crazy at first glance.

That said, at this point I agree that STIX and CybOX should not be merged, for all the reasons pointed out below.

On the other hand, as Jason said, that doesn’t necessarily mean that we need CTI Common as a separate thing. My current opinion is that much of what’s in CTI Common actually belongs in STIX, and that the reason we can’t do that now is our conception of what goes in STIX vs. CybOX is wrong.

I attached a .ppt with a more complete discussion, but the bottom line is that what I’m proposing is that we refocus STIX and CybOX on their core missions:

- CybOX is a registry of definitions for cyber observables (IP, File, E-mail, etc.)
- STIX is the way to represent and share cyber threat intelligence.

The big change here is that “Observation”, previously defined in CybOX, would move to STIX. This would mean that CTI Core and associated fields/capabilities can also move into STIX, since CybOX no longer needs to deal with versioning, marking, etc. outside of STIX. That greatly mitigates the need for having CTI Common, as very little outside of CTI Core was really shared (just ID, timestamp format, and maybe some miscellaneous other things).

Obviously there are more details here, in particular because CybOX currently requires relationships to represent some types of observations. The attached powerpoint talks more about this and how we could solve it. Overall though, this separation of concerns makes much more sense to me personally and seems to lead to a cleaner structure that lets other specifications (e.g. MAEC) use CybOX without being required to pull in things like versioning, data markings, and CTI Core.

I’m sorry to rush this proposal out, but the CTI Common ballot closes Monday and I wanted to give everyone at least a couple business days to think this proposal over first. I’m happy to talk about it on Slack or on the phone if anyone is interested.

John

From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Thursday, March 17, 2016 at 1:59 PM
To: Paul Patrick <ppatrick@isightpartners.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] RE: Some additional thoughts on combining STIX and CybOX



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).

-
Jason Keirstead
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


Inactive hide details for Paul Patrick ---03/17/2016 01:43:42 PM---+1 on the comments both by Sean and Jeff. Paul PatrickPaul Patrick ---03/17/2016 01:43:42 PM---+1 on the comments both by Sean and Jeff. Paul Patrick

From: Paul Patrick <ppatrick@isightpartners.com>
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 03/17/2016 01:43 PM
Subject: Re: [cti] RE: Some additional thoughts on combining STIX and CybOX Sent by: <cti@lists.oasis-open.org>


________________________________




+1 on the comments both by Sean and Jeff.  



Paul Patrick





On 3/17/16, 10:58 AM, "Mates, Jeffrey CIV DC3/DCCI" <cti@lists.oasis-open.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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computer Scientist
Defense Cyber Crime Institute
jeffrey.mates@dc3.mil
410-694-4335

-----Original Message-----
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Barnum, Sean D.
Sent: Thursday, March 17, 2016 10:52 AM
To: cti@lists.oasis-open.org
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.

Sean’s opinion:
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.

sean







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