I would suggest the time window for Relationship and Indicator are similar as they are both given a validity window for a particular assertion.
If folks feel that the observation-based semantics of first_seen and last_seen are important then I believe Jason is right that it would require 4 fields instead of 2.
Personally, I do not believe first_seen and last_seen are currently necessary. I do believe valid_from and valid_to are necessary.
Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E: sean.barnum@fireeye.com
From: Sarah Kelley <Sarah.Kelley@cisecurity.org>
Date: Wednesday, August 30, 2017 at 3:23 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, Sean Barnum <sean.barnum@FireEye.com>, "John Wunder (*CONTRACTOR)" <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
So, to be fair, we’ve used both. We have used “valid_from” and “valid_until” on indicator.
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)
31 Tech Valley Drive
East Greenbush, NY 12061
518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org - 1-866-787-4722
From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Wednesday, August 30, 2017 at 3:13 PM
To: Sean Barnum <sean.barnum@FireEye.com>, "Wunder, John A." <jwunder@mitre.org>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
We’ve used first_seen and last_seen in other objects.
I suggest we be consistent with both terminology and semantics of these properties with prior SDOs.
Regards
Allan
From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Sean Barnum <sean.barnum@FireEye.com>
Date: Wednesday, August 30, 2017 at 10:53 AM
To: "Wunder, John" <jwunder@mitre.org>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
I could support “valid_from” and “valid_to”
Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E: sean.barnum@fireeye.com
From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Wednesday, August 30, 2017 at 10:26 AM
To: Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
I support this change, which I believe was originally suggested by Allan. You can think of many use cases in real intelligence:
- This threat actor tended to use this particular RAT in 2016, but moved on to a different one in 2017
- The intrusion set targeted the US in 2016, but expanded to also target South America in 2017.
I would say that the big question here is whether we call the fields “valid_from” and “valid_to” or “first_seen” and “last_seen”. I think I have a slight preference for valid_from and valid_to because of some
of the connotations of “last_seen” being present vs. absent. Like if last_seen is not on the object, what does it mean, vs. if last_seen is on the object set to yesterday. Valid_from on the other hand makes it clear that if the producer feels like the relationship
is still valid they don’t provide the field.
John
From: <cti-stix@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Date: Wednesday, August 30, 2017 at 10:18 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
I’m going to be sending a series of emails regarding small changes that have been requested in moving from STIX 2.0 to STIX 2.1. The hope is that these won’t be particularly controversial, but if anyone has
any objections to these changes, please speak up.
GITHUB issue #11 (https://github.com/oasis-tcs/cti-stix2/issues/11 )
There has been a suggestion to add “first_seen” and “last_seen” properties onto the relationship object. The Relationship object would then look something like this (with the suggested changes highlighted
in yellow):
3.1.2 Properties
|
Common Properties |
||
|
type,
id, created_by_ref, created, modified, revoked,
labels, confidence, lang, external_references, object_marking_refs,
granular_markings |
||
|
Relationship Specific Properties |
||
|
relationship_type,
description, source_ref, target_ref |
||
|
Property Name |
Type |
Description |
|
type (required) |
string |
The value of this property
MUST be relationship. |
|
relationship_type (required) |
string |
The name used to identify the type of Relationship. This value
SHOULD be an exact value listed in the relationships for the source and target SDO, but
MAY be any string. The value of this property MUST be in ASCII and is limited to characters a–z (lowercase ASCII), 0–9, and hyphen (-). |
|
description (optional) |
string |
A description that provides more details and context about the Relationship, potentially including its purpose and its key characteristics. |
|
first_seen
(optional) |
timestamp |
The beginning of the time window during which the relationship should be considered valid. |
|
last_seen
(optional) |
timestamp |
The end of the time window during which the relationship should be considered valid. |
|
source_ref (required) |
identifier |
The id of the source (from) object. The value
MUST be an ID reference to an SDO (i.e., it cannot point to an SRO, Bundle, or Marking Definition). |
|
target_ref (required) |
identifier |
The id of the target (to) object. The value
MUST be an ID reference to an SDO (i.e., it cannot point to an SRO, Bundle, or Marking Definition). |
Does anyone have any objections to making this change?
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)
31 Tech Valley Drive
East Greenbush, NY 12061
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.
.....
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.
. . . . .