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] 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
Sent: Thursday, February 25, 2016 10:11 PM
To: Mark Davidson
Cc: Kirillov, Ivan A.; Barnum, Sean D.; Wunder, John A.; cti@lists.oasis-open.org
Subject: Re: [cti] CybOX Datatype Refactoring/Deprecation

 

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.

Sent from IBM Verse

Mark Davidson --- Re: [cti] CybOX Datatype Refactoring/Deprecation ---

 

From:

"Mark Davidson" <mdavidson@soltra.com>

To:

"Kirillov, Ivan A." <ikirillov@mitre.org>, "Barnum, Sean D." <sbarnum@mitre.org>, "Wunder, John A." <jwunder@mitre.org>, cti@lists.oasis-open.org

Date:

Thu, Feb 25, 2016 2:09 PM

Subject:

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

  1. Analyzing Cyber Threats - 24 Use Cases
  2. Managing Cyber Threat Response Activities – 5 Use cases
  3. Managing Situational Awareness – 1 Use Case
  4. Management of Content Over Time – 3 Use Cases
  5. Sharing Cyber Threat Information – 14 Use Cases

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>
Date: Thursday, February 25, 2016 at 1:10 PM
To: "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

 

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]