Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live on the website

From: Luis Nunez <[email-masked]>
Date: Mon, 16 Apr 2012 18:44:28 -0400

I like the inclusion of the network-centric objects.  IPFIX (netflow)  will add an additional perspective from an incident information sharing standpoint.  

-ln

On Apr 16, 2012, at 4:04 PM, Barnum, Sean D. wrote:

> Hey everyone,
>  
> I just wanted to let you all know that CybOX v1.0 (Draft) content is now live on the website. http://cybox.mitre.org
> The release notes are provided inline below.
> The key items of note are:
> ·        The release of two formal specifications for the CybOX language (one for the core language and one for the defined objects)
> ·        The XML Schema has gone through extensive improvements for expressiveness, clarity, consistency, efficiency, alignment to existing normative references and documentation.
> ·        This release includes an initial set of language utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set of Python bindings for the CybOX language.
> ·        The website now includes a small set of content examples. This set will grow going forward.
> 
> This release involved a lot of hard work from a diverse group of people. Thank you all for your contributions and effort. We could not have done it without you.
> We look forward to everyone’s feedback and collaboration as we continue to improve and mature the CybOX language.
>  
> Sean Barnum
>  
>  
>  
> CybOX v1.0 (Draft) Release Notes
> 
> The Version 1.0 (Draft) release of Cyber Observable eXpression (CybOX™) is intended as a draft release of an initial major version of the CybOX Language that could be utilized for practical operational use and integration into other standards efforts. This release consists of three primary components: a pair of formal language specifications for the core language content and defined objects content, a set of language implementation XML schemas (core, common_types, and ~70 defined object schemas), and a small initial set of language utilities including an initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX transform and a set of CybOX language Python bindings. Recognizing that this is the first time that the formal language specifications will be available for review and as such will likely generate feedback from new stakeholders, this initial major version is being released as a “draft” v1.0 with the expectation of cycles of new feedback and revision before a “final” v1.0 is released.
> The CybOX v1.0 (Draft) XML schemas include a significant number of changes from v0.7 to improve:
> ·       Clarity, documentation, and descriptive formality for reference and implementation by other standards and users.
> ·       Consistency, simplicity, and efficiency.
> ·       Alignment (as appropriate) to existing normative references.
> ·       Expressiveness of the schema to better support the broad set of use cases it targets (malware characterization, indicator and incident data sharing, event management, etc.) including the addition of an initial set of network-related defined objects.
> 
> Summary of changes from CybOX_v0.7 to CybOX_v1.0_(Draft):
> Refinement of namespaces and schema locations for better effectiveness and flexibility going forward.
> Normalized all content according to an established set of naming conventions.
> Fully annotated all language items (types, attributes, elements, etc.).
> Moved several commonly leveraged types out of the core schema and into common_types.
> Achieved full typing of entire schema structure such that all attributes and elements are definitively typed.
> Changed all identifiers from ID and IDREF types to be QNames enabling globally unique identifiers and flexibility for domain-specific users of CybOX to define their own identifier syntax locally.
> Reordered attributes and elements in numerous types to better reflect common usage and priority.
> Added major_version and minor_version attributes for core schema.
> Added capability to characterize source of overall observable package data and for individual observables.
> Modified the logical composition structure such that any such compositions are now contained within a Observable_Composition element providing improved simplicity and modularity.
> Removed the Delta element from ObservableType and relocated the appropriate portions (Change, Trend, and Frequency) to appropriate locations under Stateful_Measure and Event.
> Added a Domain_Specific_Object_Attributes field to Object utilizing an abstract type that will allow domain-specific use cases to add in their own domain-specific attributes for Objects.
> Added a Tool-Specific_Data field to ToolInformationType utilizing an abstract type that will allow addition of tool-specific data.
> Added an Indicators field to MeasureSourceType utilizing an abstract type that will allow characterizing differing formats or standards of indicators that may have led to the identification of the observable data.
> Enhanced the Hash structure to capture full fuzzy hashes in addition to simple hashes
> Added a new ExtractedFeaturesType that can be used to adorn differing objects (e.g., files, memory, etc.) to capture extracted strings, imports, functions and code snippets
> Added a ByteRunsType to enable capture of byte runs within various objects.
> Added object_reference attribute to DefinedObjectType to better support referencing of independently defined Objects from within another Object definition.
> Added a generic DataSegmentType to provide a relatively abstract way of characterizing data segments that may be written/read/transmitted or otherwise utilized in actions or defined in objects.
> ·        Added several new defined object schemas (API, Code, Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, Network_Subnet, Unix_Network_Route_Entry) including an initial set of network-centric defined objects.
> Modified every defined object schema with added annotations as well as minor and in some cases substantive changes to fix errors, improve consistency and alignment with existing normative references, and to improve expressiveness in support of the targeted use cases.
> Detailed changes from CybOX_v0.7 to CybOX_v1.0_(Draft):
> The level of changes within v1.0 (Draft) in the core schema, common_types and the defined object schemas is too great to list every change in these release notes. Detailed difference reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_reports.zip
>  
>  
> ===============================================
> Sean Barnum
> Cyber Security Principal
> The MITRE Corporation
> Email: [email-masked]
>  
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: "Omar Santos (osantos)" <[email-masked]>
Date: Mon, 16 Apr 2012 19:17:15 -0500

I echo Luis' comments. It is good to see the inclusion of network
objects. Quick question to the team related to your netflow comment.

I am looking at:

http://cybox.mitre.org/XMLSchema/cybox_core_v1.0%28draft%29.xsd

... and it looks that we renamed it to "Data Flow"?

<xs:enumeration value="Data Flow">

   <xs:annotation>

        <xs:documentation>Specifies the class of events dealing with
data flow.</xs:documentation>

   </xs:annotation>

</xs:enumeration>

What is the difference between that and "Packet Traffic"?

<xs:enumeration value="Packet Traffic">
   <xs:annotation>
     <xs:documentation>Specifies the class of events dealing with packet
traffic.</xs:documentation>
   </xs:annotation>
</xs:enumeration>

 

Regards,

Omar Santos
Incident Manager, PSIRT
Security Research and Operations
Cisco Systems, Inc.
Email: [email-masked]
Phone: +1 919 392 8635
PGP Key: 0x3AF27EDC

