Understood.
Personally, was concurring with Terry’s position in general and if folks here decided they must add such a field to Identity for now, I think “role” makes far more sense than identity_type.
That being said, we would also be very happy not adding such a property to Identity regardless.
We model Role as a separate object such that it can be related to Identity with a Relationship object with its time window properties. This supports the fact that identities play different roles at different times.
This also lets us use the Role object for associating roles played by things (service, software, tools, malware, etc.) other than just identities (e.g. a particular ThreatActor utilizing Amazon CloudFront in the role of content-delivery-network
over the period of 3 months then switching to using Cloudflare CDN in that role).
I am not suggesting that the TC needs to take up consideration of a new Role object right now but we would prefer not to kluge a role property onto Identity right now if it is not needed as it will make future evolution easier.
Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E:
sean.barnum@fireeye.com From: "Wunder, John A." <
jwunder@mitre.org>
Date: Friday, May 18, 2018 at 8:18 AM
To: Jason Keirstead <
Jason.Keirstead@ca.ibm.com>, Sean Barnum <
sean.barnum@FireEye.com>
Cc: "cti-stix@lists.oasis-open.org" <
cti-stix@lists.oasis-open.org>, "Kirillov, Ivan A." <
ikirillov@mitre.org>, Terry MacDonald <
terry.macdonald@cosive.com>
Subject: Re: [cti-stix] RE: New property names for previous label properties
To clarify one thing…the reason we didn’t propose identity_roles was that there’s no vocabulary defined for identity labels right now and therefore per the issue decision we wouldn’t be creating a property at all for. This is my fault…I
misunderstood when I first did the analysis because we had included it in the property table with an updated definition, so I just assumed that it had a vocabulary when it didn’t.
So I think this updated suggestion is in-line with #1 for the properties that we already plan to add. If people think we should do the same thing for identity and add a “roles” (or “identity_roles”) property we would need to define the
vocabulary for it. If that’s the case, can someone add an issue – preferably with some suggested values for the vocab - and maybe we can consider for a future CSD?
John
From: <
cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <
Jason.Keirstead@ca.ibm.com>
Date: Friday, May 18, 2018 at 7:50 AM
To: Sean Barnum <
sean.barnum@FireEye.com>
Cc: "cti-stix@lists.oasis-open.org" <
cti-stix@lists.oasis-open.org>, Ivan Kirillov <
ikirillov@mitre.org>, Terry MacDonald <
terry.macdonald@cosive.com>
Subject: Re: [cti-stix] RE: New property names for previous label properties
I also vote #1 as appears to be concensus...
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security "Things may come to those who wait, but only the things left by those who hustle." - Unknown
From: Sean
Barnum <
sean.barnum@FireEye.com>
To: Terry
MacDonald <
terry.macdonald@cosive.com>, "Kirillov, Ivan A." <
ikirillov@mitre.org>
Cc: "cti-stix@lists.oasis-open.org"
<
cti-stix@lists.oasis-open.org>
Date: 05/17/2018
10:46 PM
Subject: Re:
[cti-stix] RE: New property names for previous label properties
Sent by: <
cti-stix@lists.oasis-open.org>
+1
Get
Outlook for iOS
From:
cti-stix@lists.oasis-open.org <
cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <
terry.macdonald@cosive.com>
Sent: Thursday, May 17, 2018 8:49:02 PM
To: Kirillov, Ivan A.
Cc:
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] RE: New property names for previous label properties
Hi All,
I am also in favour of #1, but I also would prefer that we use better names than restricting ourselves to *_types where it makes sense. Specifically I'm thinking of the Identity
object (where Roles makes more sense). The following tweaked list (based on Jason's proposal earlier) would suffice in my opinion:
Identity: roles
Indicator: indicator_types
Malware: malware_types
Report: report_types
Threat Actor: threat_actor_types
Tool: tool_types
Cheers
Terry MacDonald Chief Product Officer
M:
+64 211 918 814
E:
terry.macdonald@cosive.com W:
www.cosive.com On 18 May 2018 at 08:34, Kirillov, Ivan A. <
ikirillov@mitre.org >
wrote:
I’m also in favor of Option 1, but mostly because I feel like “_types” is vastly preferable semantically over the other options. I could go either way on “labels” vs “tags”.
Regards,
Ivan
From:
<
cti-stix@lists.oasis-open.org >
on behalf of Paul Patrick <
Paul.Patrick@FireEye.com>
Date: Thursday, May 17, 2018 at 2:23 PM
To: Sean Barnum <
sean.barnum@FireEye.com>, "Kelley, Sarah E." <
skelley@mitre.org >,
John Wunder <
jwunder@mitre.org >,
"
cti-stix@lists.oasis-open.org "
<
cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] RE: New property names for previous label properties
+1 in agreement with Sean’s assessment.
From:
<
cti-stix@lists.oasis-open.org >
on behalf of Sean Barnum <
sean.barnum@FireEye.com>
Date: Thursday, May 17, 2018 at 2:29 PM
To: "Kelley, Sarah E." <
skelley@mitre.org >,
"Wunder, John A." <
jwunder@mitre.org >,
"
cti-stix@lists.oasis-open.org "
<
cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] RE: New property names for previous label properties
I will restate the FireEye position again. Based on both our operational experience (currently generating, exchanging, analyzing, consuming and presenting this data amongst a large
FireEye ecosystem and externally to customers/partners) and our experience with scores of developers writing code against this data in dozens of systems we very strongly suggest option #1, strongly oppose option #3 and very strongly oppose option #2.
The names of properties in these standards are for human intuition and understanding. They are not for machines as machines would be fine with just using numbers for the properties.
We would assert that option #1 is far and away the most intuitive and clear naming approach for the information we are trying to capture/convey. The vast majority of developers or
consumers of STIX information when handed a Malware object with a malware_type property are going to immediately understand what that property is intended to convey. The same cannot be said for labels, tags or classifications. I say this from experience of
having to explain the current structure to developers many times.
The current approach of using labels for this info and for user-defined ad-hoc labeling/tagging has two main issues we are trying to overcome:
1. By munging the object “type” (e.g., malware_type) content into the ad-hoc list there is no way for consumers of the data to inherently know which “labels” represent specific
object “type” info and which are user labels/tags.
2. The name is very ambiguous and very non-intuitive for conveying a specific structured assertion of what type of object it is (malware_type=”backdoor”, indicator_type=”IP
blacklist”, etc.). This leads to confusion for producing developers to know where to put object “type” info as well as confusion for consuming developers or users to know where to look for such info and how to distinguish it from other info.
Option #1 presented here clearly solves both of these issues.
Option #2 solves the first issue (though will require a developer to really read the spec to know how) and does not solve the second issue. In fact, it actually makes the second
issue worse as now there are two ambiguous non-intuitive terms being used heightening the likelihood of confusion.
Option #3 solves the first issue but does not solve the second issue. While it does not increase the confusion as option #2 does, it still uses an ambiguous and non-intuitive term
that has clear and conflicting semantic meaning to entire sub-portions of the CTI community.
Sean Barnum
Principal Architect
FireEye
M: 703.473.8262
E:
sean.barnum@fireeye.com From:
<
cti-stix@lists.oasis-open.org >
on behalf of "Kelley, Sarah E." <
skelley@mitre.org >
Date: Thursday, May 17, 2018 at 1:44 PM
To: "Wunder, John A." <
jwunder@mitre.org >,
"
cti-stix@lists.oasis-open.org "
<
cti-stix@lists.oasis-open.org >
Subject: [cti-stix] RE: New property names for previous label properties
I would also like to remind people that not every object has one of these vocabs that cause the issue. So you can’t, as Jeff mentioned, always look in each object and expect to find
the same data, because sometimes it’s not there.
My preference would be for 1, 2, 3. I don’t like using the word classifications, though as John said, they would all work.
Did we ever officially agree if we were going to make these (labels/tags/classifications, whatever they wind up being) all optional? Currently, the ones with defined vocabs are required.
Sarah Kelley
Lead Cybersecurity Engineer, T8B2
Defensive Operations
The MITRE Corporation
703-983-6242
skelley@mitre.org From:
cti-stix@lists.oasis-open.org [mailto:
cti-stix@lists.oasis-open.org ]
On Behalf Of Wunder, John A.
Sent: Thursday, May 17, 2018 1:32 PM
To:
cti-stix@lists.oasis-open.org Subject: [cti-stix] RE: New property names for previous label properties
All,
I wanted to bump this discussion on the “labels” topic being tracked as issue 37 [1]. We discussed it on the May 8 working call [2] but unfortunately still don’t seem to be at consensus
on this topic. It’s a blocker for releasing the STIX 2.1 CSD so getting to a resolution is important.
Along those lines, one other option came up on Slack recently: while we typically avoid using “classification” because of connotations for the government community (and those supporting
them), the feeling maybe we should reconsider it. Given that new option, to restate the proposals:
1. *_types (indicator_types, malware_types, threat_actor_types, etc.) for the categorizations/types, and use “labels” for user-defined tagging
2. Keep these values from the vocab in “labels” (as they are now), add a new property called “tags” to capture the user-defined tagging
3. Use the name “classifications” for the categorizations/types, and use “labels” for user-defined tagging
We could really use more input on these, in particular if you’re now open to different options or have not yet weighed in. I’d suggest we just list an order of preference to see
if maybe there’s a compromise that gets us somewhere. My order of preference is 1, 3, 2 but any of them seem fine.
Thanks,
John
[1]:
https://github.com/oasis-tcs/cti-stix2/issues/37 [2]:
https://www.oasis-open.org/apps/org/workgroup/cti/document.php?document_id=63120 From:
"Bret Jordan (CS)" <
Bret_Jordan@symantec.com >
Date: Friday, April 27, 2018 at 1:48 PM
To: "Mates, Jeffrey CIV DC3/TSD" <
Jeffrey.Mates@dc3.mil >,
Terry MacDonald <
terry.macdonald@cosive.com >,
Sean Barnum <
sean.barnum@FireEye.com >
Cc: John Wunder <
jwunder@mitre.org >,
"
cti-stix@lists.oasis-open.org "
<
cti-stix@lists.oasis-open.org >
Subject: Re: [Non-DoD Source] Re: [cti-stix] Re: [EXT] [cti-stix] New property names for previous label properties
Jeff, I think you hit on a really important point that we need to all remember. STIX is a serialization format for COMPUTERS. What you display in the UI is independent. So proposal
2 really seems like a better solution for our design principles.
Bret
From: Mates, Jeffrey CIV DC3/TSD <
Jeffrey.Mates@dc3.mil >
Sent: Friday, April 27, 2018 11:41:04 AM
To: Terry MacDonald; Sean Barnum
Cc: Bret Jordan; Wunder, John A.;
cti-stix@lists.oasis-open.org Subject: RE: [Non-DoD Source] Re: [cti-stix] Re: [EXT] [cti-stix] New property names for previous label properties
I’m strongly in favor of having a single named field for this (proposal 2). The primary purpose that was being discussed for this was
to allow display information to be sent using STIX for specific products. As a programmer it’s a lot easier for me to know that every object type will have the same field that I should query for if I want this value rather than having to fill in a special
configuration entry for each and every STIX object type.
That way when a STIX viewer application reads an entry it knows it always needs to look at 2 fields to determine what icon to display.
1.
Look at tags and see if any match my icon rules. If one does use it, if more than one does decide which to use.
2.
Look at the TLO and use the default icon for this type. If it is an unknown TLO use a fallback icon.
If we go with options that make more sense to a human then it ends up requiring an additional lookup step:
1.
Lookup the key for tag names and see what field or fields to use.
3.
If a tag name exists for this type see if any match my icon rules. If one does use it, if more than one does decide which
to use.
2.
Look at the TLO and use the default icon for this type. If it is an unknown TLO use a fallback icon.
Jeffrey Mates, Civ DC3/DCCI
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computer Scientist
Defense Cyber Crime Institute
jeffrey.mates@dc3.mil 410-694-4335
From:
cti-stix@lists.oasis-open.org <
cti-stix@lists.oasis-open.org >
On Behalf Of Terry MacDonald
Sent: Thursday, April 26, 2018 2:11 AM
To: Sean Barnum <
sean.barnum@fireeye.com >
Cc: Bret Jordan <
bret_jordan@symantec.com >;
Wunder, John A. <
jwunder@mitre.org >;
cti-stix@lists.oasis-open.org Subject: [Non-DoD Source] Re: [cti-stix] Re: [EXT] [cti-stix] New property names for previous label properties
I also strongly support #1, but with the caveat that we don't always user _types if another word makes more sense e.g. roles for the Identity object. I like the list that Jason posted
in the issue comments, with a slight tweak as suggested by Sean:
Identity: roles
Indicator: indicator_types
Malware: malware_types
Report: report_types
Threat Actor: threat_actor_types
Tool: tool_types
Cheers
Terry MacDonald Chief Product Officer
M:
+64 211 918 814
E:
terry.macdonald@cosive.com W:
www.cosive.com On 25 April 2018 at 10:11, Sean Barnum <
sean.barnum@fireeye.com >
wrote:
I strongly support #1 as it meets what is needed and is by far the most intuitively clear on what it means. I would suggest the large majority of people would understand what
it means.
I would strongly disagree with #2. I would suggest that it would be found almost universally to be confusing and unclear on what labels are, what tags are and what the difference
is. “Labels” is far too general to convey the specific meaning of a specific type of something (malware, threat actor, indicator, etc).
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, April 24, 2018 5:32:01 PM
To: Wunder, John A.;
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: [EXT] [cti-stix] New property names for previous label properties
I like #2, this is what we had originally in STIX 2.0 before we merged them.
Bret
From:
cti-stix@lists.oasis-open.org <
cti-stix@lists.oasis-open.org >
on behalf of Wunder, John A. <
jwunder@mitre.org >
Sent: Tuesday, April 24, 2018 2:31:06 PM
To:
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: [EXT] [cti-stix] New property names for previous label properties
Hey all,
We discussed this on the working call and had a quick straw poll. The options we discussed were:
1.
*_types (indicator_types, malware_types, threat_actor_types, etc.): 5 votes
2.
Keep these values from the vocab in labels (as they are now), add a new property called tags to capture the user-defined tagging: 4
votes
3.
Something else: 0 votes
4.
Abstain: 5
If you haven’t weighed in on this topic yet, can you please shoot a message to the list to help us decide? It can be just a quick “I like #3”, or it can be something with a longer
description, or it can be a new suggestion to consider. You can also comment on github:
https://github.com/oasis-tcs/cti-stix2/issues/37 .
We need to resolve this issue before we can finish CSD01 so any feedback is appreciated.
Thanks,
John
From:
<
cti-stix@lists.oasis-open.org >
on behalf of Allan Thomson <
athomson@lookingglasscyber.com >
Date: Friday, April 6, 2018 at 5:13 PM
To: "Bret Jordan (CS)" <
Bret_Jordan@symantec.com >,
John Wunder <
jwunder@mitre.org >,
"
cti-stix@lists.oasis-open.org "
<
cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] New property names for previous label properties
Agree with Bret’s issues. I posted my comment to the github repo and suggested an alternative.
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 1:57 PM
To: "Wunder, John" <
jwunder@mitre.org >,
"
cti-stix@lists.oasis-open.org "
<
cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Re: [EXT] [cti-stix] New property names for previous label properties
As noted in the Github issue tracker, I really dislike the "_type" names. I think it will be really confusing for people long
term.
Bret
From:
cti-stix@lists.oasis-open.org <
cti-stix@lists.oasis-open.org >
on behalf of Wunder, John A. <
jwunder@mitre.org >
Sent: Friday, April 6, 2018 2:34:58 PM
To:
cti-stix@lists.oasis-open.org Subject: [EXT] [cti-stix] New property names for previous label properties
Hey all,
Per Issue 37 (
https://github.com/oasis-tcs/cti-stix2/issues/37 ),
the TC has decided to stop using the labels property for the default vocabularies we have on some object types that generally categorizes the object. Given that change, we need to name the new properties on each of the objects that the change applies to.
After hearing from Jason on Slack, I captured some potential names in the last comment on that github issue (
https://github.com/oasis-tcs/cti-stix2/issues/37#issuecomment-379361610 ).
Can you please take a moment and review those suggestions? If you agree, please +1 my comment or respond over e-mail. If you disagree and have a different suggestion, please comment in Github or respond over e-mail. I’d like to get at least a few people to
positively agree to these decisions…especially if you were a proponent of making the change called out in the issue.
You can find the vocabs themselves in Part 1 (
https://docs.google.com/document/d/1ShNq4c3e1CkfANmD9O--mdZ5H0O_GLnjN28a_yrEaco/edit )
and the definitions for how they’re used in the objects in Part 2 (
https://docs.google.com/document/d/1bkMmU1PxlwlAwjrMmyWV147rvLcRs2x62FicHbpH2gU/edit ).
Just search for the object name.
Many of the suggestions are “_type”…just note that there’s already a “type” property on the objects, so it would lead to both a required “type” property and a required “indicator_type”
property on Indicator, for example. That may be fine, it was just pointed out already in Slack so I wanted to bring it up here.
Thanks!
John
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.
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.