[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Re: Observable Patterning
Comments inline
From: <cti@lists.oasis-open.org> on behalf of Steve Cell <ikirillov@mitre.org>
Date: Friday, September 25, 2015 at 9:13 AM To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] Re: Observable Patterning To Terry’s point about tool-specific versus generic patterns - to me at least, this is rather relative. While it’s true that there is often a hard dependency between a particular pattern language and engine/tool that consumes it, this is not always the
case; for example, YARA rules can be consumed by several different tools, including Cuckoo Sandbox. Thus, going back to Mark’s point below, I don’t see a true semantic distinction between STIX/CybOX patterns and those expressed in other forms (test mechanisms)
– ultimately they are meant for detecting badness, and either your tool(s) can parse and make use of them, or they cannot.
[sean]I would concur.
Relevant part of my previous post:
"It looks like the difference between Observable and Test_Mechanism within STIX Indicators may be confusing for some. There really is not a strong semantic difference between these sub-structures of Indicator. They both are intended to express the
observable pattern relevant to that Indicator. The only difference is that Observable is built on the presumption that the pattern is expressed using CybOX while Test_Mechanism is an extension point for expressing the pattern is any other format desired (e.g.
YARA, OVAL, OpenIOC). They are currently separate structures because at the time they were designed there was a clear desire to demonstrate a preference for CybOX over other approaches for expressing observable patterns due to the value of consistency as
CybOX is used in many other areas of STIX (malware characterization, incident investigation, digital forensics, etc.) where these observable patterns would likely come from anyway. It may be possible (potentially desirable) in STIX 2.0 to remove the separation
between STIX/Indicator/Observable and STIX/Indicator/Test_Mechanism with a single Observable Pattern structure that is basically what Test_Mechanism is today but with a default implementation of a CybOX based observable pattern. So basically the current Observable
field would be renamed Observable Pattern and changed to TestMechanismType, and a new CybOXTestMechanismType would be created and asserted as the suggested default extension. It would also probably make sense to change the wording of Test Mechanism to Observable
Pattern."
I’m of the opinion that the value that CybOX offers in terms of patterning is with regards to expressing patterns against its Objects and their corresponding data models (very similar to OVAL in that respect, as Jerome alluded to :)),
[sean]I would assert that it is more than just Objects but also Actions as well.
and enhancing this capability should be our primary focus. Trying to create a monolithic pattern language that subsumes all others is untenable (not that I think anyone is really suggesting this), and I think having Snort, YARA, and the like out there is a
great thing; they do what they do very well, and thus we should leave their capabilities to them. I don’t view it as a negative if an Indicator pattern can be better expressed, say, through a YARA rule than through a CybOX pattern.
[sean]I agree that a monolithic pattern language is impractical.
Also, I’m supportive of Bernd’s idea of a top-level Pattern structure, and also one that is relatively abstract and amenable to being used in different domains (e.g., fraud). Ultimately, I think this structure needs to be able to express some set of constraints
against a data model and its fields, whether it’s a CybOX Object or something else, like a structured representation of a bank account (as an example). Therefore, perhaps it could even live as a separate effort/work product – Generic LangUage for Patterning
(GLUP), anyone? :-)
[sean]At this point, I would neither agree or disagree with the idea of a top-level Pattern structure. I would have so see more of what is being proposed. At the level of detail provided so far I am not seeing how it would serve the relevant patterning
needs that exist within STIX.
So, to offer up another straw man (and I think Jason had something very similar), it would be interesting to see if we can converge on a YARA-like patterning structure that is easy for humans to read and write, and also machine-parseable:
pattern example_1
{
objects:
$OBJ1 = {type = AddressObject, fields = [{“category”:”ipv4-addr”}, {“address_value”:”192.168.2.3”}]}
$OBJ2 = {type = AddressObject,
fields = [{“category”:”ipv4-addr”}, {“address_value”:”192.168.4.7”}]}
condition:
OBJ1 and OBJ2
}
Regards,
Ivan
On 9/25/15, 8:02 AM, "Davidson II, Mark S" <mdavidson@mitre.org> wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]