Security Analytics: Event Normalization, Detection Queries, Alert Volume, Long Retention, and Investigative Search

Learning outcomes

1. AtlasMart problem: the same login event arrives in five vendor dialects

Security analytics starts with event normalization. A detection cannot be trusted if source.ip, user identity, action, outcome, process name, or file hash change field names by source. ECS helps Elastic normalize security data; OpenSearch Security Analytics ships detector workflows and maps supported log types to detection rules, including Sigma-based content. Neither removes the need to verify the actual event-to-rule mapping.

Define the layers: a raw event is observed activity; a rule encodes suspicious conditions; a finding is a rule match or detector result; an alert is a routed state that warrants attention; a correlation links multiple findings/events into a higher-level scenario. Treating each failed login as a page is an alert-volume design bug.

2. Portable security-event fixture

All Chapter 28 labs keep the existing local endpoints and security assumptions: Elasticsearch at https://localhost:9200 with ELASTIC_PASSWORD and the copied CA file atlasmart-es-http-ca; OpenSearch at https://localhost:9201 with OPENSEARCH_INITIAL_ADMIN_PASSWORD. OpenSearch's demo certificate trust bypass (-k) is acceptable only for this disposable local lab, never production. The shared Docker network remains atlasmart-search. Lab indices use one primary and zero replicas so a single-node workstation can complete the exercises; production redundancy decisions are deliberately separate.

PUT atlasmart-security-events-v1
{
  "settings":{"number_of_shards":1,"number_of_replicas":0},
  "mappings":{
    "dynamic":"strict",
    "properties":{
      "@timestamp":{"type":"date"},
      "event.category":{"type":"keyword"},
      "event.action":{"type":"keyword"},
      "event.outcome":{"type":"keyword"},
      "source.ip":{"type":"ip"},
      "user.name":{"type":"keyword"},
      "host.name":{"type":"keyword"},
      "rule.id":{"type":"keyword"},
      "tenant.id":{"type":"keyword"},
      "message":{"type":"text"}
    }
  }
}

POST _bulk?refresh=wait_for
{"index":{"_index":"atlasmart-security-events-v1","_id":"S-001"}}
{"@timestamp":"2026-09-12T12:10:00Z","event.category":"authentication","event.action":"login","event.outcome":"failure","source.ip":"203.0.113.50","user.name":"alex","host.name":"portal-1","tenant.id":"tenant-a","message":"Login failed"}
{"index":{"_index":"atlasmart-security-events-v1","_id":"S-002"}}
{"@timestamp":"2026-09-12T12:10:20Z","event.category":"authentication","event.action":"login","event.outcome":"failure","source.ip":"203.0.113.50","user.name":"alex","host.name":"portal-1","tenant.id":"tenant-a","message":"Login failed"}
{"index":{"_index":"atlasmart-security-events-v1","_id":"S-003"}}
{"@timestamp":"2026-09-12T12:10:40Z","event.category":"authentication","event.action":"login","event.outcome":"failure","source.ip":"203.0.113.50","user.name":"alex","host.name":"portal-1","tenant.id":"tenant-a","message":"Login failed"}
{"index":{"_index":"atlasmart-security-events-v1","_id":"S-004"}}
{"@timestamp":"2026-09-12T12:11:00Z","event.category":"authentication","event.action":"login","event.outcome":"success","source.ip":"203.0.113.50","user.name":"alex","host.name":"portal-1","tenant.id":"tenant-a","message":"Login succeeded"}

3. Portable detection baseline: prove the event evidence first

POST atlasmart-security-events-v1/_search
{
  "size":0,
  "query":{
    "bool":{
      "filter":[
        {"term":{"tenant.id":"tenant-a"}},
        {"term":{"event.category":"authentication"}},
        {"term":{"event.action":"login"}},
        {"term":{"event.outcome":"failure"}},
        {"range":{"@timestamp":{"gte":"2026-09-12T12:10:00Z","lte":"2026-09-12T12:11:00Z"}}}
      ]
    }
  },
  "aggs":{
    "by_source_user":{
      "composite":{
        "size":100,
        "sources":[
          {"source":{"terms":{"field":"source.ip"}}},
          {"user":{"terms":{"field":"user.name"}}}
        ]
      }
    }
  }
}

The fixture should show three failures for the same source/user before a success. That is evidence, not an incident verdict. A production detector might include impossible travel, device history, MFA state, threat intelligence, or an account lockout signal. The portable baseline intentionally avoids pretending one simple threshold equals a mature detection.

4. OpenSearch Security Analytics: detector → finding → alert → correlation

OpenSearch 3.8 includes the Security Analytics plugin in the standard distribution. Current documentation describes detectors that apply rules to mapped log types, generate findings, optionally generate alerts, and correlate findings across log types. Sigma rules are a key content format, but the detector still depends on correct field mapping and permissions. Security Analytics system indexes are protected; users should receive scoped Security Analytics roles/actions rather than unrestricted cluster credentials.

For the lab, first validate the raw-query baseline above. Then, if the plugin is enabled in your local distribution, map the normalized fields and create a detector for the appropriate log type. The plugin result is an additional implementation surface—not the definition of the suspicious behavior itself.

5. Elastic Security: normalize first, then select solution-specific detections

Elastic Security similarly depends on normalized event fields and supports rule/detection workflows whose availability and advanced capabilities vary by deployment and subscription. Do not write the course as though OpenSearch Sigma detector JSON can be pasted into Elastic, or vice versa. Preserve the intent—data source, condition, schedule, severity, suppression, investigation fields, and response—then implement with the product’s current rule surface.

6. Alert-volume engineering

7. Retention and investigative search

Investigations often require long lookback windows and joins/correlations that differ from real-time alerting. Retention must follow legal, business, and forensic requirements, not a copied “30-day logs” policy. Long retention may justify lower-cost tiers, snapshots, or a separate security cluster. The important design variable is recovery/investigation time under real incident conditions.

8. Mini lab: portable finding plus optional platform detector

1. Run the baseline failure query and store the source/user/count/window as a deterministic “finding.”
2. Query the subsequent success event. Decide whether the combination should increase severity; document the rule logic.
3. Create a reader role that can inspect atlasmart-security-events-v1 but cannot write/delete it. Use product-specific security APIs from Chapters 19–20.
4. If using OpenSearch Security Analytics, map the fields and create a lab detector; compare its finding to the raw-query evidence.
5. Measure how many alerts would result from 100 repeated failure events under no suppression versus grouped suppression. Report counts from your run, not invented values.

References and current-version checks

• Elastic Stack 9.5.3 release
• Elasticsearch 9.5.3 release notes
• Elastic Common Schema 9.5 reference
• ECS getting started and normalization
• ECS log fields
• Elastic Observability fields and object schemas
• Elastic ECS-formatted application logs
• OpenSearch 3.8 version history
• OpenSearch Security Analytics overview
• OpenSearch Security Analytics detectors
• OpenSearch Security Analytics access control
• OpenSearch APM configuration
• OpenSearch Trace Analytics
• OpenTelemetry logs data model
• OpenTelemetry service semantic conventions