Subject: [mile] Brief overview context of CybOX vision and status as it relates to a Digital Forensics extension to IODEF

From: "Barnum, Sean D." <[email-masked]>
Date: Fri, 23 Mar 2012 19:08:44 +0000

There has been some discussion on the list recently about the relevance and
opportunity that CybOX (http://cybox.mitre.org) offers for a Digital
Forensics (DF) extension to IODEF. Those familiar with CybOX and its current
uses within CAPEC (attack patterns), MAEC (malware characterization) and
efforts to standardize the expression of cyber threat indicators will
recognize the overlap between DF and the purpose and structure of CybOX.
Elaborating CybOX to more effectively support the needs of DF has been
within our stated plans for some time now as can be seen on the CybOX
website (http://cybox.mitre.org/language/usecases.html). We have had several
discussions with Simson Garfinkle in regards to his DFXML efforts and his
stated interest in having us refactor DFXML based on CybOX and to elaborate
CybOX appropriately to better cover DFXML's informational scope.  

We are currently in the last week or so of wrapping up work on a v1.0(draft)
release of CybOX that will include a significantly refined schema with more
elaborate objects that better cover the domain (~ 65 defined objects
including an initial set of network objects), a set of formal specifications
for the language, and an initial set of transforms for related
representations like Snort and OpenIOC. This version will already cover a
good portion of the information structures needed to express the basics of
DF (including defined schemas for Device objects, Volume objects, File
objects, Registry objects, etc.) as described by DFXML and several other
similar works. However, there will still be open questions on specific fine
details as well as additional DF domain-specific information needs that will
not yet be sufficiently covered. Our plan has been to focus on resolving
these issues starting in April after the v1.0(draft) release. Our hope has
been that by resolving these issues we would be able to then submit a mature
and practical Internet Draft to the MILE WG for a Digital Forensics
extension to IODEF that is compatible with CybOX, MAEC, and CAPEC. Chris
Inacio's work pulling together an initial Internet Draft and the schedule to
discuss it at the Paris meeting is a little early for us to constructively
engage given our original schedule outlined above.

The draft submitted by Chris is clearly targeted at the same space of
intersection and support that CybOX enjoys with DF and appears to be derived
from a subset of DFXML. While we have taken a slightly different approach to
how the information is structured, we are targeting the same problem and we
feel that there should be ample opportunity to collaborate and work together
as a working group on maturing towards a common practical solution.

In absence of a complete Internet Draft from us, I am hoping that a very
brief description of our vision (some of which has been explained above) and
how we are approaching it will at least give some context for the group
discussion of extending IODEF for forensics during the MILE WG meeting in
Paris. 

In a very brief summary, the unique dimension to our vision and approach for
DF lies in our emphasis on a layered approach that we believe is important
for flexibility and modular reusability of various structures and content
across a variety of use cases.

We envision the following four-layered structure:

Layer 4: A representational structure for lightweight incident information
exchange to aggregate and communicate a variety of structured cybersecurity
information related to specific incidents. 

IODEF obviously makes the most sense here.

This layer is focused on the exchange of Incident data.

Layer 3: A representational structure for the exchange of Digital Forensics
data with a focus on integrity, confidentiality and chain of custody. 

Currently, the DEXF Recommendation under ITU-T as supported by South Korea
appears to be a logical choice for this layer.  

This layer is focused on the exchange of Digital Forensics data.

Layer 2: A representational structure for the contextual packaging and
characterization of forensic data analysis (the analysis itself not the data
being analyzed) including forensic domain-specific data and references or
inclusion of actual raw evidence itself such as image files, volumes or
memory dumps.

No standardized structural representation for this layer currently exists.
Formats such as DFXML currently conflate this layer with the underlying data
analysis characterization layer described below. Part of the work that the
CybOX effort plans to take on starting in April is to work with relevant
experts to determine where the dividing line exists between Layer 2 & Layer1
and defining a lightweight schematic representation for this layer.

This layer is focused on characterization of the process, context and
packaging of Digital Forensics analysis (data about the analysis itself)

Layer 1: A representational structure for the characterization of the
forensic data analysis results (structured metadata about the evidence in
the form of cyber observables). CybOX appears to be a good choice for this
layer as it is focused specifically on the characterization of cyber
observables (including all of the DF usual suspects) and brings with it
correlation value and potential economies of scale due to its use in several
other use case domains related to DF.

This layer is focused on the characterization and description of Digital
Forensics analysis results (data about the actual evidence analyzed) to
support evidentiary purposes or to guide and enable further analysis.

Slide 1 of the attached deck gives a simple graphical view of this layering.

Why a layered approach?

By having the full layer stack described above we have adequate capability
for addressing the full issue of exchanging incident-related DF data.

By having the pieces broken into layers based on their focused function,
domain of supporting experts and their practical use case footprint we
enable better flexibility in how they are developed and matured and enable
the use of individual layers in varying use cases within and outside of DF.
Slides 2-7 of the attached deck outline how the layers apply to a few simple
but important use cases.

>From our perspective, we do not see any real conflicts among the various
layers described here and the proposed existing representations. On the
contrary, it looks like there should be some potentially powerful synergies.

While I recognize that this brief overview of our approach cannot possibly
answer all questions you may have, I hope that it at least lets you know
where we are coming from, where we are at in working the issue and that your
input and collaboration are very welcome. I hope that it also can help
inform the upcoming discussions in Paris of the potential approaches and
solutions to this problem.

Thanks for taking the time to read this BRIEF (J) message,

Sean Barnum

MITRE