Tuning Log Management and SIEM for Compliance Reporting
The winter holidays are quickly approaching, and one thing that could probably make most IT Security wish lists is a way to produce automated compliance reports that make auditors say “Wow!” In last month’s newsletter, we took a look at ways to work better with auditors. This month, we’re going to do a deeper dive into tuning of log management and SIEM for more effective compliance reporting.
Though being compliant and having a strong, well-managed IT risk posture aren’t always the same thing, they are intertwined. Auditors look for evidence – documentation and reporting that validates and supports compliance activities. For example, if a policy or mandate requires that access to a database be protected and monitored, evidence comprised of a log management or SIEM report can show who accessed that database and when. If the users who accessed the database have roles that are approved for access, the reports can provide proof that the access controls were working.
To ensure that the reports generated by the log management and SIEM solutions support compliance work, it’s important to understand the IT controls underlying the mandates. Last month we discussed some of the regulations and standards that mention log reviews (including HIPAA, PCI, and FISMA). Compliance Frameworks also highlight the importance of log reviews. ISO/IEC 27001:2005 calls for audit logs that record “user activities, exceptions, and information security events(1),” and CoBiT 4.1 references that organizations should “ensure that sufficient chronological information is being stored in operations logs.”
The trick is to know how to translate the log management and SIEM information into reports that speak directly to the requirements. Log review is a fairly broad category – it’s what’s being monitored and reported in the logs that counts. Getting the right set of criteria to monitor for can be challenging, but mapping policy to IT controls is a good place to start. Some mandates are more prescriptive than others. PCI, for example, calls out which areas of reporting will be of high interest to auditors. Is there a credit card number being captured in the logs? That’s an indicator that an application is out compliance with PCI because PANs (Primary Account Numbers) are not allowed to be stored, unencrypted, anywhere in the payment systems.
Some log management and SIEM tools have compliance reporting built in – they might, for example, have a PCI report that you can run that shows what an auditor might look for during an actual audit. This can help with the process by creating a baseline template for reporting, but keep in mind that the pre-canned reports may not tell the entire story. Review the reports to confirm that the correct information is being logged and reported on. Keep in mind that templates created by vendors are designed to meet a large number of customers, so although some event information is clearly in the scope of certain compliance reports, your environment is (probably) not exactly the same as the other guy’s.
To make sure that you’re getting the right level of detail and that you’re covering the right areas, map which systems and events are specifically required for your environment and the set of regulations in your scope. For example, if you’re a hospital or other covered entity, be mindful that HIPAA requires there to be separate/unique logins for access to protected health information. But many healthcare organizations have systems where logins are shared by employees in violation of the regulation. A report that simply looks for unique logins may not tell the whole story because one login could be shared across multiple users. In this case, a covered entity may need to create additional correlation rules to identify that each user has his/her own unique login ID and that logins are timed out on shared machines to force unique logins for access.
What isn’t being monitored may matter for compliance as well. Email logs can be integrated into the larger log management and SIEM reporting console, but not all critical business correspondence goes through email nowadays. Many companies are also using IM and other peer to peer solutions for important business communications – if an organization approves IM for use, adding these systems to the log management review will provide a more complete view of whether or not critical data is being shared. Collaboration workspaces, like Lotus Notes, Microsoft Sharepoint, and Google Docs, are important data repositories where controlled or regulated information may be shared. If these tools are in use in your organization, be sure to capture the relevant log and event information in your reporting console to show to auditors that the broader universe of protected data is being monitored and reported on.
Don’t forget that compliance reporting covers technical IT controls as well as written policy creation and distribution. While a log management solution isn’t a document management tool, it may be possible and advisable to capture the log data from the document tool. Events such as an employee reviewing an acceptable use policy can be brought into the reporting console to round out the compliance reporting coverage.
Finally, be prepared to continue the tuning work as new systems and regulations come online. IT environments and the regulatory landscape change frequently, so don’t expect reporting on these to stay static. Rather, use existing mapping work of policy to controls to leverage re-use where possible. For example, already have unique logins and tight access controls on a database? When a new regulation or standard is activated for your compliance program, look at what is already being reported on. It could be that you’re already gathering the right information. Another area for careful re-use is bringing new systems or applications on-line. Rather than re-invent the compliance reporting wheel, look at how previous versions of the system (or similar versions) were monitored by the log management or SIEM system and confirm that the same level and granularity of compliance reporting can be implemented in the new system. And knowing what, if any, exposures in the reporting system were missing in previous versions of application and systems logs can provide a solid baseline for log and reporting requirements definitions when introducing a new solution.
Log files are treasure troves of data, much of which can be used in effective compliance reporting. To make the most of your solutions, read through the mandates and regulations and translate the words into areas of reporting that can be managed by a log or SIEM solution. Look for exposures in any systems that aren’t already covered and continue to tweak the reporting for new mandates. While this may require a little bit of upfront work, the ongoing benefits for automated compliance reporting will more than make up for the extra effort upfront. And no matter what time of year, more efficient compliance reporting is a great gift we can all appreciate.
1 ISO/IEC 27001:2005, A.10.10.1
Did you know? EventTracker provides over 2000 pre-configured reports mapped to specific FISMA, PCI-DSS, HIPAA, NISPOM and Sarbanes-Oxley requirements.
State pilot shows a way to improve security while cutting costs
The State Department may have cracked a vexing cybersecurity problem. With a program of continuous monitoring…and a focus on critical controls and vulnerabilities (Consensus Audit Guidelines), the agency has significantly improved its IT security while lowering cost.
Did you know? EventTracker supports all 15 automated controls of the Consensus Audit Guidelines to help organizations mitigate the most damaging threats known to be active today.
Compliance as security: The root of insanity
How companies lose their way by confusing a completed compliance checklist with ironclad security…This leads us to the undeniable realization that while a byproduct of security is compliance, the reverse couldn’t be further from the truth.
Did you know? EventTracker doesn’t just help you comply with regulatory requirements, but fundamentally improves your security posture and protects your organization from a wide variety of attacks including , and zero-day attacks
EventTracker 6.4 launches with deep support for virtual infrastructures
EventTracker version 6.4 offers SIEM support for all layers of the virtual environment including the hardware, the management application, the barebones hypervisor, the guest OS, and all resident applications. Also new is a dashboard that identifies any new or out-of-ordinary behavior by user, admin, system, process and IP address to detect hitherto unknown attacks such as zero-day breaches and malware.