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
[RFID], etc.) can complement other security measures and compensate for lack of controls on devices such as printers/copiers, modalities, etc. In some cases, such as with legacy printers/copiers, physical security may be the only reasonable means of security. Compliance officers should be reviewing facility security plans specifically for the level of integration between physical and technical security measures around information technology.
Step 6: Encryption
By now you should have discerned that I recommend minimizing the use of encryption. I’d much prefer to eliminate the risk than to have to encrypt. First and foremost, this is because encryption relies on other measures and user behavior to be successful. Also, the operational impacts, user workflow issues, maintenance, and administrative requirements and costs can be significant. Also, remember that encryption that meets HITECH is standards-based, and as standards are updated and methodologies/algorithms change, organizations will have to refresh their solutions. Encryption does play an important role in the overall solution when used as part of an integrated security architecture.
Consider encryption in circumstances where risk to PHI cannot be reasonably eliminated, encrypt mobile devices with PHI regardless of other measures deployed, and encrypt data in motion. Last, but not least, encryption is required to meet the safe harbor if a breach occurs, so it should be considered wherever risk to patient information remains.
Step 7: Neighborhood watch
Everyone knows intuitively that security is heightened when everyone pays attention to what’s going on around them. Even with the best security, bad things can happen, and information system risk is amplified by the number of people who have or seek to gain access. For that reason, we need ongoing risk management supported by real-time network and user monitoring. Because it may not be feasible to encrypt everything to achieve a safe harbor, we need to ensure that other controls and processes are being enforced and are effective. Fortunately, many of the technologies used to enable and enforce protections also offer monitoring capability. Take advantage of audit capabilities in DLP, network monitors, configuration managers, e-mail encryption appliances, vulnerability scanners, etc. Utilize log managers to monitor controls and user activities, and conduct independent process and controls audits to supplement audit technical controls. Developing this information system activity review capability is not only a HIPAA requirement, but it is critical to identifying areas where breach could occur and, therefore, for predicting where your controls need to focus on achieving safe harbor.
Step 8: Never forget people
They say the only secure computer is one that is disconnected, turned off, and at the bottom of the Marianna Trench. People are always a very important part of any security program (including safe harbor) and are usually the last line of defense. Because encryption relies on other measures to create a secure environment, what people do (whether they are helping to manage the system or are end users) will remain important. For all security measures requiring user interaction – not just encryption – there should be clear policies and procedures in use, and people should be trained on what to do if an incident occurs. User training should be customized, start at orientation, and be reinforced frequently. Activities should be openly monitored and, in the case of an event, needed sanctions should be clearly articulated and enforced. Most importantly, users need to understand the safe harbor requirements and the importance of immediately reporting any incident involving PHI. The better they understand the safe harbor plan, the better they will support it.
Step 9: Transference
There will always be some residual risk, and organizations may elect to share or transfer some risk. Outsourcing may provide a viable alternative that enhances security and serves to share risk. Whether it’s taking advantage of software as a service (SaaS) or an application service provider (ASP) service, or moving to the “cloud,” organizations can take advantage of vendors’ security controls to augment their own. However, Business Associate Agreement security considerations are very important in any such decision. Business associates have proven that they are not immune to incidents, so vet vendors carefully, provide a security checklist, interview or even make a site visit if possible, and articulate security requirements in detail. Having security requirements addressed up front as part of the contracting process will help ensure success. Absolutely review all plans for encryption of data in transfer and at the vendors location.
The last consideration of a best practice program that can have a bearing on safe harbor is cyber insurance to address not only the residual risk, but protect against the costs of a breach. Many organizations see this as a reasonable precaution, and following these steps to incorporate a safe harbor strategy in your security program will position you favorably to satisfy most cyber insurance underwriting requirements.
HIPAA and HITECH are about managing information responsibly, and organizations can employ “any” security measure that reasonably safeguards patient information. To be most effective, a security strategy should include encryption as one element of an integrated approach that “uses” all reasonable and appropriate safeguards to manage risk and meet a safe harbor, if needed. Sixty percent of breaches in health care last year involved data that was unencrypted, and many organizations had no idea what was on those devices. More importantly, though, there were no policies or controls to assess the appropriateness of the data being placed there or to enforce restrictions.
Safe harbor is an opportunity to reconsider our data security strategy as a whole. It emphasizes breach, encryption, and notification, but the smart approach is to focus on real protection of data with the understanding that security controls and technologies, if deployed properly, can provide overlapping and complementary effects that can address multiple HIPAA/HITECH requirements and reduce the need for a safe harbor.
The following are some suggested questions that the Compliance department can ask to assess their organization’s readiness around a safe harbor strategy. Although not all-inclusive, answers to these questions will allow you to ascertain not only what the organization is doing, but also how they are approaching the safe harbor requirements.
- Where do we have systems where vulnerabilities cannot be addressed adequately?
- What compensating measures does IT propose to mitigate this risk?
- How do we monitor outbound transmissions for inappropriate content?
- Have all systems/data sources and their locations that require physical controls been identified?
- Have alarm and monitoring requirements been determined?
- Does the HIPAA Facility Security Plan reflect accommodation of these requirements?
- Have departments/management/staff been made aware of heightened need for accountability/observance?
- Has IT identified all systems with embedded encryption that do not meet the National Institute of Standards and Technology (NIST) standards?
- Has IT determined which systems require encryption?
- Has IT ensured appropriate encryption on wireless and web-based systems?
- Have users been made aware of their responsibilities and risks with encryption?
- Has a long-term plan been developed for compliance and maintenance of encryption controls?
- Does IT/Security monitor all systems with PHI?
- Is there an audit strategy to periodically review effectiveness of controls?
- Are incidents and anomalous behavior investigated in a timely manner?
- Is evidence of tampering or willful disabling of controls reported?
- Are processes and procedures associated with controls easy to understand and follow?
- Have users been trained properly on both the technology and the processes they must employ?
- Is there a data life-cycle model?
- Have we discovered/mapped where PHI is within the enterprise?
- Have we determined where PHI “needs” to be accessible and how?
- How do we utilize the IT architecture to isolate critical assets, networks, and data?
- Do we use application firewalls and/or access control lists to create true segmentation?
- Do we deploy network access controls to avoid unauthorized connections?
- Do we conduct ongoing vulnerability analysis and remediate issues?
- How does IT verify and ensure that policies/settings are enforced?
- How does IT ensure that actions involving PHI are appropriate?
- How does IT handle ongoing integrity review?