[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] CybOX Datatype Refactoring/Deprecation
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.
John
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
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org
Patrick Maroney
President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org 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:
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.
Regards,
Ivan
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]