[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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:
<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]