Data Loss Prevention — Who owns what?

Having endpoint data loss prevention (DLP) capability has become an essential part of any information security strategy. Being able to prevent company and customer data on desktops, laptops and other electronic devices is essential. Any firm without a data loss strategy risks dampening consumer confidence, fines from regulators and overall embarrassment within the industry.

Having effective endpoint DLP is not as easy as calling up a vendor, writing a check, putting the product in the data center and handing DLP over to Chuck aka “the DLP guy”. An effective effort will have several stakeholders, optimally several teams, working together to ensure that the right policies are created, tested and deployed in a manner minimizes data loss while ensuring the business can do their job. Because if your DLP solution interrupts the business, the business will let you know.

Data Loss Prevention Governance

Management is going things right. Governance is doing the right things — Peter Drucker

A company can have the most effective and refined DLP policies in place, but if all your policies do is block Java source code — and you happen to be a health insurance company — there’s good a chance you have poor DLP governance.

There needs to be an entity in any security organization that drives direction. This direction will be determined by the organization’s business requirements (e.g. Protection of source code), regulatory requirements (e.g. HIPAA) and contractual requirements (e.g. PCI). If the organization is on the small size, it can be one or two people.

Regardless of the makeup, the group is tasked with developing and communicating the requirements. These requirements should be specify the details of the DLP policy and to whom in the organization it should apply. There should also be additional communication about the risks of implementing the DLP policy. This will give technical teams additional insight and possibly prevent errors and business disruption down the road. This guidance should be presented in a clear and professional manner. A short hand-off meeting may also be a good idea ensure requirements, risks and timelines are understood and agreed upon.

The DLP Test Environment

Once the requirements are fully understood, it is time for the policy to be created in the DLP software. Should this be done “on the fly” in production? Of course not. This means a test environment for endpoints must be in place.

Mature organizations usually have a test environment set up for key systems. A test environment for desktops and laptops are often overlooked. The assumption may be that if a change or a patch has a negative effect on a PC, that device can be easily replaced. In practice, the risks are more complicated. Today’s business user may have a diverse set applications installed on their device. Most will be those sanctioned and approved by the technology group. Others will be open source or “shadow IT” apps. Whatever the makeup, any one of these tools can be affected any upgrade, patch update or DLP policy addition or modification. Without a test environment, your organization is at larger risk of a business disruption.

The endpoint test environment should represent the PCs and laptops currently in use throughout the enterprise. Consideration should be paid to what applications are in use. Optimally, all of the applications in use should represented in at least one machine in the test environment. This will lower the risk of a policy adversely affecting a business critical application. It may also be a good idea to have endpoints in this environment solely for the purpose of testing the functionality of the policy.

The use of this test environment will go far beyond the testing of DLP settings. With this in mind, the ownership of this environment should lie with the IT Infrastructure or End User Computing department. These area typically have more visibility into the technology in use throughout the company.

Policy Creation and Testing

At this point, you have a DLP test environment and detailed requirements from your security governance group. Time to create the policies and deploy them out to 3,000 endpoints before lunch, right? Not so fast.

While it is time to get into the nuts and bolts of policy creation, it’s important to do so in a manner that ensures the desired effect is achieved, while minimizing the risk of interrupting key business functions.

This is where the talents of the security architecture group become valuable. The security architects plan, build and implement the organization’s information security infrastructure. Members of this team typically have a broad technical knowledge base coupled with a security mindset. They have the ability to see security technology implementations through from concept to go-live.

Because of their skills and mindset, they are uniquely qualified to own this portion of the DLP lifecycle. In the policy creation and testing stage, the goal is to turn the data loss policy requirements received from the governance group into a working mechanism in the DLP tool. At the same time, considering what tweaks will cause false positives or negatives to rise and fall. What details of this implementation have the possibility of affecting a business process? These concerns are what makes the security architects the most qualified to serve in this role.

The goals of the policy creation and testing phase are clear: create the policy in the software that align to the requirements specifications while considering the risks and consequences of deployment to in scope endpoints. As with many processes, the goal is straightforward, while the implementation is hard work. Once the initial policy is created, the architecture team has to test it to ensure the desired effect is generated. For example, if the blocking of a combination of a social security number plus an American name is expected, one might try saving a text or MS Office with these attributes to a USB stick. What are the results with slightly different files, communication channels and data? Also, while making several attempts with slightly different files, what is the ratio of false positives to false negatives? The testing stage is the only on in which you have the opportunity to experience false negatives. After deployment, they’re largely invisible.

Once a DLP policy is created with a desired effect that is within a tolerance that management is comfortable with, it may be tempting to deploy it out to the enterprise and move on to the next challenge. Nope, not yet. You have more testing to do. Especially in larger organizations, it’s close to impossible to predict how a policy is going to affect key systems and business processes. Organization have a wide assortment of business applications, both commercial off the shelf (COTS) and home grown. To mitigate the risk of the policies negatively affecting these business applications, they should be deployed in a preproduction environment. Typically, these endpoints will include a sampling of users, whose PCs should contain a good cross section of the enterprises applications. If the endpoints, systems and processes are adequately documented, Security Architecture will be better suited to respond to issues and adjust the policies accordingly and, if needed, engage the vendor for assistance.

Ready to deploy, Captain

You’ve shown the policies will have the desired effect. You’ve tested it on a variety of endpoints containing a diverse collection of enterprise apps. You’re ready to deploy. How’s tomorrow at 10am sound? Don’t even think about it. Two words: change control.

Remember, you’re making a change to production systems. Instead of the payroll system, it’s the laptop of Mary in Accounting or Jeff in Marketing. To them, those are mission critical. As security professionals we need to mindful of the importance these endpoints are in the work life of end users. With that in mind, following proper change control practices are a must.

A good change control process asks the following questions:

• Why is this change needed?
• What are the risks of this change?
• How will you know the change was successful?
• How will the change be tested?
• How will the change be backed out, if needed?

Long story short, good a change control process allows for admins to be ready for the unintended consequences of a change. This is especially true for DLP changes pushed to multiple endpoints. One minor change could disrupt key functionality is a critical system for used by the business.

Endpoint data loss prevention is a powerful tool that can be used to prevent sensitive data from leaving an organization’s secure environment. Along with other data loss prevention mechanisms, such as cloud and network DLP, endpoint DLP provides assurance that information security security policies and standards are being followed. Without properly define roles, responsibilities and processes, organization may experience delays in policy implementation and unnecessary business interruption.