[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti] CybOX Datatype Refactoring/Deprecation
|
Totally concur. I’m all about creating a normative defanging standard, and wish everyone would embrace it. I also think that effective tools implementing
this standard would start to convince the email lists to do things a certain way. Pat, do you think this is acceptable even if we pursue option #1 to keep the information in the packages fanged? Alex From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Wunder, John A. 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> 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
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. Regards, Ivan 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]