If you have a regulatory element to your organization, the security program is never separate from the compliance program. The same controls that protect you against unauthorized access, data exfiltration and insider threat are usually the same ones that satisfy your audit requirements, demonstrate due care to regulators and deliver the evidence of control for examination by auditors. The problem for security and compliance teams is how to discover technology that can meet both sets of objectives without duplicating workflows or breaking the chain of evidence regulators and auditors count on.
At this intersection, security information and event management software occupies the focal point. They are the platform that logs and retains log data as required by compliance frameworks, applies monitoring controls prescribed by regulators and produces reports for auditors. Knowing what SIEM software brings to each of these functions is not just an intellectual exercise for compliance-driven organizations; it is a requirement for actually being able to craft a security programme that can hold up under external scrutiny.
If you are an organization building or testing your compliance posture, SIEM security software for compliance shows how purpose-built platforms uniquely meet the precise needs of regulated environments at enterprise scale.
Security Monitoring Needs to Consider Compliance Frameworks
Across industries, there is a common theme in regulatory frameworks around security monitoring; organizations must understand what is happening within their systems, demonstrate they are looking and produce evidence of findings when called upon to do so. Each framework has different exact specifications but the operational demand is consistent across them.
Monitor all access to network resources and cardholder data; log for at least 12 months, with a minimum of 3 months immediately available. This is where covered entities must employ audit controls to review activity in information systems that contain protected health information and record that those audit controls are functioning. Financial institutions are required under SOX to have processes that maintain the integrity and availability of financial data, whereas who has access to it as well as what they can do with it is dictated by controls. As per the GDPR, organizations that use European resident personal data must put technical measures into place to be able to detect, contain and report breaches within a defined time-frame.
The functional requirements pertaining to data, which apply across each of these frameworks, are: capture the right data; keep it for however long it is required to be kept; continuously monitor it and be able to generate reports that demonstrate compliance when called upon.
See also: Recognising the Signs of Sleep Apnea in Hong Kong’s Busy Population
The SIEM Contribution to Compliance
Centralized Log Collection And Long Term Storage
SIEM software performs the first compliance task of collecting log data from around the environment into a single, centralized location. Monitor all systems but not just the visible ones, not just the easy to instrument but in short all systems that touch regulated data. This challenge is met by SIEM platforms which pull logs from endpoints, network devices, identity and access management systems, cloud platforms, databases and applications; normalize data into a common format; retain it according to retention policies defined by the organization.
And usually, both individual and organized retention are specific compliance requirements per framework. Each of PCI DSS’s twelve-month requirement, SOX seven-year retention requirement for financial records and HIPAA six-year retention period for security documentation all mandates a minimum enforcement period the platform must reliably guarantee. Regulatory inquiries and litigation holds do not just fetch log data for recent events; therefore, organizations must be assured that the retained data is indexed and searchable across the entire retention window.
Continuous Monitoring and Alerting
Most compliance frameworks do not accept periodic spot-checks as a substitute for continuous monitoring. The FTC’s Safeguards Rule, for instance, explicitly requires financial institutions to implement controls to monitor when authorized users are accessing customer information and to detect unauthorized access and specifies that continuous monitoring of information systems is the preferred mechanism for satisfying the requirement to test safeguard effectiveness. The specific technical requirements for organizations covered by this regulation are documented in the compliance guidance published by the Federal Trade Commission through the data safeguards compliance requirements covering the Safeguards Rule.
SIEM platforms provide ongoing monitoring by cross-referencing log data with detection rules in real time as data is ingested. A privileged account that is accessing a system outside its normal activity, a large transfer of data to an unusual destination and pattern of multiple failed authentication attempts when any such activity becomes true against some rule condition the platform generates an alert that can be routed to the most relevant response workflow. Ongoing assessment generates the written record of monitoring that regulators review for determining if an organization’s controls are functioning as intended.
Logging of Access Monitoring and Privileged Activity
Access control is also a compliance requirement that shows up in almost every regulatory framework and access event monitoring is the way you show compliance with those controls. The fundamental questions of access monitoring are who, when, from where and with what level of privilege. SIEM platforms aggregate access event data from identity systems, authentication logs, directory services and application audit trails into a single source of truth that allows the reconstruction of access histories in an environment to detect violations of access policies.
And one located at the opposite end of the Privileged access spectrum. There is always a risk to data integrity and confidentiality posed by accounts with administrative or elevated permissions, and all compliance frameworks requires that privileged activity be logged, monitored and periodically reviewed. This is where SIEM platforms come into play, because they aggregate all the privileged session data and apply monitoring logic to flag activity that does not fit with expected activity for privileged accounts new access patterns, after-hours activity, or access to systems beyond what the account would normally be used for.
Automated Compliance Reporting
SIEMs have a function for reporting, which converts the operational monitoring work of a SIEM platform into compliance evidence. Pre-built report templates mapped to a particular framework enable compliance and security teams to produce the documentation needed by auditors without having to manually pull together evidence from separate systems. Configured once, scheduled reports can automatically run on the cadence each framework needs (monthly for internal reviews or quarterly for external audits) and be exported into the formats each submission requires.
Now, the scope and freshness of these templates is important. Frameworks evolve. Since then we’ve seen at least three major revisions of PCI DSS, an almost unprecedented emergence of state-level privacy laws like California’s, as well as continued interpretations and enforcement by international regulations like GDPR that shape what organizations must prove. It means maturing to a state where platforms maintain up-to-date compliance content libraries aligned with current framework requirements, eliminating manual effort in keeping reporting compliance aligned with evolving obligations.
The landscape of frameworks that compliance-driven organizations must navigate is extensive and continues to expand across both domestic and international jurisdictions. A comprehensive overview of the major security and privacy laws affecting organizations, including PCI DSS, HIPAA, SOX, GDPR, and a range of US state privacy laws, is available through the reference directory of security and privacy laws directory maintained by CSO Online’s editorial team.
Using SIEM Software in a Compliance-First Environment
Compliance-driven organizations will deploy SIEMs differently to those that want them for threat detection. With compliance as the primary driver, focus is first on collecting the correct data from appropriate source systems, retaining that data for suitable timeframes and then ensuring it is available in relevant formats before extending the platform to cover detection and investigation use cases.
Why this order of operations is important boils down to being practical: compliance gaps are much easier to find and fix before running an audit than during one. Organizations that use SIEM software with compliance coverage as the baseline requirement and layer detection and response capability on top of such a foundation are much more defensible positions both with regulators and during breach investigations.
Source Coverage and Gap Analysis
SIEM should have the capability to map every system that accesses regulated data before deployment, verifying each system is covered under the SIEM’s log collection. Sources outside of scope represent non-compliance, not just non-security compliance and different from security, but could also be disclosed to regulators as a result of the ability (or inability) to reach into that source during an incident.
And the normalization quality for each source also matters. A compliance report that mentions access events across various systems requires those events to be normalized so that the same activity looks exactly the same across all products generating logs. Inconsistent normalization generates barely interpretable reports, and is difficult to support for audit scrutiny.
Establishing Chain of Custody and Data Integrity
Organizations in heavily regulated industries or those exposed to litigation risk should ensure the integrity of log data forms a part of their compliance requirements. Logs that can be edited after they are collected are less good as audit evidence compared to logs in tamper-evident formats. Cryptographic integrity controls for SIEMs or, at minimum, immutability from equivalent storage strengthen the evidentiary basis of retained data.
Frequently Asked Questions
What are the compliance frameworks covered by SIEM software?
Commonly, the frameworks you mention around pipelines are PCI DSS, HIPAA, SOX, GDPR, GLBA and FISMA. SIEM platforms are architected to satisfy each of these disparate requirements, including log retention, access monitoring and audit reporting. A number of platforms offer out-of-the-box reports that are mapped to these frameworks and many new state level regulations like CCPA or New York’s cybersecurity mandates for financial services firms.
How do you prove continuous monitoring using a SIEM to auditors?
The SIEM generates a continuous, reportable record of correlation rules that were active, alerts generated by the SIEM, events investigated, and suppressions applied for auditors to review and verify monitoring was done in an ongoing fashion rather than only periodically. It also provides an indication of the extent of source coverage, which indicates that the platform was indeed receiving data from all systems it had been configured to monitor for the duration of the audit period.
When gaps in log data are discovered in audits?
Log coverage gaps are obvious indicators of timeframes when a monitored source is either down, misconfigured, or not yet onboarded. Authors treat these gaps variably, dependent on the framework and scenario. Those organizations that have written evidence of managing log sources going through change management, monitoring alerts when log sources fail to reach their destination, and can demonstrate that they reacted in a timely manner, are much better placed than those who learn about the gap only when their auditors ask the question. Log sources, which are expected to produce logs in accordance with the detection rules of SIEM platforms that generate alerts when these log sources stop producing data help organizations catch issues before they become an audit finding.
