Jock thinks that the integration of DRM will make the user more conscious of the need to protect data. By exposing the features in office, and integrating it into the usual 'how-to' training instead of separate security training, this could become a de-facto way of getting users to look after their own security.

Now, this is something we want. The big problems with implementing a DLP solution, as I see it are:

• Understanding the context of a communication in order to make the correct security decision
• Building a workflow that the data owners manage, not security

Communication Context

The first point is where getting the users involved helps. To provide a round-about illustration; while running a DLP PoC I cam across several points where I did not know whether the incident discovered was a breach or a problem. Should the sender have access to that information, should the receiver, and how sensitive is the information in the first place. For example, we noticed communications about a confidential strategic project going to a Gmail account of someone who did not work for the company and was not obviously affiliated with anyone who knew about the project. To resolve it we needed to follow up and investigate. It turned out the information was going to lawyers who's mail servers were bouncing the mail.

Another incident showed a massive amount of credit card numbers going from a DBA to HR people at a competitor. Upon investigation it appeared that the DBA was sending his CV to the competitor, but had inadvertently attached a DB dump he had been using for debugging purposes.

Both of these incidents required additional context and understanding, which takes time and a soft-touch approach (you can't storm the board demanding to know why information was sent to an unknown gmail account). This is not something a small security team (as they all are) can practically deal with. You also can't hire junior lackeys to do it for you, because they'll have even less of an understanding of the context.

Users can Help

This is where Jock's point comes in, getting the users involved and more aware via the DRM functionality could help them embed some of that context as security principles. For example, if a document should only be shared between the board, then the PA typing it up can embed that assertion. Or more simply, if a document is final and you don't want any surreptitious changes to be made, you can mark it as final without relying on the idea that people can't modify a PDF.

While I think DRM functionality is great, and I am glad to seem the DLP vendors integrating it. I don't think this is going to help us with the communication context. In the first example with the gmail account, the criticality of the information would be no more obvious, and the person it was being sent to would be no less anonymous. In the second incident, the DBA would not be less prone to mistakes, and it is unlikely that DRM will be embedded in the debugging DB dump.

Data Owner Workflow

This is where the second point comes in. It is my belief that it isn't the users that will be able to help with DLP, but the data owners. While this is a fairly obvious statement, the few DLP implementations I have seen which consider the data owners at all is slim, and the number which try and get them involved in the DLP processes are near zero (although this is coloured by DLP not being a currently wildly deployed process). However, when you speak to some vendors and ask for information on these sorts of processes, they usually don't have it.

Funnily enough, I just read Allen's entry on this topic and it seems we are about to say the same thing.

What you need is to get the data owners involved. They need to be empowered to have the tool understand their critical data, and provide workflows around making decisions on what is being done with it, in line with the relevant communication context. Allen call's this 'business context' but I think 'business' is an abused term as is.

For example, if the minutes for the last board meetings are being mailed to an unknown external person, then get the COO's PA to approve it, and if necessary escalate it to the COO. If the DBA is sending credit card details to the competition, get the customer transaction guy to approve it, block and alert or escalate to someone else. This needs to be done careful and intelligently to prevent hours of wasted time while user's click the approve button on 30 e-mail each morning. It also needs corresponding processes up front, ideally built into the process of data creation, to have the principles defined.

This is where the DRM integration helps. Security assertions in line with the data owners approved use can be defined once and checked in both the DRM and DLP environments, but without the workflow components, this just becomes another firewall - blindly blocking with little understanding of what is encapsulated in the content.

For these purposes, I like Allen's differentiation between Generation 1 and Generation 2/3 type solutions.

Security Teams Benefit

With the above in mind, I don't think that security teams should be blindly ignoring the DLP solution's alerts. There is an awesome amount of information about what people and what data is actually being used and how, that can help security teams better approach some of the harder security problems. I am not advocating a 'thought police' approach as often happens with these sorts of technologies - creepy security people reading your e-mail and surfing habits so that they can stop all this awful non-productive behaviour (is that an mp3 I see?!). I mean actually getting an understanding of reality, and implementing solutions that take reality into account. But the price tag doesn't justify this being it's only use.