Detection and response
Run SIEM and SOAR inside your own environment, not inside a vendor's cloud.
Nexus Sentinel ingests telemetry, correlates it into alerts, enriches those alerts with context, and routes response actions through the same workflow engine used across Nexus, with people kept in control of consequential actions.
- SIEM and SOAR in one product
- SovereignSIEM and SOAR in one product
- alerts, not raw log lines
- Correlatedalerts, not raw log lines
- response with human review where required
- Governedresponse with human review where required
- record of every decision and action
- Auditedrecord of every decision and action
The buyer problem
Detection and response often means sending your telemetry somewhere else.
A cloud SIEM asks you to ship logs, endpoint telemetry and network data into a vendor-hosted platform, then charges again for the automation to act on it. For organisations that must keep operational data inside their own boundary, that starting condition is a blocker before the tool's detection quality is even evaluated.
The result is either a sovereignty gap accepted under pressure, or a self-managed open-source stack stitched together with no vendor support and no coherent workflow layer underneath it.
What changes
SIEM and SOAR, unified, and run where your data already lives.
Category
Log ingestion
What that category does
A cloud SIEM ingests logs into a vendor-hosted data lake, often billed by ingestion volume.
Where Nexus sits
Sentinel ingests and stores logs inside your environment, without shipping raw telemetry to a third party.
Category
Detection and correlation
What that category does
Detection rules run in the vendor's infrastructure against your data.
Where Nexus sits
Correlation runs on the same execution layer used across Nexus, inside your boundary.
Category
Response automation
What that category does
SOAR playbooks are often a separate purchase, integrated after the fact.
Where Nexus sits
Response actions use the same connector library and workflow engine as the rest of the platform, not a bolted-on add-on.
How it works mechanically
Ingest, correlate, enrich, decide, respond, record.
- 01
Ingest
Log and telemetry sources are ingested from endpoints, network devices, cloud services and applications into Sentinel.
- 02
Correlate
Events are correlated against detection rules to surface an alert: repeated failed logins followed by a successful one from a new location.
- 03
Enrich
The alert is enriched with identity, asset and threat context pulled through connector actions, without an analyst manually pivoting across tools.
- 04
Route for decision
A confidence and policy check determines whether the case is auto-closed as benign, escalated to a human analyst, or auto-contained under a pre-approved policy.
- 05
Respond
Approved response actions run through the Nexus workflow engine: disable the account, isolate the host, notify the on-call responder.
- 06
Record
The alert, enrichment, decision and response actions are captured as an audit record and used to tune future correlation rules.
Worked example
An anomalous login becomes a contained incident.
Illustrative Sentinel case
Representative output, not a live customer instance
- Case 4821: Impossible travel loginfinance-analyst@example-corp.com, new geographyEscalated
- Enrichment: device not previously seenNo matching MDM recordHigh confidence
- Response: account disabled pending reviewAuto-contained under approved policyActioned
- Response: host isolationHeld for analyst approval, non-standard hostAwaiting review
Auto-contained actions follow a pre-approved policy; anything outside that policy is held for a human decision before it runs.
What you get
A working SOC loop, not a log dashboard.
Correlated alerting
Alerts arrive already correlated against detection rules and enriched with identity and asset context, cutting the manual pivoting between tools.
Governed response
Response actions run under policy: some auto-execute within approved bounds, others are held for a human analyst to approve or reject.
Full audit record
Every alert, enrichment, decision and response action is retained, supporting incident review and framework mapping after the fact.
Where it deploys
Kubernetes-agnostic, inside your boundary.
Deployment options
Sentinel deploys on-premises, in a private cloud, in a sovereign cloud, or air-gapped, alongside the log and telemetry sources it ingests.
Identity and access
Analyst and administrator access follows your existing SSO, MFA and RBAC, with role-based visibility into cases and response actions.
Connected to the rest of Nexus
Response actions use the same connector library, code nodes and human-in-the-loop approval model as workflows built for other parts of the business.
Buyer roles
Who runs security operations day to day.
Architecture session
See a Sentinel case handled end to end.
We will walk through ingestion, correlation, enrichment and a governed response action, running against representative data.