Cisco.com - http://www.cisco.com
Cisco Security Advisories and Notices - http://www.cisco.com/go/psirt

This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Luis Nunez
Sent: Monday, April 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: [email-masked]; [email-masked]; Doug Wilson ([email-masked]);
[email-masked]; IPA-Masato Terada ([email-masked])
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live
onthe website

I like the inclusion of the network-centric objects.  IPFIX (netflow)
will add an additional perspective from an incident information sharing
standpoint.  

-ln

Hey everyone,

I just wanted to let you all know that CybOX v1.0 (Draft) content is now
live on the website. http://cybox.mitre.org

*        The release of two formal specifications for the CybOX language
(one for the core language and one for the defined objects)

*        The XML Schema has gone through extensive improvements for
expressiveness, clarity, consistency, efficiency, alignment to existing
normative references and documentation.

*        This release includes an initial set of language utilities: a
draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, and
a set of Python bindings for the CybOX language.

*        The website now includes a small set of content examples. This
set will grow going forward.

This release involved a lot of hard work from a diverse group of people.
Thank you all for your contributions and effort. We could not have done
it without you.

We look forward to everyone's feedback and collaboration as we continue
to improve and mature the CybOX language.

Sean Barnum

The Version 1.0 (Draft) release of Cyber Observable eXpression
(CybOX(tm)) is intended as a draft release of an initial major version
of the CybOX Language that could be utilized for practical operational
use and integration into other standards efforts. This release consists
of three primary components: a pair of formal language specifications
for the core language content and defined objects content, a set of
language implementation XML schemas (core, common_types, and ~70 defined
object schemas), and a small initial set of language utilities including
an initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX
transform and a set of CybOX language Python bindings. Recognizing that
this is the first time that the formal language specifications will be
available for review and as such will likely generate feedback from new
stakeholders, this initial major version is being released as a "draft"
v1.0 with the expectation of cycles of new feedback and revision before
a "final" v1.0 is released.

The CybOX v1.0 (Draft) XML schemas include a significant number of
changes from v0.7 to improve:

*       Clarity, documentation, and descriptive formality for reference
and implementation by other standards and users.

*       Consistency, simplicity, and efficiency.

*       Alignment (as appropriate) to existing normative references.

*       Expressiveness of the schema to better support the broad set of
use cases it targets (malware characterization, indicator and incident
data sharing, event management, etc.) including the addition of an
initial set of network-related defined objects.

*	Refinement of namespaces and schema locations for better
effectiveness and flexibility going forward.
*	Normalized all content according to an established set of naming
conventions.
*	Fully annotated all language items (types, attributes, elements,
etc.).
*	Moved several commonly leveraged types out of the core schema
and into common_types.
*	Achieved full typing of entire schema structure such that all
attributes and elements are definitively typed.
*	Changed all identifiers from ID and IDREF types to be QNames
enabling globally unique identifiers and flexibility for domain-specific
users of CybOX to define their own identifier syntax locally.
*	Reordered attributes and elements in numerous types to better
reflect common usage and priority.
*	Added major_version and minor_version attributes for core
schema.
*	Added capability to characterize source of overall observable
package data and for individual observables.
*	Modified the logical composition structure such that any such
compositions are now contained within a Observable_Composition element
providing improved simplicity and modularity.
*	Removed the Delta element from ObservableType and relocated the
appropriate portions (Change, Trend, and Frequency) to appropriate
locations under Stateful_Measure and Event.
*	Added a Domain_Specific_Object_Attributes field to Object
utilizing an abstract type that will allow domain-specific use cases to
add in their own domain-specific attributes for Objects.
*	Added a Tool-Specific_Data field to ToolInformationType
utilizing an abstract type that will allow addition of tool-specific
data.
*	Added an Indicators field to MeasureSourceType utilizing an
abstract type that will allow characterizing differing formats or
standards of indicators that may have led to the identification of the
observable data.
*	Enhanced the Hash structure to capture full fuzzy hashes in
addition to simple hashes
*	Added a new ExtractedFeaturesType that can be used to adorn
differing objects (e.g., files, memory, etc.) to capture extracted
strings, imports, functions and code snippets
*	Added a ByteRunsType to enable capture of byte runs within
various objects.
*	Added object_reference attribute to DefinedObjectType to better
support referencing of independently defined Objects from within another
Object definition.
*	Added a generic DataSegmentType to provide a relatively abstract
way of characterizing data segments that may be written/read/transmitted
or otherwise utilized in actions or defined in objects.

*        Added several new defined object schemas (API, Code, Device,
DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry,
Network_Subnet, Unix_Network_Route_Entry) including an initial set of
network-centric defined objects.

*	Modified every defined object schema with added annotations as
well as minor and in some cases substantive changes to fix errors,
improve consistency and alignment with existing normative references,
and to improve expressiveness in support of the targeted use cases.

The level of changes within v1.0 (Draft) in the core schema,
common_types and the defined object schemas is too great to list every
change in these release notes. Detailed difference reports are available
for each individual schema
at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff
_reports.zip
<http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_r
eports.zip> 

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: [email-masked]

---

From: "Omar Santos (osantos)" <[email-masked]>
Date: Mon, 16 Apr 2012 22:32:05 -0500

Thanks for the clarification Sean. It does make sense..

Regards,

Omar 

From: Barnum, Sean D. [mailto:[email-masked]] 
Sent: Monday, April 16, 2012 11:29 PM
To: Omar Santos (osantos); Luis Nunez
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live
onthe website

Thanks Omar.

To answer your question, first let me point out to other readers that
the two entries that Omar is quoting here exist as values in an
enumeration called EventTypeEnum which as its name implies contains a
list of different labels for grouping types (or classes) of events to be
used as low-granularity buckets for characterizing and classifying
events.

Other entries in this enumeration include things like "File Ops (CRUD)",
"Process Mgt", "Authorization (ACL)", etc.

The "Packet Traffic" value is intended to characterize events dealing
with network packet traffic as its name implies.

