Unfortunately, we’re running into issues with none standardized tagging in our current systems now. Each vendor does have their own tagging formate for example:
APT-1
apt1
Apt 1
apt-1
When a search is done on APT-1 not all the results are returned because half the data is tagged wth apt1. I can probably generate many more uses cases. The question that should be ask is, do we leave the standardizing of tagging to the working group or do we leave it with the vendors? Are we prepared to take on that challenge?
Best Regards, Nicholas Hayden, CISSP, GICSP, CNDA, CEH, Sec+
Director of Engineering Anomali | anomali.com
808 Winslow St Redwood City, CA 94063
Phone: (650) 257-0867 | Twitter: @anomali
On May 5, 2017, at 9:44 AM, Wunder, John A. <> wrote:
Ah, good feedback Paul…does anyone else have a similar namespaced tagging approach?
Maybe we should put a pin in this topic for either 2.1 or 2.2. I’m curious about what the cross-tool usages of the fields are…if it’s just displaying to users or searching on it, jamming it into strings might not be so bad. If there’s automated processing based on specific tags though, obviously that doesn’t work so well. It would probably be useful to take some examples and run them through some sharing scenarios. Or maybe we’ll find out everyone has the same set of “vendor-specific” tags and we literally can just standardize on them.
John
From: Paul Patrick <>Date: Friday, May 5, 2017 at 9:26 AMTo: John Wunder <>, OASIS CTI TC Discussion List <>Subject: Re: [cti] MISP format <-> STIX 2.0 - Discussions
John,
To your very point and the examples Alexandre used, we’ve had to add a custom property that is a dictionary to hold exactly the kind of things that Alexandre is attempting to do for very similar reasons. “Tagging” is a very common and unfortunately often vendor specific thing, but a reality.
Like Alexandre did, we toyed with the idea of “encoding values” and putting them in labels, but it very unattractive and mixed the semantics defined for the use of labels on a given SDO. We also toyed with the idea of adding a custom property for each “tag”, but that quickly became unworkable.
It too bad we didn’t make labels a dictionary instead of a list of strings.
Paul Patrick
From: <> on behalf of "Wunder, John A." <>Date: Friday, May 5, 2017 at 9:15 AMTo: OASIS CTI TC Discussion List <>Subject: Re: [cti] MISP format <-> STIX 2.0 - Discussions
Yeah this is a great writeup.
One thing I would consider as you (and others) are doing this comprehensively is the use of custom properties. Specifically, if there are cases where a generic STIX tool (not coded support for your specific capabilities) just has no hope of doing something intelligent with the data you should probably use custom properties.
As an example, in the taxonomy section you have a label called "osint:source-type=\"blog-post\"". If a generic tool gets that property it’ll probably just display it to the user as it does with other labels…which in this case, kinda makes sense. It’s not ideal because there’s markup in there but it’s at least readable.
OTOH you also suggested putting Machine IDs into labels, which would give a label like "misp:to_ids:true". Would that make sense for a general tool to display to the user? Would the user (who doesn’t know MISP) know what it means? I think the answer is no, so that seems like a good use for custom properties. Just add a generic property to the STIX object called {“x_misp_to_ids”: true}
Here are some specific comments…
Contextual Categories:
I agree that kill chain phases is the right place for this. I also like the idea of the TC somehow publishing a set of known kill chain and phase names so we get better consistency. I don’t think it makes sense as part of the STIX spec itself, but maybe as a non-standards track work product (or, to be honest, just on our docs site would be better than nothing).
Taxonomies:
As I said above I think it makes sense to use labels for this. I’m not sure about having generic machine tags as a standard part of STIX…one of the key features of STIX is to standardize on things, and so we probably just want to consider adding fields specific to the commonly used taxonomies.
That actually already applies to one of your labels…you have “tlp:amber” in there, but in STIX that should really go in data markings. That does mean that you probably need to treat some of your taxonomies different than others.
Machine IDs:
I also don’t really understand this. As I said above, though, the best place to put it is probably custom properties.
Versioning:
I agree about versioning. You should make sure to consider this on both import and export (i.e. if you get a STIX object from another tool that’s revoked, can you handle it correctly and, if you create a STIX object that’s revoked, can you create it correctly).
Events:
Yeah I agree there’s not a great place for this now. CRITS had a similar type capability called “event” that, back in the STIX 1.x days, we aligned to a named package (which is now report) because it was incident seemed excessive. If we add the event object in 2.1 that would work. If you want to do something for 2.0 I would consider either report (I don’t think a generic tool that got a report w/ your collection of data would be confused by it, especially if you set a label to “event-report”) or custom object (aligned to your event proposal for 2.1) as a stopgap.
John
From: <> on behalf of Jason Keirstead <>Date: Friday, May 5, 2017 at 8:49 AMTo: "" <>Cc: OASIS CTI TC Discussion List <>Subject: Re: [cti] MISP format <-> STIX 2.0 - Discussions
This is a very good read. These kinds of validations and challenges to our modeling with real-world use cases are critical to make sure we are getting things right...- Being a MISP novice, can you go into more detail on the "MISP IDS/Machine" field? What is this used to convey?- From my reading around it, A MISP "event" to me seems like it would be most properly modeled using an Incident object, which was something that was pitched and is in the STIX 2.1 Working Concepts, but has not yet had anyone take it over for refinement to get into STIX 2.1. Maybe MISP would like to take that on?-Jason KeirsteadSTSM, Product Architect, Security Intelligence, IBM Security Systemswww.ibm.com/securityWithout data, all you are is just another person with an opinion - Unknown From: Alexandre Dulaunoy <>To: OASIS CTI TC Discussion List <>Date: 05/05/2017 07:29 AMSubject: [cti] MISP format <-> STIX 2.0 - DiscussionsSent by: <>
Hi All,We recently had an extensive discussion within the MISP core teamfor the MISP format conversion from/to STIX 2. We pinpointedsome issues and possible remedies (short-cuts?) on the following page:https://github.com/MISP/MISP/wiki/NotesMISP-STIX2As discussed with Trey, we would like to share our findings withthe community and are hoping to see whatever our solutions fit theenvisioned STIX 2 standard.Thank you very much.Cheers.-- Alexandre DulaunoyCIRCL - Computer Incident Response Center Luxembourg41, avenue de la gare L-1611 - www.circl.lu---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
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.
