And from our "real world" example, since about 2001-ish we have been passing and collecting an enormous amount of threat intel objects on a daily basis from sites all over the planet and we have never had a problem. We do this at scale, and are not seeing
an issue.
This is not a specification level item. This is an implementation / deployment / process level issue. Any vendor or user organization that wants to do this, can do so in a product (if the product UI allows them). This is exactly why we called
out support for the "x_" prefix.
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."
I will also provide my “real world” examples of dealing with various intelligence feeds over the wire since about 2009 (I lead the Threat Intel group at my organization)
and have never experienced a negative outcome due to unadulterated indicators. We are an SSL inspection environment, monitor on every ingress/egress point at all levels of the stack, and I’m pulling from a number of commercial and open source providers. It
is simple to disable SSL inspection on the network feeds from the defined sources to avoid the false positives.
The STIX standard should only address how the data will be represented, not how it will be transported, presented to the user, etc etc.
From: Patrick Maroney [mailto:Pmaroney@Specere.org]
Sent: Friday, March 04, 2016 8:09 PM
To: Terry MacDonald; Bret Jordan
Cc: cti@lists.oasis-open.org; Crawford, David; Jason Keirstead; Foley, Alexander - GIS
Subject: Re: [cti] CybOX Datatype Refactoring/Deprecation
I'm not going to beat this one to death, but need to highlight that I provided a half dozen "real world" examples where passing "Truth on the Wire" resulted in very very negative outcomes. One scenario could have easily resulted in $Millions of mitigation
costs. Admittedly none of these scenarios were based on STIX as very little security/network infrastructure actually supports same operationally today. However, the core root causes leading to significantly undesirable outcomes *will be identical* as we
pass these same clear text IOCs embedded in STIX Packages.
I don't want to draft a treatise on the issues of architecting, deploying, and managing large scale mesh VPN/GRE/etc networks. Suffice it to say this sounds good as a philosophical concept but fails in large scale complex networks, especially those that intend
to integrate CTI capabilities in as many devices/systems
In my view it is trivial to base64 encode/decode the STIX packages as they are serialized/deserialized.
Please note that I'm a staunch supporter of passing the "Truth on the Wire". So this is really a separate argument from the defanging discussion. It is however, in my view, a direct secondary issue from a presumed decision to require/pass "Fanged" content.
This will be my last attempt to provide the use cases and basis for the proposed method of minimizing impacts of handling "Live Ammo".
On Fri, Mar 4, 2016 at 1:51 PM -0800, "Terry MacDonald" <terry@soltra.com> wrote:
The one problem with 'raw' indicators is the fact that they are exposed on the wire and can create a lot of alerts on SSL intercepting network IDS tools.
This fact can be mitigated by adding alert suppression on the network IDS to stop it alerting. This of course causes its own problems, as it means that if the TAXII server is compromised and starts communicating with malicious infrastructure it may not be detected by the network IDS due to its alert suppression.
That being said, I'm still not a fan of base64 encoding all indicators. We didn't do it in STIX v1.x and the internet didn't break. Network is could see the raw XML and we all coped OK. And it makes it simpler for people to build the tools and to learn, read and write the JSON -which is important in the early embryonic stages of a new standard such as this one.
My vote is to NOT base64 all the things on the wire.
Cheers
Terry MacDonald
I do not believe base64 encoded JSON is needed. Further, that would provide one more step in the computational cycle and hinder STIX at scale. Just to level set everyone, we need to plan for procession 50-100 million STIX objects a day. At that scale, no
one is going to be looking at the RAW JSON and thus tools will be responsible for displaying data correctly.
This whole thing is an implementation and deployment level issue, not a specification level issue.
Sent from my Commodore 64
The motion to require Base64 of encoding of STIX Data "on the wire" is completely independent of any decisions about whether or not we pass "the truth on the wire".
If no one seconds the motion, then the Base64 question is a moot point.
I don't see how we can include that on the ballot, since it implies a "yes" vote to the first question.
IE if we don't want support defanging inside STIX at all, then a question on the method of defanging is a moot point.
Sent from IBM Verse
Foley, Alexander - GIS --- RE: [cti] CybOX Datatype Refactoring/Deprecation ---
|
From:
|
|
|
To:
|
|
|
Date:
|
Fri, Mar 4, 2016 11:25 AM
|
|
Subject:
|
RE: [cti] CybOX Datatype Refactoring/Deprecation
|
I’m sorry all, I haven’t opened the ballot yet because I haven’t heard a second on Pat’s motion that we also include an option on base64 encoding in addition to the
yes / no options for “should we allow for defanging.” Is there a second for the explicit option that the “yes” option for defanging should insist on base64 encoding as the one way of defanging?
Which of the Cybox objects are you recommending be Base64 encoded, just those that may contain binaries?
In addition to the up or down motion to pass "truth on the wire", I make a motion to add (2) Base64 encoding of STIX/Cybox content "on the wire" as a "Must" requirement for low impact/high effectiveness method to minimize impacts of handling "Live Ammo" within
STIX Packahes as they are passed between systems, applications, APIs, etc..
I second the motion and will open the ballot today.
The co-chairs and Rich discussed this issue and issues like it at length this morning. The conclusion we came up with is that it appears that there is general consensus. However, to be sure, we are going to propose that when issues like this get this muddy,
that we just open a simple vote to see if we have official consensus so we can just move on, and stop having circular discussions.
Alex, I therefor motion that we open a ballot on this issue. Namely "Should STIX and CybOX support the ability to capture content in a defanged form and thus also include the ability to track that yes it was defanged and how it was defanged"
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
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."
That seems a reasonable summary to me. I think there is enough consensus to at least park it until after the first release of CybOX 3.
Cheers
Terry MacDonald
It seems to me there is a rough concensus that we *should not* be supporting the de-fanging of data within STIX, with several people bringing up many strong arguments for why it is a bad idea to transmit on the wire and/or store data in a de-fanged fashion.
At a minimum, it seems to me that there is certainly a rough concensus that the supporting of de-fanging of data within STIX is not an MVP requirement.
Any chance we can proceed with this concensus, table this issue until after the release, where it can be raised again if it is later found to be a requirement? Anyone opposed to that?
-
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
<graycol.gif> Joep Gommers ---03/03/2016 05:05:26 AM---To support this statement based on our implementation of exactly this; At rest any information is st
From: Joep Gommers <joep@eclecticiq.com>
To: Chris Ricard <cricard@fsisac.us>,
Mark Clancy <mclancy@soltra.com>, "'cti@lists.oasis-open.org'"
<cti@lists.oasis-open.org>
Date: 03/03/2016 05:05 AM
Subject: Re: [cti] CybOX Datatype Refactoring/Deprecation
Sent by: <cti@lists.oasis-open.org>
To support this statement based on our implementation of exactly this;
At rest any information is stored as close to its original as possible. Defanging information is fanged back
to ensure the ability to correlate, compare, cluster, etc. Depending on the use-case of the information, information is defanged on consumption by humans or when presenting on systems (e.g. a browser app for example) that could potentially generate action
outside of the users control. E.g. Our UI ensures that things are defanged.
E.g. When exported:
E.g when you need to be able to compare mentally
e.g when you risk clicking it:
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.
If you are not the intended recipient, please delete this message.
This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.
If you are not the intended recipient, please delete this message.
This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna
|