[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Observable Patterning
Agreed, that’s definitely the question we need to be asking with regards to where patterning should live. I think this ultimately comes down to whether having a single patterning implementation
is useful in multiple contexts, i.e., if a CybOX pattern is used in a MAEC or DFAX instance (both users of CybOX), does it (or can it) signify something else than if the pattern is used in STIX instance? For example, a pattern could potentially be used to
describe a set of filenames created by a particular malware instance in MAEC. However, this could also be done in a MAEC-specific manner, without needing all of the heavyweight structure and semantics of an Indicator-based pattern. My feeling is that trying
to support different contexts with a single Indicator-focused pattern structure is going to be messy and more trouble than it’s worth.
Regards,
Ivan
From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead
Date: Monday, September 21, 2015 at 2:04 PM To: Ivan Kirillov Cc: "cti@lists.oasis-open.org" Subject: Re: [cti] Observable Patterning "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.
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]