[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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:
<cti@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> 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:
<cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> 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...
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]