IR is more than IOCs - It's About Inventory Too

If you work IR, you know how frustrating the whole process can be, especially when a customer wants to fly the "mission accomplished" banner prematurely.  Of course I understand the desire to bring it all to and end.  The long hours start to wear on people.  Questions of cost start to come in.  "How much more time will this take?"

A few years ago, I worked with a customer who was ready to call the IR done based on the fact that we didn't see any known IOCs in the data collected.  The problem was that the data collected accounted for less than half of the environment.  How much less than half?  Nobody, including the customer knows.  That's because they had never performed a hardware or software inventory before.  Seeing how those are #1 and #2 respectively on the SANS 20 Critical Controls, they're pretty darn important.

Detecting Code Injection on an Enterprise Scale 
You probably already know that I'm a huge proponent of memory forensics.  But you can't do memory forensics on an enterprise scale.  Fortunately, there are tools available that will help you at least look for injected memory sections (code injection) on enterprise scale.  I say fortunately because this is a technique used by attackers today with relative impunity.  If we lack the visibility to see that data, then we're urinating into a strong headwind and should expect predictably messy results.

To say that you have endpoint visibility covered when you can't detect code injection is like a SWAT team clearing a building for hostages without checking all the floors.  It's just plain stupid.  You don't have to ensure maximum visibility, but at least communicate correctly what you have and what you don't.

So if you've exhausted your known IOCs, can you call the investigation done?
Not if you haven't checked all of your endpoints.  Most investigations start with a single IOC.  This turns into multiple host and network IOCs.  Attackers are smart and will use different techniques across the environment so all of their eggs are not in a single basket.  Given available data and good data analysis techniques, we regularly find new IOCs.  It isn't easy, but our attackers are counting on us taking the easy way out.  Don't oblige them - make their lives tough.  Complete your host inventories and then scan, at least for known IOCs, across 100% of the environment.  Declaring an IR over when you've exhausted the initial IOCs may feel like an easy way out, but if you're wrong it can be a career ending move.

We continued looking back through collected data from the endpoints that we had access to and discovered additional IOCs two weeks after the IR had been called done.  For those curious, we discovered them using some proprietary data analysis techniques that have their roots in machine learning.  We learned we were nowhere near done with the IR and had not previously discovered the "zero patient."  The irony is that we learned even later that had we just completed a good inventory and scanned for the known IOCs we'd have found these new IOCs through traditional forensics too.

The Conclusion
Sure, briefing to the board that the IR is still going on can be uncomfortable.  But saying "oops we screwed it up" is even more so.  Don't call the IR done until you've at least looked at all your hosts for known IOCs.  And if you don't have an inventory, complete one first as part of the IR.  You have executive visibility and funding.  No better time than the present to do what you know needs to be done to call the IR a true success.