OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] Observable Patterning


Thanks for the new thread and tracker.

We already have the CybOX Object Relationships Vocabulary
https://cyboxproject.github.io/documentation/object-relationships/

and

ConditionTypeEnum
Equals
DoesNotEqual
Contains
DoesNotContain
StartsWith
EndsWith
GreaterThan
GreaterThanOrEqual
LessThan
LessThanOrEqual
InclusiveBetween
ExclusiveBetween
FitsPattern
BitwiseAnd
BitwiseOr
BitwiseXor

ConditionApplicationEnum
ANY
ALL
NONE

I think we should focus on the temporal elements, and when/where/how
to put them.




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]