What data is most important to protect?

I've read recent reports about a new function in DLP: the ability to learn what is important to protect. Can you explain this in more detail? How is it different from past offerings?

By Dr. Ratinder Paul Singh Ahuja

Today, data-leak prevention implementations have to undergo an elaborate pre-install checklist; infosec teams have to ask business stakeholders what their confidential data is, where can it reside, who is allowed to handle it, and when transmitting this data is a violation of a rule or policy.

For infosec teams this is a formidable task, as they do not work with the operations teams and have to go through a lot of trial and error to figure out what the right policies ought to be. In fact, this issue of not knowing when a certain flow or the location of certain information violates policy prevents vendors and buyers from effectively demonstrating the value of DLP.

This problem can be a major hindrance to the cost-effective deployment of DLP; what is needed is a technical solution that captures, classifies, and indexes information. Such a solution could be used to learn the normal flows of information and determine what might be violations-without going through an elaborate interview process.

To explain this further, imagine trying to construct a policy that protects "marketing strategy." In many cases, such information would flow to business partners, and this flow would not violate policy. But how does the infosec team know, without conducting time-consuming interviews or generating a lot of false positives, who the business partners are?

If the infosec team had some way to capture, index, and classify everything, it could quickly learn about the normal and outlier information flows. One way to do this would be to query the index for the information flows (DIM) or location (DAR); built-in analytics could generate summaries of senders, recipients' domains, locations, content, and protocols used, all in a matter of seconds. If the policy also wanted to look for "sales forecasts," another query into the index would obtain the results. Based on the summaries, infosec could construct rule parameters and quickly back-test them against the historic captured and indexed information. Compare this approach to letting a rule run for weeks, then refining some parameters and again running the rule to ascertain its effectiveness.