New audit protocol
The Health and Human Services Office for Civil Rights (OCR) has launched the second phase of its HIPAA Audit Program. Now, both covered entities and business associates are subject to the audits. The process will include RFI’s, desk audits, and for a select number of entities, on-site audits.
In preparation for the phase 2 audits, OCR has updated the audit protocol. This new protocol dwarfs the previous release, with over 1,000 audit inquiry line items. The sheer volume of audit inquiries will be monumentally time consuming for an entity’s IT and Security teams. Consider this one inquiry:
Obtain and review documentation demonstrating the records of information system activities that were reviewed such as audit logs, access reports, and security incident tracking reports. Evaluate and determine if information system records were reviewed in a timely manner and that the review was conducted and certified by appropriate personnel.
Questions to ask
Entities need to be asking themselves: Am I collecting these logs? Can I access them in a format for review? Have I actually reviewed them? Do I have a record of when you reviewed them? Is meeting these standards alone enough to keep our patient data safe?
While extensive, the OCR has set its expectations in detail so these questions need to be asked now. HIPAA compliance can be fairly amorphous when reading the letter of the law, but the audit protocol provides us the clarity of how it will be enforced. It’s the job of the security and compliance teams for covered entities and business associates to get the audit inquires reviewed. The first person asking these questions should not be the OCR’s auditor.
Once these questions get asked, you might not like the answer you find. So you’ll have to develop an action plan, listing gaps and assigning them to members of your team – you may soon find you’re too understaffed to deal with these actions on top of the day to day necessities. So you will need help. Hopefully some of that help may already be available to you, but not leveraged for compliance.
SIEM to the rescue?
SIEM tools continue to be implemented more and more. Your organization may be using one today to identify threats and malicious activity on your network. Did you know that the data used to provide cybersecurity functions can also be leveraged to provide reporting and analysis for compliance purposes? With some customization, you can utilize a SIEM system for multiple purposes, to make sure your organization stays secure.
To best leverage the SIEM tool, a comprehensive review of the logs within the SIEM tool needs to made. Each type of log may provide the underlying data needed to fufill one or more audit inquiries. A collaborative review of the events by security and compliance teams enables efficient mapping of events. In addition to base events sent directly from devices, correlated events generated by rules designed to identify threats or breaches should be mapped to the audit inquiries.
Once mapped, each type of event can be reported on, turned into a dashboard including a real-time dashboard, to monitor events as they occur. Some type of events will be too numerous for reports, such as login activity. Summary reports and “top tens” can be created, but on-going monitoring through automated correlation rules that notify on exceptions will provide better compliance.
During the review, it will be common to find audit inquiries that should be answered by your logs, but aren’t. There could be several reasons – if you have active directory logs but aren’t seeing them in the SIEM, it could be these devices are not properly reporting or event parsing is mis-configured. In this case its worthwhile to invest some time to get the SIEM fixed. If you aren’t seeing logs for compliance purposes, it means you also aren’t getting the value you originally intended them to provide for security.
Its also likely to find you don’t have the devices you need to provide the logs in the first place. Here, cost/benefit of fufilling the requirement through some manual process or control vs. purchasing new devices will need to be made. The HIPAA security rule specifically allows these types of tradeoffs to be made (164.306(b)).
Even without addressing these gaps, as long as your SIEM is performing security functions today, it can help you address HIPAA compliance. The key is to re-frame the perspective that, in addition to its core role it identifying threats, it can provide compliance functionality.