HCCA, Compliance Today
May 2011, v13 No. 5, p 51
by Mac McMillan
In 2011, organizations have begun attestations for Meaningful Use of electronic health records, which will include a statement that they have assessed risks and remediated gaps in their security. As part of this process, they must address incident response, encryption, access controls, auditing, and more as part of making sure they are ready to demonstrate compliance and meaningful use. Despite these efforts, eliminating risk completely will continue to be impossible. Incidents will occur, and when they do, organizations will need to demonstrate that they took reasonable actions to minimize risk.
HIPAA requires that organizations take reasonable precautions to secure protected health information (PHI) from unauthorized access, use, or disclosure. It requires administrative, physical, and technical controls where appropriate, with flexibility in selecting controls and designing programs. The Breach Notification Rule provides requirements for notification, defines what constitutes unsecured PHI, and identifies specific requirements for achieving a safe harbor from breach notification, including rendering PHI inaccessible, unreadable, or indiscernible.
It is important to remember that encryption is just one method of achieving this goal, and that any measures that reasonably and appropriately implement safeguards are permitted. The Breach Notification Rule neither modifies responsibilities under the HIPAA Security Rules, nor imposes new requirements to encrypt “all” PHI. For compliance officers, this means looking beyond encryption, and any effective safe harbor strategy should include encryption as just one element of an integrated approach.
Truly effective or “in depth” security involves a compensating, overlapping, and complementary set of controls, often described as “security in depth.” No one control is foolproof, and this is particularly true with encryption. Encryption is not possible everywhere on every system in an organization’s environment, so any strategy based on encryption alone will have gaps. Encryption relies on other controls and network integrity to make it effective, and systems compromised by poor patching can obviate encryption. It also does not address appropriateness of action, so it can only partially meet the requirement to disclose only the “minimum necessary” amount of information to perform the task. For example, an encrypted thumb drive ensures physical protection, but not whether the data should be there in the first place.
The Breach Notification Rule does provide a safe harbor when a breach occurs. If it is determined that patient information was encrypted appropriately using an approved methodology, the organization avoids notification. Organizations will want to incorporate encryption with other best practice controls to ensure patient privacy is protected adequately.
Taking your strategy apart
Step 1: Think “information first”
Ask yourself if your organization has adequately assessed its risks. Have you conducted a thorough data discovery project to identify exactly where all PHI resides and where it is going? Before you apply encryption or any control measure, first ask whether it is necessary and appropriate for PHI to reside in a particular location or be transmitted via a certain mechanism. The most effective way to do this is to employ a data discovery tool that searches structured and unstructured data and reviews network traffic content to more effectively inform control selection. Compliance officers should ask how their organization has developed their risk baseline and what that PHI map looks like, to know what to assess next. When you think “safe harbor,” think about authorization, accessibility, acquisition, and use – not just encryption. If data can be rendered inaccessible, then encryption may not be needed. If we can restrict locations where PHI resides, then other areas may require less stringent controls. Compliance officers should ask what we have done to reduce the risk profile and therefore, the need for encryption.
tep 2: How strong is your house?
One of the best ways to restrict accessibility is to “architect” it into how you build and manage the network. Traditionally, most networks were “flat,” meaning you could go from any point to any other point, and every asset on the network was at risk if any element was compromised. Today, we reduce that risk through architectural design and controls that create secure areas within the network through segmentation and access restrictions, which can mitigate the need for encrypting data at rest. Compliance officers should assess how segmentation has been used to protect critical assets, separate networks of differing access levels, and isolate vulnerable systems.
Step 3: Cleaning up the clutter
Once we know what we have (i.e., PHI) and have limited access architecturally, we need to look at the universe of systems and devices where data resides and how each is secured. These can include applications, databases, storage, backup tapes, shares, USB/CD, websites, desktops, laptops, personal devices, printers/copiers, e-mail, file transfers, and social media. Options for securing each of these are many, and all should be considered with a focus on eliminating, restricting, or controlling access.
In many instances, this will come down to configuration, but the process can include virtualization of systems, using group policies to control actions or lock systems, and disabling/enabling services or functionality. Compliance officers need to ensure that each asset/device with PHI in the enterprise has been identified and considered. Ideally, measures that eliminate the risk of exposure are best, and where exposure cannot be eliminated, encryption should be considered. Let’s look at a couple of examples.
Unfortunately, these assets are susceptible to theft and will be re-purposed or eliminated eventually. If we permit PHI on a desktop, we need to encrypt the asset. However, this does not address the whole of the problem. It protects for breach notification, but it does not, for instance, ensure that data (i.e., PHI) placed on the desktop is protected against destruction if the system fails. Why? Because data saved locally on a desktop is not backed up. The question to ask is: “Does PHI, or any data, need to reside there?” If not, then consider virtualization, using group policy to lock down the desktop, or deploying a data loss prevention (DLP) agent to restrict sensitive data from being saved locally. All of these eliminate the risk to PHI, but the last allows greater flexibility in how the desktop is configured and used. None require the addition of encryption or its overhead, but they effectively eliminate notification, thereby eliminating the need to exercise safe harbor.
These assets are almost always shared, and many have a processor that can store thousands of documents. Together, this creates an asset with potentially a lot of PHI that no one in particular is watching. To make matters worse, many older systems do not have automatic erase or encrypt functions, creating a physical security/accountability challenge. The only safe approach from a safe harbor perspective is to upgrade to newer systems with automatic overwrite, erase, and/or encryption capability when practical to do so. In the near term, for older systems placement, accountability, audit, and reuse/disposal processes need to be strictly followed.
Step 4: Shoring up controls
There is only so much an organization can do with architecture and organic controls. For remaining gaps, other technologies will need to be considered. Encryption is one of these, but again, we want to consider all options, and especially ones that create inaccessibility to the threat. These include other technologies that support, enable, or enforce features and eliminate or control access, configuration settings, actions, or behaviors. Examples of technologies in this category include:
- Configuration management tools for monitoring and enforcing settings.
- Host and network-based IPS for monitoring access to critical systems, such as integration engines and to provide early detection of threats and anomalous behavior, and forensics.
- Data loss prevention tools for data discovery/mapping, enforcing policies around PHI and assisting endpoint security.
- Vulnerability scanners for ongoing threat awareness and maintaining integrity.
Compliance officers need to appreciate that due to complexity of information technology environments today, manual processes and organic controls alone are not sufficient to ensure compliance. They should assess what technologies the organization has for protecting information and enabling safe harbor, if needed.
Step 5: Sometimes you need a fence
Sometimes, due to the nature of the system, operational environment, or threats, technology just isn’t enough. Physical security controls (e.g., alarms, access controls, cameras, radio-frequency identification