Rational Survivability

If you haven’t been following Rich Mogull’s amazing writeup on how to "Understand and Select a DLP Data Leakage Prevention Solution" you’re missing one of the best combinatorial market studies, product dissection and consumer advice available on the topic from The Man who covered the space at Gartner.

Here’s a link to the latest episode (part 7!) that you can use to work backwards from.

This is not a knock on the enormous amount of work Rich has done to educate us all, in fact it’s probably one of the reasons he chose to write this opus magnum; this stuff is complicated which explains why we’re still having trouble solving this problem… 

If it takes 7 large blog posts and over 10,000 words to enable someone
to make a reasonably educated decision on how to consider approaching the purchase of one of these solutions, there are two possible reasons for this:

1. Rich is just a detail-oriented, anal-retentive ex-analyst who does a fantastic job of laying out everything you could ever want to know about this topic given his innate knowledge of the space, or
2. It’s a pie that ain’t quite baked.

I think the answer is "C – All of the above," and t’s absolutely
no wonder why this market feature has a cast of vendors who are
shopping themselves to the highest bidder faster that you can say
"TablusPortAuthorityOakelyOnigmaProvillaVontu."

Yesterday we saw the leader in this space (Vontu) finally submit to the giant Yellow Sausage Machine.

The sales cycle and adoption attach rate for this sort of product must
be excruciating if one must be subjected to the equivalent of the Old
Testament just to understand the definition and scope of the solution…as a consumer, I know I have a pain that needs amelioration in this category, but which one of these ointments is going to stop the itching?

I dig one of the first paragraphs in Part I which is probably the first clue we’re going to hit a slippery slope: 

The first problem in understanding DLP is figuring out what we’re
actually talking about. The following names are all being used to
describe the same market:

• Data Loss Prevention/Protection
• Data Leak Prevention/Protection
• Information Loss Prevention/Protection
• Information Leak Prevention/Protection
• Extrusion Prevention
• Content Monitoring and Filtering
• Content Monitoring and Protection

And I’m sure I’m missing a few. DLP seems the most common term, and
while I consider its life limited, I’ll generally use it for these
posts for simplicity. You can read more about how I think of this progression of solutions here.

So you’ve got that goin’ for ya… 😉

In the overall evolution of the solution landscape, I think that this iteration of the DLP/ILP/EP/CMF/CMP (!) solution sets raise the visibility of the need to make decisions on content in context and focus on information centricity (data-centric "security" for the technologists) instead  of the continued deployment of packet-filtering 5-tuple network colanders and host-based agent bloatscapes being foisted upon us.

More on the topic of Information Centricity and its relevance to Information Survivability soon.  I spent a fair amount of time talking about this as a source of disruptive innovation/technology during my keynote at the Information Security Decisions conference yesterday.

Great conversations were had afterwards with some *way* smart people on the topic, and I’m really excited to share them once I can digest the data and write it down.

/Hoff

(Image Credit: Stephen Montgomery)

Let’s hope the Windy City isn’t as windy as Beantown is thanks to that hurricane from the Carribean.  I’m digging the car out from under what leaves haven’t already fallen.  The forecast for Chicago showed <gasp!> snow on Tuesday.

I’ll be in Chicago Sunday-Monday, speaking at the TechTarget Information Security Decisions conference.

Ping  me: hoff [at] packetfilter.com or +1.978.631.0302

/Hoff

Back in August I wrote a post debating against the notion that SaaS vendors were apparently, by definition, "…able to secure assets better than customers." 

My position on the "quality" levels of security from SaaS vendors was reasonably straightforward.  I’ll summarize it here:

Not one to appear unclear on where I stand, I maintain that the SaaS
can bring utility, efficiency, cost effectiveness, enhanced
capabilities and improved service levels to a corporation depending
upon who, what, why, how, where and when the service is
deployed.  Sometimes it can bring a higher level of security to an
organization, but so can an armed squadron of pissed off armed Oompa
Loompa’s — it’s all a matter of perspective.
…
So just to be clear, I believe in SaaS.  I encourage its use if it
makes good business sense.  I don’t, however, agree that you will
automagically be *more* secure.  You maybe just *as* secure, but it
should be more cost-effective to deploy and manage.  There may very
well be cases (I can even think of some) where one could be more
or even less secure, but I’m not into generalizations.

This is all a matter of context; what sort of data is stored, what value does it hold, who can access it and what assessment of risk has been performed to determine the impact to the company should it fall into the wrong hands? 

Many times the "security" of the SaaS service comes right down to basic security practices such as access control.  For example, I’ve seen multiple times that SF.com login accounts of salesfolk that went to competitors were left enabled after separation, potentially exposing the forecast, pipeline, customer service records and customer details of the entire customer base.  That’s not the SaaS vendor’s fault, but is a potential issue systemic to the model.

As the adoption of SaaS increases driven by compliance, outsourcing, or efficiencies of a leveraged business model, we’re going to have to pay more attention to what it means to have our data spread out beyond those supposedly impenetrable perimeter boundaries we’ve spent all that time and money on.

Again, that means more than reviewing a SAS-70 or taking the vendor’s word that they are secure.  It means making sure your policies extend and are applicable "outside the castle."  It means potentially engaging a third party to test the assertions the company makes about their posture.

A great example are two recent debacles from SaaS vendors Salesforce.com and Monster.com. Brian Krebs from the Washington Post recently did a great job illustrating the issues that a breach from an SaaS vendor causes; there’s a "secondary market" for breach data and once the information is loose, the lost trust can mean lost business:

A database of e-mail addresses and other contact information stolen from business software provider Salesforce.com
is being used in an ongoing series of targeted e-mail attacks against
customers of several Salesforce.com business clients, including SunTrust and Automatic Data Processing Inc. (ADP), one of the nation’s largest payroll and tax services providers.
…
In August, job search giant Monster.com‘s resume
database was breached by hackers, exposing confidential data on 1.3
million job seekers. The attackers then used the contact information
from that database to send users targeted e-mails that appeared to come
from Monster.com. Recipients were directed to click on a link in the
message, which tried to install malicious software through Web browser
security vulnerabilities.

Salesforce.com and Monster.com provide valuable SaaS functions to corporations globally and it illustrates the fragile mantle of trust upon which we tread.  There exists a tenuous balance when outsourcing applications and information processing/storage to a third party.

Some folks argue that any information entrusted to a third party business partner or vendor (email addresses included) are "private" while others might suggest that if you’ve decided to outsource this function beyond the realm of your ability to protect it, any information outside the castle should be considered public and dealing with its exposure should be something you’re prepared for.

This comes down to a maintaining a posture of what I call Information Centricity and an appropriate level of information classification paired with the assessment of risk assuming something ‘bad’ happens to it.

As a free piece of advice to SaaS vendors and customers alike, comments like this are not a good way of handling the press regarding a breach:

Salesforce.com’s Bruce Francis, the company’s vice
president of corporate strategy, declined to say whether any
customer-specific data was stolen, and refused to answer direct
questions about the alleged incident, saying that doing so would not be
in the best interests of its customers. He did, however, stress several
times that "phishing is a fact of life for any company that does
business on the Internet these days."

/Hoff

Update:  Bill Brenner just did a nice write-up on this same topic and was kind enough to reference/quote me and the RS Blog.  You can read his piece here.  I also got some interesting feedback from Bob Warfield over at the SmoothSpan blog ( a fantastic SaaS reference) which I will ask if I can reprint.