The "Data Flow" value is intended to characterize events dealing with
forms of data flow at a higher level of abstraction than just packet
traffic. The relationship between these two values could be viewed as
"Packet Traffic" being a more detailed form of "Data Flow" just as the
values "App Layer Traffic" and "HTTP Layer Traffic", also in this
enumeration, could be other levels in this same abstraction stack.

The idea behind the varying levels of abstraction is to leave  buckets
large enough to capture a wide variety of potential event types (e.g.
data flow events other than obvious things like packet traffic) but also
enable the use of smaller more specific buckets when they are
appropriate and commonly used.

Does this make sense? 

sean

From: Omar Santos (osantos) [mailto:[email-masked]] 
Sent: Monday, April 16, 2012 8:17 PM
To: Luis Nunez; Barnum, Sean D.
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live
onthe website

I am looking at:

   <xs:annotation>

   </xs:annotation>

</xs:enumeration>

 

Regards,

Omar Santos
Incident Manager, PSIRT

-ln

Hey everyone,

Sean Barnum

*         Normalized all content according to an established set of
naming conventions.

*         Fully annotated all language items (types, attributes,
elements, etc.).

*         Removed the Delta element from ObservableType and relocated
the appropriate portions (Change, Trend, and Frequency) to appropriate
locations under Stateful_Measure and Event.

*         Added object_reference attribute to DefinedObjectType to
better support referencing of independently defined Objects from within
another Object definition.

*         Added a generic DataSegmentType to provide a relatively
abstract way of characterizing data segments that may be
written/read/transmitted or otherwise utilized in actions or defined in
objects.

 

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: [email-masked]

---

From: "Omar Santos (osantos)" <[email-masked]>
Date: Mon, 16 Apr 2012 22:57:15 -0500

I believe that what Sean is saying is that “data flow” is just a value that is meant for upper layer protocols. But, you have a good point. Traditionally, a “flow” in “Netflow” is based on a set of 5 and up to 7 IP packet attributes:

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

- Router or switch interface

Although, there is a lot more support with Netflow version 9:

http://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00800a3db9_ps6601_Products_White_Paper.html

Regards,

Omar 

From: Millar, Thomas [mailto:[email-masked]] 
Sent: Monday, April 16, 2012 11:46 PM
To: [email-masked]; Omar Santos (osantos); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website

If "data flow" is a euphemism for "netflow" is there any reason not to call it that?

Tom Millar 
http://www.us-cert.gov/ 
------------------ 
Missit me Rubus fruticosus: 
202 631 1915 

From: Barnum, Sean D. [mailto:[email-masked]] 
Sent: Monday, April 16, 2012 11:29 PM
To: Omar Santos (osantos) <[email-masked]>; Luis Nunez <[email-masked]> 
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]> 
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website 

Thanks Omar.

To answer your question, first let me point out to other readers that the two entries that Omar is quoting here exist as values in an enumeration called EventTypeEnum which as its name implies contains a list of different labels for grouping types (or classes) of events to be used as low-granularity buckets for characterizing and classifying events.

Other entries in this enumeration include things like “File Ops (CRUD)”, “Process Mgt”, “Authorization (ACL)”, etc.

The “Packet Traffic” value is intended to characterize events dealing with network packet traffic as its name implies.

The “Data Flow” value is intended to characterize events dealing with forms of data flow at a higher level of abstraction than just packet traffic. The relationship between these two values could be viewed as “Packet Traffic” being a more detailed form of “Data Flow” just as the values “App Layer Traffic” and “HTTP Layer Traffic”, also in this enumeration, could be other levels in this same abstraction stack.

The idea behind the varying levels of abstraction is to leave  buckets large enough to capture a wide variety of potential event types (e.g. data flow events other than obvious things like packet traffic) but also enable the use of smaller more specific buckets when they are appropriate and commonly used.

Does this make sense? 

sean

From: Omar Santos (osantos) [mailto:[email-masked]] 
Sent: Monday, April 16, 2012 8:17 PM
To: Luis Nunez; Barnum, Sean D.
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website

I echo Luis’ comments. It is good to see the inclusion of network objects. Quick question to the team related to your netflow comment.

I am looking at:

… and it looks that we renamed it to “Data Flow”?

   <xs:annotation>

        <xs:documentation>Specifies the class of events dealing with data flow.</xs:documentation>

   </xs:annotation>

</xs:enumeration>

What is the difference between that and “Packet Traffic”?

<xs:enumeration value="Packet Traffic">
   <xs:annotation>
     <xs:documentation>Specifies the class of events dealing with packet traffic.</xs:documentation>
   </xs:annotation>
</xs:enumeration>

 

Regards,

Omar Santos
Incident Manager, PSIRT

From: [email-masked] [mailto:[email-masked]] On Behalf Of Luis Nunez
Sent: Monday, April 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: [email-masked]; [email-masked]; Doug Wilson ([email-masked]); [email-masked]; IPA-Masato Terada ([email-masked])
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website

-ln

Hey everyone,

Sean Barnum

·         Refinement of namespaces and schema locations for better effectiveness and flexibility going forward.

·         Normalized all content according to an established set of naming conventions.

·         Fully annotated all language items (types, attributes, elements, etc.).

·         Moved several commonly leveraged types out of the core schema and into common_types.

·         Achieved full typing of entire schema structure such that all attributes and elements are definitively typed.

·         Changed all identifiers from ID and IDREF types to be QNames enabling globally unique identifiers and flexibility for domain-specific users of CybOX to define their own identifier syntax locally.

·         Reordered attributes and elements in numerous types to better reflect common usage and priority.

·         Added major_version and minor_version attributes for core schema.

·         Added capability to characterize source of overall observable package data and for individual observables.

·         Modified the logical composition structure such that any such compositions are now contained within a Observable_Composition element providing improved simplicity and modularity.

·         Removed the Delta element from ObservableType and relocated the appropriate portions (Change, Trend, and Frequency) to appropriate locations under Stateful_Measure and Event.

·         Added a Domain_Specific_Object_Attributes field to Object utilizing an abstract type that will allow domain-specific use cases to add in their own domain-specific attributes for Objects.

·         Added a Tool-Specific_Data field to ToolInformationType utilizing an abstract type that will allow addition of tool-specific data.

·         Added an Indicators field to MeasureSourceType utilizing an abstract type that will allow characterizing differing formats or standards of indicators that may have led to the identification of the observable data.

