What DBAs Should Know About HIPAA and Other Data Protection Regulations

Keeping confidential data protected is important no matter the industry, but when it comes to medical records and related data you would be pressed to find a more highly regulated industry.

While most eyes are fixed on the massive and historic theft of credit card information in 2017, some believe the most dangerous threat comes from theft of medical information. Last month Forbes published a piece explaining how a “dark web” marketplace can get up to a hundred dollars for each medical record when sold. The data is then used for everything from blackmail to data analytics.

Much has been written about what doctors, medical facilities, and insurance companies need to do to maintain compliance to the regulations in their region. In this blog we’ll talk about what a DBA or System Administrator should know.

Different Regulations for Different Regions

In the United States

In the United States the protection of medical data is regulated by the Health Insurance Portability and Accountability Act of 1996, know by most as HIPAA. The act contains five sections that provide guidelines to achieve two main purposes. One is to ensure that people can continuously have health coverage when they lose or change a job. The second is to reduce the administrative burdens and cost of healthcare by standardizing the electronic transmission of medical information.

In 2013 the act was expanded to implement the 2009 Health Information Technology for Economic and Clinical Health Act (HITECH), which was created to stimulate the adoption of electronic health records.

One of the main aspects of HIPAA which applies to the work of the DBA is the HIPAA Privacy Rule. It applied to any organization that is considered to operate under the umbrella of the act and includes health plan providers, clearinghouses, and healthcare providers. It also expands to any company that works with a business that operates under HIPAA.

This privacy rule…

• Covers personal health information or PHI whether its digital, paper or orally communicated.
• Guarantees a user can access their own PHI at any time. This includes their name, DOB, SSN, medical condition, care provided, information about payments for care provided.
• Requires someone at the company to be appointed the Privacy Official, for employees to be trained on process and procedures, and a process for complaints
• Requires appropriate administrative, technical (we’ll talk about this more below) and physical safeguards to be maintained in regards to the PHI.
• Failure to meet these requirements can result in fines. The 2013 Omnibus Rule doubled the maximum fine for a single violation from $25K to $50K.

In addition to the privacy rule there is also a HIPAA Security Rule, also known by its full name The Security Standards for Protection of Electronic Protected Health Information. Under the security rule there are guidelines and a handy Security Risk Assessment Tool that helps you audit yourself.

Within this tool there is a specific technical audit which every SysAdmin and DBA should follow to ensure their environment is compliant.

In the European Union (EU)

In 1998 the EU adopted the Directive on Data Protection which outlaws the disclosure of details held by a European company to any foreign entities who do not follow the EU guidelines. This differs from HIPAA largely because, while it includes medical information, it covers much more data which is deemed confidential.

The law focuses on four basic principles…

• Focus only on the specific data you need
• Analyze the way you process data
• Consult a lawyer if you are handling confidential information to ensure compliance
• Stay up-to-date with the frequent changes to the directive

In 2015 the EU issues a partial general approach on Chapter II of the directive that provided more specific information in regards to health data.

In 2017 the EU largely replaced the directive with the EU General Data Protection Regulation (GDPR). While this regulation, like the directive before it, covers a wide variety of data, it also affects medical records in the following ways…

• Requires consent for collecting medical data with exceptions made for “public health”
• Allows for the use of health information for scientific research as long as safeguards are in place
• Systems are required to implement data protection by design and by default into their systems
• Requires the use of Data Protection Impact Assessments (DPIA)
• Requires the retention of processing activities for audit purposes
• Users are required now to report data breaches

What This Means to Your Environment

Here are some basic general recommendations to the SysAdmin or DBA to make sure they are keeping their data secure.

