For some background, please see my post here
Here at Perch Security (perchsecurity.com) we’re building a community intelligence sharing platform that adds value to existing intelligence sharing communities… (our marketing folks say that better than I do!).
I’m building a bunch of services to ingest external intelligence, normalize, persist etc. I’m very thankful for standards such as TAXII (transport) and STIX (intelligence).
Reading a STIX doc makes sense for an analyst. The document gives great context around some piece of intelligence. An analyst can look it over, figure out some bad IP addresses and figure out what to do with them. The challenge comes with machine to machine communication. STIX can be used to relate Observables (IP addresses) into context.
For example, when analysts set of a new Indicator (the story of why we care about these IP addresses), they can set a relationship between ports and IP addresses. The facts are the observables (Port 80, IP: 220.127.116.11) etc.
So, looking at this net flow, 192.168.1.1:6633 -> 18.104.22.168:53 , we can very quickly determine that it’s a DNS request from an internal IP to Google’s DNS server. If that was determined to be malicious, the STIX should be set up like this:
Observable 1: IP 22.214.171.124
Observable 2: Port 53
Observable 3: 192.168.1.1
Observable 4: Port 6633
Observable 5: “Observable 1” AND “Observable 2”
Observable 6: “Observable 3” AND “Observable 4”
Observable 7: “Observable 6” AND “Observable 5”
See the tree?
– Description: “There’s a story here about malicious DNS traffic going to host 126.96.36.199 on port 53. We observed this on our network from an internal client 192.168.1.1:6633”
– Observables: “Observable 7”
So, an analyst reading that understands what’s going on. The immediate issue though for a Machine, is that the ‘internal’ IP part is effectively useless. No big deal, I can programmatically ignore internal IP addresses.
BUT, The REAL problem comes with fast analysts or bad tools. My Stix document comes back looking like this:
– Description: “Bad IP address found”
– Observables: “Observable 1” OR “Observable 2” OR “Observable 3” OR “observable 4”
That’s just plain wrong! Now, all my signature triggers on ALL DNS requests.
I see an education opportunity here for analysts using tools that create this intelligence. Not calling them wrong, but it’s an opportunity to learn to use the tooling a little better to improve all of our communities.