[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Re: Observable Patterning
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:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]