·         Enhanced the Hash structure to capture full fuzzy hashes in addition to simple hashes

·         Added a new ExtractedFeaturesType that can be used to adorn differing objects (e.g., files, memory, etc.) to capture extracted strings, imports, functions and code snippets

·         Added a ByteRunsType to enable capture of byte runs within various objects.

·         Added object_reference attribute to DefinedObjectType to better support referencing of independently defined Objects from within another Object definition.

·         Added a generic DataSegmentType to provide a relatively abstract way of characterizing data segments that may be written/read/transmitted or otherwise utilized in actions or defined in objects.

·         Modified every defined object schema with added annotations as well as minor and in some cases substantive changes to fix errors, improve consistency and alignment with existing normative references, and to improve expressiveness in support of the targeted use cases.

The level of changes within v1.0 (Draft) in the core schema, common_types and the defined object schemas is too great to list every change in these release notes. Detailed difference reports are available for each individual schema at:http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_reports.zip <http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_reports.zip> 

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: [email-masked]

---

From: <[email-masked]>
Date: Tue, 17 Apr 2012 03:47:49 -0400

Thank you for sharing the publication of the CybOX specification to the MITRE site, Sean.  

As an FYI to those who are not familiar with IODEF, I just want to clarify that incident descriptions via IODEF already can include network-centric objects (NetFlow data was specifically considered for this representation) in the IODEF flow class.  If there is something missing, please post to the MILE mailing list and we will track that for possible revision in IODEF to the guidance document.

If CybOX gets submitted to the IETF or another standards body, then we will be able to consider the intersection and how CybOX might be incorporated in IODEF. 

Thank you,
Kathleen

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Luis Nunez [[email-masked]]
Sent: Monday, April 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: [email-masked]; [email-masked]; Doug Wilson ([email-masked]); [email-masked]; IPA-Masato Terada ([email-masked])
Subject: Re: [mile] CybOX v1.0 (Draft) is now released and live on the  website

-ln

Hey everyone,

I just wanted to let you all know that CybOX v1.0 (Draft) content is now live on the website. http://cybox.mitre.org
The release notes are provided inline below.
The key items of note are:
•        The release of two formal specifications for the CybOX language (one for the core language and one for the defined objects)
•        The XML Schema has gone through extensive improvements for expressiveness, clarity, consistency, efficiency, alignment to existing normative references and documentation.
•        This release includes an initial set of language utilities: a draft Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set of Python bindings for the CybOX language.

•        The website now includes a small set of content examples. This set will grow going forward.

Sean Barnum

The Version 1.0 (Draft) release of Cyber Observable eXpression (CybOX™) is intended as a draft release of an initial major version of the CybOX Language that could be utilized for practical operational use and integration into other standards efforts. This release consists of three primary components: a pair of formal language specifications for the core language content and defined objects content, a set of language implementation XML schemas (core, common_types, and ~70 defined object schemas), and a small initial set of language utilities including an initial draft Snort->CybOX transform, an initial draft OpenIOC->CybOX transform and a set of CybOX language Python bindings. Recognizing that this is the first time that the formal language specifications will be available for review and as such will likely generate feedback from new stakeholders, this initial major version is being released as a “draft” v1.0 with the expectation of cycles of new feedback and revision before a “final” v1.0 is released.
The CybOX v1.0 (Draft) XML schemas include a significant number of changes from v0.7 to improve:
•       Clarity, documentation, and descriptive formality for reference and implementation by other standards and users.
•       Consistency, simplicity, and efficiency.
•       Alignment (as appropriate) to existing normative references.

•       Expressiveness of the schema to better support the broad set of use cases it targets (malware characterization, indicator and incident data sharing, event management, etc.) including the addition of an initial set of network-related defined objects.

 *   Refinement of namespaces and schema locations for better effectiveness and flexibility going forward.
 *   Normalized all content according to an established set of naming conventions.
 *   Fully annotated all language items (types, attributes, elements, etc.).
 *   Moved several commonly leveraged types out of the core schema and into common_types.
 *   Achieved full typing of entire schema structure such that all attributes and elements are definitively typed.
 *   Changed all identifiers from ID and IDREF types to be QNames enabling globally unique identifiers and flexibility for domain-specific users of CybOX to define their own identifier syntax locally.
 *   Reordered attributes and elements in numerous types to better reflect common usage and priority.
 *   Added major_version and minor_version attributes for core schema.
 *   Added capability to characterize source of overall observable package data and for individual observables.
 *   Modified the logical composition structure such that any such compositions are now contained within a Observable_Composition element providing improved simplicity and modularity.
 *   Removed the Delta element from ObservableType and relocated the appropriate portions (Change, Trend, and Frequency) to appropriate locations under Stateful_Measure and Event.
 *   Added a Domain_Specific_Object_Attributes field to Object utilizing an abstract type that will allow domain-specific use cases to add in their own domain-specific attributes for Objects.
 *   Added a Tool-Specific_Data field to ToolInformationType utilizing an abstract type that will allow addition of tool-specific data.
 *   Added an Indicators field to MeasureSourceType utilizing an abstract type that will allow characterizing differing formats or standards of indicators that may have led to the identification of the observable data.
 *   Enhanced the Hash structure to capture full fuzzy hashes in addition to simple hashes
 *   Added a new ExtractedFeaturesType that can be used to adorn differing objects (e.g., files, memory, etc.) to capture extracted strings, imports, functions and code snippets
 *   Added a ByteRunsType to enable capture of byte runs within various objects.
 *   Added object_reference attribute to DefinedObjectType to better support referencing of independently defined Objects from within another Object definition.
 *   Added a generic DataSegmentType to provide a relatively abstract way of characterizing data segments that may be written/read/transmitted or otherwise utilized in actions or defined in objects.

•        Added several new defined object schemas (API, Code, Device, DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry, Network_Subnet, Unix_Network_Route_Entry) including an initial set of network-centric defined objects.

 *   Modified every defined object schema with added annotations as well as minor and in some cases substantive changes to fix errors, improve consistency and alignment with existing normative references, and to improve expressiveness in support of the targeted use cases.

