To be honest, this doesn’t make sense to me – STIX Patterns should not dictate which parts of the STIX data model (if any) they should match against. The core semantics of STIX Patterns are based on matching on specific artifacts, wherever they may be found – in a STIX SDO, in a PCAP, on an endpoint, etc. How are you supposed to convert STIX Patterns to other _expression_ such as YARA or SIEM correlation rules if the pattern is intrinsically tied to the data model? If a matching Object (File in this case) is contained in an Observed Data blob, then you can match against that, and similarly if it’s encompassed inside of the sample_metadata property of a Malware SDO.
I think it would be much more sensible to keep patterns data-model agnostic and instead include language that encourages indicators to be created when necessary for SDOs like Malware and Infrastructure that may include instantial Cyber Observable data.
-Ivan
On 5/25/17, 10:41 AM, "Trey Darley" <
cti-stix@lists.oasis-open.org on behalf of
trey@kingfisherops.com> wrote:
On 25.05.2017 08:25:35, Jason Keirstead wrote:
Sorry I wrote that pattern before I had coffee.. it makes no sense.
This is what the pattern would be with my proposal.... you are
looking for the hash contained inside a specific object...
[file:hashes.“SHA-256" =
stix-object:malware-12345-aaaaa-bbbbb-ccccc.sample_metadata[*].hashes.“SHA-256"]
Good thinking, Jason! I think this approach solves many of the
challenges we discussed yesterday around Malware and Infrastructure
vis-a-vis Indicators.
--
Cheers,
Trey
++--------------------------------------------------------------------------++
Kingfisher Operations, sprl
gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D
++--------------------------------------------------------------------------++
--
"Any sufficiently complex input format is indistinguishable from
bytecode." -- Bratus, Patterson, & Shubina