Security Monitoring (SIEM)

The SIEM is AI-evaluated and EU-sovereign by design. Customer log data is stored in the EU (GCP Amsterdam) and never leaves the region for normal operation. AI evaluation runs on Amazon Bedrock in an EU region, so investigations and verdicts stay within European infrastructure.

Because it is built on the same LPQL + ClickHouse engine as the rest of the platform, every detection is just an LPQL query on a schedule, and every alert is something you can click into, pivot from, and re-run interactively. The defining architectural choice is Risk-Based Alerting (RBA): rather than paging on every rule match, detections contribute risk to the entities they touch (user, host, IP). When accumulated risk crosses a threshold, a single notable is opened for that entity.

LogPulse ships with 50+ built-in detections written in LPQL. Each detection is a scheduled query that runs on an interval, evaluates recent data, and emits risk events for the entities it matches. Detections are tagged with the relevant MITRE ATT&CK tactics and techniques so coverage can be measured and gaps identified.

# Custom detection: repeated failed admin logins from one source
auth.signin
| where outcome == "failure" and user.is_admin == true
| stats count() as failures by source.ip, user.name
| where failures >= 10

# Sequence detection (multi-stage), per user, 15m window
sequence by user.name within 15m
  [ auth.signin where outcome == "failure" ] count >= 5
  [ auth.signin where outcome == "success" ]
  [ iam.role_change where action == "grant" and role.privileged == true ]

Risk-Based Alerting is the core of the SIEM. Instead of firing an alert for every rule match, every signal — a detection match, an AI verdict, or an anomaly — emits a risk event attributed to one or more entities (user, host, IP). Risk accumulates on the entity over time, and only when the entity's risk crosses a threshold is a notable opened.

Every signal that contributes risk is written as a risk event you can inspect, search, and pivot from. Around these sit an analyst dashboard for triage and a full investigation workflow on each notable.

LogPulse includes a built-in IOC reputation store fed by free, reputable threat-intel feeds: AlienVault OTX, AbuseIPDB, the abuse.ch suite (Feodo Tracker, URLhaus and ThreatFox), and the Spamhaus DROP and ASN-DROP blocklists. The store is used to automatically enrich risk events — when a detection touches an IP that is known-bad, the risk is boosted and the resulting notable is tagged with the threat-intel match, so analysts see the reputation context without leaving the alert.

On top of the feeds, each organization can maintain its own allow/deny watchlists. A deny-list entry forces a known-bad classification (for entities you have confirmed internally), while an allow-list entry suppresses noise from sources you know to be benign (for example, a scanning service you operate).

web.access
| where status >= 400
| threatintel source.ip
| where threat.verdict == "malicious"
| stats count() as hits by source.ip, threat.source, threat.score
| sort hits desc

auth.signin
| where outcome == "success"
| iplocation source.ip
| stats count() as logins by user.name, geo.country, geo.asn
| sort logins desc

Security telemetry from cloud and identity providers is ingested through built-in connectors and normalized to canonical, CIM/OCSF-aligned data models. Normalization means a detection written against, say, an authentication model works across sources without rewriting field names per vendor.

These join the existing platform connectors — Azure DevOps, GitHub, Railway, and Cloudflare — so application, infrastructure, and security data live side by side in the same engine.

User and Entity Behavior Analytics adds detections that depend on an entity's own history rather than a static rule. Findings flow into the same risk model and open or augment notables, tagged with a behavior:* label so they are easy to filter.

When a notable is opened, LogPulse runs an AI auto-investigation that gathers context, correlates the contributing risk events, and forms a verdict. Investigations that conclude a notable is benign close it automatically, keeping the analyst queue focused on real incidents.

Because every detection and AI verdict is tagged with MITRE ATT&CK tactics and techniques, LogPulse renders a coverage heatmap derived from your currently enabled content. The heatmap shows which tactics and techniques are covered, helping you see and close gaps in your detection surface as you enable packs or add custom detections.

Entity 360 is a single unified view of an entity — a user, host, or IP — combining a security lens and an observability lens. The security lens shows accumulated risk, open notables, and IOC reputation; the observability lens shows the services, KPIs, and telemetry already tracked for that entity. The same view is reachable from both the security hub and the observability hub, so an analyst and an SRE arrive at the same full-context page from different directions.

The SIEM produces control-coverage reports that map regulatory controls to the detections and data that evidence them. Supported frameworks include NIS2 (Article 21), DORA (ICT risk management), and ISO 27001. Each report shows which controls are evidenced by active detections and ingested data, and reports can be delivered on a schedule.

For the platform's broader certification status, DPA, sub-processors, and data residency, see the Compliance & Trust page.