Data Leakage: The Human End-Around to DLP

Posted on by Christopher Burgess

Binary_TunnelThe old adages "still water finds its own level" and "moving water finds a path of least resistance" both have applicability when we think of data leakage and employees' engagement with data loss prevention (DLP) processes, policies, procedures, and software. With still water, data is at rest; with moving water, your data in transit. There are also two types of employees: Those who are trying to do the right thing each time they touch your data, and those who have more malevolent intentions.

The latter is perhaps best exemplified by former National Security Agency (NSA) independent contractor, Edward Snowden. Snowden stated in June 2013 during an interview with the South China Morning Post that he had sought the position with NSA contractor Booz Allen Hamilton specifically with the intent to collect, remove, and expose data about the NSA's programs. These types of individuals exist, with more regularity than you may think, and are a prime rationale for having a formal DLP program at many companies. These individuals know and understand that they are breaking their trusted access to protected information, as opposed to the well-meaning employee who, trying to do the right thing, ends up doing it at odds with existing DLP process, finding that it is the path of least resistance. Take the case of the City of Milwaukee, which recently discovered city employees' (and their families') personal identifying data was placed at risk when an employee of a city vendor, Dynacare, copied personal identifying information (PII) to a USB stick and placed it in her purse. The purse was then stolen from the Dynacare employee's vehicle. It is doubtful the Dynacare employee had copied the data to the USB stick with the intent of having it stolen—no doubt the copy was made for another reason—but the end result is the same as if she had taken the PII of the city employees and published it in the Milwaukee Journal Sentinel. Data leakage occurred, and the information is lost.

It is necessary to protect against both intentional and unintentional data losses. The first step must be to verify where your data is at rest and if it's stored where it should be on the company network and devices. That is to say, is the data being stored in accordance with the information security policies and the regulatory and compliance requirements? It matters not what sector or business, if you don't know where your data is, you will not be able to determine if it is lifted or lost.

The next step is to detail who has access to the data. Smaller companies as a norm have broader access controls, given the many hats worn by the limited number of employees as compared to larger companies, whose employee's roles are more segregated. Access control lists (ACL) have been used for many years as a means to ensure access to sensitive data is restricted to those with a need to know in order to perform their job functions, otherwise known as the "principle of least privileged" access. Are the ACLs actually used to restrict access? Is there a means to discover if the authorized user is placing the data in an unauthorized locale or otherwise retaining or sharing the information?

Once you know where your data is stored and who has access to the data, enabling DLP programs will go a long way to serving any compliance or regulatory requirements, and it will also provide an opportunity to create workable information security policies designed to enhance, rather than restrict, business success. The responsibility for data protection is not restricted to the IT team—it is every employee's responsibility—and policies and procedures must be crafted appropriately.

Christopher Burgess

, Prevendra Inc.


risk management data security identity management & governance

Blogs posted to the website are intended for educational purposes only and do not replace independent professional judgment. Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA Conference™, or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.

Share With Your Community

Related Blogs