[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Re: Observable Patterning
>Where I get confused is whether the intent is to pass “observed” or “observable” patterns.
>I see the latter term used to mean both what is seen and what could hypothetically be seen
>(but may not have been in recent history).
>The former means I am seeing an attack ongoing here and now.
>The latter means one could see this pattern, look for it, and look to see how complete the pattern is. >Furthermore, if you see it, it means this.
Great questions, Michael, and I think you characterized things quite well in your description. The intent is to support both characterization of “observed” data (which we refer to as observable “instances" in CybOX parlance) and also observable “patterns” (captured as STIX Indicators) that could hypothetically be seen and represent some specific thing if seen (e.g., the presence of a particular malware instance). From my perspective, one of the potential issues with our existing implementation of this approach is that observable instances and patterns are captured in the same place and using the same structure (the CybOX ObservableType); the primary difference between the two is a “condition” property that is present on patterns and not on instances.
>One more question, do we expect patterns to span multiple organizations? >(where a pattern is only observable when events across organizations are assembled)
From a practical standpoint, I don’t see this happening, is it would require shared visibility into each organization’s sensor network (SIEM/IDS/HIDS/etc.). However, this is not to say that our pattern implementation will necessarily preclude this.
Regards, Ivan
From: Michael Hammer
Date: Thursday, October 1, 2015 at 1:21 PM To: Sean Barnum, Ivan Kirillov, Mark Davidson, "trey@soltra.com", "cti@lists.oasis-open.org" Subject: RE: [cti] Re: Observable Patterning Please pardon me if this is such a basic question. I understand that there are atomic events that are observable. I understand that those events may be constructed into either simplex or complex patterns of observables. (where the atomic observables can appear across multiple possible patterns) The above are things that can be observed as facts or inputs to some logic machine. I understand that there can be patterns of assertions that can lead to a set of conclusions. Those assertion patterns could be simple or complex. Such patterns might represent hypothesis or experience. (Reminds me of the design combinational or even sequential digital logic hardware, Which as we know, any hardware can be converted into software.) Where I get confused is whether the intent is to pass “observed” or “observable” patterns. I see the latter term used to mean both what is seen and what could hypothetically be seen
(but may not have been in recent history). The former means I am seeing an attack ongoing here and now. The latter means one could see this pattern, look for it, and look to see how complete the pattern is. Furthermore, if you see it, it means this. I am seeing this as one thing is a set of inputs to a logic machine, While the other is really just a blueprint of a logic machine. One more question, do we expect patterns to span multiple organizations? (where a pattern is only observable when events across organizations are assembled) ________________________________ Michael Hammer Principal Engineer Mobile:
+1
408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA From:
cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Barnum, Sean D. Hi all, I am trying to catch up on this thread and offer some thoughts. I will start here but will likely add some thoughts farther along the thread as well. Let me start by saying that I think we are talking about several different topics here and kind of munging them all together. I think we are going to need
to separate them to deal with them appropriately. So far I see the following topics:
My thoughts on these topics:
Sorry for the long email but wanted to comment at least briefly on all the various topics being combined in this thread. Again, I would suggest we separate them out. sean From:
<cti@lists.oasis-open.org> on behalf of Steve Cell <ikirillov@mitre.org> > In order for a pattern to be specified in a STIX Indicator
(e.g., ‘IP Address in 1.2.3.4/24’), would the pattern would need to use fields from a CybOX object? If the answer is yes, does that create a hard dependency between STIX Indicator and a particular CybOX object and version? Having a separate patterning structure would mean that we would somehow need to reference CybOX Object fields, and unless we completely decouple CybOX from
STIX Indicators (this seems unlikely, though I believe there have been a few suggestions to this effect), there would indeed be a hard dependency between a STIX Indicator and a particular CybOX Object version. This is necessary to explicitly specify the semantics
of “what” the Indicator is looking for. > What about consistency with other uses of STIX Indicator?
Consider a SNORT signature or YARA rule – patterning is contained in those signatures and wouldn’t be at the STIX Indicator level, which seems inconsistent to me. This seems to be more of an issue with how different types of patterns are captured in STIX Indicators. CybOX-based patterns are currently represented as a
separate entity, whereas other types of patterns (SNORT, YARA, etc.) are captured as Test_Mechanisms. Given their functional overlap, it may make more sense to have a single “Pattern” field that can be extended to capture CybOX-based patterns, SNORT rules,
YARA sigs, etc. Regards, Ivan From:
Mark Davidson What implication would patterning in STIX Indicators have for the relationship between STIX Indicators and CybOX objects? In order for a pattern to be specified in a STIX Indicator (e.g., ‘IP Address in 1.2.3.4/24’), would the pattern would need to use fields from a CybOX
object? If the answer is yes, does that create a hard dependency between STIX Indicator and a particular CybOX object and version? What about consistency with other uses of STIX Indicator? Consider a SNORT signature or YARA rule – patterning is contained in those signatures and
wouldn’t be at the STIX Indicator level, which seems inconsistent to me. > Patterning should live in _one_ place and have _one_ syntax. I really like this idea, and I’m asking questions that I hope will lead us in this direction. Thank you. -Mark From:cti@lists.oasis-open.org
[mailto:cti@lists.oasis-open.org]
On Behalf Of Trey Darley +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
From:cti@lists.oasis-open.org
<cti@lists.oasis-open.org>
on behalf of 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). Regards, Ivan |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]