cti-stix message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: Sean Barnum <sean.barnum@FireEye.com>
- Date: Thu, 31 Aug 2017 18:37:41 +0000
I would be fine with any of these
start_time / end_time
start_time / stop_time
first_seen / last_seen
I am not OK with valid_from / valid_until,
because this implies a very different data set (the time range that the
creator is asserting the relationship has validity, as opposed to the times
they actually saw the relationship).
Even if we don't want to capture this
now, we may at some later date decide we want to capture it.
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
Without data, all you are is just another person with an opinion - Unknown
From:
Sean Barnum <sean.barnum@FireEye.com>
To:
"Wunder, John
A." <jwunder@mitre.org>, 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>
Date:
08/31/2017 03:30 PM
Subject:
Re: [cti-stix]
Small changes from 2.0 - 2.1 - dates on relationships
Sent by:
<cti-stix@lists.oasis-open.org>
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
---
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 PropertiesCommon
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]