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] Re: Observable Patterning


Comments inline

On 9/25/15, 7:02 AM, "cti@lists.oasis-open.org on behalf of Grobauer, Bernd" <cti@lists.oasis-open.org on behalf of Bernd.Grobauer@siemens.com> wrote:

Hi,

I don't really see Test_Mechanisms as a candidate for reusing the
patterning that we've been discussing. Each Test_Mechanism rule is a
rule derived from the Indicators, and written in the tools native
language.

The principle of having a test-mechanism derive from what is described
within an indicator using observable patterns is the intended meaning,
but this principle is not always followed: it may be quite complicated
to describe in STIX/CybOX, what can be succinctly described in a
certain pattern language or the authoring party simply does not want to
bother with this -- so the STIX indicator is also used as a vehicle to
exchange such a test mechanism, enriched with contextual information
contained in the indicator and referenced/referencing STIX objects,
but not containing corresponding observable patterns. I would guess
that we will continue to see such use of a TestMechanism within an
otherwise rather empty indicator (empty with respect to Observables),
even if the pattern language is evolved such that in theory it could
describe everything that is expressible in any thinkable test
mechanism.

[sean]Spot on. Test Mechanisms are not necessarily “derived from” the CybOX observable patterns in Indicators. An Indicator can have just an Observable, just a Test_Mechanism or both. As Bernd points out, sometimes a Text_Mechanism can the most appropriate way to express the pattern either due to inherent capabilities of the external patterning format or due to the available tooling of the recipient. The only real key requirement is that if they are both present the patterns should not be in conflict.



It doesn't make sense to me to have patterning in the
Test_Mechanism unless it is natively in the tool that uses the rules.

I had made that proposal in one of my emails with the intent of encapsulating
complexity. I can see why one would not want to use a test mechanism
as container for STIX/CybOX containers -- after all, no other test mechanism
would have references out of the test-mechanism blob, whereas a
STIX pattern could have many references to objects/object properties
defined elsewhere.

But I really would like to get rid of AND/OR/...-composition on
the level of indicators and push the whole pattern language
into (oh no, here it comes) yet another STIX top level object
STIX_Pattern or whatever. Then allow STIX_Patterns to reference
other patterns for composition, but not Indicators.

The reason is that the whole logical and temporal composition
is really complicated. The Indicator is absolutely central
to STIX, but like I said above, there may be use-cases to
communicate things to look out for *without* the use of
CybOX and CybOX patterning but via a test mechanism (or,
I haven't given up on that idea, a STIX-standardized key/value-pair
mechanism for communicating patterns).

[sean]for reasons described in my first post on this thread and in the documentation it links to, I don’t think that this will be practical


Now, if we encapsulate the complications of the pattern language
in something that is removed from the Indicator level, then
one can implement the non-patterning-part of STIX much easier
in order to use it for use cases as described above. Also,
using STIX for other domains (fraud and what not) as has
been mentioned on the list yesterday, could become easier, since
for these other domains, the full might of STIX patterns
may not be needed ... or such domains may even need something
else entirely. (Hm, I just realize that this reasoning
would actually support making patterning part of CybOX
as a CybOX-pattern-top-level object.)

[sean] I think your last parenthetical nailed it. It is exactly this need for differing context-specific patterning that argues against trying to define one ring … erm I mean pattern language to rule them all.


In closing, because I have proposed yet another top-level STIX entity:
in one of his mails about a possible top-level targeting object,
Aharon was concerned about making things too complicated by adding
more and more top-level objects. That is a valid concern, but on the
other hand, having huge schema definitions for objects that encompass
all kinds of substructures, is also quite complicated.  So, while we
certainly should have good reasons for introducing new top-level
objects, I would say that given the right circumstances, new top-level
objects will actually decrease complexity.

So, in short:

- I fully agree that decoupling patterning and instances
  is the right way to go.

- I would like to encapsulate patterns in a top-level construct
  that may be referenced by STIX indicators while removing
  not/and/or composition for indicators.

- I am not quite sure yet whether the 'Pattern' top-level object
  would better be part of STIX or part of CybOX.

  If we think the patterning is reusable also for extended domains such
  as a possible SocEngOX (Social Engineering Observable EXchange)
  language and we think we will want to write things like

  (SocEng-Observation "Phone call from Mr. Evil") THEN
  (CybOX Email Object with sender "lucifer.evil@hell.com)

  then patterning is probably part of STIX rather than CybOX; otherwise,
  as a cyber-focused language, it might well be part of CybOX.


Kind regards,

Bernd

------

Bernd Grobauer, Siemens CERT





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