How to process Elastic Security alerts with Sigma detections in Security Onion ?

[nayadmohamed]

Version

2.4.211

Installation Method

Other (please provide detail below)

Description

other (please provide detail below)

Installation Type

Standalone

Location

other (please provide detail below)

Hardware Specs

Exceeds minimum requirements

CPU

16

RAM

128GB

Storage for /

1TB

Storage for /nsm

1TB

Network Traffic Collection

other (please provide detail below)

Network Traffic Speeds

Less than 1Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

Yes, there are additional clues in /opt/so/log/ (please provide detail below)

Detail

Hello,
Thank you for the previous explanations, they helped me better understand how Security Onion handles detections and Elastic alerts.

I am currently doing an internship and I am still learning how Security Onion detection pipelines work, so I may ask beginner questions.

After your previous answer (#15909), I added the Elastic alerts index so that the alerts generated by Elastic Security become searchable in SOC / Hunt:

soc > config > server > modules > elastic > index [adv]

I added:

.internal.alerts-security.alerts-default-*

This works correctly for search and dashboards, and I can now see the Elastic alerts in SOC/Hunt.

However, I am now facing another issue regarding Sigma detections.

From my understanding:

• Elastic Security alerts are stored in:
  .internal.alerts-security.alerts-default-*
• But Security Onion detections / Sigma seem to query mainly:
  .ds-logs-*

When I test Sigma conversion / EQL generation, I still see queries using:

GET /.ds-logs-*/_eql/search

So even though the Elastic alerts are searchable in SOC, Sigma rules do not seem to evaluate those indices.

My goal is:

• Use Elastic Security rules for detections (SSH brute force, off-hours login, etc.)
• Then make these alerts visible / usable inside Security Onion SOC detections and workflows

I am trying to understand what the recommended architecture is.

My questions:

1. Is it expected that Sigma detections only work on .ds-logs-* and not on .internal.alerts-security.*?

2. If we want Sigma to process Elastic-generated alerts, what is the recommended approach?

For example:

• Reindexing .internal.alerts-security.* into a logs-* index?
• Using an ingest pipeline?
• Logstash?
• Another supported approach?

3. Is modifying the Sigma / detection backend index pattern recommended, or would that break expected behavior?

I tested adding the index in SOC configuration, but Sigma conversion still appears to target .ds-logs-*.

I just want to make sure I am approaching this correctly and not fighting against the intended Security Onion workflow.

Thank you again for your help and patience.

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[cm-ops]

The ability to select the data view/index is something that is being working on for sigma rules. You could write a custom Elastalert rule to target those - https://docs.securityonion.net/en/3/main/elastalert/#custom-rules and https://docs.securityonion.net/en/3/main/elastalert/#custom-rules You would want to use the alert modules.so.securityonion-es.SecurityOnionESAlerter you can see an example in /opt/so/rules/elastalert/rules

[nayadmohamed]

Thank you for your help. I managed to get it working successfully. I really appreciate your guidance!