Cloud DLP in Healthcare: Five Must-Do Strategies

The healthcare market is ripe for cloud access security broker (CASB) and cloud data loss prevention (cloud DLP) solutions. Between a major transition to online medical records, a transient and distributed professional user base, critical need for collaboration across providers, and sheer usefulness of mobile technology for healthcare use cases, cloud has grown into a major asset to healthcare organizations. Is has also become a major liability. Criminals pay top dollar for users’ protected healthcare information, and preventing a healthcare data breach or exposure of protected health information (PHI) is not easy. Netskope serves five of the top 10 hospital networks in the U.S., and sees up-close the demand and requirements for securing PHI and other kinds of regulated and sensitive data in the cloud.

As one of our solutions architects in Southern California, I serve a number of our healthcare customers, and have learned a great deal about how to get the most out of CASB to protect PHI in the cloud. Here are five must-do strategies I have seen work and recommend to our healthcare customers:

1. Map out your cloud DLP policies by violation, app type, user type, device classification, severity, and the action you will take if the policy is triggered. Here’s a simplified example of how you might lay this out:

Note that many of our customers simply remove the ability to perform certain activities in cloud apps or app categories for certain groups of users, such as “no sharing outside of the company if you’re an insider and it’s our quiet period.” Since they can do this by app category, AD group, device, location, etc., they can be granular and flexible. Removing even the possibility of triggering a DLP violation vastly reduces the surface area for potential violations, increasing detection accuracy.   

2. Go beyond regular expressions and be precise. Anybody who’s ever done battle with DLP software in years past (and lived to tell the tale!) knows that there’s a real art to accurately detecting sensitive data, and that there can be a lot of noisy false-positives if you don’t invest the time and effort to tune your policies. The good news is that in the cloud it gets much easier to tune. First, reduce the volume of potential DLP violations through fingerprinting and exact match techniques. If you know exactly what standard form or document you’re looking for, or similarly, if you have a standard block of text, you can start with it and be deterministic in your detections. From there, you can use boolean logic to precisely lay out what you’re looking for and in what format. For example, if you know that your organization’s medical records contain the hospital’s name, patient’s name, medical record number, and illness or injury within close proximity of each other, you can specify the following in a rule:

{Hospital Name} NEAR {Patient Name} NEAR {Medical Record Number} NEAR {Illness or Injury}

What if the above techniques don’t work because your medical records aren’t in a consistent format? One of the hospitals that uses Netskope has medical record numbers that range from 1-9 numbers and don’t contain letters. This makes things incredibly challenging! But rather than try to weed out the false positives (which is virtually impossible), they solved the problem by entering known patient first and last name pairs into our dictionary feature, shown below. This vastly reduced false positives and created an efficient process in identifying PHI in the cloud.

3. Use filtering techniques to cancel the noise. With an eye toward getting even more precise, you should use contextual factors to filter down to the highest-probability situations for a DLP violation to occur. Once you have your DLP rules and profiles built, you can combine these with contextual factors to create simple policies that accomplish this. See the right hand side of the policy screenshot below for sample contextual elements upon which you can filter, including user type (e.g., contractors), location (e.g., NOT in headquarters), device (e.g., Mac), app category (e.g., Business Intelligence), DLP profile (e.g., PHI), activity (e.g., upload), and more. That way, you can go from millions of potential violations to thousands or hundreds.  

And for those of you with an on-premises DLP solution that you’ve invested a great deal of time and effort to tune just right, you can get even more aggressive in your filtering strategy by conducting your first round of detections in the cloud and then shuttling back only the suspected violations to your existing solution via secure ICAP. That enables you to extend the usefulness of your on-premises solution while not choking it with all of the data in your cloud.

4. Prioritize DLP violations. Beyond using DLP profile precision and contextual filtering to increase detection accuracy, you should set severity thresholds by detection volume. For example, you may detect a thousand files containing PHI, but only three that contain the PHI of 50,000 users. Which violations would you tackle first if you couldn’t assign a severity level based on volume thresholds? Notice the default (but configurable) thresholds in the DLP rule wizard below. 

5. Coach users. It’s always a good idea to let users know why they’ve been blocked from a certain activity. Not only does this create transparency, but it helps to influence the right behavior. With a CASB solution, you can enforce a cloud DLP policy that includes an automated coaching message for users. That message can be configured to redirect a user to a sanctioned app (e.g., “You may not upload PHI to an unsanctioned Cloud Storage app, but you may upload it to our corporate-sanctioned Cloud Storage app, and here’s the link to sign up or log in”), enter a justification (e.g., “This attempted PHI upload is out of policy. If you have a legitimate reason for uploading it, write a short justification for our audit records”), or report a false positive (e.g., “This attempted upload of PHI is out of policy. If you believe this is a mistake and your file does not include PHI, please click here”).