[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Observable Patterning
I just would like to highlight (again) the similarities between the example described on github and the OVAL language see end of this page https://oval.mitre.org/language/about/definition.html while an Observable is an 'object with a state', the test/check/pattern is separated from the list of 'static observables' (Note that I am not suggesting using OVAL, but we could inspire from some of its mechanisms) 2015-09-21 20:47 GMT+03:00 Kirillov, Ivan A. <ikirillov@mitre.org>: > Relaunching this as a separate thread based on Jerome’s suggestion, so as to > not further hijack the discussion around Bernd’s suggested refactoring. > > I think there are a few broad questions around this topic that we can touch > upon here: > > 1. What capabilities should STIX/CybOX patterning have? > 2. Where should STIX/CybOX patterning live? > 3. Should patterns have their own implementation/structure, or continue > to be embedded in Observables/Objects? > > As far as 1) I would say the following, as a straw man: > > * Conditional operators > * AND > * OR > * NOT > * Basic temporal operators > * FOLLOWED_BY > * WITHIN > * String matching > * EQUALS > * DOES_NOT_EQUAL > * CONTAINS > * DOES_NOT_CONTAIN > * Basic arithmetic operators > * > > * < > * >= > * <= > * Regular Expressions > * PCRE compatible > * Variable substitution > > Regarding 2), it seems to me that patterning is inherent to Indicators, and > thus should be part of STIX. I just can’t see the use case for a CybOX > Observable with a pattern that stands on its own, or is used in a > non-Indicator context. This would also serve to greatly simplify CybOX, as > it would mean that CybOX can ONLY capture instances of cyber data. > > With regards to 3), I see lots of advantages to having a separate structure > for patterns, which I’ve documented in the corresponding CybOX issue [1]. > The short of it is that it will get rid of the instance/pattern duality, > allow for the creation of a domain-specific patterning language (necessary > for more complex pattern expressions), and also give us the flexibility to > move patterning out to wherever makes the most sense (whether it’s STIX or > somewhere else). > > [1] https://github.com/CybOXProject/schemas/issues/381 > > Regards, > Ivan
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]