I've had another "aha" moment -- actually, a whole series of them -- recently.
The first hint that something big was going on came as part of a flurry of announcements at RSA World, including this hidden gem around DLP.
It turns out that I only had a half-baked notion of what all the fuss might be about, until late last week. I was privileged to spend some quality time with the RSA team who went through the concepts and demo'd the product.
When they were done, my head was spinning. Not so much around the product capabilities (which were very cool, to be sure), mostly it was the new way they were approaching the problem that got me so excited.
I probably won't be able to fit in all into a reasonable-sized post, so consider this the first installment exploring a topic that I'm sure we'll all be interested in -- sooner or later.
What's This All About?
Data Loss Prevention -- simply put, being able to keep information out of the wrong hands -- is a rising bullet on the buzzword chart.
The reason is pretty simple. I won't bore you with the literally hundreds of public disclosures that someone lost someone's information. I used to keep track of these articles, but I really don't need to anymore. We're all aware that unintended information disclosure happens everywhere, all the time.
No one likes admitting to the world that they've mis-handled sensitive data. In addition to a growing trend to specified consequences (fines, audits, public disclosure, informing your customers, etc.) I'm sure each event is putting a big dent in brand, reputations and careers.
It's almost as bad as mis-handling toxic waste -- there's just no upside.
And the trending doesn't look good. More information being gathered, being used more widely, and a growing societal sensitivity to information breaches. Simply put, it's going to get worse, not better.
Who's Responsible?
The answer varies widely by industry, but we're meeting more people with the title of CISO or CSO.
CISO stands for Chief Information Security Officer -- it's a role that usually reports to the CIO, and we find it in industries that handle unusually sensitive information. A CSO (Chief Security Officer) has a much broader role; including aspects of physical security, employee / partner / customer protection, -- general risk identification and remediation.
If neither of these roles are in place -- whether formally or informally -- the job usually falls to either legal (e.g. Chief Counsel), or -- sometimes -- the CFO.
But, if I had to hazard a trend over the last few years, we're meeting more and more organizations that have role identified for keeping an eye on data loss as well as related issues.
Framing The Problem
Perhaps the most interesting part of the presentation I sat through was exploring the embedded assumptions -- they're very, very different than what I would have expected at the outset.
As you might guess, how you frame the problem leads to how you build the solution. And, given that this is a relatively new topic, I'd offer that -- before considering any solutions -- you should understand how the vendor frames the DLP problem, because it seems that there's a lot of differentiation here.
Mindset Change #1 -- The Primary Source Of The Threat
One striking example is the primary source of threats. We tend to think of bad guys stealing data -- mostly, because that's what we read about -- but EMC's CSO (Roland Cloutier) has a very different view.
BTW, if you can ever get Roland to speak to your team, go for it. He's a truly unique gem on the topic.
He categorically states that the #1 problem he sees is well-intentioned employees simply getting their jobs done, and doing something that inadvertantly puts information at risk in the process.
Maybe someone ran a report from a "protected" database, and emailed it to a co-worker, or saved it in an open file share. Or, perhaps, "quiet period" financials got sent to a wider distribution list than was intended. It's mostly normal people, getting their job done, taking information from one source, transforming it, and sending it along to somewhere else.
Roland talks in terms of insecure "business processes". I don't think he's mostly referring to the big, honkin' everybody-can-see-it ones, but more about the thousands and thousands of ad-hoc processes people use every day.
It turns out that any approach that has this frame of reference also does a good job of addressing the problem of the more "focused" individual who has negative intent. But, if you think only in terms of bad guys, you'll miss the much larger problem of people who are just going about their everyday jobs.
Mindset Change #2 -- Where It Happens Matters
The RSA team uses a three-part conceptual model to describe where problems can arise.
First, of course, is data-at-rest: named applications and their supporting infrastructure (servers, storage, backup, etc.). This, of course, includes file shares and other repositories.
Second is data-in-flight. Sure, this means the network, but it also includes the network-centric technologies that people use: email, web access, instant messaging, and so on.
Third is data-in-use: these are the endpoints that are part of our everyday lives: PCs, mobile devices, cell phones, remote web access, USB sticks, and so on.
The "ideal solution" should comprehensively cover all three concepts using a consistent set of capabilities. Problems are problems, wherever they might be.
Going a bit farther, the form that the technology takes changes depending on the domain you're talking about. Finding "data-at-rest" problems might involve a server-based solution scanning data. Data-in-flight points at enhanced network technology cracking packets. And endpoint solutions usually involve an agent or something similar.
This leads to a "framework" approach; optimized technology for different domains; with a consistent mechanism for pushing policies, capturing the results, and driving process change. Point solutions won't be very useful here.
Mindset Change #3 -- Accuracy Really, Really Matters
One of the critical success factors that the RSA team believes is extremely important here is accuracy. A flood of false positives tend to clog up the system, and -- eventually -- no one pays attention to anything.
Conversely, missing bad stuff isn't good, either.
If I had to point to one area where unique IP really matters, it's probably in this arena. RSA has a fairly unique (and expensive) dedicated team of linguistic knowledge experts that build the "content blades" that detect potential problems.
One example was offered up: an Italian phone number can look a lot like a US social security number. One is harmless, the other isn't. And, unless you know that fact, and can identify a contextual document as Italian, you may end up with a LOT of false positives, especially from your EMEA operation.
That's just one small example; there are literally thousands of these linguistic chestnuts out there.
Simply put: RSA believes that incredible accuracy isn't just a "nice to have"; it's the foundation on which all other features are based.
Mindset Change #4 -- Watch First
Roland and the RSA team believe the first conceptual step in addressing the DLP problem is simply finding out where you have the problem. He recommends gathering data and creating understandable reports as a basis for engaging the business.
As an example, he put up a chart that showed all the different credit card information that's in various EMC systems. Now, if you know anything about EMC's business, you'd be surprised to learn that we collect credit card data (at least, I was surprised), but -- there it was, in lots and lots of places.
Oh, wow.
Now, if you think about it, this leads to an interesting discussion between the CSO and the owners of business processes, e.g. "did you know that you had credit card data in your system or process?" and taking logical, rational steps to protect more thoroughly.
Lots of goodness can come from this approach: having the data to start the discussion, making the owner of the process more aware and more accountable, and -- most importantly -- focusing resources on where the real problems are, rather than imaginary or hypothetical ones.
Mindset Change #5 -- Engage The Users
We all tend to think of brittle, forceful reactions to information policy breaches. And I'm sure there are a few situations where that's called for.
But one of the embedded philosophies in RSA's approach is being able to warn people that they're about to do something that might be ill-advised:, e.g. "this email has been quarantined for the following reason, do you really want to send it?" or "you're about to save some really sensitive stuff to your USB, are you sure you want to do this?", or -- perhaps -- "you're using a Gmail account, did you know that everything is public there?" and so on.
If you go back to the original assumption -- the biggest threat is people just doing their jobs -- this strikes me as a key insight: rather than getting in the way, just advise people that (a) you're doing something that's ill-advised, and (b) oh, by the way, we're watching ...
Mindset Change #6 -- Prioritization and Workflow Really Matter
OK, your new tools have found something. Maybe several thousand "somethings" in a very short period of time.
Unless you think in terms of prioritization and workflow, any team you have looking at this stuff is going to get overwhelmed pretty quickly.
Prioritization helps: something that looks like a lone social security number sitting in an email is one thing; a file with 6,000 of them is quite something else.
Workflow can take a variety of forms, formal and informal. Maybe it's a quick follow-up automated email to the people involved, sending them to a web site where your company's policies are spelled out in a more formal fashion. Maybe it's an email to a manager, or perhaps HR.
Or, in some cases, maybe it's an entirely different (and more severe) form of "workflow".
Context matters as well. Certain users might have be in a situation where they're routinely exposing the company to risk -- maybe it's not the individual incident, but there's a pattern there. Or, perhaps, the individual has a privileged role in the company, and is trusted with handling very sensitive information.
Or (my favorite!) maybe it's tax season in the US, and there seems to be a flood of financial data in the email and file system: all of it personal, and none of it corporate.
Mindset Change #7 -- Supporting The Admins Really Matters
Although a lot can be automated in a DLP environment, the interesting bits land (or should land) in front of a human being to make an informed decision. If you don't make their job as easy as possible, you're going to end up with less-than-optimal results.
The demo I saw had put a lot of thought into the day-to-day job of the information security administrator -- real-time status, short-term and long-term trending, a nice workflow manager, prioritized alerting via email, the ability to flexibly report, and so on.
Two concepts jumped out at me that , of course, now seem obvious. The first was "role separation" -- allowing a security admin to do their job without seeing the actual content that raised a flag. The second was an up-the-stack integration with the overall security event management framework, based on priority.
Put differently, a security event is a security event at a certain level, and the ability for DLP to push specific events into a bigger framework is probably a very useful feature.
Mindset Change #8 -- Do It All, Or Don't Bother
Something that was very clear to me as I was taking all of this in -- a vendor is either offering a framework that can handle 85%+ of the problem, or it's not. Sure, there will always be vendors that can handle a piece of the problem better than some other guy, but I don't see that being broadly useful.
What jumped out was the need for entperise-wide uniformity, consistency, pervasiveness and so on. Unless you can trust that breeches are being detected uniformly everywhere it matters, you end up with a patchwork that's not only a pain, but can't be trusted.
And, at the end of the day, it's all about giving the business the confidence it needs to get things done and not worry too much about information security breeches.
Putting It All Together
Taken together, this was a pretty significant mindset change in how I think about the DLP problem. And that's just what I was able to get out of the presentation -- I'm sure there's more, but even the bits I was able to process are pretty significant.
I'd like to think that, somewhere, some smart team had an "aha" moment. I heard the story was very different. Tablus (an acquired RSA company) has been chipping away at this problem for many years. When EMC and RSA acquired Tablus, it was pretty clear that they had figured out the problem the best possible way -- by working directly with customers in extended engagements across multiple versions of their product.
It was pretty clear -- as they went through the roadmap -- that they had started with one set of assumptions, but -- over time -- had ended up with a very different set of assumptions, ones that reflected what people actually needed from the technology, rather than just a clever idea or two.
Pretty cool thinking, I'd offer.
Wait until I tell you what the product actually does ...
For that same reason, the software to prevent data is very important. The problem is not just losing data; it is also preventing theft of them.
The loss of data is very expensive, but can be effectively prevented. There are many systems available for companies (every day you can find more and better software).
The cost of prevention is always less than the cost of loss, and even if there is no loss, the cost worth it: Safety is the first, for your business and your customers!
It is not so difficult to prevent, but it is really hard to heal this damage! And we must not forget that we need also to protect our reputation.
As you said well, a change of mentality is essential!
Great post, congratulations!
Posted by: Data Loss Prevention | April 07, 2009 at 07:29 AM