Implement Principle of Least Privilege for HIPAAAnirban Banerjee
Hello again! HIPAA, one of the most commonly mentioned compliance regimes (in addition to many others like PCI, SOC I,II , FISMA, FedRamp) is based on some core principles that aim to protect the data your company is transacting back and forth internally or externally. These core principles are tied into an easy to understand construct: The principle of least privilege (POLP). Even though it makes good sense and its easy to say – Duh! of course – we get it, there is something that makes life just a bit thorny.
The thorn I speak of is the balancing act between letting employees fulfill their duties and the requirements for compliance. Your company needs to ensure adherence to various rules and regulations to stay within the compliance boundaries for your IT infrastructure. This is a real world issue. You don’t think so? try the following exercise: Send an email to 25 people (randomly selected) and tell them that beginning next week you are implementing a token based 2 Factor verification system for anyone to access email. Solicit their advice on what they think of this direction. Wait and see the responses that come back – especially – from the non IT group. Its not that people are actively opposed to security but because they have been constantly exposed to security measures that often act as roadblocks and not enablers is why they often push back as a gut reaction.
At some point of time you have to realize that a balance needs to be maintained. Easy user experience for a security product and the power to do your job effectively are not one versus the other type of choice. This is most important when we talk about administrative accounts.
Administrative Accounts, also known as privileged user accounts, or super user accounts are a fact of life in most organizations. These accounts, provisioned on SaaS services and servers help your employees perform critical tasks on a daily basis. Quoting (take your pick) Voltaire or Spiderman – With great power comes great responsibility – hence the abuse of these privileged accounts can have far reaching consequences and be extremely debilitating to the survival and successful operation of a business.
Administrative accounts are present on SaaS services and Servers. In fact, often times SaaS services only have one type of role – users – everyone gets a level playing field. Other times there are just too many roles to make sense of what is going on. In either case it makes good sense to understand if there is alignment between your company’s needs and what the application or server offers to you.
A typical example of a privileged account on a SaaS app would be “administrative rights” on Office 365. On servers it could be similar to being able to run “sudo” commands.
What is the relation with HIPAA
Within the HIPAA guidelines a quick look at section 45 CFR 164, will provide insight into what requirements need to be satisfied for IT infrastructure. This portion talks about the integrity, availability, and privacy of ePHI. Additionally it provides information about auditing access to systems that contain ePHI data. Here are some condensed nuggets of information:
(1) Integrity of ePHI Data—45 CFR 164.312(c)(1), (2), & (e)(2)(i). Controls must be put in place to erify legitimate changes to ePHI data until it is safely destroyed.
(2) Availability of ePHI Data—45 CFR 164.308(a)(7)(ii). There needs to be documented polcies and procedures about making available copies of ePHI data. There must also be a way to recover information from a loss.
(3) Authentication to ePHI Data Systems—45 CFR 164.312(d). There must be a way to verify the identity of a person attempting to gain access to any system contaning or handling ePHI data.
(4) Access Control in ePHI Data Systems—45 CFR 164.312(a)(1), (2), & (3). There needs to be in place a procedure so that inactive sessions are killed off, every user or device accessing ePHI data has a unique ID and there are strict access control requirements in place.
(5) Audit of ePHI Data Systems—45 CFR 164.308(a)(5)(ii)(c) & 164.312(b). Controls need to be in place to not only monitor and report but also to audit access rights and actions taken when any device or person accesses ePHI data.
In most organizations these requirements cause a lot of pain for users and management. The primary cause being the friction caused by hastily putting in policies to just “conform”.
HIPAA and POLP
The goal of these regulations and guidelines is not only to protect data but also to make it recoverable from a loss, build in audit-ability and in general keep a tight leash on how sensitive data is being transferred and handled. In order to comply with some of the guidelines IT organizations must recognize that the envelope for privileges is fluid. It is rarely the case where once privileges are set they never get modified. This actually exacerbates the tension between IT, GRC and users. By lieu of the constant need to give and take away access it leads to a lot of overhead for groups inside the organization.
The POLP is not a new concept. It is as old as human history. However, the DoD came out with a formal definition for POLP in standard # 5200.28 in 1985.The POLP “requires that each subject in a system be granted the most restrictive set of privileges…needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use.”
HIPAA and POLP are perfectly aligned. The guidelines and the concept go hand in hand. The question is how to manage this happy coexistence so that it does not turn into a nightmare.
Happily implementing POLP for HIPAA
Lets us acknowledge that POLP is more than simply eliminating administrator rights.
The privileges that any person should have can be based upon various factors. Parameters like seniority, business unit, reason for access, time of day, device based and much more. You can implement POLP at a fine granular level so that the flexibility to modify and adapt is easily present. You do not have to outright ban all administrative privileges, nor do you have to take drastic measures. The goal should be to build and operate a system that allows you to grant and revoke privileges as and when needed.
Here are some rules of thumb that help comply with HIPAA POLP:
(A) Focus on making sure that the SaaS service or servers you are using do provide enough granularity that is necessary for you build out your own Role Based Access Control.
(B) Acknowledge and understand that Access control and Privilege Management are different. You can provide access to an application but can you tightly control which button they can click on the SaaS application, or which form a certain employee group can fill out or a piece of text/PII someone can see? If the answer is no, you should implement a PAM solution that can help manage SaaS applications in addition to servers.
(C) Implement easy 2 factor authentication like geofencing, geoproximity, fingerprint sensing instead of SMS or apps on the phone that spit out random numbers.
(D) Make sure your tools allow you to do reporting and auditing easily. There’s no point in chasing solutions that make you spend time on doing the heavy lifting. Identify which solutions will do 90% of the work for you.
(E) Always, always, always provide user level access and escalate to admin level with time limits. There should never be a case to say – you are an admin on SaaS app X or server Y forever.
In this article we have talked about how POLP and HIPAA are tightly intertwined. The issues that often come up when addressing each other in the context of compliance are tricky and often difficult to reconcile. We hope that this article helps you in terms of formulating your HIPAA POLP strategy.