SentraMind
中文 Private Evaluation
← All crew Design-partner roadmap M5 Security Log Intelligence

Correlator

Reconstructs attack chains across the systems that each saw one piece.

What changes for the organisation

Attack chains spanning SIEM, EDR, DNS, proxy and VPN get told as one story instead of six alerts.

How it works

Your existing SIEM, IDS and anomaly engines do the high-volume filtering. The LLM receives bounded, structured event groups — never raw packets or every log line — and reconstructs the chain with ATT&CK mapping and cited supporting evidence.

What it watches
  • Normalized findings and selected telemetry from SIEM, EDR, AD, VPN, DNS, proxy, firewall, email, cloud and on-premises applications, and network flow
  • Authentication, device, time, location and privilege-use patterns
  • Beaconing, suspicious DNS, anomalous transfer and lateral-movement indicators
Log-source coverage

The log families Correlator can bring into one investigation

Correlator is designed for selected, security-relevant events already produced by your on-premises estate and security stack. Connectors parse each source into a canonical event model while retaining the original event identifier, timestamp, host and provenance, so a narrative can always point back to evidence.

Source family Common sources Signals we can correlate
Identity & access Active Directory, domain controllers, Windows logon events, LDAP, Kerberos, RADIUS, SSO/MFA, PAM and VPN concentrators Sign-in success/failure, ticket use, account and group changes, privilege elevation, MFA events, impossible travel and unusual access paths
Endpoints & servers Windows Event Log, Sysmon, Linux auditd/journald/syslog, Unix auth logs, EDR/HIDS findings and file-integrity monitors Process and service creation, command lines, file/registry changes, scheduled tasks, network connections, device events and sensor health
Network & perimeter Firewalls, IDS/IPS, routers, switches, wireless controllers, NAC, DNS, DHCP, VPN, proxy, secure web gateway and NetFlow/IPFIX Connections, denies, DNS queries, address leases, remote sessions, beacon timing, east-west movement and unusual transfer patterns
Web, API & applications IIS, Apache, NGINX, reverse proxies, load balancers, WAF/API gateways, application audit logs and framework logs Requests, status codes, routes, sessions, authentication/authorisation failures, admin actions, data export and application-specific security events
Databases & data platforms Microsoft SQL Server, Oracle, MySQL/MariaDB, PostgreSQL, MongoDB, Elasticsearch and database activity monitoring Authentication, privileged queries, schema or permission changes, bulk reads/exports, failed access and audit-policy changes
Email & collaboration Exchange Server, mail-transfer and secure-email gateways, Postfix, Sendmail, Exim, Dovecot, Zimbra and collaboration audit feeds Message trace, authentication, forwarding-rule changes, mailbox access, administrative actions, delivery anomalies and suspicious-link or attachment metadata
Infrastructure & platforms VMware vSphere/ESXi, Hyper-V, Kubernetes audit, containers, Docker, storage/NAS, backup platforms and hypervisor management Administrative actions, workload lifecycle, configuration changes, image or secret access, backup deletion and control-plane activity
Security controls SIEM alerts, EDR/XDR, NDR, IDS/IPS, DLP, WAF, vulnerability scanners, malware sandboxes and threat-intelligence platforms Normalized findings, detection metadata, severity, disposition, affected entities, indicators and links to the authoritative source alert
Physical, OT & custom systems Badge/access control, building systems, industrial gateways, historian alarms, ERP/CRM and customer-built applications Physical access, operator actions, alarms, transaction anomalies and domain-specific audit events; custom mapping and validation are required

Connector and format paths

  • Existing SIEM or data-lake APIs and exports are preferred when they already normalize and filter the estate.
  • Syslog over protected transport; Windows Event Forwarding; agent/collector APIs; database audit exports; and read-only file or object-store ingestion where appropriate.
  • Structured JSON, NDJSON, CEF, LEEF, CSV, XML/EVTX, RFC-style syslog and vendor-specific key-value or text formats can be mapped through versioned parsers.
  • OpenTelemetry logs and ECS/OCSF-style schemas can be accepted where deployed; the internal canonical vocabulary remains vendor-neutral.
  • Custom connectors are available for proprietary or legacy logs after representative samples, timestamp/identity semantics, redaction rules and throughput are qualified.

