HIPAA Security Rule: 5 Common Shortcomings (Technical Safeguards)

Go beyond HIPAA’s language to achieve better security and compliance. Here’s how:

This is the third post in a three-part series on the HIPAA Security Rule. See Post 1 on Administrative Safeguards and Post 2 on Physical Safeguards.

In this post, we’ll take a look at some of the Technical Safeguards found under the HIPAA Security Rule and how merely sticking to the Rule’s language is simply not good enough. In other words, if you simply do what a particular safeguard says you are supposed to do—and nothing more—you’re setting yourself up for failure from both a security and compliance standpoint.

 

1. Neglecting Technical Safeguards for all ePHI Applications

Many healthcare organizations have one or two main systems that they utilize for ePHI purposes. A common example is a medical practice with an Electronic Health Record (EHR) or Electronic Medical Record (EMR). These are typically the organization’s “crown jewels” in terms of the amount of Electronic Protected Health Information (ePHI) they store.

But in addition to these “crown jewel” assets like EHRs or EMRs, there are usually several applications utilized by workforce members that store, transmit or otherwise use ePHI in some form or fashion; however, organizations often neglect to implement important technical safeguards for them. They fail to explore what options they have to safeguard these applications in terms of audit controls, password requirements, multi-factor authentication, role-based access controls, encryption, and so on.

Here are some applications that organizations commonly overlook:

• billing and accounting applications
• revenue cycle management applications
• customer relationship management solutions (CRMs)
• voice dictation applications

As recommended in Post 1, create an inventory of all your organization’s ePHI assets, including all applications (whether self-hosted or cloud-based). For each application, determine what technical safeguards should be in place and come up with a plan to implement them. Start with the applications that pose the highest risk first and then work your way down the list.

 

2. Failing to Enable and Properly Configure Audit Logs within Microsoft Office 365

Many healthcare organizations and business associates that use Microsoft Office 365 fail to take advantage of the security features it offers, including enabling and properly configuring audit logs.

Besides being a good security practice, having audit logs enabled within Office 365 can help with compliance objectives under Audit Controls (§ 164.312(b)), as well as Information System Activity Review (§ 164.308(a)(1)(ii)(D)) and Login Monitoring (§ 164.308(a)(5)(ii)(c)).

Having audit logs enabled can also be valuable from a forensics standpoint for investigating security incidents.

If your organization uses Office 365, be sure that audit logs are enabled and that relevant activity for each application is being recorded at an appropriate level of detail. You’ll also need to set up some configurations in terms of retention of logs, live-alerting for certain types of events, and more.

Be sure to check out this post written by Matt Durrin of LMG on securing Office 365.

3. Unclear Roles and Responsibilities of Managed Services Providers

Many organizations rely on managed services providers (MSPs) for the majority of their IT needs. Under these arrangements, however, it is sometimes unclear what roles and responsibilities MSPs have when it comes to security and compliance.

Organizations sometimes incorrectly assume that their MSP is handling certain security and compliance-related functions on their behalf. In some cases, this is due to the organization not addressing these issues with the MSP before the contract has been signed. In other cases, an MSP might represent it will carry out certain tasks but the organization has never actually taken the time to verify that they are.

If your organization uses an MSP, make sure you know what technical safeguards they have in place to help protect your ePHI. Consult your services agreement and set up a meeting to talk through these issues with your point-of-contact. Consider bringing in outside help to identify any security and compliance gaps, as well as how to best address them.

When we work with clients who have MSPs, we often find that the MSP can provide certain security-related services (e.g., performing vulnerability scans or setting up multi-factor authentication); however, they only do so if the client requests. That’s why it’s important to be proactive in asking about services and requesting them.

4. Insufficient Password Policies and other Authentication Methods

Our technical testing team at LMG routinely sees first-hand what can happen when an organization uses weak passwords and does not have multi-factor authentication in place. The result: they have a much easier time getting into a client’s network.

If your organization only requires passwords to be eight characters in length—and with no multi-factor authentication in place either—it’s time to rethink your approach.

We currently recommend clients prioritize password length over complexity requirements (16 characters for user accounts, and 25 characters for administrator and service accounts). We also strongly encourage the use of multi-factor authentication where possible. Additionally, account lockout policies should enforce a sufficiently long lockout duration.

 

5. No Periodic Technical Testing

Having periodic technical testing can be invaluable in terms of identifying and addressing flaws in an organization’s network. For a variety of reasons, though, organizations will sometimes put off conducting penetration tests, web application assessments, vulnerability scans, and other technical testing.

Technical testing can reveal any number of flaws that an attacker might try to take advantage of: misconfigurations, missing patches and updates, weak transmission security protocols, the use of weak passwords, and more

Be sure your organization conducts periodic technical testing. Even if your organization has certain tools or in-house personnel to perform certain testing, consider hiring an outside team like LMG to assist on occasion. An outside security team can bring unique perspective, along with other tools and methods, to help you identify vulnerabilities that you might not otherwise.

 

Conclusion

The list above includes common shortcomings we encounter when performing HIPAA assessments for clients. These shortcomings can exist even if the organization is abiding by the language found in the HIPAA Security Rule.

If your organization is subject to HIPAA, be aware of these shortcomings and consider the recommendations included above.

Have questions about HIPAA? Get in touch with LMG today