===============================================
Sean Barnum
Cyber Security Principal
The MITRE Corporation
Email: [email-masked]<mailto:[email-masked]>

_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

---

From: "Barnum, Sean D." <[email-masked]>
Date: Tue, 17 Apr 2012 03:14:18 +0000

I am glad to hear that you find it useful Luis.

We felt that a minimum initial set of network-related objects was an
important part of any sort of 1.0 release.

The initial set of network-related objects for CybOX v1.0 (Draft) includes:
Address, Port, URI, Socket, DNS_Record, DNS_Cache, Network_Flow,
Network_Packet, Network_Route_Entry, Unix_Network_Route_Entry,
Win_Network_Route_Entry, Network_Route, Network_Subnet, and
Win_Network_Share. From our discussions with various knowledgeable parties,
this seemed like a good initial baseline.

If any of you experts have suggestions on other objects that would be useful
for current needs or suggestions on refinements to these existing objects,
we humbly welcome your input.

Thanks Luis,

sean

From: Luis Nunez [mailto:[email-masked]] 
Sent: Monday, April 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: [email-masked]; [email-masked]; Doug Wilson ([email-masked]);
IPA-Masato Terada ([email-masked]); [email-masked]
Subject: Re: [mile] CybOX v1.0 (Draft) is now released and live on the
website

I like the inclusion of the network-centric objects.  IPFIX (netflow)  will
add an additional perspective from an incident information sharing
standpoint.  

-ln

Hey everyone,

.        The release of two formal specifications for the CybOX language
(one for the core language and one for the defined objects)

.        The XML Schema has gone through extensive improvements for
expressiveness, clarity, consistency, efficiency, alignment to existing
normative references and documentation.

.        This release includes an initial set of language utilities: a draft
Snort -> CybOX transform, a draft OpenIOC -> CybOX transform, and a set of
Python bindings for the CybOX language.

.        The website now includes a small set of content examples. This set
will grow going forward.

This release involved a lot of hard work from a diverse group of people.
Thank you all for your contributions and effort. We could not have done it
without you.

We look forward to everyone's feedback and collaboration as we continue to
improve and mature the CybOX language.

Sean Barnum

The Version 1.0 (Draft) release of Cyber Observable eXpression (CybOXT) is
intended as a draft release of an initial major version of the CybOX
Language that could be utilized for practical operational use and
integration into other standards efforts. This release consists of three
primary components: a pair of formal language specifications for the core
language content and defined objects content, a set of language
implementation XML schemas (core, common_types, and ~70 defined object
schemas), and a small initial set of language utilities including an initial
draft Snort->CybOX transform, an initial draft OpenIOC->CybOX transform and
a set of CybOX language Python bindings. Recognizing that this is the first
time that the formal language specifications will be available for review
and as such will likely generate feedback from new stakeholders, this
initial major version is being released as a "draft" v1.0 with the
expectation of cycles of new feedback and revision before a "final" v1.0 is
released.

The CybOX v1.0 (Draft) XML schemas include a significant number of changes
from v0.7 to improve:

.       Clarity, documentation, and descriptive formality for reference and
implementation by other standards and users.

.       Consistency, simplicity, and efficiency.

.       Alignment (as appropriate) to existing normative references.

.       Expressiveness of the schema to better support the broad set of use
cases it targets (malware characterization, indicator and incident data
sharing, event management, etc.) including the addition of an initial set of
network-related defined objects.

.        Refinement of namespaces and schema locations for better
effectiveness and flexibility going forward.

.        Normalized all content according to an established set of naming
conventions.

.        Fully annotated all language items (types, attributes, elements,
etc.).

.        Moved several commonly leveraged types out of the core schema and
into common_types.

.        Achieved full typing of entire schema structure such that all
attributes and elements are definitively typed.

.        Changed all identifiers from ID and IDREF types to be QNames
enabling globally unique identifiers and flexibility for domain-specific
users of CybOX to define their own identifier syntax locally.

.        Reordered attributes and elements in numerous types to better
reflect common usage and priority.

.        Added major_version and minor_version attributes for core schema.

.        Added capability to characterize source of overall observable
package data and for individual observables.

.        Modified the logical composition structure such that any such
compositions are now contained within a Observable_Composition element
providing improved simplicity and modularity.

.        Removed the Delta element from ObservableType and relocated the
appropriate portions (Change, Trend, and Frequency) to appropriate locations
under Stateful_Measure and Event.

.        Added a Domain_Specific_Object_Attributes field to Object utilizing
an abstract type that will allow domain-specific use cases to add in their
own domain-specific attributes for Objects.

.        Added a Tool-Specific_Data field to ToolInformationType utilizing
an abstract type that will allow addition of tool-specific data.

.        Added an Indicators field to MeasureSourceType utilizing an
abstract type that will allow characterizing differing formats or standards
of indicators that may have led to the identification of the observable
data.

.        Enhanced the Hash structure to capture full fuzzy hashes in
addition to simple hashes

.        Added a new ExtractedFeaturesType that can be used to adorn
differing objects (e.g., files, memory, etc.) to capture extracted strings,
imports, functions and code snippets

.        Added a ByteRunsType to enable capture of byte runs within various
objects.

.        Added object_reference attribute to DefinedObjectType to better
support referencing of independently defined Objects from within another
Object definition.

.        Added a generic DataSegmentType to provide a relatively abstract
way of characterizing data segments that may be written/read/transmitted or
otherwise utilized in actions or defined in objects.

.        Added several new defined object schemas (API, Code, Device,
DNS_Record, Network_Flow, Network_Packet, Network_Route_Entry,
Network_Subnet, Unix_Network_Route_Entry) including an initial set of
network-centric defined objects.

.        Modified every defined object schema with added annotations as well
as minor and in some cases substantive changes to fix errors, improve
consistency and alignment with existing normative references, and to improve
expressiveness in support of the targeted use cases.

The level of changes within v1.0 (Draft) in the core schema, common_types
and the defined object schemas is too great to list every change in these
release notes. Detailed difference reports are available for each individual
schema at:
<http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_repor
ts.zip>
http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_report
s.zip

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: [email-masked]

---

From: "Barnum, Sean D." <[email-masked]>
Date: Tue, 17 Apr 2012 03:29:07 +0000