What cross-source correlation can reveal

  • One identity moving across VPN, directory, endpoint, application and database events.
  • Process-to-DNS-to-proxy-to-firewall sequences that suggest beaconing or command-and-control.
  • Privilege changes followed by remote service use, lateral movement or access to sensitive data.
  • Web or API activity linked to WAF signals, application audit events and downstream database access.
  • Mailbox or forwarding-rule changes connected to suspicious sign-ins, endpoint activity and data transfer.
  • Missing telemetry, clock skew, parser failure and broken identity joins surfaced as explicit evidence gaps—not silently guessed away.

Coverage categories and logging principles are informed by MITRE ATT&CK detection knowledge, OWASP security-logging guidance, NIST log-management guidance and vendor documentation. These sources guide schemas and evaluation; they do not turn model output into authoritative evidence.

Correlator workflow

From selected telemetry to an evidence-linked attack-chain hypothesis

Deterministic tools retain detection authority. The local model connects cross-source clues, cites the evidence for every step and names the gaps; an analyst decides what to investigate or deploy.

Correlator log-correlation workflow: selected signals are normalized and bounded, a local model uses versioned security knowledge to build an evidence-linked hypothesis, and a person reviews the output before an auditable record is created.
Read the accessible text walkthrough
  1. Collect selected signals from identity, endpoint, network, application, database, email, infrastructure and security platforms.
  2. Parse, redact, time-align and map identities while preserving original provenance.
  3. Build a bounded event group around assets, actors, sessions and a defined time window.
  4. The local model reconstructs sequence, cites each step, maps ATT&CK, states confidence and identifies missing links.
  5. An analyst reviews and decides whether to investigate or approve detection content; the result becomes an auditable case record.
How it actually works

The mechanism, not the marketing. If a step below would not survive an engineer's scrutiny, it should not be on this page.

1
Volume filtering stays with the tools built for it
SIEM, IDS and anomaly engines do what they are good at. We ingest normalized findings and selected telemetry, never raw packet capture and never every log line.
2
Bounded groups, never streams
Related events are assembled into a structured group, sized and scoped before the model sees any of it. There is no code path where the LLM reads the corpus.
3
Everything normalizes to one canonical vocabulary
Asset identity, actor identity, technique, vulnerability identifier and evidence provenance are mapped to a shared model, so the platform is not coupled to any single SIEM's schema and a customer can change SIEM without changing us.
4
Each step of a reconstructed chain cites its evidence
A narrative is only as good as the events under it. Every step names the supporting events, and confidence states the method that produced it rather than a number the model felt like.
5
ATT&CK mapping is evidence-linked
A technique is asserted because specific events support it, not because the description sounded similar.
6
Missing steps become named gaps
Where a chain requires a step nothing observed, that becomes a detection gap and a candidate hunting query — an output in its own right, not a silent weak link.
7
Nothing deploys without approval
Detection content is drafted and reviewed. The platform does not push rules into your stack.

Operating path

From signal to auditable evidence

Roadmap

01Observed inputs

  • Normalized findings and selected telemetry from SIEM, EDR, AD, VPN, DNS, proxy, firewall, email, cloud and on-premises applications, and network flow
  • Authentication, device, time, location and privilege-use patterns
  • Beaconing, suspicious DNS, anomalous transfer and lateral-movement indicators

