SIEMs (Security information and event management systems) are often considered sufficient for certain compliance needs – they “tick” boxes on numerous standards and regulations and have built-in compliance reports.
However, legacy SIEMs don’t always work for the compliance department. While in theory, they support the necessary functionality, in practice they lack some features, but more importantly, they lack the compliance mode of thinking.
Let’s review several aspects that don’t work for the compliance department:
- Non-repudiation and integrity of logs – if your SIEM doesn’t protect the integrity of your logs and doesn’t provide definitive proofs that they have not been modified, they have a much lower value for compliance purposes. Regulators may accept just a bunch of text files, but they are in their full right to demand integrity proofs (and standards and regulations often require it).
- Integrations often miss audit logs – SIEM projects often focus on the main sources of security logs and miss application-specific audit logs. It’s probably sufficient to integrate network devices, OS logs, and ActiveDirectory for security purposes, but your accounting or document management system’s audit log in custom format represents important compliance information – who did what, when? Lack of visibility over those often forgotten logs makes it hard for compliance people to get value.
- No user-friendly way to query and display data – security analysts and outsourced managed service providers are used to the complex queries they have to write to obtain the right information. But compliance people are not necessarily fluent with SQL, for example. SIEMs often lack the option to present pre-defined search templates with friendly visualization of results
- Rules engines focused on security events, not business-level events – if compliance is to use a SIEM for fraud detection, they need more focus on the business-level events that happen in systems. “Unsuccessful login”, “Connection on port 22” and other granular security events are of little use to them. That gets us back to the 2nd point – you can’t have good rules for compliance purposes without proper audit log collection
- Superficial compliance reporting – while most SIEMs have built-in compliance reports, they may not reflect what a local regulator requires. It depends, of course, on regulatory practices, and vendors may have adjusted their reports to regulatory requirements in larger markets and jurisdictions, but a particular missing field or representation may make the regulator or auditor unhappy and deem the whole report either useless or requiring additional manual work.
While Gartner doesn’t differentiate between legacy and next-gen SIEMs, there’s an important feature set and philosophy distinction when it comes to compliance.
LogSentinel SIEM was built with compliance in mind, and our non-repudiation and integrity functionality that provide legal strength, including in court proceedings, has been recognized as a crucial element for compliance. Our business-level rules are used for internal fraud detection beyond security and our rich integrations allow for feeding the right events to those rules.
It’s a good practice to include the compliance department when reviewing a SIEM solution – they may not be the primary user in the organization, but they will certainly benefit from it, and a better SIEM would save a lot of work for the security team when compliance knocks on the door.
If you want to find out how you can leverage LogSentinel SIEM‘s advanced compliance features to ease compliance and reporting, feel free to book a demo today:
Bozhidar Bozhanov is a senior software engineer and solution architect with 15 years of experience in the software industry. Bozhidar has been a speaker at numerous conferences and is among the popular bloggers and influencers in the technical field. He’s also a former government advisor on e-government, transparency, and information security.
