and/or logic

[jeff bryner]

Writing a fledgling parser for .ioc files in python and stumbling on the and/or logic behind the IOC editor.

Any docs or pseudo code for how to interpret the various combinations of and/or levels that are possible within an .ioc file?

Thanks,

Jeff.

[David Ross]

The AND OR tree can be as deep as needed.
When parsing it in code, it's a method that can call itself.

walkTree(nodes)
   for node in nodes
       if node is element do parseElement( node )
       if node is branch do walkTree( node )


Pretty much. I have some perl around here that converts IOC to XPath and Lucene that I might be able to post.

-David

[Jeff Bryner]

Thanks for the reply.

That's pretty much how I ended up implementing it; a self referential
function.

FYI to the list: I released pyioc a client/server framework for IOC
issuing and processing last week at the energySec2012 conference. You
can find it here:
https://github.com/jeffbryner/pyioc

Presentation and video here:
https://github.com/jeffbryner/pyioc/tree/master/docs

Jeff.

[David Ross]

I was looking at what you built. Cool stuff!!

If I'm reading right, your agent parses and processes 1 IOC file at a time and you pass the actual IOC to the agent.
You might want to consider a few things:
  1. if the attacker compromises your agent or is able to mimic your agent, they now have your intelligence (what you are looking for and why)
  2. There are a lot of IOCs out there. One at a time will take a long time.

It might be better/faster if you aggregated the IOC definitions server side into a format your agent can make use of directly. This way, optimizations across IOCs occurs in one place.
Also, if/when the IOC format is updated, you may not have to refactor your agents to absorb the new capabilities.

I like what you're doing!

[Jeff Bryner]

Thanks!

<1. if the attacker compromises your agent or is able to mimic..>
True that; it's a client-side agent so it has the same issues that AV,
HIPS, etc have as far as an active attacker.

The server only sends IOCs bound for the agent IP range and does so
over SSL, so there are some protections against an attacker gaining
access to all IOCs. The server is meant to be instantiated as needed
and so a minor deterrent would be the attacker needing the IP of the
server. I'd thought of building some authentication into the SSL
handshake but it's not there yet.

< 2. There are a lot of IOCs out there. One at a time will take a long time.>

That's true. There's definitely room for enhancement especially using
caching of files/registry/hashes and multithreading. As a previous
post mentioned, I think there is lots of room for pre-processing IOCs
to find the fastest route to conclusion (i.e. an ioc consisting of
process OR file hash will always complete faster examining processes).

<It might be better/faster if you aggregated the IOC definitions server side
into a format your agent can make use of directly>

I thought about transforming IOC to yara rules or some other format,
but wanted to just focus on IOC for this release. If someone generates
a pre-processor for IOCs it may be best to 'compile' them for agents
to guarantee the shortest path to completion.

Thanks for the feedback! Much appreciated!

Jeff.



David Ross <david...@openioc.org> says: