Nexus Sentinel
Your security telemetry is everywhere. Your response is not.
Nexus Sentinel is a sovereign SIEM and SOAR. It centralises security telemetry, detection, correlation, investigation, case management and governed automated response inside your own estate, so a signal becomes a decision and an evidenced action without leaving your boundary.
- 01
Collect
Normalised telemetry from your estate.
- 02
Detect
Sigma rules, severity and ATT&CK tags.
- 03
Correlate
Related alerts become one signal.
- 04Gate
Respond
Governed runbooks with approval gates.
- Runs inside your estate, including air-gapped environments
- SovereignRuns inside your estate, including air-gapped environments
- Sigma detection content you can read, author and port
- Open rulesSigma detection content you can read, author and port
- Approval gates on the actions that need them
- Human controlApproval gates on the actions that need them
- Append-only record of alerts, decisions and outcomes
- EvidenceAppend-only record of alerts, decisions and outcomes
The problem
Security teams are not short of signals. They are short of a single place where a signal turns into a governed action.
Most security operations functions have accumulated tools rather than an operating model. The result is visible in the queue every morning.
Telemetry is fragmented across tools
Endpoint data sits in one console, application firewall events in another, traffic and load balancer logs in a third, and identity events somewhere else again. Reconstructing one incident means five logins and a spreadsheet, and the timeline is assembled by hand every time.
Alert volume outpaces the analysts
Rules fire faster than anyone can read them. Without correlation and deduplication, one ongoing condition produces hundreds of near-identical rows, and genuine high severity activity competes with noise for the same attention.
Point tools carry weak context
An alert that arrives without asset ownership, prior case history or related activity on the same host is a research task, not a finding. Analysts spend their day rebuilding context that the platform should already hold.
Response is either manual or ungoverned
Teams end up choosing between running containment by hand at three in the morning, or handing a script broad authority with no approval, no timeout policy and no record of who decided what. Neither survives an audit or a serious incident review.
Security data leaves the estate
Many analytics platforms require telemetry, detections and case content to be shipped to a vendor tenant. For government, defence, critical infrastructure and regulated enterprises, that is a jurisdiction and classification problem before it is a technical one.
What Sentinel is
One sovereign operations layer, from telemetry through response and audit.
Sentinel is a SIEM and a SOAR in a single product, not a log store with an automation add-on bolted to the side. Collection, detection, correlation, investigation and response share one data model, one identity model and one audit record.
On the SIEM side, Sentinel ingests and normalises security telemetry, retains it under lifecycle policies you configure, and evaluates it against detection rules written in an open format. On the SOAR side, the same product runs ordered response runbooks with timeouts, retries, failure policies and approval gates, then writes the outcome back to the case that triggered it. Joining them preserves context: a detection knows the agent that produced it, the case it belongs to, the techniques it maps to and the actions already taken against the same host.
Sentinel is the security operations layer of the Nexus product line. Nexus Shield enforces protection at the point of request and Nexus Edge handles traffic infrastructure. Both produce telemetry that Sentinel ingests and correlates next to endpoint activity.
Operational boundaries
Detection and response, not traffic infrastructure
Sentinel analyses, decides and orchestrates. Enforcement at the request layer belongs to Shield and traffic distribution to Edge, both of which Sentinel can consume and drive as response actions.
Retention follows customer policy
Hot, warm, cold and deletion stages are configured to your retention obligations, with index health, cluster health and storage consumption visible to the team that owns the platform.
Automation runs under authority
Response actions execute with the permissions you grant, against the scope you define, and pause for a named authoriser wherever your policy says they should.
Operations workflow
Collect, detect, correlate, investigate, approve, respond, audit.
The same path runs for every signal, whether it completes in seconds without a human or waits at an approval gate for a decision. Approval is a first-class control applied where consequence warrants it, not a tax on every action.
- 01
Collect
Endpoint, load balancer, application firewall and behavioural telemetry arrive in one normalised stream.
- 02
Detect
Sigma detection rules evaluate events and raise alerts with severity and ATT&CK technique tags.
- 03
Correlate
Threshold-over-window rules group related alerts and suppress repeat firings of the same condition.
- 04
Investigate
Serious signals create or feed a case with observables, tasks, assignee and full context.
- 05Gate
Approve
Actions that carry operational consequence pause for a named authoriser before they run.
- 06
Respond
Runbooks execute ordered actions across endpoint response, behavioural blocking, notification and integrations.
- 07
Audit
Every alert, decision, approval, action and outcome is written to an append-only record.
- 08
Improve
Coverage gaps, noisy rules and failed steps feed the next round of detection and runbook engineering.
Automatic where it is safe, human where it matters
Operations view
The state of the operation on one screen.
Alert volume and high severity volume over the last 24 hours, open cases, agent fleet health, severity breakdown, recent alerts, event trends and the mix of ingestion sources feeding the platform.
Security operations overview
- Alerts, 24h
- 1,284
- High severity, 24h
- 37
- Open cases
- 12
- Agents
- 486 / 512
Across all ingestion sources
Eligible for case creation by policy
Assigned, triaged and in progress
Active of total enrolled
Severity breakdown
- High9%
- Medium34%
- Low57%
Ingestion sources
- Endpoint agents
- Application firewall
- Load balancer and traffic
- Behavioural enforcement
- Platform and integrations
Recent alerts
- 09:41Credential dumping tool signature on workstationHigh
- 09:38Repeated authentication failures followed by successMedium
- 09:33Scheduled task created by unexpected parent processMedium
- 09:27Outbound connection to newly observed destinationLow
- 09:22Application firewall blocked injection attemptLow
Illustrative structure of the operations view, not a customer environment.
Volume
Alerts and high severity over 24 hours
Workload
Open cases and fleet status
Coverage
Ingestion source counts
Endpoint visibility
A managed agent fleet, enrolled under control.
Sentinel tracks total, active, disconnected and pending agents, with identity, IP address, platform, operating system, agent version, group membership, status and last seen time held against each one.
Endpoint agent fleet
| Identity | Platform | Version | Status | Last seen |
|---|---|---|---|---|
| ws-fin-0142 | Windows 11 | 4.9.2 | Active | 12 seconds ago |
| srv-app-021 | Linux, RHEL 9 | 4.9.2 | Active | 31 seconds ago |
| ws-ops-0087 | macOS 15 | 4.8.7 | Disconnected | 4 hours ago |
| srv-db-004 | Linux, Ubuntu 24.04 | 4.9.2 | Pending | Enrolment link issued |
Enrolment is controlled. New endpoints join through expiring installer links issued by an authorised operator, so an agent cannot be added to the fleet with a credential that was pasted into a runbook eighteen months ago and never rotated.
Fleet state is an operational signal in its own right. A cluster of hosts moving to disconnected is a collection gap, and a collection gap is a detection gap. Sentinel surfaces it next to alert volume rather than hiding it in an administration screen.
Search and retention
Index health and lifecycle stages
Sources
More than endpoints
Detection engineering
Open detection content, mapped to MITRE ATT&CK, tested before it goes live.
Rules are written in Sigma, an open and portable format. You can run public rule content, rules provided with Nexus, and rules authored by your own detection engineers, and you can read and change all of them.
rules/credential-access/lsass-memory-read.yml
Rule metadata
- Format
- Sigma, open and portable
- Severity
- High
- ATT&CK
- T1003.001T1055
Rules compile and lint as they are edited, dry run against sample events before deployment, and are converted into the Sentinel search and detection layer once enabled. Severity, technique mappings, recent firing activity and enable or disable state are held against each rule.
Pre-deployment checks
- Syntax compilepassed
- Field and schema lintpassed
- Dry run against sample events6 matches, 0 errors
- Technique mapping present2 techniques
- Deployment stateenabled
MITRE ATT&CK coverage by tactic
- Initial access18 rules, 3 gaps
- Execution26 rules, 2 gaps
- Persistence21 rules, 4 gaps
- Privilege escalation17 rules, 4 gaps
- Defence evasion29 rules, 3 gaps
- Credential access22 rules, 3 gaps
- Lateral movement14 rules, 5 gaps
- Exfiltration11 rules, 6 gaps
Coverage
Heatmap by tactic and technique
Gaps
Gap analysis drives the backlog
Language
Mapped to, not certified
Correlation
Many alerts, one situation.
Correlation rules evaluate a threshold over a time window and group related alerts by agent, source or rule, so the queue reflects situations rather than repetitions.
Raw alerts
- 09:33 auth-failure ws-fin-0142
- 09:34 auth-failure ws-fin-0142
- 09:35 auth-failure ws-fin-0142
- 09:37 auth-success ws-fin-0142
- 09:41 credential-access ws-fin-0142
Correlation rule
- Window
- 10 minutes
- Threshold
- 5 contributing alerts
- Group by
- Agent identity
- Minimum severity
- Low and above
- Emits
- High severity correlated signal
While the condition persists, repeat firings are deduplicated against the same key rather than raising a new alert every time the threshold is met again.
Correlated output
CORR-2291 Suspected credential attack on ws-fin-0142
One signal reaches the queue with the contributing alerts attached, so the analyst opens a situation rather than a page of near-identical rows.
Configurable
You own the thresholds
Deduplication
One key while the condition persists
Operability
Run history and on-demand evaluation
Investigation
Cases hold the context, the observables and the decisions.
Serious alerts create or feed a case according to the policy you configure. The queue is live, filterable and shared, and each case carries the material an analyst needs to reach a conclusion.
The case queue shows severity, status, MITRE ATT&CK tags, deduplication key, assignee and age, with filters across each of them and live updates as the shift works. Nothing needs to be refreshed by hand to see that a colleague has already claimed an item.
Case detail holds the observables gathered during investigation, including IP addresses, file hashes and domains, the analyst task list for the investigation itself, and the execution history of every response action taken against the case. The investigation and the response live in the same record.
Because cases inherit the platform identity model, who did what is never a question of reconstructing from logs afterwards. Assignment, comment, task completion, approval and action are attributed as they happen.
- Queue fields
- Severity, status, MITRE ATT&CK tags, deduplication key, assignee, age, with filters and live updates.
- Observables
- IP addresses, file hashes, domains and other indicators gathered during the investigation.
- Tasks
- Analyst task lists that structure triage and record completion against the case.
- Response history
- Every runbook execution against the case, with per-step status and the identity that authorised it.
Response
Runbooks that execute in order, under policy, with people in the loop.
Response runbooks are event triggered and run ordered steps across endpoint response, behavioural blocking, notifications and integrations, with a timeout, a retry count and a continue-or-abort failure policy on each step.
Response runbook
Trigger: Correlated signal, severity high, group endpoint
- 01
Enrich the alert
Query internal context, asset ownership and prior case history
- Timeout
- 30s
- Retries
- 2
- On failure
- Continue
- 02
Isolate the endpoint
Endpoint response action against the affected agent
Human approval required- Timeout
- 60s
- Retries
- 1
- On failure
- Abort
- 03
Block the source
Behavioural enforcement rule applied at the protection layer
- Timeout
- 45s
- Retries
- 2
- On failure
- Continue
- 04
Notify the duty analyst
Notification to the on-call channel and case assignee
- Timeout
- 20s
- Retries
- 3
- On failure
- Continue
- 05
Raise the downstream ticket
Integration action into the service management system
- Timeout
- 45s
- Retries
- 2
- On failure
- Continue
- 06
Write the outcome to the case
Append action results, identities and status to the case record
- Timeout
- 20s
- Retries
- 1
- On failure
- Abort
Runbooks are validated before deployment, and every execution is recorded as succeeded, partially completed or aborted with the reason attached.
Actions
Pluggable action library
Reliability
Timeouts, retries and failure policy
Control
Validation before deployment
Powered by Nexus
Built on the same execution layer we sell as a platform.
Sentinel is powered by Nexus, the embedded execution and governance engine. Orchestration, approval gates, integrations, secret handling, functions, audit and human-in-the-loop control come from the engine that ships inside the product. That is why a response action can pause for a named authoriser, call a line-of-business system, use a vault-backed credential and land in an append-only audit record without anyone assembling that plumbing per customer. Sentinel is bought as a product, and Nexus is included in it.
You do not need to buy or implement the Nexus platform to run this product. The shared foundation is why the product deploys into your environment, keeps its data local and produces an audit record you can inspect.
Explore the Nexus platformEvidence and audit
One timeline that survives the incident review.
The case timeline records the detection, the correlation, the analyst work, the approval decision, the actions taken and the outcome, with identities and timestamps against each entry.
CASE-4471 Suspected credential attack on ws-fin-0142
Severity: HighStatus: In reviewTechniques: T1003.001, T1110Dedup: agent:ws-fin-0142:credAge: 41m
- 09:41:07Detection ruleCredential dumping signature raised as high severity on ws-fin-0142, tagged to two ATT&CK techniques.
- 09:41:09CorrelationGrouped with four related alerts on the same agent inside a ten minute window and deduplicated under one key.
- 09:41:11Case policyCase opened automatically, severity high, queued to the endpoint triage group.
- 09:44:32Analyst, L2Case claimed. Observables recorded: two IP addresses, one file hash, one domain. Triage task list started.
- 09:47:05RunbookEnrichment step completed. Isolation step paused awaiting approval as configured for that action.
- 09:48:20SOC leadIsolation approved with a written justification attached to the case.
- 09:48:26RunbookEndpoint isolated, source blocked at the protection layer, duty analyst notified, downstream ticket raised.
- 10:12:44Analyst, L2Investigation tasks closed, outcome recorded, case moved to review with the full action history attached.
Attribution
Named identities, not service accounts
Integrity
Append-only record
Reporting
Evidence without reconstruction
Use cases
Where Sentinel is deployed.
The common thread is an operation that must keep its security data inside its own boundary while still running detection, investigation and response at pace.
01
National CERT and government SOC
A central capability that must retain telemetry, detections, cases and evidence within national jurisdiction, with open detection content that can be inspected rather than trusted.
02
Defence and disconnected operations
Deployment in air-gapped and intermittently connected environments, where detection content and runbooks are delivered through controlled transfer and nothing depends on an outbound vendor service.
03
Regulated enterprise SOC
Financial services, healthcare and utilities operations that need retention policy, approval evidence and a defensible audit record alongside day-to-day triage.
04
Critical infrastructure
Operators consolidating endpoint, network and application signals across corporate and operational estates, with response actions gated so containment never surprises an engineering team.
05
Multi-tenant or institutional SOC
Managed providers, government departments and institutional groups running one capability across several tenants with separation, identity, role-based access control and audit.
06
Telemetry consolidation programme
Teams retiring overlapping consoles by bringing endpoint, application firewall, traffic and behavioural telemetry into one correlated operations layer.
Why Sentinel
What separates it from a log platform with automation attached.
Sovereign by design
Self-hosted in your environment, on premises, in a sovereign cloud, or air-gapped. The product does not require security telemetry, detections, cases or evidence to leave the organisation in order to work.
One execution layer for detection and response
Detection, correlation, case management and response runbooks share the same engine, identity model and audit record. The handover from analysis to action is not an integration project.
Open detection content through Sigma
Rules are readable, portable and yours. Public content, Nexus-provided content and your own detection engineering coexist in one library, with compile, lint and dry run before anything reaches production.
ATT&CK visibility with honest gap analysis
Coverage is presented by tactic and technique with rule counts and recent firing activity, which makes the uncovered part of the matrix as visible as the covered part.
Human-controlled automation
Approval is a configurable control on the actions that carry consequence, with the authoriser, the justification and the timestamp recorded. Automation earns trust by being governed, not by being unrestricted.
It inherits the Nexus operating model
Integrations, workflow execution, secret handling, functions and audit come from the embedded engine. Sentinel connects to the systems your organisation already runs without a bespoke connector programme per customer.
Deployment and trust
Installed where your security data is allowed to live.
Sentinel is deployed into a customer-controlled environment and operated by your team, under your identity, access and retention policy.
- Deployment
- Self-hosted in a customer-controlled environment: on premises, sovereign cloud, or air-gapped where required.
- Data residency
- Telemetry, detections, cases, observables and response history remain inside the organisation.
- Identity and access
- Single sign-on, multi-factor authentication and role-based access control across the operations workspace.
- Multi-tenancy
- Tenant separation with per-tenant identity, access control and audit for shared or managed operations.
- Secrets
- Vault-backed credential handling for every integration and response action, inherited from Nexus.
- Audit
- Append-only audit logging across detections, cases, approvals, runbook executions and administrative change.
- Observability
- Index and cluster health, ingestion source counts, agent fleet status and retention and storage visibility.
- Content supply
- Detection content and runbooks can be delivered through your controlled transfer process in disconnected environments.
Operating model
Your team runs it
Scope
Sentinel, Shield and Edge
Language
Claims we do not make
FAQ
Questions security leaders ask first.
How an engagement starts
Most teams begin with one telemetry source and one runbook.
A scoped deployment proves the path end to end before the estate migrates: connect a source, enable a rule set, correlate it, open cases from it, and run one governed response with an approval gate.
Scope the sources and the retention obligation
Agree which telemetry enters first, what the hot, warm, cold and deletion policy needs to be, and what the storage envelope looks like for that volume.
Deploy inside your environment
Sentinel is installed in the environment you control, integrated with your identity provider, and access is granted through role-based control from day one.
Enable and tune detection content
Start from public and Nexus-provided Sigma content, dry run against sample events, and record the ATT&CK coverage position you are starting from.
Correlate and open cases
Configure the first correlation rules, set the policy for which alerts create cases, and put the queue in front of the analysts who will live in it.
Run one governed response
Build a runbook with an approval gate, validate it, execute it against a real case, and review the resulting evidence with the people who will own the process.
Sentinel briefing
Bring your alert queue to the conversation.
A Sentinel briefing works best with a real problem in front of it: the sources you cannot correlate, the alerts nobody can keep up with, or the response you are not allowed to automate yet. We will walk the path from collection to signed-off action against your own operating constraints.