By Matt Fisher, General Counsel, Carium
Twitter: @matt_r_fisher
Twitter: @cariumcares
Host of Healthcare de Jure – #HCdeJure
A common area of HIPAA that receives a lot of attention by organization is the Security Rule. The focus is driven by the requirement to implement various policies, procedures, and processes to secure the protected health information in each organization’s possession. Too often the compliance can take the form of just checking boxes ad not thinking about the impact of each element.
The HIPAA Security Rule
As a quick recap (which hopefully is not really necessary), the HIPAA Security Rule can be viewed broken down along a few different lines. First, the various components of the rule are identified as required or addressable. The required components (as should be self-evident) must be followed and implemented as laid out in the Security Rule. An example of a required element is the obligation to conduct a risk analysis. A risk analysis must occur because the results of the risk analysis inform how to implement the rest of the requirements set forth in the Security Rule. Not collecting the information from conducting the “accurate and thorough assessment of the potential risks and vulnerabilities” (45 C.F.R. § 164.308(a)(1)(ii)(A)) to an organization’s systems likely means that any measures implemented are just a guess (hopefully a best guess), but not necessarily ones that address the actual issues that the particular organization is facing. The other components are addressable ones, which means an organization can flex those requirements to meet the actual issues facing that organization. Again, that is where the required risk analysis comes in because it provides a basis for how to approach an addressable element. Importantly, addressable does not mean optional.
The second division contained in the Security Rule is to break the requirements down into three main categories of safeguards: administrative, physical, and technical. The high level categorization provides some insight into what each area covers. The administrative components looks to overseeing operations, both systems and people. The physical components look to the physical environment where an organizations operates (which requirements seem to become less applicable the more cloud-based or remote that an organization becomes). Finally, the technical components go to access to systems and baseline processes such as usernames and passwords. The three categories are broadly meant to establish the basis by which an organization can begin to become secure.
A couple of important aspects of the Security Rule to keep in mind though are that it is not overly prescriptive in terms of how to implement the security controls and that it is flexible. By not tying the rule to specific means of implementation, the rule arguably becomes a bit more future proofed because it does not present just a snapshot in time of what would be considered good security measures from when the rule was promulgated. There is an inherent recognition that best security practices should and need to change over time, which could not happen if compliance were stuck to outdated requirements.
The lack of prescriptive requirements is also evident in the flexibility and scalability contained with the rule. The rule itself discusses this benefit in saying:
(b) Flexibility of approach.
(1) Covered entities and business associates may use any security measures that allow the covered entity or business associate to reasonably and appropriately implement the standards and implementation specifications as specified in [the Security Rule].
45 C.F.R. § 1664.306((b)(1)
That inherent recognition that different organizations will need to implement the Security Rule differently is an important aspect of the rule. At the same time, it is also a primary clue as to why the Security Rule in and of itself does not translate to fully securing data.
Where to Go with Security
The best way to think about the HIPAA Security Rule is that is establishes a solid foundation upon which even better security can be built. Demonstrating compliance with HIPAA requires having certain written policies and procedures in place, but those measures should really only be the start of a security plan. Support for this perspective can be found in common understanding among security developers as current security best practices are well above and beyond what HIPAA sets out. As suggested above, that reality is driven to a large degree by the lack of specifics set out in HIPAA. It would be dangerous for regulators to attempt to impose specific requirements set to a specific point in time as attackers are constantly evolving and would likely be able to develop ways around exact requirements almost as soon as those requirements were identified. Instead, good security measures take the requirements set out in HIPAA and keep going up.
Additional support for the HIPAA as foundation perspective can be found in some of the third party certification programs that organizations will seek to provide assurance that data are secure. For example, HITRUST and SOC 2 will incorporate HIPAA to a large degree (partly because compliance is a must), but then look for controls that are more in-depth and demonstrate greater attention to detail. If the more expansive controls cannot be demonstrated, then those certification programs would find it difficult to determine that data are truly secure.
Lastly, the ever evolving standards and guidance from the National Institute of Standards and Technology (NIST) is another indication of the need to go beyond HIPAA. In fact, there are many instances of crosswalking between NIST standards for security and/or cybersecurity and the obligations required under HIPAA. The purpose of the crosswalks is to show where meeting the more comprehensive NIST standards also check the boxes for HIPAA. The key part though is that the NIST standards are more comprehensive and get more into the exact details of solid security practices.
The greater specificity and exactitude of the security focused guidances and certifications all lend support for the view that HIPAA is only a foundation. Getting to that understanding sooner will help drive better security practices and implementation of measures to lock down data more quickly.
In It Together
Beyond implementing protections and measures called for by industry best practice standards, fostering an all for one approach to security will also prove beneficial. One aspect can be viewed as threat intelligence sharing, but ultimately most actions where a collective benefit is advanced will be good. Maintaining silos and hiding information hurts everyone because it delays when threats can be understood and identified.
Efforts have occurred in the past to grow threat intelligence sharing, but have not necessarily become widespread or well adopted. If that can change, then it may be possible to reduce the success rate of various attacks and/or stop certain attack vectors. Promoting how sharing can benefit all can play a part in changing perspectives. Additionally, if it is understood that an attack will happen sooner or later, then the stigma of not wanting to admit to something may also be removed.
Ultimately, security is an ever moving target and effort. If any organization attempts to rest on its laurels at any point, it will likely find itself on the wrong side of an incident fairly quickly. The ongoing efforts can be tiring, but preventing attack or making it harder to for an attack to get through can all be good rewards to emphasize to justify the effort.
This article was originally published on The Pulse blog and is republished here with permission.