Sigma Rules Import Module

What is this?

Logsign One can import detection rules written in the Sigma format, the open, vendor-neutral standard for SIEM detection rules (YAML files, widely published by the community, e.g. the SigmaHQ project). You upload a Sigma rule and Logsign converts it into a native Logsign alert that runs on your own log data.

You do not need to rewrite community rules by hand. Import them, review, and enable.

To open the importer, go to Settings > Alerts & Incidents > Alert Rules and click Import Sigma above the rule list. The button is visible to users whose role allows editing alert rules.

How you use it

  1. Upload a Sigma rule (.yml or .yaml): one rule on the Single Rule tab, or many at once on the Bulk Import tab. On the Single Rule tab you can also paste the YAML into the YAML Content box. Each file must contain a single rule and cannot exceed 1 MB. Choose the target Category; if you leave it as Sigma Imported (default), the rules are placed in a category with that name.
  2. Preview: click Preview. Logsign shows you exactly how the rule will be translated (generated alert name, target category, generated severity, generated conditions and log source) before anything is saved.
  3. Import: click Import and the rule is saved as a Logsign alert. The button becomes active only after a successful preview of a supported rule.
  4. Review & enable: every imported rule arrives disabled. You review it and enable it manually when you are ready.

On the Bulk Import tab you can also choose files with Select Files or a whole directory with Select Folder and click Start Bulk Import. Up to 1,000 files can be selected at once.

Why disabled by default? This is a safety choice. An imported rule never starts firing on its own. You stay in control and turn it on after review.

Supported log sources

If your environment sends these log types to Logsign, Sigma rules targeting them can be imported:

Area Sources
Windows Sysmon (all event types), Security / System / Application event logs, PowerShell
Linux auditd, syslog, process / file / network activity
Network & firewall Firewall, DNS, Zeek, Cisco, FortiGate, Juniper, Huawei
Web Web servers & proxies (Apache, Nginx, IIS)
Cloud AWS CloudTrail, Microsoft Azure, Microsoft 365, Google Cloud (GCP)
Identity Okta, Cisco Duo, OneLogin
Endpoint / other macOS, antivirus, database, application logs

What kinds of rules import cleanly

  • Rules that match fields with equals, contains, starts-with, ends-with, numeric comparisons ( > , >= , < , <= ), and "field exists".
  • Rules that combine several conditions with AND (including "all of" selections).
  • Rules that use a single exclusion ( selection and not filter ). The filter must be a single field; negated starts-with, ends-with, numeric and "exists" conditions are not supported.
  • Web rules that search for keywords in the request (these are matched against the URL/query field).
  • MITRE ATT&CK technique tags and the rule description are carried over (the description lands in the alert Notes field).

What is not supported (and why)

Logsign follows a "safe by default" rule: if a Sigma rule cannot be translated exactly, it is not imported instead of importing it with the wrong meaning and having it silently misfire. The preview always tells you the reason. The main cases:

  • OR logic between selections and bracketed/grouped conditions: the current engine evaluates flat AND only.
  • "1 of …" / "1 of them" patterns (these need OR semantics).
  • Regular-expression matching and a few advanced text transforms ( base64 , cidr ,windash , case-sensitive match, …).
  • Full-text keyword search on non-web log sources (keywords are only supported on web/proxy sources, mapped to the URL field).
  • "field does not exist" and field-to-field comparisons.
  • A field used by the rule that has no equivalent column in your Logsign schema (you can define the missing mapping yourself, see below).
  • Correlation rules (multi-event aggregation): single-event rules only.

When a rule is rejected, this is expected behaviour, not an error. It means the rule cannot be run faithfully yet, not that the rule is "broken".

Custom field mappings

If a rule references a field that Logsign does not map automatically, the preview on the Single Rule tab lists it under Unmapped Sigma Fields. Pick the matching Logsign column for each Sigma field and click Preview again; the preview is regenerated with your mapping and you can then import the rule. Tick Save this mapping permanently if you want the mapping to be reused for later imports, including bulk imports.

Known limitations

  • DNS-query rules that inspect the calling process (e.g. "DNS query made by regsvr32.exe"): these import, but because Logsign's DNS-query events do not carry the originating process, that specific condition will not match at runtime. The rule is imported but effectively dormant.
  • Linked / nested "related" rules are not followed; each rule is imported on its own.
  • Severity mapping: Sigma levels are mapped by design so that imported detections are not under-weighted. critical becomes Emergency, high becomes Critical, medium becomes Warning, and low and informational both become Information. The generated severity is shown in the preview.

FAQ

Why was my rule not imported? It uses a feature that cannot be translated faithfully yet (e.g. OR logic, regex, a correlation rule, or an unmapped field). The preview shows the exact reason. This is by design: Logsign refuses to import a rule it would run incorrectly.

A rule imported but never fires. Why? First check it is enabled (imports arrive disabled). If it targets dns_query and filters on the calling process, see "Known limitations". Otherwise confirm the relevant log source is actually reaching Logsign.

Can I import many rules at once? Yes. Bulk import accepts multiple files; each is converted independently, and the Bulk Import Results table shows the Imported, Failed and Already Exists counts, with the reason for every failed rule.

Will importing change my existing alerts? No. Imports are created as new, disabled alerts. If an alert with the same name already exists, the rule is skipped and counted as Already Exists. Nothing existing is modified and nothing fires until you enable it.

The rule references a field Logsign doesn't know. What do I do? Map it under Unmapped Sigma Fields in the preview (Sigma field → Logsign column), click Preview again, and import.

In one sentence

Import community Sigma rules into Logsign, preview the exact translation, and enable the ones you trust, with a safety net that refuses to import anything it cannot run faithfully.

Was this article helpful?
0 out of 0 found this helpful

Articles in this section

See more
Become a Certified Logsign User/Administrator
Sign-up for Logsign Academy and take the courses to learn about Logsign USO Platform in detail. Enjoy the courses, and get your badges and certificates. In these courses, you'll learn how to use Logsign in your work and add value to your career.
Visit Our Blog
Our Logsign USO Platform illustrate our expertise. So do the blog. Through our blog posts, deepen your knowledge on various SecOps topics or get updated about important news & modern approaches for cybersecurity. Get into the habit of reading valuable information provided by Logsign. Be a step ahead.