Thanks Omar.

To answer your question, first let me point out to other readers that the
two entries that Omar is quoting here exist as values in an enumeration
called EventTypeEnum which as its name implies contains a list of different
labels for grouping types (or classes) of events to be used as
low-granularity buckets for characterizing and classifying events.

The "Packet Traffic" value is intended to characterize events dealing with
network packet traffic as its name implies.

The "Data Flow" value is intended to characterize events dealing with forms
of data flow at a higher level of abstraction than just packet traffic. The
relationship between these two values could be viewed as "Packet Traffic"
being a more detailed form of "Data Flow" just as the values "App Layer
Traffic" and "HTTP Layer Traffic", also in this enumeration, could be other
levels in this same abstraction stack.

The idea behind the varying levels of abstraction is to leave  buckets large
enough to capture a wide variety of potential event types (e.g. data flow
events other than obvious things like packet traffic) but also enable the
use of smaller more specific buckets when they are appropriate and commonly
used.

Does this make sense? 

sean

Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe
website

I echo Luis' comments. It is good to see the inclusion of network objects.
Quick question to the team related to your netflow comment.

I am looking at:

. and it looks that we renamed it to "Data Flow"?

   <xs:annotation>

        <xs:documentation>Specifies the class of events dealing with data
flow.</xs:documentation>

   </xs:annotation>

</xs:enumeration>

 

Regards,

Omar Santos
Incident Manager, PSIRT

From: [email-masked] [mailto:[email-masked]] On Behalf Of Luis
Nunez
Sent: Monday, April 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: [email-masked]; [email-masked]; Doug Wilson ([email-masked]);
[email-masked]; IPA-Masato Terada ([email-masked])
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe
website

-ln

Hey everyone,

Sean Barnum

 

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: [email-masked]

---

From: "Millar, Thomas" <[email-masked]>
Date: Mon, 16 Apr 2012 23:46:18 -0400

Tom Millar 
http://www.us-cert.gov/ 
------------------ 

Thanks Omar.

Does this make sense? 

sean

I am looking at:

   <xs:annotation>

   </xs:annotation>

</xs:enumeration>

 

Regards,

Omar Santos
Incident Manager, PSIRT

-ln

Hey everyone,

Sean Barnum

 

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: [email-masked]

---

From: "Barnum, Sean D." <[email-masked]>
Date: Tue, 17 Apr 2012 04:52:27 +0000

It is not a euphemism for netflow.

It is about all kinds of data flow not just network-related.

It could be about ETL within a database or datawarehouse.

It could be about data flow within an information system (perhaps observable within an application log).

It could be about data flow related to all sorts of forms of message passing.

It could be about data flow within data-driven reactive programming software architectures.

Etc., Etc.

“Data Flow” is a fairly abstract bucket acting as a classifier for a broad range of potential event types. 

Of course, we will seek to offer relevant lower abstraction buckets within this broad bucket (e.g. “Packet Traffic”) to offer more specific characterization where we have a clear understanding of the sub-bucket but it is still useful to have the broader bucket available to catch the things we do not have more specific sub-buckets defined for yet.

Does that help clarify?

sean

To: Barnum, Sean D.; [email-masked]; [email-masked]

Tom Millar 
http://www.us-cert.gov/ 
------------------ 

Thanks Omar.

Does this make sense? 

sean

I am looking at:

   <xs:annotation>

   </xs:annotation>

</xs:enumeration>

 

Regards,

Omar Santos
Incident Manager, PSIRT

-ln

Hey everyone,

Sean Barnum

The level of changes within v1.0 (Draft) in the core schema, common_types and the defined object schemas is too great to list every change in these release notes. Detailed difference reports are available for each individual schema at: <http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_reports.zip> http://cybox.mitre.org/XMLSchema/release_notes/cybox_v1.0(draft)_diff_reports.zip

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: [email-masked]

---

From: "Barnum, Sean D." <[email-masked]>
Date: Tue, 17 Apr 2012 05:09:35 +0000

“upper layer”? Yes, as in higher abstraction.

Just “protocols”? No.

You guys have been looking at this through the lens of network flow which if fine for thinking about that perspective but it is important to also realize that the EventTypeEnum and its “Data Flow” value go far beyond network-related scope.

It is about a lot of other types of potential data flows (as I just outlined in a response to Tom) that have nothing to do with network flow.

Thanks for your response though. This is the kind of discussions that we hope to have a lot more of among the various supported communities.

BTW, you may have noticed that the Network_Flow object within CybOX v1.0 (Draft) supports expression of netflow within several of the most common formats including Netflow9 (as well as IPFIX as Luis pointed out, Netflow5 and SiLK as well as bi-directional flow in YAF). The common 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we broke the router interface out into both ingress and egress J) shared by pretty much all of the netflow approaches has been broken out into a shared Network_Flow_Label structure. The various context-dependent portions of the independent approaches are then captured within optional structures dedicated to each of them. We hope that eventually the community can work to come together towards a single overall common expressive structure for netflow that meets the needs of all. We hope that CybOX and its use can even help that sort of maturation and normalization. But since no such universal structure exists today, we decided to enable optional expression of the most common individual formats within a single netflow object to serve the large majority of relevant users, maintain flexibility and enable discussions and analysis of netflow within a common package.

We look forward to continuing discussions with the community to validate or invalidate this approach and to refine and mature going forward.

Sean 

From: Omar Santos (osantos) [mailto:[email-masked]] 
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, Thomas; Barnum, Sean D.; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

 

Regards,

Omar 

Tom Millar 
http://www.us-cert.gov/ 
------------------ 

Thanks Omar.

Does this make sense? 

sean

I am looking at:

   <xs:annotation>

   </xs:annotation>

</xs:enumeration>

 

Regards,

Omar Santos
Incident Manager, PSIRT

-ln

Hey everyone,

Sean Barnum

 

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: [email-masked]

---

From: Michael Hammer <[email-masked]>
Date: Tue, 17 Apr 2012 13:17:42 +0000

Sean,

Does the overlap between the various objects present a problem?

If there are one or more objects that could carry the same data, then human nature means that probability-wise someone will choose data flow instead of Netflow.

