Achieving & Maintaining Database Compliance for HIPAA Cover your Bases with GreenSQL Complying with HIPAA can be confusing, especially with so many products providing protection on only a portion of HIPAA regulations. Database security provides protection on the actual data. With GreenSQL, you can: Discover exactly where all of your HIPAA resides: In what databases, tables, and columns. Discover what individuals, servers, applications, and systems have access to every database. Create rules to protect HIPAA-sensitive data at the database, table, and column level. Create separation of duties schemes for different users. Mask HIPAA sensitive data, including patient information, payment information, and personal identification. This paper shows exactly what parts of HIPAA you can comply with using GreenSQL. You ll see exactly how database protection works and get specific breakdown of each of the database compliance HIPAA regulations that GreenSQL helps you satisfy. These functions are provided out-of-the-box, with minimal installation time and absolutely no changes needed on your network, giving you the ability to answer the HIPAA auditor with minimal time and effort. HIPAA and Database Security Naturally, all of the information about patients, their health situation, billing, and personal data is stored in the databases of the organizations providing health services. Databases can be protected in a number of ways. Solutions that do not specifically focus on the database talk about limiting access, and creating a firewall to protect the whole organization. Unfortunately, such solutions fall short. It s necessary to provide access to the database by the employees and by the programmers, database administrators, and remote access contractors who work on the systems. Dedicated database firewalls provide a number of additional layers of protection for organizations who want to protect their core data and comply with HIPAA and other regulations while still giving access to those who need it.
What is GreenSQL? Features of the GreenSQL Unified Database Security Solution GreenSQL, a Unified Database Security (UDS) system, handles multiple layers and issues in a single product. It is the first solution to supply out-of-the-box real-time regulatory compliance for databases, with over 28% of the HIPAA requirements met as soon as GreenSQL is installed and configured. The innovative, robust GreenSQL UDS ensures the safe handling of all your sensitive information, including patient records, billing information, and credit cards. The 4 main areas of the Universal Database Security solution are as follows: Database Security Stops SQL injection attacks and blocks unauthorized database access, providing full separation of duties (SOD). Dynamic Data Masking Database Activity Monitoring Compliance Reports Allows Personally Identifiable Information (PII) to be hidden in real time from unauthorized users such as developers and CRM users. Monitors database access and activity and tracks before-and-after audit values. Real-time alerts help provide full compliance with regulatory requirements. Ad-hoc and scheduled reports which provide compliance reports as required by HIPAA. Give auditors exactly the reports they need right when the request it. How does GreenSQL work? GreenSQL is a software-based solution that analyzes and approves every request to a database server or cloud-based database server. In other words, every single request going to your database, no matter what the source, needs to pass through GreenSQL s software and be approved before it reaches the actual database. This provides complete coverage and real-time ability to stop unauthorized access of any sort or from any source. As software, GreenSQL can be deployed on premise or in cloud infrastructures. It sits inline, in front of the database. Because of its strategic location, as a shield to all of the database, GreenSQL can perform a wide range of protective activities, from SQLi protection through data masking and separation of duties, as outlined in the next section. Application GreenSQL Database Server
What Does GreenSQL Offer for HIPAA? Identification of databases, roles and administrators Upon installation, GreenSQL scans to find out exactly what databases are accessible and by whom. You can see exactly how many people have admin privileges, what privileges they have, and when they are using their privileges. Most companies don t even have an organized accounting of who can access the databases. Not only do individuals access databases, but other databases and processes may have direct access. All of this is visible through GreenSQL s scan. Built-in rules for database protection from SQL injection attacks GreenSQL s database firewall contains the fundamental requirements for immediately blocking SQLi attacks, right out of the box. Suspicious behavior is identified, blocked and reported instantly. Discovery of HIPAA-sensitive information in the databases Using a database scan, GreenSQL identifies information such as name, social security number, etc., and can provide a report of what tables store sensitive data. Masking of HIPAA sensitive information at granular level (per table, per column, per user, user group) Data identified as sensitive can be masked specifically according to use. Using these rules, you can ensure that developers and testers can work on the system, without seeing the data. You can also create rules that allow physicians to view only their patient s personal data, but get information on diagnoses and statistics from other doctors, without seeing the patient details. Hiding database existence and location Because it works as a proxy, GreenSQL allows you to have applications access the address of GreenSQL, and mask the actual identity of the databases. This adds another layer of protection against malicious attacks. Separation of duties Every user can be granted only the permissions that are necessary for the particular role of that user. Separation of duties provides granular-level permissions, such that nobody has access to any part of the data that they do not need for their particular role. Real-time alerts, reporting, and auditing capabilities Real-time alerts provide the ability to intervene immediately with any suspicious or malicious behavior. Advanced reporting capabilities provide a variety of reports, described below, as well as customized reporting. Much of HIPAA compliance is based on reporting and auditing, and GreenSQL provides a full suite of reporting capabilities for all activity on the organization s databases.
Line-by-Line HIPAA Compliance with GreenSQL GreenSQL Unified Database Security (UDS) helps IT Organizations Address HIPAA Requirements where they apply to databases. In particular, GreenSQL provides Administrative Safeguards as outlined in HIPAA Citations 164.308 and 164.312, as described below. HIPAA Citation Requirement Description How GreenSQL Applies 164.308(a)(1)(ii) (B) Implement security measures to reduce risk of security breaches. GreenSQL s flagship product delivers a unified database security solution that includes Database Activity Monitoring anddynamic Data Masking. 164.308(a)(1)(ii) (D) 164.308(a)(3)(i) Implement procedures to review system activity Ensure protected health information (PHI) is accessed only by authorized people. GreenSQL Database Auditing includes real-time knowledge and reporting of all activities performed on the database, including what individual performed each action. Separation of duties and prevention of SQL injections ensure that only the proper individuals can access the database tables containing PHI. Data masking ensures that those others who need to use the database for administrative purposes can view only masked data. 164.308(a)(3)(ii) (A) Create authorization and supervision of PHI access. GreenSQL provides capabilities for specifying exactly what access is available to each application or user. Access privileges can be defined granularly, down to the level of table, column, or row. HIPAA Citation Requirement Description How GreenSQL Applies 164.308(a)(3)(ii) (B) Ensure access of PHI records is appropriate. Database monitoring means that alerts and reports can tell exactly the activities that are performed on the database by each individual. Suspicious or unauthorized behavior can be flagged or prevented. 164.308(a)(3)(ii) (C) Implement procedures to terminate PHI access. The GreenSQL solution makes it simple to remove access rights to all or part of the data or databases. 164.308(a)(4)(i) Implement policies and procedures for authorizing access to electronic records. Both automated and manual capabilities for individual and group access definition are available through GreenSQL.
HIPAA Citation Requirement Description How GreenSQL Applies 164.308(a)(4)(ii)(A) (A) 164.308(a)(4)(ii) (B) 164.308(a)(5)(ii) (C) 164.312(a)(2)(i) 164.312(a)(2)(iv) 164.312(b) 164.312(c)(1) Isolation health clearing house functions to separate PHI from other operations. Allow authorized access to PHI records. Monitoring of log-in attempts. Assign unique IDs for individual user tracking Encrypt stored PHI. Record and examine activity in systems containing health information. Ensure data integrity by preventing inappropriate altering or deleting of data. A number of functions are available to ensure databases are safe from other organizations. Limited authorization, or authorization with data masking can prevent clearing houses and other outside organizations from accessing data. Advances SQLi protection means that database commands from other databases or organizations are analyzed for authorization and even if a partner company is compromised, GreenSQL will protect the organization s data. By implementing a database firewall, you can feel confident that when you implement a program to allow health care professionals and patients to access data, you won t be compromising other data. SQLi protection ensures that when you give access to a user, they will not be able to take malicious action to get unauthorized data. GreenSQL monitors all access and attempted to access, whether by individuals or by other systems. Tracking of individuals is implemented only for database users (admins, developers, testers). Data masking automatically hides and encrypts data, showing dummy data to developers and admins who are not authorized to view PHI All activity on databases and database records is tracked and full reports and auditing are available. It s possible to limit or even eliminate the ability of all administrators to delete record. Policies can be enforced to limit or prevent alteration of records. Because all changes are tracked, in case someone authorized makes an unauthorized change, it is possible to detect precisely what happened and revert and restore records. 164.312(c)(2) Detect and authenticate that data has not been altered or destroyed in an unauthorized manner. Full auditing capabilities provide complete reporting of any alterations or deletions of data, such that it is easy to corroborate if any unauthorized activities occurred. 164.312(d) Authenticate that the individual seeking access is actually the person they claim to be. The database firewall can include a variety of criteria for verification, including specific IP address, domain, geography, and other criteria as well as password protection.
HIPAA Citation Requirement Description How GreenSQL Applie 164.312(e)(1) 164.312(e)(2)(i) 164.312(e)(2)(ii) Protect data transmitted over an electronics communications network. Ensure that when data is electronically transmitted, it is not altered in an unauthorized fashion. Encrypt transmitted PHI. When using outside developers or testers, it is possible to send masked data, so that no PHI data is exposed to unauthorized officials. Separation of duties ensures that only authorized data is transmitted to authorized individuals. The system can be set up to accept only specific types of changes for electronic records accepted from other systems. Data masking is able to prevent transmittal of PHI in a format that can be read by others. GreenSQL Compliance Reporting Inactive Database Users Login Name Login Create Date Last Login Jesse 01/04/11 1/4/2011 8:00 AM KayKay 12/04/11 1/3/2011 5:55 PM Newton 01/08/12 2/4/2013 5:07 PM Amanda 01/01/13 1/4/2013 10:22 AM This report lets you see all users who have not logged in for any length of time, letting you easily see which users are eligible for having their privileges revoked. Satisfies HIPAA requirements: 164.308(a)(1)(ii)(B), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.308(a)(3)(ii)(B) Database Users with Passwords that never expire Login Name Login Create Date Last Password Update Daniel 01/04/11 1/2/2014 8:00 AM Danielle 12/04/11 1/3/2014 5:55 PM Ariel 01/08/12 2/4/2014 5:07 PM Yu 05/12/12 9/4/2014 4:57 PM Terry 01/01/13 10/4/2014 10:22 AM This report lets you easily pinpoint the security risk that exists when users are not forced to change their passwords periodically. Satisfies HIPAA requirements: 164.308(a)(1)(ii)(B), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A) Database Users with Passwords that haven t changed in 90 Days Login Name Login Create Date Last Password Update Eli 02/14/14 02/14/14 Tim 08/01/09 10/01/09 Sue 08/01/09 10/01/09 Mia 07/26/09 09/26/09 This report lets you see any user who has not changed his/her password in the past x number of days. Satisfies HIPAA requirements: 164.308(a)(1)(ii)(B), 164.308(a)(1)(ii)(D), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.308(a)(3)(ii)(B)
Changes in User Settings Event Time Username Application Name Action Query Affected User 5/22/2014 8:33 AM Amy SAP GRANT Certificate Permissions GRANT permission [,...n ] ON CERTIFICATE :: certificate_name TO principal [,...n ] [ WITH GRANT OPTION ] [ AS granting_principal ] Ivan 5/19/2014 4:53 AM Amy REVOKE Certificate Permissions REVOKE [ GRANT OPTION FOR ] permission [,...n ] ON CERTIFICATE :: certificate_name { TO FROM } database_principal [,...n ] [ CASCADE ] [ AS revoking_principal ] Ivan 4/06/2014 7:21 PM Sven Dynamic CRM REVOKE Object Permissions REVOKE [ GRANT OPTION FOR ] <permission> [,...n ] ON [ OBJECT :: ][ schema_name ]. object_name [ ( column [,...n ] ) ] { FROM TO } <database_ principal> [,...n ] [ CASCADE ] [ AS <database_principal> ] Nick 2/28/2014 6:33 AM Brent DENY Schema Permissions DENY permission [,...n ] } ON SCHEMA :: schema_name TO database_principal [,...n ] [ CASCADE ] [ AS denying_principal ] Joe This report displays all queries that attempted to create, modify or delete any user settings during a specific time period. Satisfies HIPAA requirements: 164.308(a)(1)(ii)(B), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.308(a)(3)(ii)(B) Changes in User Settings Event Username Application Action Query Affected User Queries Run after Time Name Chanted Right 5/22/2014 8:33 AM Gary GRANT Certificate Permissions GRANT <permission> [,...n ] TO <database_principal> [,...n ] [ WITH GRANT OPTION ] [ AS <database_principal> ] Ned 5/19/2014 4:53 AM Eric GRANT Certificate Permissions GRANT permission [,...n ] ON SCHEMA :: schema_name TO database_principal [,...n ] [ WITH GRANT OPTION ] [ AS granting_principal ] Kim 4/06/2014 7:21 PM Gary DENY Full-Text Permissions DENY permission [,...n ] ON FULLTEXT { CATALOG :: full-text_ catalog_name STOPLIST :: full-text_ stoplist_name } TO database_principal [,...n ] [ CASCADE ] [ AS denying_principal ] Lou 2/28/2014 6:33 AM Joe REVOKE Object Permissions REVOKE [ GRANT OPTION FOR ] <permission> [,...n ] ON [ OBJECT :: ][ schema_name ]. object_name [ ( column [,...n ] ) ] { FROM TO } <database_ principal> [,...n ] [ CASCADE ] [ AS <database_principal> ] Dave This report displays all queries that attempted to create, modify or delete any user privileges during a specific time period. This report includes changes made by the user after his rights were changed. Satisfies HIPAA requirements: 164.308(a)(1)(ii)(B), 164.308(a)(1)(ii)(D), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.308(a)(3)(ii)(B), 164.308(a)(3)(ii)(C), 164.312(d)
Changes in User Access Rights (Part 2: Queries run after changes to User Access Rights) Login Name Query Run Date of Query Ava Ava SELECT * from credit_cards WHERE (concat(year, -, month, -01 ) < CUR- DATE()) SELECT * FROM credit_cards WHERE month = MONTH(CURDATE()) AND year = YEAR(CURDATE()) 4/23/2014 4/23/2014 Tom select patient_id,max(month(received_ DATE)) AS Mnth, max(year(received_ DATE)) AS Yr, ACCESSION_DAILY_KEY 4/05/2014 This report displays all queries made by the user after his rights were changed. Satisfies HIPAA requirements: 164.308(a)(1)(ii)(B), 164.308(a)(1)(ii)(D), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.308(a)(3)(ii)(B), 164.308(a)(3)(ii)(C), 164.312(d) Database Users with Administration Privileges Login Name Login Create Date System Administrator Eli 05/14/14 YES Tim 05/08/14 YES Sue 04/27/14 YES Mia 04/27/14 NO This report gives you a full list of all database users with administrative privileges. Satisfies HIPAA requirements: 164.308(a)(1)(ii)(B), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.308(a)(3)(ii)(C) Latest Database Administrator Logins Login Name Login Date & Time Originating IP Application Name Sue 5/19/2014 11:53 AM 206.196.115.38 SAP Tim 5/12/2014 4:01 AM 41.206.12.7 Tim 5/11/2014 2:37 AM 41.206.1.1 Dynamic CRM This report displays all the administrative logins that occurred in the past 7 days. Satisfies HIPAA requirements: 164.308(a)(1)(ii)(B), 164.308(a)(1)(ii)(D), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.308(a)(3)(ii)(B), 164.308(a)(5)(ii)(C) Latest Database Administrator Actions Login Name Login Date & Time Originating IP Application Name Database Name Action (query) Jim 5/19/2014 11:53 AM 216.27.61.137 Northwind SELECT EMP_ID, LAST_NAME FROM EMPLOYEE_TBL WHERE EMP_ID = 333333333 Mia 5/12/2014 4:01 AM 172.16.81.100 select name from ids left join tokens on ids.eid = tokens.eid where ids.typedef = true Amy 5/11/2014 2:37 AM 255.255.0.0 Northwind SELECT * FROM shop WHERE price IN (SELECT MAX(price) FROM shop GROUP BY article);; Alex 5/10/2014 8:37 PM 122.140.201.66 Northwind SELECT * FROM PRODUCTS ORDER BY PRICE DESC LIMIT 0,1 This report displays all the administrative logins that occurred in the past 7 days. Satisfies HIPAA requirements: 164.308(a)(1)(ii)(B), 164.308(a)(1)(ii)(D), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.308(a)(3)(ii)(B), 164.308(a)(5)(ii)(C)
Conclusions When it comes to protecting patient records, the closer you get to the record itself, the better your protection is. Database protection like GreenSQL doesn t just protect the access to data; it protects the data itself. Each and every database request needs to go through GreenSQL before it touches your database. This methodology provides the closest protection possible, in real-time. This paper gives a specific breakdown of each of the HIPAA regulations where GreenSQL is relevant for your organization, so you know exactly what coverage you get, and you can show an auditor the specifics of your HIPAA compliance. Best of all, these functions are provided out-of-the-box, with minimal installation time and absolutely no changes needed on your network. GreenSQL UDS provides 4 lines of coverage: Database Firewall using a reverse proxy that intercepts each and every command and access to the database, analyzing the specific commands and making sure every single command is valid, issued by the proper user and permissible. Separation of duties is available, to define different levels of access for different individuals and groups. The granular definitions allow assigning permissions at the level of specific tables and columns. Auditing is available in real-time as well as in retrospect. Not only can you know exactly who has accessed the databases and in what capacity, you can receive alerts of any suspicious behavior in real-time and prevent unauthorized access. In cases of suspicious behavior, you will know immediately instead of at the time of a scheduled audit. Data masking means that developers, contractors and testers can use a fully-functioning production database, without actually seeing the real data. Masked data performs as real data without any of the exposure risks of data. Masking makes it possible to grant full access to DBAs without compromising privacy. Reports provide accounting of security threats that were prevented and insight into the activity on your databases. A flexible reports generator allows you to offer your staff, auditors and administrators exactly the reports needed. Built-in reports are appropriate for HIPAA and other types of auditors. About GreenSQL GreenSQL delivers Database Security and Compliance Solution for the small and medium businesses (SMB) and the enterprise markets. The company is committed to protecting information by making database security affordable and easy to manage for every company. With an all-in-one approach to database security, the GreenSQL software-based platform offers Security, Caching, Auditing and Masking in a single package.