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: Agenda for 8/23 TC Working Session


Hex and “binary” (via base64) are both representations of bytes/octets. IMO, there should be one data type in CybOX. The best way to represent this data as JSON/text can be up for debate, and I could almost see supporting multiple ways of encoding it (leading “h” or “b” prefix, for instance). I know this violates the “one way to do it” mantra, and in some respects it’s easy enough to convert between them that we can probably just pick one and be OK. I’d lean towards hex, since it’s easier to visually identify individual bytes, and it shouldn’t be used for extremely long values where the size would be significant (even then, judicious compression of the overall JSON should compensate for this).

 

For purposes of patterning, binary strings should be treated as opaque values; if there’s a need to match patterns on data included in binary fields, those subfields should be specified separately. Using hex also makes it slightly easier for a (custom) patterning syntax to match (for instance) flag fields using & and ^ operators, for cases where individual users want to match specific subfields.

 

Happy to discuss more tomorrow!

 

Greg

 

From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Kirillov, Ivan A.
Sent: Monday, August 22, 2016 2:47 PM
To: cti@lists.oasis-open.org
Subject: [cti] Agenda for 8/23 TC Working Session

 

All,

 

On tomorrow’s working call we’ll be focusing on a number of CybOX topics, including the following:

 

·         File/Directory Object

o   Trey and I recently added a new Directory Object, and welcome your feedback: https://docs.google.com/document/d/1DdS-NrVTjGJ3wvCJ7dbSlhYeiaWS6G6dOXu2F3POpUs/edit#heading=h.lyvpga5hlw52

o   Semantically this seems clearer than having a File Object that can also characterize directories

·         Hex/Binary Object DataTypes: https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit#heading=h.6qyimz2u366

o   It has been pointed out that our binary and hex datatypes are duplicative because they can convey the same data; accordingly there are a few questions around them that we need to address:

§  Should we coalesce Hex/Binary into a single datatype?

§  If we keep hex as a separate type, how should we represent hex data?

·         As a C-style delimited string? E.g., \x2A\xFF?

·         As a non-delimited string? E.g., 2AFF?

·         PE Binary Extension Datatypes: https://docs.google.com/document/d/1DdS-NrVTjGJ3wvCJ7dbSlhYeiaWS6G6dOXu2F3POpUs/edit#heading=h.tlok7x3ugmrd

o   Does our use of non-hex datatypes for PE header characterization make sense? It has been pointed out that it would be useful for patterning to use the existing datatypes (integer, timestamp, etc.) vs. hex.

 

If anyone has other CybOX-related topics they’d like to discuss, feel free to bring them up!

 

Regards,

Ivan



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