1Security + Microsoft Sentinel
Sentinel tells you what happened. 1Security tells it who could reach what.
Sentinel is where your SOC works: every source normalized, alerts grouped into incidents, playbooks that carry the response. 1Security connects to your Microsoft 365 tenant read-only and adds the piece a raw audit event does not carry - which user, on which device, from which city, touched which file, and how many more files that account could open. An incident opens on a row that already answers the first three questions.
What Sentinel does
The SIEM of record, built into the cloud you already run.
One query surface for detection, investigation, hunting and response, at the scale of everything you send it.
Every source, one surface
Data connectors ship packaged in solutions: Microsoft sources stream in real time, and Syslog, CEF and REST APIs bring in the rest of the estate you run. ASIM normalization turns all of it into one model you can actually query.
Alerts become incidents
Analytics rules combine low-fidelity alerts about different entities into high-fidelity incidents, mapped to MITRE ATT&CK and enriched with threat intelligence. The analyst starts from a case, not a haystack.
Response as workflow
Automation rules coordinate incident handling centrally, and playbooks on Azure Logic Apps carry the response into ServiceNow, Jira and the rest of your stack. Hunting queries and notebooks reach past what any rule anticipated.
The question this pairing answers
A log line says what happened. It does not say what it could have reached.
A Sentinel incident names an account at 02:14. The next three questions are always the same: who is this, what can they open, and is tonight normal for them? Those answers do not live in any event, because standing permissions in Microsoft 365 are state, not activity. A sharing link created in 2023 writes nothing tonight. A nested group extends reach to a site no log line mentions. In a typical tenant an ordinary account can open more than 200,000 files, and nothing in the audit stream says so.
So the analyst leaves the incident to find out - permission dialogs, group memberships, a script per site - and comes back an hour later with an estimate. That hour is the whole cost of the alert, and it is paid on false positives too.
1Security keeps that answer ready. It resolves what every user, guest, app and AI agent can reach through direct grants, sharing links, groups and inheritance, keeps up to three years of attributed activity, and hands Sentinel events that already carry the context. The incident still opens in Sentinel. The hour goes away.
What 1Security adds
Four things Sentinel gets from the tenant that it did not have before.
1Security connects read-only to Microsoft 365, builds the permission graph and the activity history, and serves both to Sentinel through a read-only REST API.
- 01
Reach on every event
Each Microsoft 365 event 1Security emits is tied to the user, the file or mailbox, the app, the device and the location, and the account behind it comes with what it can open: sites, files, mailboxes, resolved through nesting, links and inheritance. A blast-radius question that took half a day is a field on the row.
- 02
A baseline for every account
Every user, app and AI agent is scored against its own trailing activity. "340 downloads today" arrives already compared with the usual 12, with an anomaly episode Sentinel can correlate on. Up to three years of history sits behind it on standard Microsoft 365 licenses.
- 03
Devices and locations, not just IPs
Every event carries the device (managed, unmanaged or never enrolled) and the location as country, city and network type - hosting, VPN, office. An impossible-travel verdict is a value in the row, not a KQL query you write.
- 04
A fix that waits for a human
When Sentinel escalates, the fix happens in 1Security behind a review window - expire the links, remove the access, revoke the sessions - staged per resource, 72 hours by default, and logged with who approved it. Nothing irreversible runs on an automation alone.
How the two fit
Sentinel keeps the record and the workflow. 1Security keeps the context.
Sentinel stays the SIEM of record: the workspace, the analytics rules, the incidents, the playbooks. 1Security connects to your Microsoft 365 tenant with read-only consent - no agents, standard licenses, first findings the same day - and maintains what a log stream cannot: the resolved permission graph, the per-account baselines and three years of attributed history. Sentinel pulls 1Security audit logs, monitoring alerts and security alerts from the read-only REST API on a schedule, and every row arrives with the who, the device, the location and the reach already attached. Sentinel and Defender alerts also appear inside 1Security, linked to the account, group, mailbox or app they concern, so the pivot works in both directions. When an analyst needs the full picture, one click opens the account in 1Security.
- 1 dayfrom read-only consent to the first findings
- 10 minto a blast-radius answer that used to take half a day
- 3 yearsof attributed activity behind every incident
Together in practice
DORA wants the impact on a deadline. The scope should be a lookup, not a project.
DORA requires financial entities to classify ICT-related incidents and report the major ones on fixed deadlines - initial notification, intermediate report, final report - with a defensible assessment of impact. The clock starts before the investigation ends.
Sentinel establishes the event chain: when it started, which systems were involved, what the analytics rules and the playbooks did. 1Security establishes the scope: every file, site and mailbox the affected account could reach, resolved in minutes, and what it actually touched, measured against three years of its own history. Both are in the row Sentinel already holds.
The initial notification ships with real numbers in it. The intermediate report cites 214,000 reachable files and 3,100 with personal data, not "potentially affected". And the remediation that follows is staged, reviewed and logged, so the final report has a timeline of fixes to attach.
Integration
Pull-based, read-only, on your schedule.
Sentinel pulls from the 1Security read-only REST API under /api/v1: normalized Microsoft 365 audit logs enriched with user, file, device, location and reach; monitoring alerts raised by your policies; and security alerts with the same context. Keys are per tenant, scoped and read-only, so a collector can read the data and change nothing in 1Security or in Microsoft 365. Sentinel and Defender alerts flow the other way too and land in 1Security linked to the entities they concern. Outbound webhook delivery is planned; until it ships, scheduled polling is the supported pattern.
Give your Sentinel incidents the who, the reach and the history.
Connect 1Security read-only and point Sentinel at the API. Your next Microsoft 365 incident opens with the account, its reach and its baseline already on the row.
Or keep leaving the analyst to answer the first three questions by hand.