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 AM
To: 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 AM
To: 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 AM
To: "" <>
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 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: Alexandre Dulaunoy <>
To: OASIS CTI TC Discussion List <>
Date: 05/05/2017 07:29 AM
Subject: [cti] MISP format <-> STIX 2.0 - Discussions
Sent by: <>
Hi All,
We recently had an extensive discussion within the MISP core team
for the MISP format conversion from/to STIX 2. We pinpointed
some issues and possible remedies (short-cuts?) on the following page:
https://github.com/MISP/MISP/wiki/NotesMISP-STIX2
As discussed with Trey, we would like to share our findings with
the community and are hoping to see whatever our solutions fit the
envisioned STIX 2 standard.
Thank you very much.
Cheers.
--
Alexandre Dulaunoy
CIRCL - Computer Incident Response Center Luxembourg
41, avenue de la gare L-1611 Luxembourg
- 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.
