[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 friendly2015-09-26 17:57 GMT+03:00 Patrick Maroney <Pmaroney@specere.org>:Probably not clear that I've similarly argued to keep TAXII focused on the transport of packages. In the query method suggested for consideration, the Pattern would be passed as a STIX (Query/RFI) package and results similarly returned (again as a STIX package).
It's important to visualize this a Data Graph that maps to the Conceptual CTI model (which is the basis for suggesting Cypher as an example representation). One can describe/query precise graphs of Objects/Relationships, any Nodes/Edges off of a Root Node, etc.
I agree with Patrick's comments about ensuring pattern support for querying, but not the idea querying should be done in TAXII.
Querying and answering should be done within STIX, so that the querying and answering done by the language contained within TAXII, and so that TAXII is free to concentrate on only delivering content. We should instead develop a STIX query object, and a STIX reply object in order to support question and answer directly within STIX. I won't go into the specific argument why here and clog this thread, but it has been discussed on the TAXII list recently.
Cheers
Terry MacDonald | STIX, TAXII, CybOX Consultant
Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.
On 26 September 2015 at 01:33, Patrick Maroney <Pmaroney@specere.org> wrote:
I would like to add a couple of conceptual ideas to this discussion (along with a specific illustrative reference):
(1) If we architect our flexible "patterning" model correctly it 'should' be directly applicable to our TAXII Query Language.
(2) Graph data models provide some interesting correlations/visualizations. As previously suggested neo4j's Cypher Query language might serve as a good conceptual model for how to express "patterns"
http://assets.neo4j.org/download/Neo4j_CheatSheet_v3.pdf
Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org
A general [+1] for everything @Ivan said below (although agnostic on some of the specifics)
To this "flexible" patterning construct, advocate inclusion of fixed/relative temporal relationship _expression_ (highly simplified examples: "a" followed by "b" , "a" during "b" ) along with compound boolean and set theory _expression_.
Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org
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.
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 :)), 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.
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? :-)
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:
Adding my thoughts to the Test_Mechanism idea.
In line with 'one way of doing things', my preference would be for all signature-ish things to be thought of in the same way. In my mind, "signature-ish things" includes SNORT, YARA, and STIX/CybOX patterns. This is a little different than what we have today, where CybOX patterns are separate from Test Mechanisms [1], and Test Mechanisms are intended to identify the CybOX pattern(s). The way I'm thinking would have all signature-ish things become peers.
If I'm whiteboarding a use-case for signature/Indicator exchange, it would be something along the lines of:
Title: Send a signature
Description: An analyst creates a signature/indicator and chooses to share it with partner organizations.
Main Success Scenario:
1. Org 1's analyst develops a signature (e.g., SNORT, CybOX pattern)2. Org 1's analyst decides to share the signature; posts the signature to a TAXII Channel (perhaps as a STIX Indicator)3. Org 2, which is subscribed to the TAXII Channel, receives the signature (or STIX Indicator) and3a. The signature (or STIX Indicator) is entered into Org 2's internal review queue to decide whether to deploy the signature (or STIX Indicator)4. The signature (or STIX Indicator) is acted on - either manually or automatedly - and is discarded or deployed (or some other action)
Each one of these steps probably has a one-level-deeper set of steps associated with them (and a bunch of dependiencies/requirement), but at least for me, this is how I understand the workflow from Indicator creation to information sharing.
Thank you.-Mark
-----Original Message-----From: Grobauer, Bernd [mailto:Bernd.Grobauer@siemens.com]Sent: Friday, September 25, 2015 7:02 AMTo: terry.macdonald@threatloop.com; Kirillov, Ivan A. <ikirillov@mitre.org>Subject: RE: [cti] Re: Observable Patterning
Hi,
I don't really see Test_Mechanisms as a candidate for reusing thepatterning that we've been discussing. Each Test_Mechanism rule is arule derived from the Indicators, and written in the tools nativelanguage.
The principle of having a test-mechanism derive from what is describedwithin an indicator using observable patterns is the intended meaning,but this principle is not always followed: it may be quite complicatedto describe in STIX/CybOX, what can be succinctly described in acertain pattern language or the authoring party simply does not want tobother with this -- so the STIX indicator is also used as a vehicle toexchange such a test mechanism, enriched with contextual informationcontained in the indicator and referenced/referencing STIX objects,but not containing corresponding observable patterns. I would guessthat we will continue to see such use of a TestMechanism within anotherwise rather empty indicator (empty with respect to Observables),even if the pattern language is evolved such that in theory it coulddescribe everything that is expressible in any thinkable testmechanism.
It doesn't make sense to me to have patterning in theTest_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 encapsulatingcomplexity. I can see why one would not want to use a test mechanismas container for STIX/CybOX containers -- after all, no other test mechanismwould have references out of the test-mechanism blob, whereas aSTIX pattern could have many references to objects/object propertiesdefined elsewhere.
But I really would like to get rid of AND/OR/...-composition onthe level of indicators and push the whole pattern languageinto (oh no, here it comes) yet another STIX top level objectSTIX_Pattern or whatever. Then allow STIX_Patterns to referenceother patterns for composition, but not Indicators.
The reason is that the whole logical and temporal compositionis really complicated. The Indicator is absolutely centralto STIX, but like I said above, there may be use-cases tocommunicate things to look out for *without* the use ofCybOX and CybOX patterning but via a test mechanism (or,I haven't given up on that idea, a STIX-standardized key/value-pairmechanism for communicating patterns).
Now, if we encapsulate the complications of the pattern languagein something that is removed from the Indicator level, thenone can implement the non-patterning-part of STIX much easierin order to use it for use cases as described above. Also,using STIX for other domains (fraud and what not) as hasbeen mentioned on the list yesterday, could become easier, sincefor these other domains, the full might of STIX patternsmay not be needed ... or such domains may even need somethingelse entirely. (Hm, I just realize that this reasoningwould actually support making patterning part of CybOXas a CybOX-pattern-top-level object.)
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 addingmore and more top-level objects. That is a valid concern, but on theother hand, having huge schema definitions for objects that encompassall kinds of substructures, is also quite complicated. So, while wecertainly should have good reasons for introducing new top-levelobjects, I would say that given the right circumstances, new top-levelobjects will actually decrease complexity.
So, in short:
- I fully agree that decoupling patterning and instancesis the right way to go.
- I would like to encapsulate patterns in a top-level constructthat may be referenced by STIX indicators while removingnot/and/or composition for indicators.
- I am not quite sure yet whether the 'Pattern' top-level objectwould better be part of STIX or part of CybOX.
If we think the patterning is reusable also for extended domains suchas 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]