[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] RE: Indicators and patterning
So we’re agreeing
J Keep the included patterns identifier and have a specific content attribute for each pattern included. allan From:
"Bret Jordan (CS)" <Bret_Jordan@symantec.com> This is very similar to what I was proposing... { "type": "indicator", ..., "pattern" : "<some STIX cyber observable pattern>", ... } Then in the future if we decide we really do want to support Yara or SNORT or OpenIOC then we can add something like: { "type": "indicator", ..., "included_patterns": [ "stix", "yara"], "pattern" : "<some STIX cyber observable pattern>", "yara": "<some yara pattern>", ... } Or if you just wanted to send SNORT in the future you could do: { "type": "indicator", ..., "included_patterns": [ "snort"], "snort": "<some yara pattern>", ... } The nice thing about this design, IMHO, is it follows our custom properties model. This allows vendors to easily expand what they support and do, without having to worry about the "pattern-lang-ov" open vocabulary and should make
it easier for us to "add" properties in the future. It also allows us to build a model in the future where a single Indicator may include multiple patterns in different languages at the same time. As I start coding APIs and tools to work with STIX 2.0, I am finding things that I want to shine a big light on. Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> I suggest that if you remove the identifier field that states what field is used then in future if others want to convey alternate fields such as yara, snort….etc then how does a recipient
know which field should be used? It also has the problem that it forces cybox field to be always be included when this might not be relevant. It comes back down to the fact that you would still need something to say ‘use the yara field instead of the cybox pattern field’. Similarly if someone is using yara by forcing producers
to generate cybox pattern content when its not used or necessary for a use case is wasteful and inefficient. Upon reflection, I suggest we keep a field pattern_lang is a list that identifies what content is provided where the values has { cybox-pattern } for now and in future if yara or snort
content is produced then those additional fields can be added. So Object 1 { Pattern_provided: [ “cybox” ] Cybox_pattern: <cybox pattern string> } Object 2 { Pattern_provided: [ “snort” ] Snort_pattern: <snort pattern string> } Object 3 { Pattern_provided: [ “cybox”, “snort” ] Cybox_pattern: <cybox pattern string> Snort_pattern: <snort pattern string> } allan From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org> I think this would be a re-evaluation of whether we think it’s valuable to be able to use Snort and YARA patterns instead of STIX Patterns in Indicators. At the time, we opened this up
as an extension because we felt that people would want to, for example, write a Yara pattern and use that in an indicator that they link to some malware. Yara, Snort, and OpenIOC are very popular languages for sharing IOCs, after all -- more so than STIX.
IMO the merge of STIX and CybOX into a single Work Product doesn’t really change that reasoning. That said I was always relatively ambivalent on this point, so if consensus is to remove them I wouldn’t object too much. John From:
<cti-stix@lists.oasis-open.org> on behalf of Greg Back <gback@mitre.org> I think getting rid of pattern_lang and pattern_lang_version makes sense (and assume pattern-lang-ov would go away as well). My only concern with using custom properties is that if “pattern”
field is required, I’m not sure what would go in that field for other types of indicators. From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Bret Jordan (CS) All, When we started really working on STIX 2.0 we had this idea that CybOX was going to be separate and we should treat it as a separate thing entirely.. This unfortunately caused us
to make some design decisions in STIX to reflect this artificial line in the sand we had drawn. Fast forward 10 months and we have now merged STIX and CybOX and during this merge we have been able to clean up some of the weirdness that existed with the artificial
line in the sand. There is however, one thing that is still in the specification, that we did because of this separation that I would personally like to us get rid of. In Indicators we created the following 3 fields to address the artificial separation: pattern pattern_lang pattern_lang_version The idea was if we are going to support CybOX as a separate "thing" we might also want to support "other" things. I would suggest at this stage we drop support for "other" things and just have a single "pattern"
property. If people want to do YARA or SNORT, they can do it via a custom property. And if we find in a later release that lots of people want to support YARA or SNORT we can then create properties for them. Bret |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]