In Part 1 of this article it was presented how to set up ApexSQL Audit to implement Administrative safeguards standards of the HIPAA regulatory (the 45 CFR Part 164, Subpart C – Security Standards for the Protection of Electronic Protected Health Information that is developed to accomplish protection of electronic protected health information (EPHI)). In this part, the rest of the Administrative safeguards will be presented, while in the Part 3 we will provide ApexSQL Audit settings which will allow you to fulfill the HIPAA’s Technical safeguards and Policies and procedures and documentation requirements sections
The HIPAA Administrative safeguards section requirements that will be covered in this article:
§164.308 (a)(4)(ii)(A) – A clearinghouse that is part of a larger organization, must implement policies and procedures to protect access to the SQL Servers’ EPHI from the larger organization
§164.308(a)(4)(ii)(C) – Implementing policies and procedures that are created according to access authorization policies, and also considers full control of a user’s right of access to a SQL Servers
§164.308(a)(5)(ii)(C) – All log-in attempts must be tracked and procedures for reporting discrepancies must be established
§164.308(a)(5)(ii)(D) – All SQL Server password creation, changes must be audited and reviewed
§164.308(a)(6)(i) – All SQL Server security incidents must be tracked, reviewed and addressed
§164.308(a)(6)(ii) – Establish procedures that will allow identifying and appropriately responding to suspected/ known SQL Server security incidents including documenting/reviewing all security incidents and their consequences
§164.308(a)(7)(ii)(B) – Establishing and implementing procedures to restore any EPHI data loss, stored electronically in SQL Server
§164.308 (a)(4)(ii)(A) Isolating health care clearinghouse functions, §164.308(a)(4)(ii)(C) Access establishment and modification
These requirements are related to a regular review of the collected audited data, with particular emphasis to who performed the operation and from where the SQL Server event is executed. This is particularly important to achieve by clearinghouses to track and document any access of the larger organization to HIPAA related objects and data. ApexSQL Audit provides the required Client host and Login information in the generated reports, allowing person in charge to identify any unauthorized and/or authorized access
Additionally, the ApexSQL Audit alerting engine is capable to create alerts in real time on any access and/or change of SQL Server objects/data by larger organization, which can ensure immediate and timely reaction by clearinghouse’s personnel in charge for maintaining the HIPAA compliance
To get alerted on any large organization activities in the clearinghouse’s SQL Server, set the following alert filter
The “Where Client host is not” field should contain the clearinghouse’s own Client host names. Also, selecting to be informed about an alert via email is highly recommended. In this particular case, any event that occurs on SQL Server where the client host is not identified as one of those listed in the alert filter condition will trigger an alert and send an email that will inform the appropriate person in charge about the access to SQL Server outside of the clearinghouse. Generating a report for the time period when alert was raised and reviewing it should allow identifying the breach in a reasonably short time.
To speed up the documenting of any unauthorized large organization activities, it is advisable to create and save the custom report dedicated to reporting on that activities
To create a report that will document any large organization activities, set the following filter and save it
Now, the report can be generated in a single click and non-clearinghouse client hosts could be easily spotted and documented, which will allow the appropriate actions to be taken
§164.308(a)(5)(ii)(C) Log-in monitoring
ApexSQL Audit filters allows you to track all Log-in and failed Log-in activities. If using the Simple auditing filter, the following server level filter selections must be checked
It is highly recommended to enable the tracking of the failed login attempts, as besides the mistyped credentials or inactive passwords, these can be used for analyzing and detecting potentially malicious and unauthorized attempts to access the sensitive EPHI data
Unauthorized and/or malicious logins or failed logins are potential security threats and being alerted and timely reaction can eliminate/prevent any potentially unwanted access to the sensitive EPHI data.
The image below shows the alert filter that should be used. Via the condition Login name is not <SQL login(s)> the trusted or users that have granted access to EPHI data could be excluded to prevent unnecessary triggering of alerts and email sending for what could be characterized as normal activity
§164.308(a)(5)(ii)(D) – Password management
ApexSQL Audit is designed to audit all security related changes including any change of the passwords in SQL Server. It can audit, store in the central repository database and generate the report on any password change. An additional benefit is the ability of creating the alerts that will be triggered in real time precisely on each password manipulation SQL Server event. This ensures that appropriate and immediate action can be taken when any such sensitive security event occurs
While password related events will be audited by defining the security related auditing filter as described in the Part 1 of the article, it is highly recommended to create an alert (or alerts if needed) to cover any password related SQL Server event. The following filter is recommended
Since ApexSQL Audit has an embedded t-SQL parser as the part of the advanced filter, it can parse the actual T-SQL of the T-SQL executed behind the actual event and to use the parsed text as a condition in advanced filter. In this case, the Text data condition is defined to check whether the executed T-SQL contains the “WITH PASSWORD=” string, and if it contain string in Alter/Create login event, the alert will be triggered
It is also recommended to create a custom report(s) that will generate report only on the password related events, which will allow easy reviewing of password changes and fast historical insight in passwords manipulations. It is advisable having separate reports for Alter login and Create login events
Custom filter condition needed for reporting on password manipulations:
Filter for Alter login
Filter for Create login
Depending on the requirements, reports can be created separately for each audited instance, or for multiple audited instances, where the only difference would be selecting the multiple required instances in the Server filtering condition
An additional requirement that is highly recommended to be audited and reported on is auditing of an Enforce password policy. Enforcing a password policy is highly recommended and obligatory in most companies to prevent any sort of hacking via exploitation of weak passwords. Establishing alerts and reports specifically for detecting the inappropriate use of Enforce password policy can ensure additional security of sensitive EPHI data
An appropriate filter that will raise an alert when wrong Enforce password policy settings are used:
In situations when Enforce password policy is mandatory, it is irrelevant whether this user didn’t stick to that when he created or altered login, so there is no need for separate alerts for that. On each and every breach of this rule an appropriate action of the responsible officer will have to be taken
A custom report that should be created so that every breach of the rule can be documented and reviewed, including the confirmation that particular breach is corrected and how fast it was corrected
The Enforce password expiration and Specify old password are usual requirements in companies that are HIPAA compliant as this is the additional insurance that SQL Server security is set at the highest level
To be alerted on inappropriate use of the above mentioned requirements, the auditing alert with the following filtering condition should be created
To be able to document this kind of security issues, the following custom report filter condition should be created and saved (in the image below the example of such generated report is displayed)
§164.308(a)(6)(i) Standard: Security incident procedures, §164.308(a)(6)(ii) Implementation specification: Response and reporting
These HIPAA requirements can be covered with ApexSQL Audit by creating the appropriate reports which should ensure the appropriate actions to be taken to minimize the effects of security incidents
There is a whole range of actions that can be characterized as security incidents, and we cannot cover all of these in the article, but we will provide examples that can be used as a guideline for other specific security accidents
The common example of the security accident covering via ApexSQL Audit will be presented below
- Reading the EPHI data by persons without clearance
Generally, all security rules define users allowed to access the EPHI data with read only permissions, where only the specific users are granted the full access permission to EPHI data. Any deviation from this predefined set of security rules should be considered as a security incident and actions should be taken to clear the causes of the security incident as soon as possible
It is important to be alerted immediately when such an incident occurs. ApexSQL Audit allows defining an alert rule that will alert the person in charge if any reading of the EPHI data has occurred by users without adequate permissions
The alert rule in the image above was set to alert on any Query based event executed by any users except the ones listed against the AdwentureWorks2014 database when any of listed tables or views are involved
To generate the report, the same filtering condition can be used in the custom reports filter, but if there is a need to quickly track individual tables/views then it could be convenient having separate reports saved for each individual table
§164.308(a)(7)(ii)(B) Disaster recovery plan
The emergency procedures have to be established that will take effect on any EPHI data lost, which should ensure recovering of lost EPHI data. Once the data loss is detected via ApexSQL Audit, another tools from ApexSQL designed with data recovery in mind – ApexSQL Log and/or ApexSQL Recover could be used to rollback any malicious/inadvertent change or delete of EPHI data. Of course, the disaster recovery plan should always include the regularly taken database backups. ApexSQL Manage ensures automation of the backup jobs and managements of created backups while keeping the backup chain intact to ensure an easy point-in-time database rollback
September 14, 2015
