Data Loss Prevention - Step 7: Actionable intelligence

[#1]

This is the final installment of the Data Loss Prevention (in a rational, sane way without new blinky boxes) series.  In this post I'm going to bring up one of the most interesting topics (at least to me) which is gathering actionable intelligence from all of your existing investments.  Since you probably have at least 100 devices across your network generating security log information - not to mention other types of useful bits - it's imperative that as you think about doing DLP you utilize this wealth of existing information available to you... or is it?

Remember - mountains of information being generated by security devices is only useful if you can transform it into actions which can increase the security posture of your organization.

What's a SIRM?

SIRM stands for Security Information and Risk Management, and it's typically served up as a platform of technologies, and can be consumed as an in-house product or service.  SIRM is the continuing evolution of the SIM platform that many years ago started as a log aggregator which of course did not one any good because no one I know had any time to actually do anything with it.  Why the new term SIRM?  Simple - the industry needs to evolve into risk management beyond just the traditional security event management.  In short, there is more to your organization than what the firewall and IPS generates.  While lots of events may mean an influx in attack, or simply noise ... it does not adequately express or correlate business risk.

You see, today's security dashboards and consoles focus on exactly that - security - and security tends to have a very myopic view of the enterprise.  Security tends to care about bad things happening, and for good reason too!  If the security team were to start looking at the totality of organizational "events" the odds of an information security team being overwhelmed in seconds is a a sure bet.

So here we have the crux of the issue with data loss prevention - too much information to process in a meaningful way without advanced insider knowledge of your specific organization.  DLP is a Catch 22, because you never know what you're looking for (or in what format) to tell the systems you have in place to look for it.  If you knew what you were looking for, you wouldn't need the big fancy systems to look for it ... so this gets complicated and SIRM technologies combined with some good 'ol fashioned brain power can actually rescue you from drowning.

Finding a needle in a stack of needles

The difficulty in DLP is that you're looking for patterns that range from obvious to downright 007-style sneaky.  What I mean by this is that sometimes you're looking for the accidental email that sends out a boat-load of social security numbers, while other times it's a trickle of events that alone don't raise suspicion but are exfiltrating data from your organization.

There are really 3 main questions when you're thinking about the mountains of information you have at your fingertips for the purposes of avoiding leaking data from your organization.  Often times, when I've seen security teams simply "dive in" to a DLP effort it turns into an exercise of trying to find the one needle they're looking for not in a haystack, but in a haystack of needles.  Information can be our biggest asset, and our greatest adversary when we're looking at preventing data loss.  On one hand you have information being generated (in the form of events) on every single piece of hardware and software in your organization.  Starting at the badge readers at the front door, to the access terminals (PC, laptop, mobile device or terminal), to the software - every kind of software - there are billions upon billions of events being generated every day.  This mountain of information is a fantastic asset - that is until you start to think about how you're going to process those events and figure out what they mean in real-time.  You see, with the way that business moves these days, you don't get the luxury of running a log analysis engine overnight to figure out that you've had information stolen yesterday - you need to be able to do this in real-time (or very nearly real time).  The challenge of course is if you turn the logging knob to maximum and point it at your log aggregator (or SIRM if you've got a copy of ArcSight [or some other SIRM platform] sitting around humming) things tend to go ka-boom quickly.  So on one end you have this wealth of information and on the other is those few events when strung together which tell you something is going wrong right now.

So here we go, let's take a look at how you can find the right needle, in that haystack of needles...

• What (to log & monitor)  - The simpleton answer to the what question is "everything".  This doesn't scale, of course, nor does it necessarily make sense.  I would tell you that it's intelligent to err on the side of caution though, and feed your intelligence platform as much as it can take.  Let me offer you some practical advice that has worked for me and others I have first-hand knowledge of over the years.  First, don't limit yourself to security information.  A good intelligence platform (like a SIRM) will look at everything from a badge-swipe into your data closet to the outbound access violations your firewall is generating and everything in between.  Applications are a wealth of knowledge when it comes to logging.  Sometimes developers restrict themselves artificially when it comes to logging "security events" so let the intelligence platform decide what's important while you feed it (nearly) everything.  Everything from successful logins to your application, to things like how long a person stays on a specific area of your application, to the database queries performed is important and can be that one key piece of information that may find the bad guys.  So my main advice - don't limit yourself to 'security events' pre-defined by the application or device.
• How (to analyze) - The how is part of the magic that makes one platform simply more effective than another.  Let's be clear, more effective actually means effective, and less effective actually means inadequate.  I'd crazy how often some people complain about their logging and intelligence platforms.  Analysts complain that you have to maintain and constantly tune the platform because it doesn't just run by itself when this is actually one of the most valuable pieces of an SIRM or intelligence platform.  You can't just set it and forget it, otherwise your intelligence engine is only as effective as the last tune-up you gave it ...how many months ago?  The analysis is purely mechanical, and it has to be with the scale we're talking about here, but the rules and analytics must be at least shared with a human.  Humans can interpret events better than machines or software and therefore are required and critical when complex analysis is required.  Until the Autonomy IDOL platform can effectively learn human patterns to detect malice (think Minority Report) we'll still need humans to tell the machines to connect two dots which seem unrelated.  I tell you what though, those PhD's over in our Autonomy group have some serious intelligence in that platform that you have to see to believe!  In the end, the key is having a well-oiled machine which can perform advanced analytics which is constantly fine-tuned by humans.
• When (to respond) - Response is key.  No matter how good the logging facility is on some platform you've heard of, no matter how good its ability to show you events relevant to your situation the most important thing your logging facility can ever tell you is when to respond.  Knowing you were compromised by SQL injection yesterday is nice from a forensic standpoint, but it doesn't actually help you stop the intrusion.  Whether it's automatic, or requires human action - the only relevant question at the end of the day is did you stop the threat?  I can name at least a dozen times over the past couple of years when, given the right information at the right time, massive data breaches could have been minor.  I realize with attack vectors like SQL Injection it's pretty much always "too late" to react but wouldn't it be better to tell the SEC or your investors that you have 1 table from your database stolen over having to tell them your entire database was stolen?  These are very realistic response issues.  Having actionable intelligence giving you the ability to stop an attack either before it starts (optimally) or as it's happening (next best thing) is the "Holy Grail" of information security teams.

Now you're reading this wondering - how you can possibly implement this type of system without buying one of those "solutions" that comes in 4 rack-mountable 2U boxes right?  Odds are you've got a SIM or SIEM or maybe if you're lucky one of the more advanced SIRM platforms already in-house.  Leveraging those platforms, and building out capability is more important than probably anything else you'll do, and brings together everything else we've talked about so far.  Knowing where your critical assets are, how they traverse your business platforms, and how your users use them is the key to plugging the holes in the boat before it sinks.  You can do this ... just don't buy into the hype around DLP and understand it's like anything else - baby steps until you have a working system.

Good luck!