SOC engineers’ workload lightened by Cymulate’s off-the-shelf sigma rules SOC engineers’ workload lightened by Cymulate’s off-the-shelf sigma rules-mask

Cymulate’s Off-the-Shelf Sigma Rules Lighten SOC Engineers’ Workload

With SOC operations workload never getting any lighter, sigma rules are a boon to accelerate their operation, maybe even enough to free the time to go out and have fun for a bit.

The chronic SOC engineers’ bloated workload relies on three main reasons:

  • Endemic skill shortage: the demand for experienced SOC engineers continues to far exceed the pool of available talent
  • Event Volume levels are on an exponential growth curve that shows no sign of leveling out
  • Tool sprawl and underutilized SIEM and SOAR fail to noticeably lighten SOC engineers’ workload

The first two are unlikely to get better any time soon. The last one can considerably benefit from a Continuous threat Exposure Management (CTEM) approach, but, regardless, Sigma Rules greatly accelerate SOC engineers’ work.

What Are Sigma Rules?

Sigma Rules are YAML-written textual signatures designed to identify suspicious activity potentially related to cyber threat anomalies in log events. One of the main advantages of these rules is their standardized format that permits writing the rule once and applying it across various SIEM products without needing to rewrite the rule.

The main focus of Sigma rules is to detect log events matching criteria established by the SoC engineer. This is especially useful for creating Incident Response detection or automated responses.

So yes, such rules can considerably lighten the SOC engineer workload, from reducing false-positive alerts to granularly automating response.

Yet, these rules still have to be written, or imported from an open-source library, costing the time to identify the adequate sigma rule for a specific case.

How to Write a Sigma Rule

The first step to writing a Sigma rule is to define your goal. The goal can be any number of things, such as monitoring occurrences or a specific log event to detecting instances of a string associated with an exploit, for example.

Regardless of its goal, a rule consists of a few required sections and several optional ones. As Sigma is a very flexible standard, there is no fixed format, which provides infinite freedom but also requires rules writers to be self-disciplined, focused, and combine being exhaustive with being minimalist to avoid unnecessary clutter.

GitHub SigmaHQ’s Rule Creation Guide provides extensive guidance on the best practices for writing Sigma rules.

Benefits of Sigma Rules

As an open-source community project, Sigma rules enable security operations teams to create queries in the Sigma rule format instead of vendor-specific SIEM languages. This means that a single rule is automatically translated into SIEM-specific code with a single click.

For example, this rule, written to detect access to printconfig.dll, an activity to would put the printer at risk of being breached, and thus potentially leak confidential information, would read as follow for Azure Sentinel SIEM tool,

Sigma rule written to detect access to printconfig.dll


and the same rule would automatically be translated into the following code for Splunk


The piece of sigma rule translated into code for Splunk


In practice, this means that a rule available on open-source for one specific SIEM in Sigma rule format is immediately available for everyone, regardless of the SIEM tool they use.

Meet Cymulate’s Off-the-Shelf Rules

So now that it is clear that Sigma rules are a game-changer and can save SOC engineers considerable time, let’s consider how to further accelerate the Mean Time to Resolution (MTTR).

Once Cymulate’s assessment detects a security gap, it is listed in the report and includes a complete breakdown of the assessment’s attack technique that breached your infrastructure.

The technical information card for that emulated attack includes a full description, a list of detection commands, API calls, events, and more to monitor, mitigation recommendations, an analysis of the attack, the related tags, a list of the data sources involved and, most notably for this blog post, a ready-made sigma rule to include in your SIEM.

To create a rule, all your SOC engineer has to do is navigate to the scenario summary technique information card’s Sigma Rules tab and then select the relevant SIEM tool and click the Generate button.

For example, suppose an assessment detected a security gap and your defensive array uses Arcsight and Sumo Logic SIEM software. In that case, all that is required is to select them one after the other from the drop-down menu and generate the rule.


Screenshot of the technique information card’s Sigma Rules tab, choosing Arcsight from drop-down menu


Screenshot of the created sigma rule by the SOC engineer


The only remaining action required is to copy-paste the rule into the relevant SIEM tools.

When taking into consideration the number of times this operation has to be repeated, the total work time Cymulate’s built-in Sigma rules save SOC engineers might even let them grab that after-work drink with friends that remained an unattainable dream until now.

Try Cymulate Exposure Management and Security Validation platform to see  CTEM in your unique environment by starting a free 14-day trial.

Start A Free Trial

Related Resources

Solution Brief

Full Kill Chain APT Simulation Module

Download the solution brief on the Full Kill Chain Advanced Persistent Threat Simulation module.

READ MORE arrow icon


APT Ready in Four Steps – Your Action Plan

Learn how you can establish an automated, continuous system to defend against sophisticated cyber attacks using Cymulate.

READ MORE arrow icon

Solution Brief

Cymulate Breach and Attack Simulation Made Simple

Cymulate challenges your security controls against the full attack kill chain with thousands of simulated cyber attacks, showing you exactly where you’re exposed and how to fix it.

READ MORE arrow icon