Monday, April 2, 2012

We Need Better Defensive Tools

We Need Better Defensive Tools
Period.  The tools we have right now are basic, non-interoperable, and non-granular.  There is no Metasploit framework for defense.  Let me paint a picture of a particular aspect - intel:
Current State
Many times after a security breach, we see a web of interactions between domains, malicious tools, C&C servers, personal information (email addresses, names, aliases), etc.
The Dell analysis of the RSA breach is one example ( These webs all seem to be manually generated after-the-fact.

Where We Should Be
Why couldn't we generate a significant amount of this in an automated fashion? Using Mandiant IOCs, IP reputation lists, or other intel feeds as well as the data from our own networks should let us build a very robust web of malicious activity.  This web can help us identify the reputation and actor behind an event (packet, netflow, higher level interaction) we observe on our networks.
Let's say you start with a database of Mandiant IOCs and suspicious IPs from updated Snort rules.  We are collecting the regular information from HIDS, NIDS, AV, Netflow, SNMP, Syslog, etc.  We compare the information we get to our database and something matches (an IP/domain, the attack vector, the malware, etc).  We now have a point connecting the event to our intelligence web.
Through the web we identify domains associated with the malware and scrape the domain for information.  The scrape pulls up multiple executables which are identified as malicious.  A Google search for the domain turns up posts linking personal information to the domain. 
A Whois search turns up other associated domains.  This can then all be fed into the web stored in the database to improve it. At the same time, we know at some level of confidence whether the event can be attributed to an attacker we know of.

Now What
The next step is to automate the response. (This is the same as your bank calling you when your credit card is used on the other side of the country or Facebook throttling your ability to send messages.) 
You can attribute an event to an attacker, and that attacker can have a response associated with them: (throttle them, block them, redirect to a honeypot, etc).  The response could be implemented automatically or with a human in the loop.
The end result is, based on your intelligence web, you degraded service to an attacker and collected more information to better identify them the next time they attack. All with minimal work on your part.
Nothing about this is revolutionary.  Marketers, Google, Facebook, etc are all able to piece information together to identify you even when you don't explicitly say who you are.  Banks, online video games, and major web services all degrade service based on perceived threats.  It's simply time for infosec defense to step into the modern world.
I've left many things out above to keep the post clear.  However, There is certainly more to this idea once you start thinking more about it.

The first is existing tools.  Mandiant OpenIOC, Verizon VERIS, Microsoft Threat Intelligence Feed, Snort VRT rules, Maltego, Incident Object Description and Exchange Format, I could go on.  I think we are getting to where we have both robust sources of intelligence as well as formats and frameworks to describe them. What we lack is away to make them actionable.
Most of the above tools/frameworks are incompatible and many aren't even actionable except manually.  We lack a single intel data storage tool that can be extended to accept whatever formats are available.  (Or if we have one, we're certainly not using it.) 
Additional the tool needs to be extendable to facilitate response and remediation.  Making response a manual effort is a losing battle when offense is push-button easy.
Another issue is sharing.  We all have intel that would be helpful but that we, frankly, are not allowed to share.  That's ok.  If the tool is flexible, we will all join the circles of sharing we are allowed in to.  Corporations can run their own sharing groups, choosing who's in and who's out. 
Industries can choose to share with each other.  Some intel feeds might be available to everyone.  Some organizations may even choose to provide access to their web as a service.  You submit an event.  They reply with associations, keeping the actual web private.
And let's not forget the benefits.  Because your defense improves every time you are attacked, you have raised the cost of attacking. Every failed attack makes the next attack more likely to fail.  That means, to be successful, attacks must be of higher quality which means they cost more resources.  Because they cost more, minor threats are priced out of the market.
Repeat attackers will have an even harder time.  They will need to stage completely from scratch for every attack. Different domains, IPs, tools, browser headers, email address, attack times of day, everything.  Otherwise they risk being associated with the web and having all of what they DID change associated with their profile. 
The flexibility to start from scratch requires a large amount of skill which again prices many attackers out of the market. It's time.  Let's build the tools to bring our intel together to execute a better defense.

(Cross posted at

Friday, January 13, 2012

On Defending Networks

In the article, he repeats a subtle point that I've heard from him before, "Defend the network". 
This is a critical distinction from "build the network securely".  It shows an understanding that engineering is only a supporting step in defending the network (as I blogged about here).
However he still seems to be concerned with planning the battle.  No war is won by planning a battle.  Wars are won by FIGHTING.
I don't mean to understate the importance of planning.  It can probably never be overstated.  However, if you're already in the battle, fighting back is critical to providing the chance to do that planning.
If a soldier is told to take a hill, he takes it, (I assume, not having ever been in the military).
More so, he is trained to do that.  He is taught to assess the hill, figure out the best defense for the situation, (no matter how good or bad the situation is), and execute it.
The same needs to be applied to our networks. 
If we can secure areas of the world existing in at least 3 domains (land, air, and space) if not four (adding sea), then we should easily be able to train to defend networks existing in a single domain (digital). 
If we can secure a spot of land which has an infinite number of paths in and out, then we should be able to train to defend a network defined digitally.
In fact, the only disadvantage to the digital domain is the speed at which conflict executes within it.
Is the defense harder than it has to be?  Absolutely.  Do we gain by going back and re-engineering the digital terrain to be more defendable?  Yes.
However, the second step is jumping on the network, mapping it out, planning a defense, and executing it (as I talked about here).  The first step is training and equipping people to do so.

(Cross posted at