Joep, et all,
I am struggling with this. The way I understand this discussion to date, over the past several months is:
1) We need a way of saying someone saw something and their assertion about that is it was bad. a) We need some way of tracking temporal aspects and chains of events. Ex. PDF got downloaded, within 20 seconds 2 EXE get downloaded, 1 minute later a connection to x.y.z.a gets opened up and we assert that it is bad. b) Need a way to track sightings of said events c) Need a way to assert relationships about said events and add to or remove relationships of said events. Or even give +1s or -1s to said assertions.
2) Test Mechanisms will have a lot of the same assertions and constructs but I see them, as you point out, as being specific patters for certain things. So I can see these as being name value pairs where it might look like:
{ test_mechanisms : [ { key : "snort", value: "some snort signature in native snort syntax" } ]
}
Thanks,
Bret Bret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
Hi Ivan,
I’d be interested what the team feels about the relationship between these patterns and test mechanism concept. Please correct me if wrong;
- indicator patterns described a pattern of potentially malicious activity that is intended to convey the pattern in a way that a human can understand and that machines can translate into action-based use-cases (like detection)
- test mechanisms are a pre-computed or created pattern specific to a certain use-case (like snort detection, yara, etc.)
Since in both cases that might be conditional relationships and nested conditional calculations (e.g. If you don’t see X, then the previous variable in de flow is +1, if you do seeX, then the previous variable in the flow is –1) - it makes it ill-suited
for graph representation in the context of graph querying.
J-
>- Human readable
Agreed.
>- Machine friendly (parsing/computation, algorithmically friendly)
Agreed.
>- Data graph friendly
Not so sure on this one.
While I agree that STIX/TAXII querying (wherever it ends up) is inherently graph-based, I don’t believe the same is true for Indicator patterning. The main difference is that, in my view, the majority of Indicator patterns are meant to be parsed and executed
against data that is inherently flat – lists of files, lists of processes, lists of IP addresses, etc. Thus while the two may overlap in certain places, I’d be very hesitant about overloading an Indicator patterning structure to support graph based querying,
though perhaps it could be extended to do so. Again, I think a primary focus here should be to keep Indicator patterns SIMPLE, so that they can easily be written and consumed by analysts.
Regards,
Ivan
From: Jerome Athias
Date: Saturday, September 26, 2015 at 12:38 PM
To: Patrick Maroney
Cc: Terry MacDonald, " cti@lists.oasis-open.org", Ivan Kirillov
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 friendly
|