Sigma Rule Pdf

[Graciano Goudreau]

Thisblog post argues for SIGMA as a detection language, covers the most critical SIGMA rule components (logsource & detection), SIGMA taxonomy, testing SIGMA Rules, and generally prepares analysts who are new to SIGMA to write their first rules. A short discussion on detection engineering with SIGMA is also provided regarding noise, ideas, log sources, etc.

In the past, SIEM detections existed in vendor / platform specific silos. Partners wishing to share detection content often had to translate a query from one vendor into another. This is not sustainable, the defensive cyber security community must improve how we share detections to keep pace with our ever-evolving adversaries.

Much like YARA, or Snort Rules, SIGMA is another tool for the open sharing of detection, except focused on SIEM instead of files or network traffic. SIGMA allows defenders to share detections (alerts, use cases) in a common language.

First released in 2017 by Florian Roth and Thomas Patzke, SIGMA is paving the way forward for platform agnostic search. With SIGMA, defenders are freed from vendor & platform specific detection language and repositories and can harness the power of the community to respond timely to critical threats and new adversary tradecraft.

There are many other resources such as the official wiki and some guides written by SIGMA experts (listed below). There are certain traps such as proper handling of wildcards or incorrect field names that can cause broken rules and many of these are addressed in these resources.

For Windows endpoint rules, Sysmon is a great place to start. Sysmon is commonly deployed in environments, and many log sources provide synonymous data (EDRs, etc). With Sysmon there are two main options, process creation (process_creation in SIGMA) and file create (file_event in SIGMA).

We will build our detection off of process creation as it is more broadly adopted, thus ensuring our rule is as useful as possible. Process creation is a great log source to learn from and it is one of the most useful / popular log sources used in endpoint detections.

Note: Often ideas come directly from data sources themselves. By reviewing the types of data available to you in your SIEM / Lab one can easily identify SIGMA rules worth writing. We can also use other sources like vendor documentation.

Additionally, often telemetry can contain similar fields but imply entirely different behaviors. For instance, Sysmon network connection events (Event Id 3) and process creation (Event ID 1) share the Image field. The existence of explorer.exe in the Image field of a Sysmon network connection event is completely different from the existence of explorer.exe in a process creation event. By providing the proper logsource component we provide invaluable context to the detection.Detection componentThe detection component is where the author defines their detection criteria. This includes at least one selection component and a condition component. There is an optional timeframe component which is required for correlation based rules.

Selections are named (e.g. selection, selection2, selection3, filter). Selections can be named (almost) anything you want. Often a variation of selection is used, but one can just as easily name their selection banana and the rule would still work. Generally, the term filter is used for selections that will be excluded (e.g. selection AND NOT filter).

Then finally if no config or rules exist we use the original field names from the originating log source. If field names come from nested values (e.g. userIdentity nested under accountId in aws cloudtrail) we use a period to indicate that the field is nested as this is relatively consistent across different SIEMS (e.g. userIdentity -> accountId becomes userIdentity.accountId).

Note: From a rule author perspective, generally you should not worry about the backend implementations of rules. It is up to the SIGMA backend authors, and folks like SOC Prime to ensure that the translations meet the original intention of a valid rule. If a bug is identified, it is always worth submitting an issue to GitHub.

We will explore the fundamental concepts of Sigma Rules, how they standardize threat detection, and their significance in the ever-evolving cybersecurity landscape. Additionally, we will examine an example of Sigma Rules, including its structure, syntax, and essential components to guide you through writing your first sigma rule. Finally, we will look at common mistakes made during the development of a sigma rule.

A Sigma rule is an open-source, generic signature format used in cybersecurity, specifically for the creation and sharing of detection methods across Security Information and Event Management (SIEM) systems. Sigma rules translate and standardize threat-detection practices, making them accessible and reusable regardless of the SIEM platform in use.

Similar to how YARA rules use Indicators of Compromise (IoC) to aid in the identification and classification of malware instances, Sigma rules match specified criteria to log events, to facilitate incident detection.

Sigma rules are written in YAML syntax, which is a human-readable and easy-to-implement format. Once you have written a Sigma rule, you can convert it to a format that fits your target SIEM or platform using an online converter. There are many different platforms that support Sigma rules, including Splunk, Elasticsearch, and Microsoft Defender.

Sigma rules provide a universal language that security analysts can use regardless of the Security Information and Event Management (SIEM) or log management system being implemented. This standardization simplifies log parsing and rule creation, as Sigma rules need to be written once and can then be automatically translated for use with various platforms, thereby enabling a more efficient use of resources and maximizing analysts' productivity.

An open-source nature allows for Sigma rules to be shared and refined via platforms like GitHub, fostering a communal environment that encourages the exchange of knowledge and ideas. The shared repository reduces redundancies and allows for the collective knowledge to better the cybersecurity industry as a whole.

By exchanging ideas and Sigma rules across the cybersecurity community, the environment fosters a culture of shared learning. Both novices and experts alike can contribute to and learn from this communal knowledge base, bridging the cybersecurity skill gap. The broader sharing of Sigma rules facilitates the sharing of novel detection techniques, fostering constant growth and development among security analysts.

The ability to convert Sigma rules to any vendor format grants security teams the flexibility to migrate from one SIEM system to another seamlessly, without losing the value of existing rules. This feature can help organizations avoid the trap of vendor lock-in and also make it easier for them to scale their cybersecurity operations with changing needs.

The sigma rule that we are about to dissect is designed to detect the attempt of SharpSecDump usage, a credential harvesting tool, ported from python/impacket to .net. This technique is commonly utilized for credential dumping. Adversaries may attempt to dump credentials to obtain account login and credential material, normally in the form of a hash or a clear text password, from the operating system and software [1].

No rule is fail-safe. While there isn't a specified list of scenarios that could result in false positives, recognizing the possibilities for such occurrences helps analysts use their judgment when alerts are triggered.

For example, Sigma can be used to create Splunk searches that detect threats. To do this, you would need to create a Sigma rule that defines the criteria for detecting a threat. Once you have created the Sigma rule, you can import it into Splunk and run it against your Splunk logs. If the Sigma rule matches any of your logs, Splunk will generate an alert.

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 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.

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,

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.

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.

3a8082e126