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.

 

How you use it

  1. Upload a Sigma rule (.yml ) one rule, or many at once (bulk import).
  2. Preview Logsign shows you exactly how the rule will be translated (which columns, which conditions) before anything is saved. 
  3. Import the rule is saved as a Logsign alert.
  4. Review & enable every imported rule arrives disabled. You review it and enable it manually when you are ready.

You can also select files in bulk and start the upload, up to a maximum of 1,000 files.

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.
  • Rules that use a single exclusion ( selection and not filter ).
  • 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, you can define the mapping yourself in the UI (which Sigma field → which Logsign column). After saving, re-import the rule and it will use your mapping.

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 is shifted up one level by design (a Sigma high becomes a Logsign critical, etc.) so imported detections are not under-weighted.

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 you get a per-rule result (imported / rejected with reason).

Will importing change my existing alerts? No. Imports are created as new, disabled alerts. Nothing existing is modified and nothing fires until you enable it.

The rule references a field Logsign doesn't know. What do I do? Define a custom mapping in the UI (Sigma field → Logsign column) and re-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.