Remediation Strategies for Sensitive Data Discovery

In the past few years, sensitive data discovery - the ability to find sensitive data in structured and unstructured data stores (not legal eDiscovery!) - has become more advanced and more accessible.  Data Leak Prevention suites - the bulk of which have been snapped up by the big boys (Symantec, McAfee/Intel, RSA etc) - have extended their functionality to find sensitive data on servers.  The ability to find sensitive data is one thing - but without a solid remediation plan, many organizations fear that while sensitive data discovery is the right thing from a security perspective, their legal risk can increase if they know where it is but haven't protected it.

So now finding the data is a possibility, but what do you do with it once you've found it?  The fear of an large number of false positives, lack of context on how the data is actually being used, how to protect the data and how to prioritize the whole process if large amounts of data are discovered can be overwhelming.   I've been doing some research in this area and while there is a lot more underneath, here are some of the major findings of how to handle it.

Know that sensitive data discovery is a discrete event and use it to control chaos:  Sensitive data discovery is typically a scheduled process.  This allows you to take bite size chunks out of the problem.  Since it is a discrete event and not a continuous process, you can perform a scan on a limited set of servers, remediate the issues that were found, and then move on to the next group of servers.  Of course, scanning for sensitive data, while a discrete event, should never be a one time event.  Periodic scans of segments should be run at regular intervals.  That sensitive data creep can just keep on going!

Prioritize based on risk:  Sensitive data discovery tools will typically tell you the type, logical location, and amount of sensitive data found but that doesn't complete the risk picture.  If you find or expect to find a lot of it, remediating the risk to that data can look overwhelming.  Creating a risk-based procedure will go a long way to an organized remediation process.  This should depend on your environment, the types of data you collect and your risk and regulatory priorities.  This could mean prioritizing based on physical location (e.g. branch offices with weak physical security), on a specific regulated or high risk data type (e.g. credit card numbers), amount of sensitive data or based on the type of server (file shares prioritized over databases or vice versa).  If there are a number of factors that effect the priority, consider developing a scoring algorithm relative to your business.

Create a remediation plan:  A lot of companies can get stuck here because there isn't a uniform method to remediate the data you will find.  Some sensitive data files will require monitoring, while some will need encryption and access control, some will need to be removed and/or quarantined and some will require review to understand if the access is appropriate.   Understand the business needs of the servers before you scan them to ensure critical business processes aren't interrupted and know what types of remediation would be appropriate.  For example, if you find sensitive customer data in a file share that the business uses on a regular basis, monitoring access and creating management reports to ensure the access is appropriate is a good place to start in slowly locking it down based on business need.  If sensitive data is found in a physically insecure location - encrypting the information to protect it from physical theft is important.

If you run into too many false positives - take a step back: The types of data you are looking for may be too broad or the keywords may need to be tuned.  If trying to find all sensitive data is creating so many false positives that you can't pinpoint the real issue, its not going to do you any good.

In summary, while sensitive data discovery combined with remediation isn't an easy cut and dry process for a complex business, its definitely achievable if its done in an organized and prioritized approach.

HIPAA Business Associate Agreements in the Cloud - Necessary?

In my conversations with Healthcare CIOs and CISOs, the need to move to the cloud and the barriers to doing so are top of mind.  In cost-sensitive healthcare organizations, public cloud promises to allow them to provide better, more reliable services to their customers at a lower cost.  However, since HIPAA requires Business Associate (BA) agreements with entities that handle healthcare data and many cloud providers won't sign them due to legal risk, healthcare public cloud initiatives have been stalled.  With the relatively new HITECH Act data breach disclosure requirements and protected data definitions it contains, there may be an argument that in certain circumstances BA agreements are not required.

Let me start on the next section by saying I'm not an attorney (I don't even play one on TV) and am not giving legal advice. I just like logic, understand the regs, and think a good argument applies here.  If your public cloud efforts are stalled by business associate agreements and you meet the criteria below this is an argument you should have your attorney's evaluate.  I'd love to hear some feedback on what they think, so please let me know.

First, cloud is a nebulous term that means lots of different things - so let's define exactly what we're talking about.

In Software-as-a-Service (SaaS) public clouds, the vendor controls your data and need access to it in either plaintext or tokenized format so it can be processed by their application.  In this model, the only security controls you have are the ones they provide and manage plus your configuration of access controls for internal users within their application.    New cloud tokenization methods can also be helpful here, because sensitive data elements can be turned into process-ready non-sensitive data bits.  Luckily in healthcare there are many SaaS providers focused on the industry and its not as hard to get a business associate agreement signed with an EMR cloud provider.

Where the problem really comes in is Infrastructure-as-a-Service (IaaS) and some Platform-as-a-Service (PaaS) architectures.  These cloud providers are not healthcare specific and have large legal teams telling them to limit liability and not sign business associate agreements.  For these cloud services, there is a shared responsibility between the user and the provider to provide security.  The user owns the operating environment or storage format and the provider owns everything else.

So here's where the argument gets interesting.  Enter the HITECH Act.  The HITECH Act says that if information is encrypted (there is detail underneath this, but easy to comply with), it is considered protected and not a breach.  So, if the user were to put a cryptographic boundary - essentially encrypt the sensitive data - around the data before it went up into the cloud, is a Business Associate Agreement really required?  If a bad guy stole the data in that format it wouldn't even be considered a breach.  Let's take a look at a couple of scenarios:

Cloud Storage:  The Healthcare provider encrypts data and sends it up into the cloud in HITECH Act "protected" encrypted format.  The data remains encrypted until it is restored to production systems.  The data has been protected by the letter of the HITECH Act the entire time and even if stolen would not constitute a breach.  So is a Business Associate Agreement actually required if they do not have access to the plaintext data?

Operating Environments in the Cloud:  Your developers want to test an application or you want to move production systems into the cloud for better scalability and high availability at a lower cost.  In this case, you control the security of the operating environment and most of the data security.  You construct a strong HIPAA compliant image - with a hardened operating system, system security components such as anti-virus and HIPS, and encrypt your data files before you send them to the cloud.  Your data is encrypted in storage, even as the storage is replicated.  The only time your data is in the clear is while it is being processed by your HIPAA compliant operating environment as long as the cloud architecture doesn't write memory to a file.  There may be a slightly weaker argument for foregoing a BA agreement here - but still a strong one that may hold - especially if you can detect intrusions in relation to the operating environment.

Hopefully in the near future, stronger guidance will be developed to formally address this issue and support healthcare in lowering costs and providing better services through the public cloud.  In the meantime, there are interesting conversations to be had!

Cliff Diving

Moving from always having had a full time job to independent consulting feels much like cliff diving - exciting and scary at the same time.  I've been overwhelmed with the support I've received from my family, friends and colleagues and thanks so much for all the good wishes and great referrals!

So, this post is the first step in my commitment to start blogging.  In the future I'll be sharing my thoughts on security, marketing, compliance, product strategy and other random musings here.  My website is going slower than expected but it will be up by Monday (note to self - get website done by Monday).   Have a great week!