Re: [cti-stix] Possible solution to conundrum of how to do patterns for Infrastructure and Malware

[John-Mark Gurney <jmg@newcontext.com>]

Jason Keirstead wrote this message on Thu, May 25, 2017 at 08:21 -0300:
> Yesterday a major discussion at the face-to-face was around trying to work 
> out the end to end workflow by which the indicators come out of the 
> malware.
> 
> Myself (and it seems several others as well) are concerned that if malware 
> sandboxes automatically start sharing tons of “malware” objects via TAXII, 
> or sensors start producing “infrastructure” objects linked to 
> observations, then software vendors are just going to code their 
> implementations to look for those things directly… indicators will never 
> “show up” because either there is no one to make them, and/or people don’t 
> want to do things twice (they don’t want to make an Infrastructure object 
> with observations *and* maintain a pattern for those observations and 
> constantly update them both and keep them in sync as they mature - it is 
> going to be a large headache.
> 
> Folks seem to be having this implicit assumption that either (a) humans 
> will make and maintain all of these indicators from the tool output “just 
> because”, or (b) vendors will change their tools to output indicators 
> because someone (?) is asking for the indicators. This to me flies in the 
> face of the fact that the market is lazy and always seeks the shortest 
> path to success; if that path is to just write code to directly search and 
> alert on malware and infrastructure observations, then that is what is 
> going to happen…. after all, the vast majority of what people share on 
> threat intel feeds are pointers to malware or infrastructure.
> 
> The danger is that indicators become not very useful and we end up with 
> somewhat crippled STIX implementations everywhere since no one can look 
> for anything complicated, because they can’t use patterns… we end up with 
> STIX 1.X.

btw, very well said...

> I have been thinking about this problem last night and am wondering if a 
> possible solution is to add an operator to allow patterns to somehow 
> reference STIX objects directly. 
> 
> IE you would have something like 
> 
> [stix-object:malware-12345-aaaaa-bbbbb-ccccc.sample_metadata[*].hashes.“SHA-256" 
> = ‘aec070645fe53ee3b3763059376134f058cc337247c978add178b6ccdfb0019f’]

Shouldn't this be:
[ file:hashes."SHA-256" = stix-object:malware-12345-aaaaa-bbbbb-ccccc.sample_metadata[*].hashes."SHA-256" ]

So that we are searching for the hash on the malware?

The example as written has a problem that you are matching a specific malware object
to a specific hash, and as the neither will change (often) it's either always true
or always false.

The other option would be:
[ stix-object:malware-*.sample_metadata[*].hashes."SHA-256" = "aec070645fe53ee3b3763059376134f058cc337247c978add178b6ccdfb0019f" ]

Where it would match any malware object, but again, this assumes that malware objects
are the new observed data, and not what we want...

> This pattern would mean “you want to look for the hashes defined in this 
> specific STIX object“ 
> 
> If we had this, then I think it is an answer to what I think is an obvious 
> problem. This way the actual definition of the object is what is referred 
> to in the indicator. It also makes it much easier to create patterns from 
> malware and infrastructure, and also eliminates the problem of having to 
> constantly sync patterns with these objects.

There is definately an advantage of this, but on the other hand, if we support my
first example, why not just have someone automatically write that indicator as
it happens?  There isn't much difference between having the tool that generates
the indicator and the patterning code handle it.  It's very easy to generate 
indicators like the first example, but NOT referencing the malware object..

-- 
John-Mark