To access the Detection Rule page:
Go to the Threat Detection Marketplace and select the Search tab.
Select the needed detection rule from the list.
To learn how to search for and filter the rules, follow this guide.
After opening a Detection Rule page, first learn more about the rule and the related threat on the Detection Intelligence tab, and then get the rule on the Detection Code tab.
The top of the page includes:
Use Case: Each detection has one or several icons next to its title to visually differentiate the applicable use cases.
Icon | Use Case | Description |
| Proactive Exploit Detection | Detection rules for proactive threat detection to anticipate potential attacks on infrastructure |
Active Directory Security | Content related to Azure Active Directory (AD) | |
| Cloud Security | Content for cloud-based products and IaaS, SaaS, or PaaS data sources |
| Endpoint Detection Enhancement | Content related to the endpoint security |
| Threat Hunting | Threat hunting hypotheses for proactive cyber defense |
| Compliance | Detection rules to ensure compliance |
| IOC Sigma | Detection rules based on IOCs (Indicators of Compromise) rather than behavior |
| AI Generated Content | Content created by the SOC Prime AI models. |
| Mixed/Other | Content that doesn't fully belong to other cases |
Content type: Each Sigma rule belongs to one of the following two content types:
Alert: Intended for real-time detection (rarely generates false positives).
Query: Intended for threat hunting (may generate a considerable rate of false positives and require fine-tuning according to your Data Plane).
Average rating: The average score the content item has received based on its approved rating and reviews. The number in parentheses indicates how many users have reacted to this content item.
Downloads: The number of downloads of the content item.
Repository name: The name of the repository the content item lives in.
Content author: The author of the content item.
Content availability: Availability of the content item depending on your subscription plan.
In the upper-right corner of the page, select the three-dot menu, and then choose one of the actions from the pop-up menu for the content item:
Mark As deployed
Hide in Search Results
Exclude from Attack Detective Scans
Custom content can be published and shared. Please note that publishing a content item makes it available to all or a subset of the SOC Prime Platform users.
Detection Intelligence Tab
Here you can find the intelligence on the related threat and the rule's metadata. Use this info to put the threat into context and look at it in terms of the MITRE ATT&CK framework. Find out everything you may need before deploying the rule for alert or running it as a hunting query.
The Detection Intelligence tab represents the following information:
Detection Stack tags: The tag is highlighted in green if the detection corresponds to that type
Query: Search over data for hunting/triage; may not auto-alert.
This tag is applied if the rule has at least one translation of type Query.
Alert: Rule-triggered signal indicating activity to review or escalate.
This tag is applied if the rule has at least one translation of type Alert.
ETL: Data pipeline stage: extract, normalize, and load telemetry.
This tag is applied if the rule is defined with
sigma type: IOC.AIDR: GenAI protection gateway that runs rule/similarity/code/ML/LLM checks to detect & block prompt-injection and harmful content before it hits AI apps.
This tag is applied if the rule has a Semgrep translation.
Severity: Describes the criticality of the triggered rule
Critical: Highly relevant event that indicates an incident. Critical events should be reviewed immediately.
High: Relevant event that should trigger an internal alert and requires a prompt review.
Medium: Relevant event that should be reviewed manually on a more frequent basis.
Low: Notable event but rarely an incident. Low-severity events can be relevant in high numbers or in combination with others. An immediate reaction shouldn't be necessary, but a regular review is recommended.
Informational: Rule is intended for enrichment of events, e.g. by tagging them. No alerts should be triggered by such rules because it is expected that a huge amount of events will match these rules.
Status. Describes the level of stability of the rule
Stable: the rule may be used in production systems or dashboards.
Test: an almost stable rule that possibly could require some fine-tuning (in some Sigma rules this status has a legacy name Testing).
Experimental: a rule that could lead to false-positive results or be noisy, but could also identify interesting events.
Author: Author(s) of the rule
Released Date: When the rule was released
Updated: When the rule was updated last time
Category, Product, and Service: log data on which the detection is meant to be applied to. It describes the log source, the platform, the application and the type that is required in the detection
Category: All log files written by a certain group of products, like firewalls or web server logs
Product: All log outputs of a certain product, e.g. all Windows Eventlog types including Security, System, Application and the new log types like AppLocker and Windows Defender.
Service: Only a subset of a product's logs, like the sshd on Linux or the Security Eventlog on Windows systems.
Depending on data availability, there are certain sections that may be displayed on the Detection Intelligence tab. Click the plus icon on the corresponding tile to expand and see more information.
Timeline: Key references about the threat ordered by its lifecycle stages. Use the Timeline to quickly dive into the context.
Audit Configuration: Provides guidance on the logging requirements and configurations needed for this detection; generated by SOC Prime AI models.
False Positives: Provides information on possible false positives or benign activities and how to avoid them. Includes data generated by SOC Prime AI models as well as entries from the original content.
Short Summary: Concise summary of the detection logic in human language; generated by SOC Prime AI models.
Full Summary: Detailed explanation of the detection logic in human language; generated by SOC Prime AI models; generated by SOC Prime AI models.
Decision Tree: Decision tree of a detection logic that explains how it works step by step, with all the embeddings, branches, and other intricate logic; generated by SOC Prime AI models.
Binaries: Malicious executable files associated with the malicious activity detected by the rule.
Triage Recommendations: Info on possible ways to validate and investigate suspected malicious activity; generated by SOC Prime AI models.
MITRE ATT&CK COVERAGE: Techniques, sub-techniques, tools, and actors mapped to the rule. Click an attribute to see its detailed description.
Tags: Use tags to quickly understand the rule. You can click a tag to open a new Advanced Search page with rules filtered by that tag
The first tag defines the type of the Sigma rule
Threat Hunting Sigma– behavior-based rule for threat hunting and proactive cyber defenseIOC Sigma– IOC-based rule for detecting vulnerabilities or attacks that have already occurredCompliance– rule for detecting mismatches against the compliance standards
Platforms: Native formats of security platforms the Sigma rule is translated into
ala-rule– Microsoft Sentinel Ruleala– Microsoft Sentinel Queryelasticsearch– Elasticsearch Query (Lucene)es-eql– Elasticsearch Query (EQL)xpack-watcher– Elasticsearch Watcherelasticsearch-rule– Elasticsearch Detection Rule (Lucene)es-rule-eql– Elasticsearch Detection Rule (EQL)kibana– Kibana Saved Searchelastalert– Elasticsearch ElastAlertqradar– Qradar Queryhumio– Falcon LogScale Queryhumio-alert– Falcon LogScale Alertsplunk– Splunk Querysplunk_alert– Splunk Alertsumologic– Sumo Logic Querysumologic-cse– Sumo Logic CSE Querysumologic-cse-rule– Sumo Logic CSE Rulearcsight-esm– ArcSight Rulearcsight-keyword– ArcSight Querylogpoint– LogPoint Querygrep– Regex Grep Querypowershell– PowerShell Querygraylog– Graylog Querykafka– Apache Kafka KSQL Queryrsa_netwitness– RSA NetWitness Querycarbonblack— VMware Carbon Black Cloud Querycarbonblack-edr— VMware Carbon Black EDR Queryopen-ioc– FireEye OpenIOCfireeye-helix– FireEye Helix Querychronicle– Google SecOps Rulesecuronix– Securonix Querys1-events– SentinelOne Events Querys1-process– SentinelOne Process State Querymdatp– Microsoft Defender for Endpoint Queryqualys– Qualys IOC Querysysmon– Sysmon Rulecrowdstrike– CrowdStrike Endpoint Security Querylimacharlie– LimaCharlie Ruledevo– Devo Querysnowflake– Snowflake Queryathena— Amazon Athena Queryopendistro-query— Amazon OpenSearch Queryopendistro-rule— Amazon OpenSearch Rule
Authors: Authors of the Sigma rule.
Log Sources: Logs you need to have to use the rule. These tags are comprised of the Category, Product, and Service.
Data Sources: MITRE ATT&CK categories of subjects/topics of information that has to be collected by your sensors/logs to use the rule.
Data Components: MITRE ATT&CK sub-categories of specific properties/values of a data source relevant to detecting a given technique or sub-technique.
Event ID: Identifiers of particular events on Windows systems you need to collect to use the rule.
CVE ID: Identifies assigned to a publicly disclosed computer security flaw whose exploitation the detection rule detects.
Custom Tags: Any other tags used to describe the detection rule, e. g. a hacking group or exploit name the rules is mapped to.
Relation Graph: Enables to visually explore related detection content based on shared metadata tags (e.g., MITRE ATT&CK). Each tag in the rule’s metadata acts as a link, connecting you to other rules with the same tag. The graph is limited to the 10 most relevant related rules, selected by the number of shared tags. You can:
Hover over a tag or rule name on the graph to highlight its connections to other related tags and rules.
Click a rule name to open it in the Detection Rule page.
Click a tag to view all detections associated with that tag on the Search page.
Drag the graph, open it in full screen, and change scale.
Comments & Reviews: Available for detections from the SOC Prime Repository or Community (content selected from Platform Repos or Community on the Search page). Use this section to provide a review that will help the community pick up the best detections and improve what needs further tuning. You can:
Leave a comment
Rate the detection content
Leave an anonymous review by selecting the corresponding checkbox
Mention other users using
@; mentioned users will receive an email notificationReply to the comment in a thread
Comments: Is available for detections from Custom Repositories (content selected from My Repos on the Search page). Comments are visible only to users within your organization. You can:
Leave a comment
Edit and delete a comment
Mention other users using
@; mentioned users will receive an email notificationReply to the comment in a thread
You can also use the Detection Code tab to leave a comment on a detection.
The Audit Configuration, False Positives, and Triage Recommendations sections allow you to report an issue if you encounter a problem. To do so, click the Report Issue button, enter the issue details in the modal, and click Submit.
Detection Code Tab
On this tab, you can select the translation you need, automatically customize it, and deploy the rule or run the query in your Data Plane.
Select a Translation
On the left pane, select the platform for which you need a translation of the chosen Sigma rule.
Then, if there're multiple native formats available above the code, select the one you are interested in.
Automatically Customize the Code
Config for alternative translations
When an alternative data schema gains in popularity among organizations using a particular SIEM, we start supporting it by adding an alternative translation configuration. If an alternative data schema is used in your security platform, for example OSSEM for Microsoft Sentinel, select its name in the Config dropdown.
Note: The Config dropdown appears only for rules that have alternative translations. If the dropdown is absent, it means that no alternative translations are available.
Custom Field Mapping
Sigma rule translations on the SOC Prime Platform are based on the standard data schema of the corresponding SIEM. Accordingly, if non-standard tables/indexes or fields are used in your Data Plane, translated rules require customization.
Customizing tables/indexes, field names, or field values in the rule code manually is a tedious task prone to errors. That's why we provide capabilities for configuring Custom Field Mapping profiles where you can specify all relevant custom tables/indexes, field names, or field values and map them to the default ones. Create a profile once, and apply it on the fly each time you deploy a rule or send a query to your Data Plane.
Learn more about Custom Field Mapping in a dedicated section of this Guide.
Preset
Presets are templates to customize content deployment to your organization's SIEM. They help streamline content management operations and avoid errors that can occur when manually editing content.
The parameters you can configure depend on the selected platform. Most of them represent various code sections of the platform's native content format. You can also add a prefix or a suffix to all rules deployed from the SOC Prime Platform to clearly identify them.
In addition, you can link filters to a particular preset. Filters are extra conditions you can add to the detection logic before deployment. Use them to exclude or include certain sets or specific items, such as particular users or hosts.
The Preset dropdown appears only for those platform formats where this feature is supported. Learn more about Presets in a dedicated article.
Filter
Filters are extra conditions you can add to the detection logic before deploying a rule/launching a query. Use them to exclude or include certain factors, such as specific users or hosts.
The Filters dropdown appears only for those platform formats where this feature is supported.
Learn more about Filters in a dedicated article. Configured Filters can also be linked to Presets and used in Automation.
Use the Code
Fine-tune and use the selected Sigma rule translation with the action menu on the right (available actions depend on content format).
Open in Uncoder AI. Open the Sigma rule or its translation in Uncoder AI to edit the code, translate it to a different language/format, save the code to your custom repository, or update the existing translation/save it as a new rule.
Edit. Manually edit the code to fine-tune it before copying, deploying, or running.
Mark as Deployed. After deploying the rule manually, click this button to mark the rule as deployed. This will ensure correct insights in your organization’s Dashboard, Log Source Coverage, and MITRE ATT&CK Coverage.
Guide. For some content formats, you can check a guide describing general deployment procedure and its fine points.
Search. Run the query in your Data Plane via integration. If you have no Data Plane integration configured, a set up modal will appear.
Report Issue. Reach out to us if you face any challenges with the code or have ideas on improving it.
Copy to Clipboard. Copy the code to clipboard to paste it in your Data Plane.
Copy URL to Clipboard. Copy the URL of the page with your platform selected to share it.
Add to List. Add the rule to your Static Content List. Learn more about Lists here.
Deploy. Deploy the rule into your Data Plane via integration. If you have no Data Plane integration configured, a set up modal will appear.
Download. Download the rule.
Push to Repository. Push content via GitHub or AzureDevOps integration.