That is the underlying principle in Murphy’s Law, where you try to design it so that there is only one way to do it, and thus private Murphy won’t do it the “wrong” way.

Just wondering if these should be mutually exclusive sets.  And designed as such.

Might improve interoperability.  (And avoid discussions like this in future.)  J

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Barnum, Sean D.
Sent: Tuesday, April 17, 2012 1:10 AM
To: Omar Santos (osantos); Millar, Thomas; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website

Just “protocols”? No.

 

Sean 

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

 

Regards,

Omar 

Tom Millar 
http://www.us-cert.gov/ 
------------------ 

Thanks Omar.

Does this make sense? 

sean

I am looking at:

   <xs:annotation>

   </xs:annotation>

</xs:enumeration>

 

Regards,

Omar Santos
Incident Manager, PSIRT

-ln

Hey everyone,

Sean Barnum

 

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: [email-masked]

---

From: <[email-masked]>
Date: Tue, 17 Apr 2012 10:07:52 -0400

Hi Mike,

Are you suggesting to just include the NetConf schema and allow that to evolve and pull it in where appropriate?  That makes sense to me...  For IODEF, right now you would use the Flow class and could optionally use NetConf using the AdditionalData to include another schema.  Although we don't have NetConf in the SCI draft, that raises a good point for MILE to consider (if there is a gap in schema or guidance).  Or to include this in the IODEF guidance document so we have an agreed way to handle this use case consistently between implementations.  SACM is thinking about the relationships between management protocols and security automation specifications in the base use case, so that should help in that space.

Understanding the use cases for CybOX and flows may help to understand why we may need the representation directly in the specification as opposed to referencing NetConf. Sean?

Thanks,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Michael Hammer [[email-masked]]
Sent: Tuesday, April 17, 2012 9:17 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website

Sean,

Just wondering if these should be mutually exclusive sets.  And designed as such.
Might improve interoperability.  (And avoid discussions like this in future.)  ☺

Mike

BTW, you may have noticed that the Network_Flow object within CybOX v1.0 (Draft) supports expression of netflow within several of the most common formats including Netflow9 (as well as IPFIX as Luis pointed out, Netflow5 and SiLK as well as bi-directional flow in YAF). The common 5-tuple or 7-tuple (you describe) (in our case it is an 8-tuple as we broke the router interface out into both ingress and egress ☺) shared by pretty much all of the netflow approaches has been broken out into a shared Network_Flow_Label structure. The various context-dependent portions of the independent approaches are then captured within optional structures dedicated to each of them. We hope that eventually the community can work to come together towards a single overall common expressive structure for netflow that meets the needs of all. We hope that CybOX and its use can even help that sort of maturation and normalization. But since no such universal structure exists today, we decided to enable optional expression of the most common individual formats within a single netflow object to serve the large majority of relevant users, maintain flexibility and enable discussions and analysis of netflow within a common package.
We look forward to continuing discussions with the community to validate or invalidate this approach and to refine and mature going forward.

Sean

