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: [cti] Timestamp Serialization Question


I agree with John.

 

Nesting only when it is absolutely required i.e. for a new object type. Not used just for when we want to group things together.

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com

 

 

From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Wunder, John A.
Sent: Wednesday, 20 January 2016 7:27 AM
To: cti@lists.oasis-open.org; Jordan, Bret <bret.jordan@bluecoat.com>
Subject: Re: [cti] Timestamp Serialization Question

 

I have a very strong preference for Option 1. Option 2 adds a layer of indirection for all users, even those who don’t care about precision, while Option 1 means that only those who care about precision have to deal with it.

 

John

On January 19, 2016 at 3:22:52 PM, Jordan, Bret (bret.jordan@bluecoat.com) wrote:

There tends to be two options for dealing with objects that have multiple timestamps and their corresponding precision. Sean and I have been talking through the pros and cons of these.  We would like to get everyone's opinion.  Which do you prefer, option 1 or option 2

 

 

 

Option 1:

This option put the burden on the JSON serialization format to add an extra "_precision" field to each timestamp enabled field.  This is a much flatter and easier to parse and process representation, but the con is it requires unique field names.

{
   "type": "incident",
   "initial_compromise_time" : "2015-12-07T22:00:00Z",
   "initial_compromise_time_precision": "hour",
   "first_data_exfiltrated_time" : "2015-12-09T05:11:00Z",
   "first_data_exfiltrated_time_precision" : "minute",
   "incident_opened_time" : "2016-01-15T11:19:22Z",
   "incident_closed_time" : "2016-01-19T17:24:017Z"
}

 

 

 

Option 2:

This option will require a nested object and struct to store this data and will have an extra layer of indirection for all of those times when the timestamp is at the default precision. 
{
  "type": "incident",
  "initial_compromise_time" : {
       "timestamp": "2015-12-07T22:00:00Z",
       "timestamp_precision": "hour"
   },
  "first_data_exfiltrated_time" : { 
       "timestamp": "2015-12-09T05:11:00Z",
       "timestamp_precision" : "minute"
   },
  "incident_opened_time" : {
       "timestamp": "2016-01-15T11:19:22Z"
   },
  "incident_closed_time" : {
       "timestamp": "2016-01-19T17:24:017Z"
   }
}

 




Thanks,



Bret







Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 




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