[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Observable Patterning
+100, Ivan.
Patterning should live in _one_ place and have _one_ syntax.
I tend to think the STIX Indicator level is the right place for this to live.
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Kirillov, Ivan A. <ikirillov@mitre.org>
Sent: Monday, September 21, 2015 19:47 To: cti@lists.oasis-open.org Subject: [cti] Observable Patterning 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.
Regards,
Ivan
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]