One of my persistent themes is that tomorrow's CIO will have to think of themselves as the "CFO of information". The parallels between the evolution of how we've learned to manage money, and how we're going to have to learn to manage information are striking.
There's a very strong linkage between this thought, and RSA's recent offerings around DLP -- data loss prevention.
I've looked at different IT products over my entire career, and have learned to evaluate them in terms of the "big thoughts" they embed. Of course, execution against those ideas matter as well ...
And I've been watching how RSA's DLP suite is rolling to market, and have been absolutely fascinated by the thinking behind it.
If you're a fan of big ideas, there's a lot to consider in this offering ...
Big Idea #1 -- Better Start Thinking Of Information Like Money
In today's corporate world, the flow of money is intensely scrutinized. If we were to consider the topic of "financial risk management", it'd be a pretty sophisticated discussion: find the risks, and invest proportionally according to the consequences.
My company doesn't scrutinize expenses below $25. Well, at least I don't think they do. But bigger numbers get a lot of scrutity -- at many levels.
So, if we shift the focus to "information risk management", some of the thinking still applies: find the risks, and invest proportionally according to the consequences. And "money" has this interesting property that bigger numbers clearly signal more importance.
But information works differently: it has to be understood in context to really understand its value -- or its risk.
Big Idea #2 -- Information Is Everywhere
In most organizations, sensitive information lives in multiple places: production systems, file systems, development environments, personal devices like cell phones and USB sticks ... you can't point to one location and say "there it is".
It's also shifting and transforming as people use it: a database gets extracted to a spreadsheet which gets embedded in a presentation, which gets emailed. And if there are social security numbers going along for the ride (as an example), that's a problem.
Conclusion? Better start thinking about the problem as holistically as possible.
Years ago, I lived in the SF Bay Area. One day, I saw a neighbor spraying around his house. He said he'd seen a few termites, and wanted to get them before they spread.
Now, if you've ever lived in an area that's prone to termites, by the time you see them, the party's over, so to speak. The only real solution is to pay someone big money to put a big tent over your house, and fumigate it with a lethal poison. Spot treating for termites is a complete waste of time.
As would be locking down one or two key applications.
Big Idea #3 -- The Real Risk Might Not Be What You Think
Of course, we've all been following the stories of bad guys penetrating IT security and making off with a bunch of credit card numbers.
But for every one of those, there's dozens of dozens along the line of some poor person just doing their job, and -- in doing so -- put themselves and the organization at risk.
Tapes get lost. Emails get into the wild. Sensitive data intended for a specific party goes missing. Laptops get stolen. Maybe a government employee is bored and wants to surf the passport files of celebrities. Or maybe someone gets clever and thinks they can make a few bucks by selling information. You get the picture.
It's easy to visualize a gang of bad guys trying to steal something. It's probably more useful to visualize ordinary employees coming to work every day.
Big Idea #4 -- The Landscape Is Changing
"Information Risk Management" is a fluid, evolving topic. Exactly what kinds of information are deemeded sensitive seems to change continually. Who thought aggregated search records would be considered private information?
And, at the other end, exactly what the consequences might be is changing as well. New regulations and mandates are continually popping up, and there's sporadic enforcement of existing ones -- until someone gets to be made the example for everyone else.
If you tend to think of static, defined requirements -- you'll probably be better served by thinking in terms of shifting requirements in two dimensions: (1) what's considered sensitive, and what's not, and (2) consequences associated with certain kinds of information being mis-handled.
That makes it simple, doesn't it? ;-)
Big Idea #5 -- Process, Control and Audit Matters
Way back when, I was exposed to ISO 9000. Naively, I thought it certified that a company built quality products. Not quite: it means that the company has documented processes in place for measuring and improving quality.
I'm no financial whiz, but the same thing seems to be largely true in the financial world: most of the focus is on process and controls. As a result, it seems to be relatively OK to lose money; it's not OK to do so sloppily.
I find no reason why this line of thinking won't extend to information risk management: it won't be too long before some Designated Authority starts asking the same process, control and audit questions around information: who's seen it, where has it gone, etc.
And can you prove it?
Big Idea #6 -- It Starts With Discovery
The old truth of "you can't manage what you don't know about" holds true here as well. It seems that -- for most people -- the first step of this journey are tools that can scan information repositories and flows, and see what's going on.
Our CSO, Roland Cloutier, tells the story of how he did this at EMC. He went to management and said "what are we going to do about our credit card problem?".
Now, the reaction was just as expected -- the belief was that EMC didn't handle credit card information.
Roland pulled out a chart listing a bunch of different internal systems that had varying amounts of credit card information in them. Oh my. An interesting discussion ensued.
The conclusion? Think big, but start small -- and tools that can scan emails, file systems, etc. looking for potential problems is probably a reasonable starting point -- or perhaps a services engagement to give you a starting point.
Big Idea #7 -- The Little Things Become Big Things
Our RSA team tells me that liguistic comprehension becomes one of the silver bullets in all of this. Too many false positives, and the system gets overwhelmed. Just a few missed negatives, and no one feels they can trust the solution.
And -- behind that -- is the ability to understand information in context.
Someone told me that a phone number in Italy looks a lot like a social security number. Sure, sensitive information can't leave the company, but if the CFO is trying to send some numbers to an external advisor, that's different.
Or, maybe it's tax season for your employees, and there's a ton of financial information and social security numbers flowing into and out of the company's email system.
Another important area is workflow management. You detect stuff, it drives a workflow. If you end up detecting a lot of stuff, workflow management becomes a really big deal.
And, not surprisingly, most people who've deployed these technologies have ended up finding a lot of termites, so to speak -- real ones.
Putting Ideas To Work
One intellectual gem in the RSA DLP offering is the notion of a "content blade". Think of this a pre-packaged definition of what you're looking for, and what you want to do when you find it.
Doesn't matter whether the information of interest is in a test/dev environment, a laptop, or going outside the company via IM: you're looking for something, and you want to take action when you find it.
The RSA team has spent a lot of time and effort putting together over 100+ nifty content blades that work right out of the box, covering topics like "transfer of intellectual property", "company confidential", "acceptable use", "regulatory compliance" (insert very long list here), and "privacy protection".
Just wading through all the different content blades is an interesting exercise.
Here's what I think is cool: not only is there a solid foundation to get to work immediately, but if things change, it's just a matter of adding or modifying a content blade, and things work pretty much as before. The whole problem has been nicely encapsulated.
True story: I met a customer who was having a legal problem due to -- ahem -- widespread use of inappropriate language in email, etc. They had to stop it, and prove that they were taking steps to stop it.
In a DLP world, that's a quick fix. Imagine what you'd have to do otherwise.
The Big Picture
If you got a new job as a CFO at a struggling company, the first thing you'd probably do is invest in control systems. You can't manage what you don't know about.
In tomorrow's world, if you're going to be the CFO of information, you're going to have to do the same thing ...
Chuck
Very provocative posting. I have a couple of thoughts.
1) Management of money is driven by context to nearly the same extent as management of information. For example, if cash is received as a one time payment for a perpetual license to technology the seller is abandoning, it is a non-recurring item and it's not income. Some cash receipts are income and some are not. Some income generates cash and some doesn't. Do businesses place different emphasis on sales that can be recorded as income, as compared with sales of identical magnitude which are not income? At every company where I've ever worked they do!
Income recognition is merely one example. Other examples where context matters to financial transactions include whether an equipment acquisition is structured as a purchase or a lease, whether a sales rep who expenses tickets to a football game with a customer attends the game herself, etc.
2) When you compare information management to money management, you have to divide money management into financial accounting (what you tell your shareholders) and internal or cost accounting (what you tell your own line managers). Financial accounting is heavily influenced by regulation and the need for objectivity, internal accounting less so. The idea is that with internal accounting you want to produce data that you believe is correct (even if you can't prove it), while with financial accounting you want to produce data that someone else cannot prove is wrong. Since (at least for now) information management doesn't have burdensome SEC requirements, information management is more like internal accounting; you take actions and incur expenses to protect information that make sense to you, even if you cannot prove they are valid. Maybe in the future the government will become more prescriptive.
Bill
Posted by: Bill Bonin | July 11, 2008 at 04:46 PM