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

I would agree with this as well.  Option #1 but have a best practices / normative text for implementers to say "how" you should defang / refang content in a tool.  

Pat, if you wanted to get a group of people together and take a first stab at some normative text, I think that would be a great idea.  



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 Feb 23, 2016, at 09:10, Wunder, John A. <jwunder@mitre.org> wrote:

Hey Pat,

Given your caveat, it sounds like you agree that #1 is the right approach for the machine-to-machine language? Based on the rest of the message, you’re thinking that we should define a normative standard for how tools should display defanged data to users in their UI?

If that’s what you’re saying, I agree. If users and vendors think it’s useful, I could see a group like us defining best practices for defanging data in the UI. That said, priority-wise I would place it lower than getting the initial 3.0 release out.


PS: I prefer #1.

From: <cti@lists.oasis-open.org> on behalf of Patrick Maroney <Pmaroney@Specere.org>
Date: Tuesday, February 23, 2016 at 10:47 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Ivan Kirillov <ikirillov@mitre.org>
Subject: Re: [cti] CybOX Datatype Refactoring/Deprecation

In the spirit of full and open discourse, I would like to elaborate on the basis for the recommendation that we establish a normative "de-fanging" standard. 

Caveat: I fully concur with core concept that at the machine to machine level we need to communicate the "truth on the ground" aka the actual actionable IOCs. Yes, de-fanging/re-fanging is an ETL ingestion and UI/UX issue which is indeed an implementation detail.

Here are the arguments for why I posit this is in "our wheeelhouse":

(1) We are seeking to define International Standards for Cyber Threat Intelligence language, interexchange frameworks, and ecosystem.  If not us, who?

(2) Handling "live ammo" is dangerours business, period. Even for "seasoned" professionals.

These risks extend beyond the obvious ones (e.g., a live http link rendered in a spreadsheet, double clicking a file when you meant to single click to select). They extend to: (1) a malicious Image file that inadvertently but effectively triggers an exploit when it's thumbnail is rendered behind the scenes; (2) a chunk of "live" _javascript_ that get's interpreted when pasted into a field on a web portal that accepts "Source"/rich content; (3) an exploit that is trigerred when the contents of a file are open for indexing. Note that these examples all reflect actual "real-world" scenarios that have burned me personally (having to rebuild my analysis systems) back before the days of revertible virtualized desktops/analysis systems.

(3) One of core missions for a section of our community is to extend protections from our crowd sourced intelligence down to all corners of society, including (under-staffed/under-resourced) IT Organizations tasked with operationalizing CTI that have no concept of the underlying risks.

The Proposal:

As anyone who has done extensive ETL from diverse structured and unstructured sources can attest: there seems to be a seemingly infinitie number of such conventions/methods. Even within a given aggregation source it seems that each analyst comes up with their own variations.

To the argument that there are existing de-fanging conventions within a given community, I wholeheartedly agree. I've led such efforts to very good effect in some communities. This is in fact the core basis for my argument for a CTI TC Normative De-Fanging Standard.

This proposed normative standard is a stand-alone CTI TC document meant to foster adoption of common methodologies in as many communities as possible. This proposal is not a panacea, there will still be folks that go their own way (and those of us doing ETL will still need to deal with decoding "chaos"), however having a normative standard to establish a global convention all can reference can only advance our game. I also believe a convention provides a valuable construct for handling "live ammo" as it passes between the diverse functional elements of the ecosystems we will build using the OASIS CTI TC Standards.

Thank you for taking the time to consider the merits of this proposal. As always, critical thinking and challenges to any of these assertions are welcomed.

Patrick Maroney
Integrated Networking Technologies, Inc.
Email: pmaroney@specere.org

Patrick Maroney
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org

On Tue, Feb 23, 2016 at 7:30 AM -0800, "Kirillov, Ivan A." <ikirillov@mitre.org> wrote:

Great discussion here! Personally, I’m with Alex and others in the school of thought that UI/presentation layer fields should be kept out of the standards. 

So I think we have a few options:
  1. Remove ALL defanging/refanging and metadata from of CybOX Object fields. The main impact of this is the simplification of Object field specification in instance data, e.g., {“file_name”:”xyz.dll”} instead of {“file_name”:{“value”:”xyz.dll”}}. The downside is that we lose the ability to specify these properties on Object fields.
  2. Orient around defining a common defanging/refanging process and use this as the “one way” of doing it in the CTI standards. We may be able to do this without having to directly specify this on the Object fields.
  3. Leave defanging/refanging open for users/implementers to specify at the Object field level; this is essentially the same as the existing (CybOX 2.1) approach.
My own preference is option 1, as this type of simplification (i.e. removing extra layers between object fields and their values) is what I had in mind when doing some of the initial thinking around CybOX 3.0.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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