CTI STIX Subcommittee

 View Only
  • 1.  Re: [cti-stix] Time Ranges

    Posted 04-06-2018 21:14




    I like the original names as they provide a level of semantic clarity that is not provided by time1, time2….etc without having to read a spec on what is the definition of time1, time2.
     
    From an object model in a database/product vendors can normalize the names to time1, time2 if they wish. But this protocol is a data exchange and clarity is better with the explicit names.
     

    Allan Thomson
    CTO ( +1-408-331-6646)

    LookingGlass Cyber Solutions

    From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
    Date: Friday, April 6, 2018 at 2:10 PM
    To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
    Subject: [cti-stix] Time Ranges


     


    I just wanted to make sure everyone was aware that we now have 5 different ways of representing time ranges in STIX...  Since we tend to split hairs on names, maybe they should just all
    be named time1 and time2 or do a single field with a dash "-" between the two values and call it "time_window" or "time_range" or something. 
     

    Relationship Object


    start_time


    stop_time


     


    Indicator Object


    valid_from


    valid_until


     


    Campaign, Intrusion Set, Malware


    first_seen


    last_seen


     


    Malware Analysis Type


    start_time


    end_time


     


    Observed Data


    first_observed


    last_observed

     
    Bret
     







  • 2.  Re: [cti-stix] Time Ranges

    Posted 04-09-2018 11:54




    +1 to Allan. The fields meaning something to humans is more important than having consistency for code.
     

    From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
    Date: Friday, April 6, 2018 at 5:14 PM
    To: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
    Subject: Re: [cti-stix] Time Ranges


     

    I like the original names as they provide a level of semantic clarity that is not provided by time1, time2….etc without having to read a spec on what is the definition of time1, time2.
     
    From an object model in a database/product vendors can normalize the names to time1, time2 if they wish. But this protocol is a data exchange and clarity is better with the explicit names.
     

    Allan Thomson
    CTO ( +1-408-331-6646)

    LookingGlass Cyber Solutions

    From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
    Date: Friday, April 6, 2018 at 2:10 PM
    To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
    Subject: [cti-stix] Time Ranges


     


    I just wanted to make sure everyone was aware that we now have 5 different ways of representing time ranges in STIX...  Since we tend to split hairs on names, maybe they should just all
    be named time1 and time2 or do a single field with a dash "-" between the two values and call it "time_window" or "time_range" or something. 
     

    Relationship Object


    start_time


    stop_time


     


    Indicator Object


    valid_from


    valid_until


     


    Campaign, Intrusion Set, Malware


    first_seen


    last_seen


     


    Malware Analysis Type


    start_time


    end_time


     


    Observed Data


    first_observed


    last_observed

     
    Bret
     







  • 3.  RE: [cti-stix] Time Ranges

    Posted 04-09-2018 12:29


    Agreed. Plus, we spent many hours wrapped around the axle about which version of “start” and “end” was appropriate for each object. I think we should leave it, as some were hard fought battles.

     

    Sarah Kelley
    Senior Cyber Threat Analyst
    Multi-State Information Sharing and Analysis Center (MS-ISAC)  
    Elections Infrastructure Information Sharing and Analysis Center (EI-ISAC)                 
    31 Tech Valley Drive
    East Greenbush, NY 12061
     
    sarah.kelley@cisecurity.org
    518-266-3493
    24x7 Security Operations Center
    SOC@cisecurity.org  - 1-866-787-4722
     
         

                   

     


    From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
    On Behalf Of Wunder, John A.
    Sent: Monday, April 09, 2018 7:54 AM
    To: Allan Thomson; Bret Jordan; cti-stix@lists.oasis-open.org
    Subject: Re: [cti-stix] Time Ranges


     



    +1 to Allan. The fields meaning something to humans is more important than having consistency for code.
     

    From: < cti-stix@lists.oasis-open.org > on behalf of Allan Thomson < athomson@lookingglasscyber.com >
    Date: Friday, April 6, 2018 at 5:14 PM
    To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
    Subject: Re: [cti-stix] Time Ranges


     

    I like the original names as they provide a level of semantic clarity that is not provided by time1, time2….etc without having to read a spec on what is the definition of time1, time2.
     
    From an object model in a database/product vendors can normalize the names to time1, time2 if they wish. But this protocol is a data exchange and clarity is better with the explicit names.
     

    Allan Thomson
    CTO ( +1-408-331-6646)

    LookingGlass Cyber Solutions

    From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
    on behalf of Bret Jordan < Bret_Jordan@symantec.com >
    Date: Friday, April 6, 2018 at 2:10 PM
    To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
    Subject: [cti-stix] Time Ranges


     


    I just wanted to make sure everyone was aware that we now have 5 different ways of representing time ranges in STIX...  Since we tend to split hairs on names, maybe they should just all be named time1
    and time2 or do a single field with a dash "-" between the two values and call it "time_window" or "time_range" or something. 
     

    Relationship Object


    start_time


    stop_time


     


    Indicator Object


    valid_from


    valid_until


     


    Campaign, Intrusion Set, Malware


    first_seen


    last_seen


     


    Malware Analysis Type


    start_time


    end_time


     


    Observed Data


    first_observed


    last_observed

     
    Bret
     


    .....

    This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender
    immediately and permanently delete the message and any attachments.


    . . . . .



  • 4.  Re: [cti-stix] Time Ranges

    Posted 04-10-2018 17:00




    Strong +1 on Allan’s comments.
    I think we should go with the existing more semantically relevant names.
     

    Sean Barnum
    Principal Architect
    FireEye
    M: 703.473.8262

    E: sean.barnum@fireeye.com

    From: <cti-stix@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
    Date: Monday, April 9, 2018 at 8:29 AM
    To: "John Wunder (*CONTRACTOR)" <jwunder@mitre.org>, Allan Thomson <athomson@lookingglasscyber.com>, Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
    Subject: RE: [cti-stix] Time Ranges


     

    Agreed. Plus, we spent many hours wrapped around the axle about which version of “start” and “end” was appropriate for each object. I think we should leave it, as some were hard fought battles.

     

    Sarah Kelley
    Senior Cyber Threat Analyst
    Multi-State Information Sharing and Analysis Center (MS-ISAC)  
    Elections Infrastructure Information Sharing and Analysis Center (EI-ISAC)                 
    31 Tech Valley Drive
    East Greenbush, NY 12061
     
    sarah.kelley@cisecurity.org
    518-266-3493
    24x7 Security Operations Center
    SOC@cisecurity.org  - 1-866-787-4722
     
         

                   

     


    From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
    On Behalf Of Wunder, John A.
    Sent: Monday, April 09, 2018 7:54 AM
    To: Allan Thomson; Bret Jordan; cti-stix@lists.oasis-open.org
    Subject: Re: [cti-stix] Time Ranges


     




    +1 to Allan. The fields meaning something to humans is more important than having consistency for code.
     

    From: < cti-stix@lists.oasis-open.org > on behalf of Allan Thomson < athomson@lookingglasscyber.com >
    Date: Friday, April 6, 2018 at 5:14 PM
    To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
    Subject: Re: [cti-stix] Time Ranges


     

    I like the original names as they provide a level of semantic clarity that is not provided by time1, time2….etc without having to read a spec on what is the definition of time1, time2.
     
    From an object model in a database/product vendors can normalize the names to time1, time2 if they wish. But this protocol is a data exchange and clarity is better with the explicit names.
     

    Allan Thomson
    CTO ( +1-408-331-6646)

    LookingGlass Cyber Solutions

    From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
    on behalf of Bret Jordan < Bret_Jordan@symantec.com >
    Date: Friday, April 6, 2018 at 2:10 PM
    To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
    Subject: [cti-stix] Time Ranges


     


    I just wanted to make sure everyone was aware that we now have 5 different ways of representing time ranges in STIX...  Since we tend to split hairs on names, maybe they should just all be named time1
    and time2 or do a single field with a dash "-" between the two values and call it "time_window" or "time_range" or something. 
     

    Relationship Object


    start_time


    stop_time


     


    Indicator Object


    valid_from


    valid_until


     


    Campaign, Intrusion Set, Malware


    first_seen


    last_seen


     


    Malware Analysis Type


    start_time


    end_time


     


    Observed Data


    first_observed


    last_observed

     
    Bret
     


    .....
    This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message
    and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.


    . . . . .

    This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited.
    If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.