Compliance has always been a sort of Reactive process since standards are long, take tons of effort and a while to update, even more time to implement and the audit process happens once a year. Coming from the SIEM world I was dealing with Compliance through a prism of canned reports which usually return empty results or something that is very far from being explainable to an external auditor. On the other hand, the underlying logic of the reports and queries is obscure and takes tons of effort to maintain to say the least. To make it work one needs to master correlation rules engine or query language of specific SIEM technology and reporting engine that comes with it, configure tons of lists and exceptions in a static way, while the actual environment is dynamic and just gathering all the data in one place can take many months. And by the time we’re done with these tasks the SIEM tech gets changed or I get to work with another customer who uses a search based security analytics system instead of old school “real time correlation” one. It gets easier if we have a security audit tools like VM scanners which have compliance audit features e.g. Qualys Policy Compliance, Tripwire and similar. However, the latter tools do not build a holistic picture nor a real time one unless connected with a SIEM or Security Analytics platform of some sorts. Then comes the GRC train with massive products and man/years of consulting effort. Boring. Cost inefficient. Guaranteed gaps in visibility. Too slow for the digital era we live in. And how good is all of the above in addressing NIST CSF or GDPR? IMHO Compliance is a reflection of Security, so if you’re doing cyber security right then compliance will follow. This does not work the other way around, however. Time for a change? Yes. And today we’ll get started on the series of articles to make your Compliance an agile, transparent and cost efficient process, fit to modern digital business.
I consider the accelerated adoption of the Sigma rules for SIEM, SOC and Threat Hunting tasks one of the most positive changes in the security industry. And while Sigma is already a de-facto standard for threat hunting queries we got this crazy idea of applying it to establish Continuous Compliance practices. In case you have not heard about Sigma before it is an easy to understand, quick learning curve, platform agnostic and open source language. Examples of the rules and source code https://github.com/Neo23x0/sigma and tutorial to get started https://www.nextron-systems.com/2018/02/10/write-sigma-rules/
If you have Elastic stack, Splunk, ArcSight, QRadar, Qualys, Microsoft Windows Defender ATP, Logpoint, Greylog: you can get value out of Sigma rules for security and hunting already. These platforms are likely part of your infosec / SOC and they have tons of data usable for compliance. And it is even more likely that you have an Elastic stack, premium or community version used in various business units of your organization which can have data for automated compliance controls. One of the important reasons for Sigma evolution and global adoption is its native support of MITRE ATT&CK https://attack.mitre.org. In case you’re reading this article and not coming from infosec: MITRE ATT&CK is the blockchain of cyber security or the periodic table of elements of chemistry. So we have an open source, widely adopted standard that is easier to learn than any query language of any SIEM and supports tagging with ATT&CK methodology to perform TTP attribution on the fly. What if we would add tags relevant to Compliance standards? Have a query for automated control according to CSC 8.2 or finding systems that process personal data for GDPR? For Sigma this is just another tag, so technically this is a logical next step of the evolution.
It is no secret that while personally I am a big supporter of Sigma, I do not write that many rules myself at this point. For detailed HOWTO guidance, I caught Alex Yamposlkyi for a quick chat. Alex, being one of the very active Sigma rules developers, in terms of developed rules quantity second only to Florian Roth, has provided some very practical insights.
AB: “Alex, have you already developed any Sigma rules for Compliance?”
AY: “Yes, it’s been a few busy months. You can find some examples at Sigma official GitHub repo: https://github.com/Neo23x0/sigma/tree/master/rules/compliance and at SOC Prime Threat Detection Marketplace: https://tdm.socprime.com/?sigmaTypes%5B%5D=Compliance ”
AB: “Great. Is there any particular algorithm you follow when creating Compliance Sigma rules?”
AY: “I guess I can describe this as a 5 step process:
AB: “This sounds like a quick win. Can we try to extend this to a step-by-step instruction?”
AY: “Yes. Here is a quick note.
We can actually mix tags for ATT&CK and Compliance. In an example above “CSC8.2” is the corresponding control number per CSC domain; “attack.persistence” is MITRE ATT&CK tactic and attack.t1053” is a specific technique that control is focused on.
An updated Sigma code will look like this
Once I publish rules to Threat Detection Marketplace I also get meta-data generated for rules by pressing “Parse Sigma Content tags” button.
In the “Tags” list I can cross-link the rules with any Compliance Standards such as ISO, PCI, NIST CSF, etc.
Our conversation went on for another hour with enough material for an interview on SOC Prime Threat Bounty program. Until then, any feedback on Sigma for Compliance is highly appreciated.
And if you would like a sneak peek on how the end result looks like on the Elastic stack, check out the video at https://my.socprime.com/en/continuous-compliance