Continuous Compliance as a Code P1: Sigma

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.

Sigma rules evolution and link to Compliance

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.

How to write Sigma rules for Compliance

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:

1. Learn the initial CIS control at https://www.cisecurity.org/controls/cis-controls-list/
2. Understand which of the log source in your organization can be used to cover the particular control’s requirements.
3. Search your SIEM platform for the needed events.
4. Once proper events are discovered decide on the rule logic: having a log entry corresponds to an event that is good or bad for compliance. Ask yourself a question: does this log entry control pass or fail?
5. Code the resulting event into Sigma rule, removing any platform specific search parameters to keep it SIEM agnostic. Add tags from item #1 and schedule automated search.”

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.

1. Select the specific domain for the control you’re building, for example, “Malware Defenses” which corresponds to CSC domain #8.
2. Dig deeper into this control’s description, in our case 8.2 reads as “Ensure that the organization’s anti-malware software updates its scanning engine and signature database on a regular basis.”
3. Think what needs to happen on the system to pass or fail this control. For 8.2 it means that if AV service is stopped or there is an error with its update we fail the control. Thus, we need to track the AV event log, specifically for service stop and update error events.
4. It is pretty easy to track this particular control, we have to install an AV product. In my case, this was a Symantec product integrated to Elastic stack using Logstash. After sorting logs for a while, I found the event I was looking for responsible for download and deployment of the updates which contains following strings “Downloaded new content”, “An update for”.
5. By checking which fields contain these keywords I can make a simple Elastic query: (event.name:(“Downloaded new content”)) OR (event.name:(“An update for”))
6. Now we make a decision on the rule logic: is having the event good or bad. In our case having the log entry is positive and means control is passed. To automate the process we will code the Sigma rule and apply it to platform specific saved search mechanism. In my case, I schedule a Watcher to run on Elastic stack with time interval specific to my environment.
7. Let’s write a Sigma rule
   
8. In this example, I may decide to schedule an alert when events are missed for a certain period of time. With other examples, the situation can be the opposite and we may need an alert when we do discover an event.
9. Now our rule needs all the relevant tags so I will go ahead and add them in this format
   Tags:
   – CSC8.2
   – attack.impact
   – attack.t1489

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

/Stay safe