[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti-stix] RE: New property names for previous label properties
All I care about is that we don’t use the word ‘classification’. Please keep in mind, this may one day in a government network go through a cross-domain-solution or some agency gets a request to search for anything classified and does a keyword search on ‘classification’ or there is a government lawyer/official who does not have the capacity to understand that the word ‘classification’ in a STIX document does not mean the same thing they think it means (even though it clearly does not). There is also the fact that government systems will add to the STIX documents actual government classification to objects, links and properties, which will result in a ‘classification’ property that does not describe how classified information is, and us having to create another property to denote government classification that is not called classification. Rant complete. Thanks! From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> On Behalf Of Shok, Richard M 1, 3, 2 Rich Shok U.S. Bank - Information Security Services Threat Intelligence & Automation 651.435.7015 - Office richard.shok@usbank.com From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Philip Royer I support Option 1 because the keywords “labels”, “tags”, and “classifications” are sufficiently overloaded already and lack specificity. From: <cti-stix@lists.oasis-open.org> on behalf of Sean Barnum <sean.barnum@FireEye.com> 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:
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 From: <cti-stix@lists.oasis-open.org> on behalf of "Kelley, Sarah E." <skelley@mitre.org> 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 From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Wunder, John A. 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:
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> 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> 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 410-694-4335 From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> On Behalf Of Terry MacDonald 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 On 25 April 2018 at 10:11, Sean Barnum <sean.barnum@fireeye.com> wrote:
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.
|
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]