02Deterministic workflow

  1. 1 Volume filtering stays with the tools built for it SIEM, IDS and anomaly engines do what they are good at. We ingest normalized findings and selected telemetry, never raw packet capture and never every log line.
  2. 2 Bounded groups, never streams Related events are assembled into a structured group, sized and scoped before the model sees any of it. There is no code path where the LLM reads the corpus.
  3. 3 Everything normalizes to one canonical vocabulary Asset identity, actor identity, technique, vulnerability identifier and evidence provenance are mapped to a shared model, so the platform is not coupled to any single SIEM's schema and a customer can change SIEM without changing us.
  4. 4 Each step of a reconstructed chain cites its evidence A narrative is only as good as the events under it. Every step names the supporting events, and confidence states the method that produced it rather than a number the model felt like.
  5. 5 ATT&CK mapping is evidence-linked A technique is asserted because specific events support it, not because the description sounded similar.
  6. 6 Missing steps become named gaps Where a chain requires a step nothing observed, that becomes a detection gap and a candidate hunting query — an output in its own right, not a silent weak link.
  7. 7 Nothing deploys without approval Detection content is drafted and reviewed. The platform does not push rules into your stack.

03Evidence outputs

  • Attack-chain narratives with per-step evidence citations and confidence
  • ATT&CK technique mapping traceable to supporting events
  • Analyst feedback captured for evaluation and future tuning
This diagram describes the specified workflow; the maturity label states its current delivery status.
A case

Beaconing that four systems each saw a fifth of

Every tool behaved correctly. Every threshold was set sensibly. Nothing alerted.

Firewall
Periodic small outbound connections to one destination — comfortably beneath the volume threshold that would have raised anything.
DNS
The same destination resolved every nine minutes, jitter under four percent. Regular, but not individually remarkable.
Proxy
A user-agent string inconsistent with any browser build deployed in the estate. On its own, a curiosity.
EDR
The parent process is a signed binary, so no behavioural alert fired. Correct behaviour by the tool.
Assembly
Correlator groups the four into one structured set and returns a beaconing narrative citing all four sources, with confidence stated and method named.
The gap it names
No endpoint telemetry ties the network handle to the process. One step of the chain is unproven, and the output says so rather than closing the loop with an assumption.
Confirmation
The drafted hunting query runs; the SOC confirms with the sandbox; the incident is opened by a person.
What it came to

No single tool was wrong and no threshold was misconfigured. The story was simply distributed across four of them, and nothing in the stack was responsible for reading it as one sentence.

All ten cases
How a decision gets made

The authority ladder. Green rungs are authoritative — a rule, a scanner, a sandbox, or a person. Blue is where the model contributes. Amber is where a human decides.

01
Authoritative signal
Existing engines filter high volume and produce the alerts. They remain the detection authority.
02
Bounded context
Structured event groups, sized and scoped before the model sees them.
03
Model contribution
Cross-source correlation, attack-chain reconstruction, ATT&CK technique mapping with cited evidence and stated confidence, detection-gap discovery.
04
Human control
Hunting content and incidents are drafted for review. Deployment of detection content requires approval.

What the model adds

The narrative across sources — the sentence that connects a VPN login, a DNS lookup and an outbound transfer into one hypothesis with its evidence attached.

What it cannot claim

It cannot independently establish that an intrusion occurred, and it does not replace the SIEM or the IDS.

What it will never do
  • Never replaces the SIEM or IDS. It sits above them and explains what they found.
  • Never establishes on its own that an intrusion occurred.
  • Never receives every raw packet or log line — bounded, structured groups only.
  • Never deploys detection content without authorised approval.
What evidence it leaves
  • Attack-chain narratives with per-step evidence citations and confidence
  • ATT&CK technique mapping traceable to supporting events
  • Analyst feedback captured for evaluation and future tuning
See it work
Not built

A specification, not a simulation

We will not show you a scripted demonstration of something that does not exist. What we publish instead is the workflow specification, held to the same standard as shipped work: actor, trigger, happy path, exceptions, terminal state, and the audit evidence it must leave. When it is built, this section becomes a demonstration.

How a module gets promoted

Status and what promotion requires

Roadmap discovery. Retention, normalization, throughput and data-source licensing are connector-specific requirements to define before implementation. Promotion requires log-ingestion lag and volume targets plus correlation-precision measurement.

Roles that touch it

SOC AnalystSecurity Engineer / Threat Hunter