• Keep Your Environment Secure – Yeah that sounds overly simple, but the reality is that often times, a “it’s not broke” mentality exists in some organizations. Making sure you are keeping external access locked down, making sure that anything that has access is staying secure, that your encryptions are working, that the latest security patches are immediately deployed, etc., are key to the first steps at meeting the requirements.
• Consistently Poke at Your System – Don’t rely on the fact that your environment is secure, you need to have plans in place to regularly attempt to beat your own security. But remember, it is estimated that 80% of the data loss comes from inside the organization (either through theft or negligence), so keeping an eye on that is key as well either by checking the logs, auditing the user permissions, etc. Depending on what type of system you are using, there are often trusted 3rd party tools that can help you with this.
• Make Sure Your Deployments are Secure – When using open source databases, a key thing to remember is that security features might not be turned on by default. Items as simple of enabling authentication is a manual process during or after deployment.
• Limit Access to PHI – It’s easy to wave a stick and give every member of the IT team admin rights to the systems. This makes it easy for maintenance and upgrade projects, but the reality is the more people who have access to the data the more at risk you are to a breach.
• Never Take Data Home – Working remote or from home is a privilege that many in our space today take for granted but when you are troubleshooting a problem or trying to recover bad data, you can’t take any medical records off your main systems no matter the circumstance.
• Be Careful How You Test – If you are using real data in a test scenario, you should always be cautious of the fact that excessive use of real data, more than what is absolutely needed, can result in violations of the regulations. Implementing Data Masking could really protect you in this scenario.
• You HAVE to Notify if You Have a Breach – In 2013 the HIPAA Omnibus Rule instituted a tough new procedure you have to follow if you have a loss of PHI data.
• Retention of Data is Tricky – The longer you have to keep the protected data in your system the tighter the regulations become. In the US alone, there are more than 150 State and Federals laws that impact the retention of data. The regulations typically apply to the “type” of data you are storing, for example, Clinical Trial information has to be kept for 35 years while audit records only need to be kept for 7. It is important to know what you are storing and do the research to know the specific regulations for your type of data.
• Backups and Data Archiving – The Data Quality Act of 2001 requires your data to be “good”. Because of this maintaining an effective backup solution (where the data is copied) coupled with an eventual data archival solution (where the data is moved) is essential.
• Use Metadata Whenever Possible – When data is tightly protected, it is hard for anyone without the full rights to know “what’s in there” this is where metadata comes into play.
• Remember Third Parties – If your environment is considered covered under regulations like HIPAA you live and breathe this stuff, but be careful of companies who work with you who don’t. These folks are called Business Associates and you should also ensure they understand the regulations and even go as far as to sign a BAA with each vendor.
• Alway Do a Little More Than What’s Required – When it comes to protecting highly-sensitive data you can’t be too careful (or too paranoid). Meeting the minimal requirements is what is just that, required, but your companies reputation, and maybe its very existence, rests on the fact that this data is kept secure… so go the extra mile.

ClusterControl for Database Security

ClusterControl provides advanced deployment, monitoring and management features to ensure your databases and their data are secure. It ensures that your open source database deployments always adhere to basic security model setups for each technology.

ClusterControl provides the Package Summary Operational Report that shows you how many technology and security patches are available to upgrade and can even execute the upgrades for you!

In addition ClusterControl offers…

• Secure Deployments
  Every technology has its own unique security offerings and ClusterControl ensures that what should be enabled is enabled during deployment. This eliminates the risk of human error which could otherwise result in leaving the database vulnerable because of a security setting oversight.
• Communication Security
  ClusterControl provides the ability to install a purchased or self-signed SSL certificate to encrypt the communications between the server and the client. Keys for these certificates are entered into and managed by ClusterControl.
• Backup Security
  Backups are encrypted at rest using AES-256 CBC algorithm. An auto generated key will be stored in the cluster’s configuration file under /etc/cmon.d. The backup files are transferred in encrypted format. Users can now secure their backups for offsite or cloud storage with the flip of a checkbox. This feature is available for select backup methods for MySQL, MongoDB & PostgreSQL.
• User Management
  ClusterControl’s advanced user management features allow you to restrict read or write access to your data at the database or even table level. ClusterControl also provides advisers that check that all of your users have proper passwords, and even comes with checks to make sure any part of your database that shouldn’t be is not open to the public.
• Reports & Auditing
  ClusterControl provides reporting and audit tools to ensure you remain compliant, whether it is to an industry standard or to your own requirements. It also provides several Developer Studio Advisors that check your database environment to ensure that it is secure and you can even create your own security advisors to automate your own best practices. In addition, several Operational Reports found in ClusterControl can provide you with information you need to know to ensure your database environment is secure.

Download ClusterControl today to take advantage of these database security features.