From: Omar Santos (osantos) [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, April 16, 2012 11:57 PM
To: Millar, Thomas; Barnum, Sean D.; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website

- IP source address
- IP destination address
- Source port
- Destination port
- Layer 3 protocol type
- Class of Service

Regards,

Omar

From: Millar, Thomas [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, April 16, 2012 11:46 PM
To: [email-masked]<mailto:[email-masked]>; Omar Santos (osantos); [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website

Tom Millar
http://www.us-cert.gov/
------------------

From: Barnum, Sean D. [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, April 16, 2012 11:29 PM
To: Omar Santos (osantos) <[email-masked]<mailto:[email-masked]>>; Luis Nunez <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website

Thanks Omar.

Does this make sense?

sean

From: Omar Santos (osantos) [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, April 16, 2012 8:17 PM
To: Luis Nunez; Barnum, Sean D.
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website

I am looking at:

   <xs:annotation>

   </xs:annotation>

</xs:enumeration>

Regards,

Omar Santos
Incident Manager, PSIRT
Security Research and Operations
Cisco Systems, Inc.
Email: [email-masked]<mailto:[email-masked]>
Phone: +1 919 392 8635
PGP Key: 0x3AF27EDC

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Luis Nunez
Sent: Monday, April 16, 2012 6:44 PM
To: Barnum, Sean D.
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Doug Wilson ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; IPA-Masato Terada ([email-masked]<mailto:[email-masked]>)
Subject: Re: [sacm] [mile] CybOX v1.0 (Draft) is now released and live onthe website

-ln

Hey everyone,

Sean Barnum

---

From: Michael Hammer <[email-masked]>
Date: Tue, 17 Apr 2012 14:50:32 +0000

Kathleen,

Not sure of the way forward, but comparing data sets could help produce a more uniform, normalized one.

I'm still trying to absorb this.  Great work by the way.

I did a scan of the words flow, network, and packet to see how often and where they appeared.
It seems that flow is the odd one, while network and packet seem scoped to the whole protocol stack with parallel elements in different parts of the core doc.
So, I didn't see the low level  (L1-L3) versus high level (L4-L7) distinction there.  The network protocol list seems to cover all layers.
BTW, wondering if the non-exhaustive protocol list is intended to be extended in the future to call out others at some point.

Also, agree discussion is good one to have.  Helps me to understand better.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2012 10:01 AM
To: Michael Hammer; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website

Hi Mike,

Thanks,
Kathleen

Sean,

Mike

Sean

- IP source address
- IP destination address
- Source port
- Destination port
- Layer 3 protocol type
- Class of Service

Regards,

Omar

Tom Millar
http://www.us-cert.gov/
------------------

Thanks Omar.

Does this make sense?

sean

I am looking at:

   <xs:annotation>

   </xs:annotation>

</xs:enumeration>

Regards,

Omar Santos
Incident Manager, PSIRT

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

-ln

Hey everyone,

I just wanted to let you all know that CybOX v1.0 (Draft) content is now live on the website. http://cybox.mitre.org The release notes are provided inline below.

Sean Barnum

---

From: Michael Hammer <[email-masked]>
Date: Tue, 17 Apr 2012 19:28:12 +0000

Sean,

What you say makes sense.  But, if you will bear with me.  (Still learning this.)

If one used Packet Traffic event type always instead of Data Flow event type, would some distinction be lost?

Or, put another way, since the packet stuff seems to cover most network-based events, does Data Flow involve something that is not on the wire?

(Such as an inter-process communication that doesn’t go through a protocol stack.)

Mike

From: Barnum, Sean D. [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2012 3:03 PM
To: Michael Hammer; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website

Mike,

Just to clarify, all of our discussion so far about “Data Flow” and netflow were all in regards to an enumeration called EventTypeEnum that simply lets you tag a cyber observable event with a type label. It is metadata for an event description.

The only object we have been talking about in any detail so far was the Network_Flow object. These two topics are totally independent of each other. There is no Data_Flow object.

The abstraction overlap we have been discussing is only in the metadata tag applied to an event to characterize what type/class of event it is.

The defined objects themselves (including Network_Flow) have been designed to avoid, as much as possible, overlap of the type you describe.

The approach we have taken is that where there is common structure and meaning relevant to multiple different types of objects, the structure for that commonality is broken out into its own object (e.g. Address, URI, Port, Account, Process, etc.).

Content based on this common object structure can be embedded within a leveraging object (via direct use of the object type) if the content is directly relevant only within the context of that object or as an independent object and associated to any number of other objects to which it is relevant utilizing relationships.

We make no guarantees that we have managed to implement this approach flawlessly but we believe that it yields a good balance of consistency, efficiency and flexibility. It also allows easy modular use of only what is relevant within a given context and enables extension and evolution to easily occur in a localized fashion rather than having to extend and modify one monolithic structure standard.

Does that make sense?

sean

From: Michael Hammer [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2012 9:18 AM
To: Barnum, Sean D.; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website

Sean,

Mike

Just “protocols”? No.

 

Sean 

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

 

Regards,

Omar 

Tom Millar 
http://www.us-cert.gov/ 
------------------ 

Thanks Omar.

Does this make sense? 

sean

I am looking at:

   <xs:annotation>

   </xs:annotation>

</xs:enumeration>

 

Regards,

Omar Santos
Incident Manager, PSIRT

-ln

Hey everyone,

Sean Barnum

 

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: [email-masked]

---

From: Luis Nunez <[email-masked]>
Date: Tue, 17 Apr 2012 15:48:57 -0400

The salient point is IPFIX/Netflow is about accounting details of packet traffic summaries (who,what, where, when and how many times).

The following articles could provide the basis for a use case around leveraging IPFIX to characterize an observable for information sharing.

http://blogs.cisco.com/security/correlating-netflow-data-for-proactive-security-network-notoriety/

http://www.cisco.com/web/about/ciscoitatwork/network_systems/network_data_monitoring_and_reporting_web.html

-ln

On Apr 17, 2012, at 3:28 PM, Michael Hammer wrote:

> Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked]<[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>

---

From: Michael Hammer <[email-masked]>
Date: Tue, 17 Apr 2012 20:51:22 +0000

Thanks.  Appreciated the detailed explanation.

Mike

From: Barnum, Sean D. [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2012 4:47 PM
To: Michael Hammer; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website

Mike,

If you always utilized the most abstract label (Data Flow) to adorn events even when you knew the more specific type that they were and had a more specific label for them, then yes you would lose distinction.

Such misuse is always the potential downside of enabling flexibility through abstraction.

If you know that the event you are characterizing has to do with Packet Traffic and not just some form of more general data flow that does not have an appropriate associated event type label, then you should absolutely use Packet Traffic and not Data Flow. An event should only be tagged with an abstract label like Data Flow if there is not an appropriate more concrete label available.

In answer to your second question, yes Data Flow definitely covers not only network-related events but also events that have nothing to do with the wire.

My response to Tom Millar that I sent at 12:52am this morning lists out several non-network related types of events that Data Flow could apply to.

Please do not feel bad for asking these questions. They help you understand our approach, they help others understand our approach, they help us better understand the perspective of the communities we are targeting to support, they help us uncover issues with our approach or implementation, and they help us understand where we need to explain ourselves better.

Thank you for the constructive discourse.

sean

From: Michael Hammer [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2012 3:28 PM
To: Barnum, Sean D.; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mile] [sacm] CybOX v1.0 (Draft) is now released and live onthe website

Sean,

Mike

Mike,

Does that make sense?

sean

Sean,

Mike

Just “protocols”? No.

 

Sean 

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

 

Regards,

Omar 

Tom Millar 
http://www.us-cert.gov/ 
------------------ 

Thanks Omar.

Does this make sense? 

sean

I am looking at:

   <xs:annotation>

   </xs:annotation>

</xs:enumeration>

 

Regards,

Omar Santos
Incident Manager, PSIRT

-ln

Hey everyone,

Sean Barnum

 

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: [email-masked]

---

From: "Barnum, Sean D." <[email-masked]>
Date: Tue, 17 Apr 2012 19:02:32 +0000

Mike,

Does that make sense?

sean

Sean,

Mike

Just “protocols”? No.

 

Sean 

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

 

Regards,

Omar 

Tom Millar 
http://www.us-cert.gov/ 
------------------ 

Thanks Omar.

Does this make sense? 

sean

I am looking at:

   <xs:annotation>

   </xs:annotation>

</xs:enumeration>

 

Regards,

Omar Santos
Incident Manager, PSIRT

-ln

Hey everyone,

Sean Barnum

 

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: [email-masked]

---

From: "Barnum, Sean D." <[email-masked]>
Date: Tue, 17 Apr 2012 20:47:23 +0000

Mike,

sean

Sean,

Mike

Mike,

Does that make sense?

sean

Sean,

Mike

Just “protocols”? No.

 

Sean 

- IP source address

- IP destination address

- Source port

- Destination port

- Layer 3 protocol type

- Class of Service

 

Regards,

Omar 

Tom Millar 
http://www.us-cert.gov/ 
------------------ 

Thanks Omar.

Does this make sense? 

sean

I am looking at:

   <xs:annotation>

   </xs:annotation>

</xs:enumeration>

 

Regards,

Omar Santos
Incident Manager, PSIRT

-ln

Hey everyone,

Sean Barnum

 

Sean Barnum

Cyber Security Principal

The MITRE Corporation

Email: [email-masked]