A while ago, I opined that IMSPs (information management service providers) might be hampered by corporate information security mandates.
At the time, I had started to meet customers who wouldn't consider using a service provider for backup, archiving, etc. simply because they (or their security officer) couldn't get over the idea of sending their important information to a third party for safekeeping.
Since then, the tide seems to have turned. I see more and more customers who are actively pursuing strategies to move more and more of the information management burden to specialized service providers. I guess they're getting more comfortable with the security provisions of these offerings.
Today, there are IMSPs who will do backup, or archive your email, or instant messages, and so on. And I think we'll see more and more of this.
So, I'm going to go out on another limb here and predict the emergence of a new IMSP service: one that manages security event information as a service,
And we might see this sooner than later.
What Is Security Event Information?
Glad you asked -- it's a fancy name for all the security event logs that many parts of the IT infrastructure continually produces.
Just think for a moment about all the network devices (gateways, firewalls, routers, etc.) and all the event information they produce.
Now let's talk about servers, operating systems, authentication systems, etc.
And don't forget all the databases and applications themselves, and the logs they produce.
Someone somewhere logged in. Someone accessed a bit of information. Someone changed a configuration file somewhere. Millions and millions of discrete events, all of which need to be logged somewhere.
Dozens -- and maybe hundreds -- of individual security event information logs.
OK, What Do We Do With All This?
Well, in simpler times, you might imagine a system administrator poring over log files periodically to see who's doing what. But in a modern IT environment, no one's likely to do this on a regular basis, or across multiple domains.
So how would you design a solution?
First, the security event information has to be captured and stored. And, for security reasons, it ought to be stored externally from the device that captured it, hopefully in some sort of tamper-proof location.
So it's easy to imagine a repository (or repositories) filing all this stuff a way, with only privileged access.
Second, it's got to be analyzed. Using human beings to do this isn't really practical (or reliable!). Today, I've seen more than a few automated analyzers that will look at one ocused part of the environment or another.
But that's not enough.
Why Correlation Is Important
Bad guys have to traverse multiple components of the IT infrastructure to do any harm. That means that they leave footprints in several, perhaps unrelated places.
Maybe a single event in a firewall log won't raise any suspicion by itself, but -- taken together with other suspicious events -- it's easy to see that there's some skullduggery going on, and to raise the flag.
Now, obviously near-realtime correlation is better than coming back several weeks after the fact, so being able to process new events against historical ones in a timely fashion becomes important as well.
So now we've got a device that's taking perhaps hundreds of feeds from multiple security logs, storing them in a protected fashion, and doing real-time correlation across multiple feed types looking for suspicious behavior.
And Then There's The Audit
Yeah. The audit.
Because it's not enough to say that you've got all this cool security technology doing realtime correlation on multiple logs, you've got to be able to prove that it's working effectively.
And, ideally, you'd like tools and capabilities that automates -- to the greatest extent possible -- routinely passing audits by an extenral entity.
That's EMC enVision
I've just described a few of the core features of enVision, one of those very-cool-but-not-widely-understood EMC products.
Right after EMC acquired RSA, RSA turned around and acquired Network Intelligence, which now is sold as enVision. We were going through a rapid acquisition phase, and many of us were so dazzled with all the new capabilities, it took some of us a while to realize how important some of this stuff was in the bigger scheme of things.
And, because of hybridization of various EMC technologies, enVision is taking on a few key capabilities found elsewhere in the EMC portfolio.
The first is storage. Yes, that boring rotating rust stuff.
You see, in even moderate environments, there can be a *lot* of log information. Part of it has performance requirements (think CLARiiON). Lots and lots of it has to be kept aorund in a prove-it-hasn't-changed format (think Centera). And access control to the storage itself is part of the security story.
Now, not to scare anyone, but it wouldn't be out of the question for a large site who's particularly security concious to end up with 10-50TB of storage over time, just for this purpose. Customers start much smaller, but -- like everything else -- things tend to grow over time.
The second is real-time discovery of IT infrastructure.
I've written before about Smarts ADM, and its ability to suss out new or changed elements in a large IT infrastructure without using agents. Lots of use cases for this, but in this specific context, an addition or change to an IT component is, by defintion, a security event.
Wasn't This All About Service Providers?
Sorry about that, but I had to provide a bit of background.
Now, imagine you're a customer, and you've realized that you need to have this sort of capability.
I like to joke that the sales cycle for enVision boils down to three question:
1 -- do you produce security logs? Usual answer is "yes".
2 -- are you keeping them? Usual answer is "no".
3 -- is anyone looking at them? usual answer is "no".
And, for the fourth optional question, do you think this is a good situation?
So, sooner or later, I think that most larger IT groups will realize they need to do something in this area.
As far as IT projects go, an enVision deployment isn't that challenging. There's no deep integration with existing stuff (it just captures logs using standard interfaces). The initial deployment isn't all that expensive in the big scheme of things. And taking an IT adminstrator who's already security-oriented and getting them ramped up on enVision is not a hard stretch.
But let's step back a moment.
In the financial accounting world, there's two types of audits: internal and external. Trust me, if it's an important issue, the external audit carries much more weight.
Well. one way of looking at an enVision deployment is an audit of existing security monitoring capabilities.
Which is better, internal or external? Especially if it's an Important Issue.
So, here's the bet: in addition to the usual "it's better/faster/cheaper to use a service provider" argument, there's a new one -- just like you use an external auditor for financial security, you're going to want an external auditor for information security.
In the accounting world, there's clear history that internal process and procedure can be compromised, usually with unpleasant results. Why would we think that IT is any different?
So, Where Are We?
The enVision product is already out there. Lots of customers, big and and not-so-big. Sales increasing at a very healthy clip. Other vendors are starting to spot the opportiunity, but I think we've got a very healthy lead. And, most importantly, there's a robust roadmap that supports new feature and functionality, which means more good stuff comming.
But I've seen interest from two directions.
First, from customers who have looked at enVision, and asked the question if they can buy it as a service, rather than a product.
And second from discussions with many of EMC service provider partners, always on the lookout for a new offering to put in their portfolio.
The question in my mind isn't whether the two will meet, but when?
Comments