OASIS Cyber Threat Intelligence (CTI) TC

 View Only
  • 1.  Timestamp Serialization Question

    Posted 01-19-2016 20:22
    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.   Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail


  • 2.  Re: [cti] Timestamp Serialization Question

    Posted 01-19-2016 20:27




    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." 



















  • 3.  Re: [cti] Timestamp Serialization Question

    Posted 01-19-2016 20:29





    I also prefer Option #1. I just want to make sure that everyone understands the tradeoff and its impact on the binding spec.


    sean









    From: < cti@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
    Date: Tuesday, January 19, 2016 at 3:27 PM
    To: " cti@lists.oasis-open.org " < 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." 






















  • 4.  Re: [cti] Timestamp Serialization Question

    Posted 01-19-2016 20:35
    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 "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."




  • 5.  Re: [cti] Timestamp Serialization Question

    Posted 01-19-2016 20:40




    +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


    "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."
















  • 6.  Re: [cti] Timestamp Serialization Question

    Posted 01-20-2016 11:06
    On 19.01.2016 20:40:18, Kirillov, Ivan A. wrote: > +1 for Option 1 also. > +1 for option 1 -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- "It Has To Work." --RFC 1925 Attachment: signature.asc Description: PGP signature


  • 7.  RE: [cti] Timestamp Serialization Question

    Posted 01-19-2016 22:53




    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." 









     













  • 8.  Re: [cti] Timestamp Serialization Question

    Posted 01-20-2016 01:31
    I’m still clueless as to the use case. Not a negative statement, but I would like to see the concise reason we need ‘precision’ before I weigh in, if at all. On Jan 19, 2016, at 3:22 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.   Attachment: smime.p7s Description: S/MIME cryptographic signature


  • 9.  Re: [cti] Timestamp Serialization Question

    Posted 01-20-2016 01:52
    I’m still clueless as to the use case. Not a negative statement, but I would like to see the concise reason we need ‘precision’ before I weigh in, if at all. On Jan 19, 2016, at 3:22 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.