Skip to main content
Stratum Labs
Cybersecurity and compliance data analytics

Security analytics you can explain

An investigation ends with someone asking why. Most tooling answers with a score and a shrug. We build analytics where every detection states its threshold, its window and its reasoning — so the answer holds up in front of a regulator, a client, or a court.

What we build

One tool, free and live, documented down to the last threshold.

AvailableFree

Corelog

Forensic investigation for Microsoft 365 audit logs

Drop a Microsoft Purview Audit Search CSV export and get a stratified activity matrix, 12 MITRE ATT&CK-mapped anomaly heuristics, IP-resolved geolocation and an exportable incident report — instantly, in your browser.

How we build detections

01

Every threshold is stated

Each detection publishes its exact criteria: the count, the window, the baseline it compares against, and the MITRE ATT&CK technique it maps to. If a tool flags an event, you should be able to say precisely why. "The model said so" is not an explanation, and it is not evidence.

02

Calibrated against real data

Thresholds are derived from production-scale audit data, not from assumption. Every rule is measured before it ships: we quantify how often it fires across real exports, examine what it fires on, and separate genuine user activity from the platform and service traffic that surrounds it. A rule that has only ever run on synthetic data has not been validated — it has merely been illustrated.

03

No assumptions about your business

Detections that depend on a rhythm learn it from your own data, per user. A tenant running Monday to Friday, one running 24/7, one busiest at the weekend and one running Sunday to Thursday are all handled by the same code with the same settings — because a threshold tuned on one organisation is worthless to the next.

04

Honest about limits

When a dataset is too short or too sparse to support an analysis, the tool says so instead of reporting a clean result. "Nothing found" and "we could not look" are different answers, and confusing them in an investigation tool is worse than useless.

Who we build for

Security operations

Teams that have to turn a stream of platform telemetry into a decision, and then stand behind that decision. We build the analytics layer that shows its working, so an escalation carries its reasoning with it instead of arriving as a number.

Compliance and audit

Evidence has to be reproducible by someone who was not in the room. Our tooling attaches the exact criteria to every finding — the count, the window, the baseline — so the same question asked twice returns the same answer.

Forensics and investigations

Reconstructing what happened, in order, from the records an organisation actually keeps. Timelines that survive being read by the other side, with every flag traceable to the events that produced it.

MSSPs and consultancies

Analysing client environments under someone else's data-handling constraints. We design so that "where did this data go?" has a short, verifiable answer rather than a diagram.

Where this is going

Corelog solves one problem completely — Microsoft 365 audit logs, in the browser, with no infrastructure to stand up. It is deliberately narrow. The work ahead is to hold a wider set of security and compliance data to the same standard: stated thresholds, measured calibration, explicit limits. That scope does not fit in a browser tab, so it will not be built like one. If you work in this field and something here is close to a problem you have, we would rather hear it early than build on a guess.

Get in touch

Every detection we ship is documented

Thresholds, windows, baselines and MITRE ATT&CK mappings for every rule — published before you run anything.

Read the documentation