My preference in order:
1 – very clear and easy for both humans and machines to correctly interpret
3 – I could live with this but absolutely not with the name “classification” for all the reasons Gary mentioned and others
From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Thursday, May 17, 2018 at 1:32 PM
To: "cti-stix@lists.oasis-open.org" <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:
- *_types (indicator_types, malware_types, threat_actor_types, etc.) for the categorizations/types, and use “labels” for user-defined tagging
- Keep these values from the vocab in “labels” (as they are now), add a new property called “tags” to capture the user-defined tagging
- 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:
Indicator: indicator_types
Threat Actor: threat_actor_types
Terry MacDonald | Chief Product Officer
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).
I like #2, this is what we had originally in STIX 2.0 before we merged them.
Bret
Hey all,
We discussed this on the working call and had a quick straw poll. The options we discussed were:
- *_types (indicator_types, malware_types, threat_actor_types, etc.): 5 votes
- 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
- Something else: 0 votes
- 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
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
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.
|