John – I think that’s a reasonable suggestion.
I’ll try to think on how to modify the text description provided originally with text changes that would be acceptable for all.
Allan Thomson,
CTO,
Lookingglass Cyber Solutions
This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential.
The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure,
copying or distribution of the contents contained within is strictly prohibited
From: "Wunder, John" <
jwunder@mitre.org>
Date: Thursday, August 31, 2017 at 5:59 AM
To: Sean Barnum <
sean.barnum@fireeye.com>, Terry MacDonald <
terry.macdonald@cosive.com>, Bret Jordan <
Bret_Jordan@symantec.com>
Cc: Allan Thomson <
athomson@lookingglasscyber.com>, Jason Keirstead <
Jason.Keirstead@ca.ibm.com>, 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
Allan and Jason, could you get behind start_time and end_time? Maybe you could throw out definitions for the terms that you would be happy with?
From: Sean Barnum <
sean.barnum@FireEye.com>
Date: Thursday, August 31, 2017 at 8:53 AM
To: John Wunder <
jwunder@mitre.org>, Terry MacDonald <
terry.macdonald@cosive.com>, "Bret Jordan (CS)" <
Bret_Jordan@symantec.com>
Cc: Allan Thomson <
athomson@lookingglasscyber.com>, Jason Keirstead <
Jason.Keirstead@ca.ibm.com>, 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 agree that a ballot at this point seems a bit too heavy.
My personal preference is for start_time/end_time but would be completely fine with valid_from/valid_until.
The only possibilities I have heard so far that I would be strongly against are having no time window fields at all or using last_seen/first_seen for the basic validity use case rather than an observation-based time window.
Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E:
sean.barnum@fireeye.com From: "Wunder, John A." <
jwunder@mitre.org>
Date: Thursday, August 31, 2017 at 8:48 AM
To: Terry MacDonald <
terry.macdonald@cosive.com>, Bret Jordan <
Bret_Jordan@symantec.com>
Cc: Allan Thomson <
athomson@lookingglasscyber.com>, Sean Barnum <
sean.barnum@FireEye.com>, Jason Keirstead <
Jason.Keirstead@ca.ibm.com>, 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
Do we really have to go to a ballot at all already? We’ve had less than a full day of discussion to try to get to consensus.
I’m guessing my start_time / stop_time proposal is not acceptable. Anybody have any other ideas on this for meeting in the middle and avoiding divergent data?
John
From: <
cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <
terry.macdonald@cosive.com>
Date: Wednesday, August 30, 2017 at 11:08 PM
To: "Bret Jordan (CS)" <
Bret_Jordan@symantec.com>
Cc: John Wunder <
jwunder@mitre.org>, Allan Thomson <
athomson@lookingglasscyber.com>, Sean Barnum <
sean.barnum@fireeye.com>, Jason Keirstead <
Jason.Keirstead@ca.ibm.com>, Sarah Kelley <
Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <
cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
But they are not final Bret. That's my concern. Why do two polls when we can do one and get a final answer?
Cheers
Terry MacDonald Chief Product Officer
M: +64 211 918 814
E:
terry.macdonald@cosive.com W:
www.cosive.com On Thu, Aug 31, 2017 at 1:32 PM, Bret Jordan <
Bret_Jordan@symantec.com > wrote:
Do you really want to ballot on everything? Everyone can easily respond here via email if they do not have access to Slack. We have done a lot of informal polls in the past 6 months to gauge where people sit.
They are very valuable.
Bret
From: Terry MacDonald <
terry.macdonald@cosive.com >
Sent: Wednesday, August 30, 2017 7:27:32 PM
To: Bret Jordan
Cc: Wunder, John A.; Allan Thomson; Sean Barnum; Jason Keirstead; Sarah Kelley;
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
Is it that much more work to do this through the official polling platform that everyone gets access to? Surely having a higher percentage of the STIX population replying is a good thing? We'll get a wider viewpoint, and a definitive answer
if we do the official polling, and then we can put this behind us.
Cheers
Terry MacDonald Chief Product Officer
M: +64 211 918 814
E:
terry.macdonald@cosive.com W:
www.cosive.com On Thu, Aug 31, 2017 at 1:20 PM, Bret Jordan <
Bret_Jordan@symantec.com > wrote:
Lets do an informal poll first. To this end I setup a poll in Slack in #polls. If you do not have access to slack, please respond here. However, if you can, PLEASE respond in slack.
Please see the screen shot for the poll:
Which time elements should the relationship object have?
1: valid_from/valid_until
2: first_seen/last_seen
3: three: both
4: neither
5: abstain
Bret
From: Terry MacDonald <
terry.macdonald@cosive.com >
Sent: Wednesday, August 30, 2017 7:12:02 PM
To: Bret Jordan
Cc: Wunder, John A.; Allan Thomson; Sean Barnum; Jason Keirstead; Sarah Kelley;
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
Then I think it is time for a ballot :).
One where its valid_*
One where it is first_*
One where its both of the above and consumers get confused
As a separate discussion we should also talk about how we will handle 'summarising' relationships in the future, so we have an STIX-wide architectural plan for doing summarisation.
Cheers
Terry MacDonald Chief Product Officer
M: +64 211 918 814
E:
terry.macdonald@cosive.com W:
www.cosive.com On Thu, Aug 31, 2017 at 12:51 PM, Bret Jordan <
Bret_Jordan@symantec.com > wrote:
Yeah, I see that now. It was a bad idea. I was just trying to find a solution. I still really dislike the idea of first and last seen on general purpose relationships.
Bret
Sent from my iPhone
On Aug 30, 2017, at 6:43 PM, Terry MacDonald <
terry.macdonald@cosive.com > wrote:
I agree with John. I would be very concerned if we make major structural changes to how STIX relationships work and how summarised STIX relationships work just because it might make sense for one potential confusion.
Cheers
Terry MacDonald Chief Product Officer
M: +64 211 918 814
E:
terry.macdonald@cosive.com W:
www.cosive.com On Thu, Aug 31, 2017 at 10:48 AM, Wunder, John A. <
jwunder@mitre.org > wrote:
I don’t think so. Sighting indicates that you saw an SDO. Doing that would significantly change the meaning to “I saw a relationship between this SDO and that SDO”…aka, a sighting
of a relationship. It would also create even further divergence in STIX, in that you could use either Sighting or Relationship to indicate that two SDOs are related (vs. now where the Sighting relationship is just saying that a thing was seen based on some
optional evidence).
From:
"Bret Jordan (CS)" <
Bret_Jordan@symantec.com >
Date: Wednesday, August 30, 2017 at 6:37 PM
To: John Wunder <
jwunder@mitre.org >, Allan Thomson <
athomson@lookingglasscyber.com >, Sean Barnum <
sean.barnum@FireEye.com >,
Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
Cc: Sarah Kelley <
Sarah.Kelley@cisecurity.org >, "
cti-stix@lists.oasis-open.org " <
cti-stix@lists.oasis-open.org >
Subject: Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
Or do we change Sighting to allow it to point to not just observed_data and an identity, but also another SDO? Because the use case that Allan brings up really feels like a sighting. The use case that Sean brings up really feels
different. The more we make a general purpose relationship look and feel like a sighting, the more problems we are going to have.
For example, if we add first_seen and last_seen to the general purpose relationship, then you could just make a sighting out of it, but linking a Threat Actor to Observed Data.
Bret
From: Wunder, John A. <
jwunder@mitre.org >
Sent: Wednesday, August 30, 2017 4:22:01 PM
To: Allan Thomson; Sean Barnum; Jason Keirstead
Cc: Bret Jordan; Sarah Kelley;
cti-stix@lists.oasis-open.org Subject: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
You’re right, it doesn’t support this now. It points to a thing and says that that thing was seen…so I think to use it for this you would need to have a relationship plus a sighting
of that relationship, which seems awkward.
Maybe if we stick with start_time and stop_time as the field names we can craft a description that’s agreeable to everyone? I would focus on what the consumer should think when
they see that field. Maybe something like:
Start_time: The time at which this relationship first came to exist. For some relationships this might be obvious or factual (MITRE is located in the United States) while for other
relationships this might be when the relationship was first observed.”
Stop_time: The time at which this relationship last existed. (Same caveat as above). If this property is omitted, the producer considers the relationship ongoing (i.e. it is still
being observed).”
I doubt those are good as-is, but I do wonder if we can get there in a way that we don’t conflate terms yet give consumers something consistent they can look for and understand
across all producers.
John
From:
Allan Thomson <
athomson@lookingglasscyber.com >
Date: Wednesday, August 30, 2017 at 5:58 PM
To: John Wunder <
jwunder@mitre.org >, Sean Barnum <
sean.barnum@FireEye.com >, Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
Cc: "Bret Jordan (CS)" <
Bret_Jordan@symantec.com >, Sarah Kelley <
Sarah.Kelley@cisecurity.org >, "
cti-stix@lists.oasis-open.org "
<
cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
John – I agree that if companies interpret the fields differently then that’s not a good situation either.
You raise a good point that if one company uses valid_from/until and another uses first_seen/last_seen for the same concept then we have incompatibility.
To that point, Bret’s suggesting that a sighting already has first_seen/last_seen but looking at Sighting again it appears that it only points to one specific SDO that it was sighting
on. What about the sighting of a connection between 2 disparate SDOs?
If sighting supports that (from my quick review I didn’t see that) then we might have a good path for both use cases.
Allan Thomson,
CTO,
Lookingglass Cyber Solutions
This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client
privileged, proprietary and/or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe that you have received this message in error, please contact the sender, delete this message,
and be aware that any review, use, disclosure, copying or distribution of the contents contained within is strictly prohibited
From:
"Wunder, John" <
jwunder@mitre.org >
Date: Wednesday, August 30, 2017 at 2:45 PM
To: Allan Thomson <
athomson@lookingglasscyber.com >, Sean Barnum <
sean.barnum@FireEye.com >, Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
Cc: Bret Jordan <
Bret_Jordan@symantec.com >, Sarah Kelley <
Sarah.Kelley@cisecurity.org >, "
cti-stix@lists.oasis-open.org "
<
cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
I agree with Allan that it’s really not productive to appeal to which company has more experience here.
I do want to strongly disagree with the statement that there’s no harm in trying to support all use cases and add both sets of fields, even though everyone will probably get everyone
angry with me. Let’s take this exact discussion as an example…so, we add both sets of fields. Clearly, FireEye will be primarily populating valid_form and valid_until, while IBM and LookingGlass will be populating first_seen and last_seen. But do these organizations
really mean to be describing different things here, especially in a way that’s important to a consumer of this data? As a visualization tool that just wants to show relationships that are “current” or were important to know in March of 2013, which field do
I look in? Do I just have to look in both? Every new field we add, especially when there’s this degree of semantic overlap, adds additional cognitive cost and increases the complexity of STIX. Maybe it’s worth it in this case because the distinction is that
critical, but it definitely does not come without cost.
This is a lesson we learned well in STIX 1. I think sometimes people have this impression that a bunch of MITRE folks sat in a room and tried to dream up multiple ways of doing
something. Believe it or not, we didn’t…it’s that we would come up with some use case and then would identify some very real distinction between it and another use case. The perfect example is composite indicators vs. composite observables…yes, there’s a difference,
and I can explain it to you…but when viewed by the wider community it was just multiple ways of doing something, and so it was a mistake for us to put that difference in the standard. So here, I would really strongly urge us to find some common ground, even
if it’s hard, and try to agree on what we’re representing and how we’re representing it so that consumers can rely on some degree of standardization in what they get.
John
From:
<
cti-stix@lists.oasis-open.org > on behalf of Allan Thomson <
athomson@lookingglasscyber.com >
Date: Wednesday, August 30, 2017 at 5:22 PM
To: Sean Barnum <
sean.barnum@FireEye.com >, Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
Cc: "Bret Jordan (CS)" <
Bret_Jordan@symantec.com >, John Wunder <
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] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
Sean – I suggest that we don’t debate in a public forum whether you have more legitimate background vs anyone else. I certainly could start doing so but it would not move our community
forward and would waste everyone’s time.
I suggest for the purposes of bringing the community together and building a standard that works for * all * that we have a mindset that supports * all our use cases *.
By your own words you understand that both capabilities support different use cases.
I suggest that there is no harm in supporting both in the standard.
Regards
Allan
From:
Sean Barnum <
sean.barnum@FireEye.com >
Date: Wednesday, August 30, 2017 at 2:17 PM
To: Allan Thomson <
athomson@lookingglasscyber.com >, Jason Keirstead <
jason.keirstead@ca.ibm.com >
Cc: Bret Jordan <
bret_jordan@symantec.com >, "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] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
My assertions were based on FireEye/iSight's extensive experience with the sorts of advanced (relating things to each other with temporal windows for the assertions) threat intel
and the many, many parties I have interacted with over the years of development of STIX.
Very roughly I would say in something like 98% of cases they meant valid_from/to and not last/first_seen.
That being said I am in no way saying that there is no use case for last/first_seen or that it should never be supported. Not at all.
I am asserting that the common use case is "valid", not "seen" and we should explicitly not use last/first_seen to try to mean valid_from/to.
Also, I am suggesting as a more edge case that first/last_seen should be added as an extension rather than base properties and maybe not necessarily in this release. If everyone
else wants them strongly, I have no objections to adding them now but the semantics need to be clear.
I apologize if I did not make my intention clear.
Get
Outlook for iOS
From: Allan Thomson <
athomson@lookingglasscyber.com >
Sent: Wednesday, August 30, 2017 5:05:52 PM
To: Sean Barnum; Jason Keirstead
Cc: Bret Jordan; Wunder, John A.; Sarah Kelley;
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
Sean – I’m not sure anyone is in a position to state that there’s a core set of use cases for either capability or not. I certainly am not.
I believe there are use cases that both property terms support. My prior email was suggesting that I (and therefore our company) would care more about the last_seen over valid_until.
I was not suggesting that others might find value in valid_until.
So if we agree as a community that both are valuable for different reasons then I suggest we not try to stop other business use cases being supported by STIX.
In summary, it sounds like we might want both concepts as optional parameters provided (and it seems like there are) valid semantic descriptions for both.
Allan
From:
Sean Barnum <
sean.barnum@FireEye.com >
Date: Wednesday, August 30, 2017 at 1:58 PM
To: Jason Keirstead <
Jason.Keirstead@ca.ibm.com >, Allan Thomson <
athomson@lookingglasscyber.com >
Cc: Bret Jordan <
Bret_Jordan@symantec.com >, "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] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
I would suggest that in the vast majority of cases for Relationships, "valid_from/valid_to" is what is intended and appropriate rather than “first_seen/last_seen”.
I can see the use for “first_seen/last_seen” but they are the edge case and not the core case.
Consider a case where Org A has “seen” several instances of (really this would be observations/sightings) Malware X being used by ThreatActor Y during the 2016 calendar year.
More specifically, they saw it being used heavily from Jan to Mar, not used at all between Mar to Sep, then heavily used Sep to Dec.
If they want to share to any internal or external party useful info about ThreatActor Y using Malware X, they would convey each of those objects along with two “uses” (or whatever
official value means that) Relationship objects relating them, one with valid_from=jan and valid_to=Mar and the other with valid_from=sep and valid_to=dec. This is asserting that ThreatActor Y was using Malware X from jan to mar and sep to dec.
They would not convey a relationship object between the actor and malware with first_seen=jan and last_seen=dec. That would accurately reflect the first time and last time it was
observed by Org A but does not tell the story that should really be conveyed in the common case.
There is also the possibility that the overall window for the assertion is based on sub-windows asserted by other parties and shared to Org A rather than Org A seeing the actual
use. This would not be appropriate to assert as first_seen or last_seen as there is confidence associated with any of the sub-assertions. The information could also have come from sources other than observation such as a human source within ThreatActor either
acting as an informant or talking about using the malware on a hacker board. Again, first_seen or last_seen would not be appropriate.
FireEye sees all of these variations in the real-world all the time.
Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E:
sean.barnum@fireeye.com From:
Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
Date: Wednesday, August 30, 2017 at 4:42 PM
To: Allan Thomson <
athomson@lookingglasscyber.com >
Cc: Bret Jordan <
Bret_Jordan@symantec.com >, 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] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
Agree, this is the point I was making.
"valid_from/to" means something very different. If we don't care to capture it, OK, but we should just re-use the terms when we actually mean first/last seen.
Sent from IBM Verse
Allan Thomson --- [cti-stix] Re: [EXT]
Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships ---
From:
"Allan Thomson" <
athomson@lookingglasscyber.com >
To:
"Bret Jordan" <
Bret_Jordan@symantec.com >, "Sean Barnum" <
sean.barnum@FireEye.com >,
"Wunder, John A." <
jwunder@mitre.org >, "Sarah Kelley" <
Sarah.Kelley@cisecurity.org >,
cti-stix@lists.oasis-open.org Date:
Wed, Aug 30, 2017 5:03 PM
Subject:
[cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
Agreed that we should be clear on what we are trying to communicate.
Valid_until suggests to me that somehow the relationship will expire after X hours/mins/days.
Last_seen suggests to me that the last time the reporting entity saw the connection between those entities.
I prefer the later because it’s a statement in fact whereas valid_until is an estimate by the producer on when they “think” something is no longer connected. That later aspect is
subjective at best.
Allan
From:
Bret Jordan <
Bret_Jordan@symantec.com >
Date: Wednesday, August 30, 2017 at 12:43 PM
To: Allan Thomson <
athomson@lookingglasscyber.com >, Sean Barnum <
sean.barnum@FireEye.com >, "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: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
well it depends on what we are saying and what use-case we are trying to solve. If we are saying that this relationship between this Malware and COA for example is only valid for these time frames, then valid_from
and valid_until are the better choice, just like what we did with Indicators.
If we are saying that this relationship was seen between these time frames, that seems like a "sighting". Remember Sighting is just a relationship with an extra property and the ability to have them be one-armed
relationships.
So what is the use-cases we are trying to solve with this request???
Bret
From:
cti-stix@lists.oasis-open.org <
cti-stix@lists.oasis-open.org > on behalf of Allan Thomson <
athomson@lookingglasscyber.com >
Sent: Wednesday, August 30, 2017 1:13:43 PM
To: Sean Barnum; Wunder, John A.; Sarah Kelley;
cti-stix@lists.oasis-open.org Subject: [EXT] 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
sarah.kelley@cisecurity.org 518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org - 1-866-787-4722
Error!
Filename not specified.
Error!
Filename not specified. Error!
Filename not specified. Error!
Filename not specified. Error!
Filename not specified.
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 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 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 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.