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


+1 for Option 1 also.

Regards,
Ivan

From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Tuesday, January 19, 2016 at 1:34 PM
To: John Wunder <jwunder@mitre.org>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Bret Jordan <bret.jordan@bluecoat.com>
Subject: Re: [cti] Timestamp Serialization Question

I prefer option one as well.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Inactive hide details for "Wunder, John A." ---01/19/2016 04:27:20 PM---I have a very strong preference for Option 1. Option 2 "Wunder, John A." ---01/19/2016 04:27:20 PM---I have a very strong preference for Option 1. Option 2 adds a layer of indirection for all users, ev

From: "Wunder, John A." <jwunder@mitre.org>
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: 01/19/2016 04:27 PM
Subject: Re: [cti] Timestamp Serialization Question
Sent by: <cti@lists.oasis-open.org>





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]