Database Encryption
Is it a HIPAA violation if data at rest in a database is not encrypted?
By: Robert Adams
Date: April 15, 2016
YES, it is a violation if data at rest in a database is not encrypted, even though a literal reading of the language of the Security Rule does not treat it as a requirement. However, for the below reasons, we must treat encryption as a requirement.
For data at rest, the Security Rule categories the encryption Implementation Specification as Addressable. According to the Health and Human Services (HHS), an Addressable Implementation Specification requires a covered entity to implement that specification if it is “reasonable and appropriate to do so …” Under this language, since encryption is Addressable, an organization must implement encryption if it determines that encryption is “reasonable and appropriate to do so.” To determine if encryption is reasonable and appropriate, HHS provides some guidance by saying “[t]his decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation.”
If an organization determines that encryption is unreasonable or inappropriate, the Office of Civil Rights (OCR) requires that the decision be documented in writing and include who made the decision, the factors that were considered and lead to the decision, and the risk assessment of those factors. During an audit, OCR will review the documentation and determine whether they agree with the decision that encryption was unreasonable or inappropriate in that organization’s environment.
In addition to documenting the decision, if an organization determines that encryption is unreasonable or inappropriate, then according to HHS, that organization “must implement an equivalent alternative … if the equivalent alternative is reasonable and appropriate.” If that organization determines encryption to be unreasonable or inappropriate, it must also look at equivalent alternatives to encryption to determine if those alternatives are reasonable and appropriate, and implement the alternative if it is “reasonable and appropriate to do so.” OCR’s documentation requirement also extends to any consideration given to an equivalent alternative using the above mentioned guidelines. Whether the organization is fined by OCR as a result of failing to encrypt PHI at rest depends on whether OCR agrees with the organization’s reasoning for not implementing encryption or an equivalent alternative. This opens an organization up to have its reasoning seconded guessed by OCR.
OCR has made it clear that they expect strong consideration of encryption, and according to the Director of OCR, Leon Rodriquez, it is strongly advisable to encrypt PHI wherever it is stored because of the protection encryption offers. In addition, under HITECH, information that is properly encrypted provides the organization with a “get-out-of-jail-free card.”
The “get-out-of-jail-free card” means that the loss of PHI is not reportable if it can be shown that the data was encrypted. While most of the OCR audits concern encrypting data at rest on laptops that are easily stolen, it also applies to databases because the physical database file can be stolen and accessed independently of the database server and front-end application. The biggest threat to a database file is not someone breaking into the data center and walking out with the server. If that were true, there are bigger security concerns! The biggest threat to an unencrypted database file is having an attacker in the network copying the actual database file from the server to an off-site computer. Once the file has been copied, the attacker will be able to view the contents of the file unless it was previously encrypted. If that file was encrypted, the loss would not be reportable under HITECH.
There are a few things to note about the HITECH incentive to encrypt. First, it applies to encryption and not to any equivalent alternative; therefore, this needs to be one of the factors considered in determining if encryption is reasonable and appropriate.
Second, the organization must have a strong password security policy that is strictly enforced. Requiring a password but setting a simple password of “Password” leads to weak encryption even though technically the password requirement has been met. Encryption is pointless if someone can get or guess the encryption credentials to access the database, as was the case with Anthem.
However, it is important to remember that having a strong password to the database does not offer the same protection as encrypting the database. A strong password alone does not protect the contents of the file because there is always a risk that an attacker will just copy the physical database file and bypass the password to extract the contents. Protecting data with passwords is better than leaving data totally unprotected; however, passwords alone are insufficient to prevent thieves from accessing the data. Encrypting the file protects against that threat and must be combined with a strong password to ensure the file’s contents remain unreadable by anyone without authorization.
Third, when discussing encryption in relation to the Security Rule, it is important to explore if there are any California laws regarding the protection of PHI that require encryption. I have not reviewed those here.
In order to avoid the uncertainty of having OCR scrutinize documentation surrounding the decision not to implement the Addressable Implementation Specification of encryption, as well as being able to take advantage of the reporting requirement forgiveness that encryption offers under HITECH, encryption must be treated as a requirement under the Security Rule.