In Data loss prevention isnt a new idea, but its a concept thats become increasingly important to IT as organizations recognize the threat to their operations from leaks by disgruntled insiders or intrusions by hostile outsiders. At least, thats the pitch DLP (data-loss-prevention) vendors use.
But in most cases, notes Securosis analyst and CEO Rich Mogull, organizations that deploy DLP find data leaks are more likely to be caused by accident or by bad procedures rather than malice, As he explained in an interview with eWEEK, when the causes of leaks are explored, the whoops factor surfaces repeatedly. Someone transmits unencrypted medical data in violation of HIPAA (Health Insurance Portability and Accountability Act) rules, or a file containing credit card numbers is moved into an unsecured area. This sort of thing, when discovered during an audit, can be a career-killer; if it becomes a news story, its damaging to the reputation of the business itself.
Of course, that doesnt mean that companies not subject to regulatory regimessuch as HIPAA, Sarbanes-Oxley Act or otherscan simply pass on implementing DLP. As Mogull explained, the risk of data loss isnt always visible: When data is stolen, or merely mishandled, you dont even have the base monitoring to know about the problem.
How can an organization introduce DLP in an effective manner, when the potential for leakage or loss is so pervasive? Lets start with a conceptual discussion before moving on to specifics.
One can begin thinking about DLP by treating data as being in one or more states: data in motion, data at rest and data in use. But theres a danger in focusing on only one of these aspects, because methods that work exceedingly well on, say, the networkor data in motionmay be of little or no use against threats that seek to obtain data in use at an endpoint. A sound DLP strategy will consider all three of these against the needs of an organization, whether these are regulatory, operational or cultural. The poser, for both IT managers and security specialists, is that no single product adequately addresses all three categories.
Or if one chooses to look at DLP from another perspective, one can consider it from the standpoint of threat vectors. In this view, the tripods legs are email, the Web and the endpoint. Protecting against the first two is fairly well understood and easily implemented. The third is a little more complicated. Removable media can be blocked or screened, but the near-ubiquity of phone-based cameras makes it possible to record on-screen data, albeit in a clumsy and terribly obvious fashion.
The first step in implementing a DLP strategy is data identification. Although it may be easy to specify the general nature of the data to be protected, such as financial records, customer information or product plans, its not always that simple to assign a risk value to an individual document. Mogull points out that one has to understand what to protect.
Context + Content
Perhaps its best to regard the context of data, with its content, as two sides of a coin. Context can take the form of file metadata, email headers or the application thats consuming the data. In more complex forms of context analysis, a DLP process might look at file formats or network protocols, or use network information from a DHCP server and a directory service to identify whos consuming the data. This can be expanded to take specific Web services or network destinations into account or identify individual storage devices such as a USB drive.
Content, as one might think, is pretty self-explanatory. Being aware of the contents of data can often give one a good indication of what kind of protection needs to be applied. Analyzing content is where things get tricky, because one has to start with the context of data, and then examine the contents. This might take a rules-based approach using regular expressions, file matching, database fingerprinting or statistical analysis. This content awareness, as Securosis Mogull puts it, is what defines true DLP.
Further stages of DLP Implementation are where things can become complicated. For example, addressing DLP in email seems relatively straightforward, because of the nature of the medium. Many products that address other email security threats also offer some DLP functionalityin a fashion that Mogull refers to as DLP Lightand if one chooses to bring a dedicated system to insert another mail transfer agent that provides a DLP layer, its unlikely to be noticed by users. The downside to such a solution is that it may cover ones external email traffic well, but leave internal traffic unprotected.
A similar situation can be seen with network-based DLP. DLP products will often work with existing reverse proxy features of an Internet gateway to inspect SSL-encrypted traffic. In a recent report from Palo Alto Networks, sampled organizations in the United States showed that 20.7 percent of bandwidth consisted of SSL, on port 443 or other ports. The same traffic analysis showed that one or more implementations of the Tor onion router were running on 15 percent of survey networks worldwide. The most a DLP solution can do for such traffic is to flag it or block it altogether, without actually identifying what the traffic consists of.
In storage, Mogull and Securosis are observing less DLP Light but better integration, thanks in part to the ability to tap into databases and document management systems. Because of the nature of these systems, real-time DLP monitoring is often limited to filterlike techniquescategories, patterns and rulesbecause anything deeper can present an obstacle to achieving optimal system performance.
Whatever one chooses as part of a DLP strategy, its important to make sure that it offers a clean user interface and solid reporting tools. Although those may seem like obvious criteria, Mogull observed that DLP tools are sometimes so engineering-driven that their designers forget that the users of the tools who may not work in IT at allneed a simple and efficient way to address potential problems. After all, there will be occasions when an immediate response is needed, and the interface should be a help rather than a hindrance.
An area of DLP that isnt often discussed is what to do when data appears to have been leaked. All too often, these efforts, which are reactive by their very nature, take on the aspects of a witch hunt. These can often do more damage than the actual data loss, by virtue of their effect on the morale of the organization and its customers and partners. Thats why its important to keep Mogulls point about intent in mind, or to paraphrase a common saying, dont assume malice when simple carelessness will suffice.
One thing that should give DLP implementers hope, according to Mogull, is that the market is starting to mature, even as the technology remains ahead of adoption. Arguably, the hardest thing for IT and security managers to cope with today is making room in their budgets for tools that are appropriate for their organizations, whether thats viewed from a threat perspective or from the available skill sets within the company. Of course, thats one problem that almost never goes away. At least, until its too late.
Add new comment