Resource Overview

Conducting an SRA in accordance with HIPAA policy is a complex task, especially for small to medium providers such as community health centers. The HIPAA Security Rule mandates security standards to safeguard electronic Protected Health Information (ePHI) maintained by electronic health record (EHR) technology, with detailed attention to how ePHI is stored, accessed, transmitted, and audited. This rule is different from the HIPAA Privacy Rule, which requires safeguards to protect the privacy of PHI and sets limits and conditions on it use and disclosure. Meaningful Use supports the HIPAA Security Rule. In order to successfully attest to Meaningful Use, providers must conduct a security risk assessment (SRA), implement updates as needed, and correctly identify security deficiencies. By conducting an SRA regularly, providers can identify and document potential threats and vulnerabilities related to data security, and develop a plan of action to mitigate them.

Security vulnerabilities must be addressed before the SRA can be considered complete. Providers must document the process and steps taken to mitigate risks in three main areas: administration, physical environment, and technical hardware and software. The following set of resources provide education, strategies and tools for conducting SRA.

Security Risk Analysis Resources
Encrypting Data at Rest on Servers
HLN Consulting

Encrypting Data at Rest on Servers

Implications for Health Centers

It is common practice today to encrypt data at rest, that is, data stored on servers. Like many smaller healthcare organizations, Federally Qualified Health Centers (FQHC) are particularly vulnerable to potential attack and infiltration by data hackers for several reasons: they tend to have fewer technical support staff, resource limitations make it harder to assess, implement, and maintain safe data practices, and organizational inertia limits preventive action when no threat is perceived.

To build off an old adage, no one ever got fired for encrypting their data. But what protection does that really provide? Is just encrypting data enough?

First, let’s distinguish between three methods for encrypting data at rest.

Full-disk encryption. Most modern operating systems (like Linux or Windows Server) provide the capability to encrypt their disks in their entirety. This is accomplished with symmetric encryption whereby there is a key or passphrase that a computer operator has to enter when the disks are encrypted and when the system boots to allow access to the data. Typically, the password must be manually entered on the physical server console, though some virtualized and cloud-based environments offer remote passphrase entry and varying degrees of passphrase management and automation. With full-disk encryption, software installed on the server does not need to know or do anything special to operate normally: the operating system provides transparent access to the encrypted data as necessary with very little performance loss. But note that the initial encryption needs to be done on a new disk (or set of disks) as an existing disk will be wiped clean in the process. So it’s easiest to do this during an initial deployment or migration to a new server.

File system encryption. Physical disks are typically divided into one or more file systems by the operating system.  As an alternative to full-disk encryption, file system encryption allows administrators to encrypt only selected file systems (or even just selected folders within file systems). This makes it possible to configure a server than can boot without a passphrase; and then require a passphase only after the system is up and running and needs to access its encrypted file systems.  Similar to full-disk encryption, the encryption is transparently provided to applications by the operating system.  Unlike full-disk encryption, developers and administrators need to be careful not to store sensitive files on non-encrypted file systems.

Database encryption.  Another way to encrypt data at rest is at the database level: The database software (Oracle, SQL Server) can provide application-level encryption. Like operating system level encryption, a key or passphrase is entered by an operator when the database starts up, after which all database operations access the encrypted data transparently (hence the name: Both Oracle and Microsoft SQL Server call the feature “Transparent Data Encryption”). For servers that may store sensitive data in files outside the database, this provides less protection than encrypting the entire file system, but likely protects the most sensitive data on the system.

What kind of protection does encrypting data at rest really provide? Here are a few salient points:

Benefits of Encrypting Data at Rest

  • First and foremost, encrypting data at rest protects the organization from the physical theft of the file system storage devices (which is why end-user mobile devices from laptops to cell phones should always be encrypted). While this might sound unlikely, the physical disk devices are only as secure as the data center where they are located. While data center access control policy is usually quite strict, in practice it can be quite lax. Door entry can employ weak precautions (like old push-button unlock devices), and the proliferation of easily-swappable modular disks for quick maintenance makes removing a disk quite easy.
  • Encrypting data at rest can protect the organization from unauthorized access to data when computer hardware is sent for repair or discarded.
  • Encrypting data at rest can help to satisfy information security or regulatory requirements such as the Payment Card Industry Data Security Standard (PCI DSS) or the Health Insurance Portability and Accountability Act (HIPAA).
  • In some deployments, the actual file system where data resides is somewhat disconnected from the server upon which applications are loaded either through the use of a storage area network (SAN) or cloud-based storage. This introduces the possibility that an intruder could break in to the storage subsystem but not the rest of the system. Encrypting the storage subsystem can protect against such attacks.

Limitations of Encrypting Data at Rest

  • Encryption of data at rest provides little protection against intrusions in which a hacker gains remote privileged access to a running server in which the passphrase has already been entered.
  • Even more so, if the applications that access the encrypted files or databases (web applications, query systems) are not themselves secured, a hacker who penetrates one of these applications gains access to the data, whether it is encrypted or not.
  • For database encryption, note that some database management systems only support data encryption in more advanced (read more expensive) versions of the software.
  • When full-disk encryption is enabled on a physical (non-virtualized) server, remember that an operator – a human being – will need to type the passphrase into a console whenever the system starts up. For database-level encryption, the passphrase will need to be entered when the database starts up. While this intervention increases the level of protection, it is at the expense of convenience, as systems cannot reboot automatically without a passphrase or even without someone actually being in the server room which can be especially inconvenient if the system manager is not collocated with the hardware. File system encryption can mitigate some of these startup issues. And, of course, if that passphrase is ever lost your data will be encrypted forever.

Special Considerations for Virtualized and Cloud-based Environments

  • As mentioned, some virtualized and cloud-based environments offer remote passphrase entry and varying degrees of passphrase management and automation for full-disk encryption – but be aware that there is often a tradeoff between convenience and security with automated solutions. For example, if a cloud provider keeps your passphrase and automatically provides it to the operating system at boot time, the level of security offered by the full-disk encryption solution is largely dependent on how securely the cloud provider manages the passphrase.

While encrypting data at rest can be a useful component in a data security toolbox, it must be implemented with a full understanding of the protection it does (and does not) provide. Organizations should consult with their vendors, data security staff, system staff, and application staff to determine an appropriate set of actions to secure institutional data.

Previous Article How to Establish an Ongoing Security Program and Meet Meaningful Use Requirements for Security Risk Analysis
Next Article Security Risk Analysis Toolkit

Leave a comment

Add comment



This resource collection was cultivated and developed by the HITEQ team with valuable suggestions and contributions from HITEQ Project collaborators.

Looking for something different or have something you think could assist?

HITEQ works to provide top quality resources, but know your needs can be specific. If you are just not finding the right resource or have a highly explicit need then please use the Request a Resource button below so that we can try to better understand your requirements.

If on the other hand you know of a great resource already or have one that you have developed then please get in touch with us by clicking on the Share a Resource button below. We are always on the hunt for tools that can better server Health Centers.

Request a Resource  Share a Resource
Search HITEQ Content
Quick Feedback Request
Highlighted Resources & Events
Need Assistance?
Would you like more assistance regarding Privacy and Security strategies or support in using any of the include resource sets?

  Request Support


The Quadruple Aim
Quadruple Aim

A Conceptual Framework

Improving the U.S. health care system requires four aims: improving the experience of care, improving the health of populations, reducing per capita costs and improving care team well-being. HITEQ Center resources seek to provide content and direction aligned with the goals of the Quadruple Aim

Learn More >