CTI STIX Subcommittee

On today’s working call, we discussed the proposal to add timestamps to the relationship object in order to indicate when the tool/analyst thought the relationship was correct.  We achieved consensus on several
things.
 

We agreed that we believe the below definitions are what we’re trying to capture and should be used (with minor wordsmithing):
Relationship Timestamp Field #1
This optional timestamp represents the earliest time at which the relationship between the objects exists. If the timestamp field #1 is a future timestamp,
at the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on the earliest time at which relationship will be asserted to be true. If not specified, then the earliest time at which the relationship between
the objects exists is not defined.
Relationship Timestamp Field #2
This optional timestamp represents the latest time at which the relationship between the objects exists. If the timestamp field #2 is a future timestamp, at
the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on the latest time at which relationship will be asserted to be true. If the timestamp field #2 is defined, then it MUST be later than the timestamp
#1 value. If not specified, then the latest time at which the relationship between the objects exists is not defined.

We gave everyone the choice of names for these fields. The votes were as follows:
 




first_seen/last_seen


0




valid_from/valid_until


0




start_time/end_time


13




 

There was some discussion about pushing this change to 2.2+:
Yes – 4
No – 10
 
 
So, current consensus is to use the above definitions (with minor wordsmithing), with the property names of “start_time” and “end_time”, and that it should be included in 2.1.
 
We’re sending this to the list to make sure everyone is aware of the discussion from the call and the current consensus, and to give everyone a chance to comment. If there are no objections, we will make these
changes to the spec.
 
Thanks,
 
 
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-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
 

      
             

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.


. . . . .

It seems like having an end_time " suggests to me that somehow the relationship will expire after X hours/mins/days." Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org> Sent: Tuesday, September 5, 2017 2:24:04 PM To: cti-stix@lists.oasis-open.org Subject: [EXT] [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships - current consensus   On today’s working call, we discussed the proposal to add timestamps to the relationship object in order to indicate when the tool/analyst thought the relationship was correct.  We achieved consensus on several things.   We agreed that we believe the below definitions are what we’re trying to capture and should be used (with minor wordsmithing): Relationship Timestamp Field #1 This optional timestamp represents the earliest time at which the relationship between the objects exists. If the timestamp field #1 is a future timestamp, at the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on the earliest time at which relationship will be asserted to be true. If not specified, then the earliest time at which the relationship between the objects exists is not defined. Relationship Timestamp Field #2 This optional timestamp represents the latest time at which the relationship between the objects exists. If the timestamp field #2 is a future timestamp, at the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on the latest time at which relationship will be asserted to be true. If the timestamp field #2 is defined, then it MUST be later than the timestamp #1 value. If not specified, then the latest time at which the relationship between the objects exists is not defined. We gave everyone the choice of names for these fields. The votes were as follows:   first_seen/last_seen 0 valid_from/valid_until 0 start_time/end_time 13   There was some discussion about pushing this change to 2.2+: Yes – 4 No – 10     So, current consensus is to use the above definitions (with minor wordsmithing), with the property names of “start_time” and “end_time”, and that it should be included in 2.1.   We’re sending this to the list to make sure everyone is aware of the discussion from the call and the current consensus, and to give everyone a chance to comment. If there are no objections, we will make these changes to the spec.   Thanks,     Sarah Kelley Senior Cyber Threat Analyst Multi-State Information Sharing and Analysis Center (MS-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                        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. . . . . .

To me, "valid_until" conveys what you express above. To me, "end_time" that the relationship existed up to that time. Get Outlook for iOS From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com> Sent: Tuesday, September 5, 2017 6:26:59 PM To: Sarah Kelley; cti-stix@lists.oasis-open.org Subject: [cti-stix] Re: [EXT] [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships - current consensus   It seems like having an end_time " suggests to me that somehow the relationship will expire after X hours/mins/days." Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org> Sent: Tuesday, September 5, 2017 2:24:04 PM To: cti-stix@lists.oasis-open.org Subject: [EXT] [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships - current consensus   On today’s working call, we discussed the proposal to add timestamps to the relationship object in order to indicate when the tool/analyst thought the relationship was correct.  We achieved consensus on several things.   We agreed that we believe the below definitions are what we’re trying to capture and should be used (with minor wordsmithing): Relationship Timestamp Field #1 This optional timestamp represents the earliest time at which the relationship between the objects exists. If the timestamp field #1 is a future timestamp, at the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on the earliest time at which relationship will be asserted to be true. If not specified, then the earliest time at which the relationship between the objects exists is not defined. Relationship Timestamp Field #2 This optional timestamp represents the latest time at which the relationship between the objects exists. If the timestamp field #2 is a future timestamp, at the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on the latest time at which relationship will be asserted to be true. If the timestamp field #2 is defined, then it MUST be later than the timestamp #1 value. If not specified, then the latest time at which the relationship between the objects exists is not defined. We gave everyone the choice of names for these fields. The votes were as follows:   first_seen/last_seen 0 valid_from/valid_until 0 start_time/end_time 13   There was some discussion about pushing this change to 2.2+: Yes – 4 No – 10     So, current consensus is to use the above definitions (with minor wordsmithing), with the property names of “start_time” and “end_time”, and that it should be included in 2.1.   We’re sending this to the list to make sure everyone is aware of the discussion from the call and the current consensus, and to give everyone a chance to comment. If there are no objections, we will make these changes to the spec.   Thanks,     Sarah Kelley Senior Cyber Threat Analyst Multi-State Information Sharing and Analysis Center (MS-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                        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.

I'm happy with this decision. Cheers Terry MacDonald Cosive On 6/09/2017 08:24, "Sarah Kelley" < Sarah.Kelley@cisecurity.org > wrote: On today’s working call, we discussed the proposal to add timestamps to the relationship object in order to indicate when the tool/analyst thought the relationship was correct.  We achieved consensus on several things.   We agreed that we believe the below definitions are what we’re trying to capture and should be used (with minor wordsmithing): Relationship Timestamp Field #1 This optional timestamp represents the earliest time at which the relationship between the objects exists. If the timestamp field #1 is a future timestamp, at the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on the earliest time at which relationship will be asserted to be true. If not specified, then the earliest time at which the relationship between the objects exists is not defined. Relationship Timestamp Field #2 This optional timestamp represents the latest time at which the relationship between the objects exists. If the timestamp field #2 is a future timestamp, at the time of the updated field is defined, then this represents an estimate by the producer of the intelligence on the latest time at which relationship will be asserted to be true. If the timestamp field #2 is defined, then it MUST be later than the timestamp #1 value. If not specified, then the latest time at which the relationship between the objects exists is not defined. We gave everyone the choice of names for these fields. The votes were as follows:   first_seen/last_seen 0 valid_from/valid_until 0 start_time/end_time 13   There was some discussion about pushing this change to 2.2+: Yes – 4 No – 10     So, current consensus is to use the above definitions (with minor wordsmithing), with the property names of “start_time” and “end_time”, and that it should be included in 2.1.   We’re sending this to the list to make sure everyone is aware of the discussion from the call and the current consensus, and to give everyone a chance to comment. If there are no objections, we will make these changes to the spec.   Thanks,     Sarah Kelley Senior Cyber Threat Analyst Multi-State Information Sharing and Analysis Center (MS-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                        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. . . . . .