[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] CybOX Datatype Refactoring/Deprecation
So at the risk of adding complexity to this should thread should "de-fanged” data be the same object type as the actual observable IPv4 vs say defanged IPv4?
1[.].2[.]3[.]4 is not the same as 1.2.3.4 in a search. Same as 1.2.0.0/8 not being the same as 1.2.3.4
IMHO stored ‘defanged’ data in a system designed for automation to use the ‘fanged’ data is really bad practice. “de-fanging’ should be an out out transform to presentation layers where live content is
a problem.
-Mark
From: <cti@lists.oasis-open.org> on behalf of "Crawford, David" <David.Crawford@aetna.com>
Date: Thursday, February 25, 2016 at 10:58 PM To: 'Jason Keirstead' <Jason.Keirstead@ca.ibm.com>, Mark Davidson <mdavidson@soltra.com> Cc: "'Kirillov, Ivan A.'" <ikirillov@mitre.org>, "'Barnum, Sean D.'" <sbarnum@mitre.org>, "'Wunder, John A.'" <jwunder@mitre.org>, "'cti@lists.oasis-open.org'" <cti@lists.oasis-open.org> Subject: RE: [cti] CybOX Datatype Refactoring/Deprecation I will add to my previous comment by saying that any de-fanging/obfuscation within STIX would greatly impact the value of the standard. Here’s a simple
reason: Picture a very simple flow of STIX into a database. If the IPv4 indicators are de-fanged/obfuscated I am now limited to a single search pattern; de-fang
my search query per STIX standard and then find the matching de-fanged string in the DB. What if I want to search by CIDR ranges? Now every IPv4 field has to be pulled from the DB, one by one, de-fanged and compared at the application layer where I’ve lost
any efficiencies of the database engine. The same applies for domains or URLs; if I want to search by wildcard, or regex patterns every indicator has to be pulled into the application layer de-fanged, compared, etc., etc. If the expectation is that I’m supposed to transform the indicators back prior to loading them into the database then what’s the point of mangling
them in the first place; to make them safe while in transit? That can be accomplished by encrypting the connection during transport. -Dave From:
cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Jason Keirstead Even with the Analysis use case - is the expectation that this will be done by a human reading raw XML and decoding a base64 binary in their head? It doesn't
make sense to me. A tool (which can do the defanging if desired based on the use case) will always be in the mix. Mark Davidson --- Re: [cti] CybOX Datatype Refactoring/Deprecation ---
I started my response thinking that we should step back and determine which use cases require defanging and/or obfuscation. That caused me to look at the
STIX use cases [1], of which there are between ~50-~200 (depending on which list you use to count). In doing that, I may have (re)identified a non-obvious issue that is tripping up the group. To start, I’ll show the breakdown of use case categories from the wiki page (using the first list only; emphasis mine):
The two biggest groups are “Analyzing Cyber Threats” and “Sharing Cyber Threat Information”, which I expected to find. However, seeing them laid out this way
caused me to think that perhaps these two classes of use cases might be incompatible. Analyzing Cyber Threats would seem to require a very human and document-oriented solution; Sharing Cyber Threat Information would seem to require a very automated and processing-oriented
solution. Note: I am not the first person to bring this up. Many have noted this group’s tendency to spend lots of time on seemingly straightforward technical discussions, only to have them re-opened months later. I
feel that the underlying cause is the unmediated tension between the Analysis perspective and the Automation perspective. And let me be clear: both perspectives have value, and both perspectives belong in the CTI TC. We just have to figure it out together. I feel that the recent defanging discussion is caught in the weeds because of this underlying dichotomy. I feel that I have seen (generally) two perspectives:
those who want something with strict processing rules and those who favor a more flexible solution. Further, pick any other beaten-to-death topic and you can find a similar tension of perspectives – automation, or flexibility? If we do not sort out these different perspectives, they will continue to plague our discussions in non-obvious ways, leading to frustration, exhaustion, and
design-by-committee. Let’s get together and figure out how these perspectives can coexist peacefully so that we can make the progress we all want to make. Thank you. -Mark From:
<cti@lists.oasis-open.org> on behalf of "Kirillov, Ivan A." <ikirillov@mitre.org> If we were to use a flattened representation for this, it would mean that every field that has a string as its base type would also need a corresponding field
for the capture of observed encoding. Accordingly, this would entail MANY extra fields in the Object data models, which doesn’t seem ideal.
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]