[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Re: Observable Patterning
Joep,
I don’t think there is a clear dichotomy as you suggest between the Observable (observable pattern) of an Indicator and any test mechanisms defined for it.
They are really semantically the same thing.
They are both simply observable patterns for identifying whether some particular factual observable conditions exist. These patterns are devoid of any context as to “malicious activity” or other wise. It is the enclosing Indicator that assigns such context
to the pattern.
You are correct in that test mechanisms would most likely be used (rather than Observable) based on some certain use case where the other format provides expressivity that CybOX does not or the fact that the targeted recipient of the Indicator has particular
tooling capabilities that you are looking to serve.
sean
From: <cti@lists.oasis-open.org> on behalf of Joep Gommers <joep@intelworks.com>
Date: Monday, September 28, 2015 at 11:57 AM To: Steve Cell <ikirillov@mitre.org>, Jerome Athias <athiasjerome@gmail.com>, Patrick Maroney <Pmaroney@Specere.org> Cc: Terry MacDonald <terry.macdonald@threatloop.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] Re: Observable Patterning Hi Ivan,
I’d be interested what the team feels about the relationship between these patterns and test mechanism concept. Please correct me if wrong;
- indicator patterns described a pattern of potentially malicious activity that is intended to convey the pattern in a way that a human can understand and that machines can translate into action-based use-cases (like detection)
- test mechanisms are a pre-computed or created pattern specific to a certain use-case (like snort detection, yara, etc.)
Since in both cases that might be conditional relationships and nested conditional calculations (e.g. If you don’t see X, then the previous variable in de flow is +1, if you do seeX, then the previous variable in the flow is –1) - it makes it ill-suited
for graph representation in the context of graph querying.
J-
From: <Kirillov>, "Ivan A." <ikirillov@mitre.org>
Date: Monday, September 28, 2015 at 3:36 PM To: Jerome Athias <athiasjerome@gmail.com>, Patrick Maroney <Pmaroney@specere.org> Cc: Terry MacDonald <terry.macdonald@threatloop.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] Re: Observable Patterning >- Human readable
Agreed.
>- Machine friendly (parsing/computation, algorithmically friendly)
Agreed.
>- Data graph friendly
Not so sure on this one.
While I agree that STIX/TAXII querying (wherever it ends up) is inherently graph-based, I don’t believe the same is true for Indicator patterning. The main difference is that, in my view, the majority of Indicator patterns are meant to be parsed and executed
against data that is inherently flat – lists of files, lists of processes, lists of IP addresses, etc. Thus while the two may overlap in certain places, I’d be very hesitant about overloading an Indicator patterning structure to support graph based querying,
though perhaps it could be extended to do so. Again, I think a primary focus here should be to keep Indicator patterns SIMPLE, so that they can easily be written and consumed by analysts.
Regards,
Ivan
From: Jerome Athias
Date: Saturday, September 26, 2015 at 12:38 PM To: Patrick Maroney Cc: Terry MacDonald, "cti@lists.oasis-open.org", Ivan Kirillov Subject: Re: [cti] Re: Observable Patterning so should we try to capture the requirements in one place for this change request?
Quickly:
- Human readable
- Machine friendly (parsing/computation, algorithmically friendly)
- Data graph friendly
2015-09-26 17:57 GMT+03:00 Patrick Maroney
<Pmaroney@specere.org>:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]