Cloud
- Microsoft Azure
- Amazon Web Services
- Google Cloud
One requirement: Microsoft Sentinel
It plugs into the estate
It plugs into the estate
you already have.
CYBERSHIELD AI reads the incidents already sitting in your Sentinel workspace, investigates them, and writes the outcome back to the same ticket. Sentinel is the one thing you need. For the rest of your estate, we build the tooling to fit.
Your tenant · connectedDelegated
SENTMicrosoft Sentinelread & write
XDRDefender XDR & Endpointread
ENTRAEntra IDread
GRAPHMicrosoft Graphread & write
MDTIDefender Threat Intelligenceread
LHAzure Lighthouseno standing creds
+Firewall, endpoint, identity, cloud, OTbuilt to fit
The one requirement
Microsoft Sentinel.
Microsoft Sentinel.
After that, whatever you run.
Sentinel is the correlation engine underneath everything, and it is the only thing we genuinely need you to have. It is not a list of supported vendors you have to match.
The Microsoft estate is where most of our customers already are, and the connections below are built out and ready on day one. There is no second SIEM to license, no data duplicated into someone else’s lake, and no migration to sit through before anything starts working.
But nothing in the platform assumes the rest of your estate is Microsoft. The investigation happens against your own workspace through delegated access, and what an agent can reach is a question of tooling rather than a question of which badge is on the product.
What we read, and what we write
The Microsoft connections, built out and ready on day one, and which way the data moves.
-
Microsoft Sentinel Reads and writes
Reads incidents, alerts and entities. Writes the classification, the closing statement as an incident comment, and the labels back to the same ticket. Deploys analytics rules.
-
Log Analytics and KQL Reads
Every query runs through one validated, read-only path against your own workspace, reached by delegated access.
-
Defender XDR and Defender for Endpoint Reads
Advanced hunting for vulnerability findings, asset context, software inventory, end-of-life software, misconfigurations, browser extensions, certificates and hardware.
-
Entra ID Reads
Directory lookups for users and devices, sign-in risk history and risk detections.
-
Microsoft Graph Reads and writes
Identity and mail, including the SOC mailbox that customer notifications are sent from.
-
Defender Threat Intelligence Reads
Threat actor profiles, articles, indicators and CVE enrichment.
-
Microsoft Secure Score Reads
Exposure and posture context, used to build your attack profile.
-
Azure Lighthouse Access
Delegated access to your workspace, so there are no standing credentials sitting in your tenant.
-
Microsoft licensing data Reads
Resolves which Microsoft SKUs you hold, so scoping and billing reflect what you actually run.
Everything else in your estate
We write the procedures,
We write the procedures,
so we can build to fit.
The usual limit on a platform like this is its integration list: if your firewall, your EDR or your identity provider is not on it, you are stuck. That limit does not apply here, and the reason is worth understanding.
-
01
The triage procedures are ours
Our analysts wrote them over years of running Sentinel in production. They are not a vendor’s playbooks wrapped in a product, so they are not tied to a vendor’s product either. A procedure describes what to establish, not which console to establish it in.
-
02
If the tooling does not exist, we build it
Where a step needs to reach something we have not reached before, we build the tool for it and sync it into the catalogue. Your environment does not have to look like anyone else’s for the investigation to run properly.
-
03
Included in the managed service
Built during onboarding, not quoted for afterwards. Not a change request, not a professional-services line, not a scoping surprise six weeks in. Building what your estate needs is part of running your SOC.
So the honest answer to "do you support X" is usually yes, and where it is not yet, the gap is work we do rather than a reason to say no.
The rest of your estate
Whatever else
Whatever else
you happen to run.
A sample of what our customers actually have in the building. This is not a compatibility list to check yourself against, and a name missing from it means nothing: where an investigation needs to reach something, building the tool to reach it is part of the service.
Firewall and network
- Palo Alto Networks
- Fortinet
- Cisco
- Check Point
- Cloudflare
Network detection
- Vectra AI
- ExtraHop
- Darktrace
Endpoint
- CrowdStrike
- SentinelOne
- Sophos
- Trend Micro
Email and web
- Barracuda
- Proofpoint
- Mimecast
Identity and access
- Okta
- Duo
- CyberArk
- Ping Identity
Threat intelligence
- Recorded Future
- Mandiant
- VirusTotal
Business systems
- Salesforce
- SAP
- Workday
OT and IoT
- Armis
- Claroty
- Forescout
- Nozomi Networks
This is a sample, not the full extent of what we support. If what you run is not on it, that means nothing at all: it is a list of examples, and the work of reaching something new is work we do rather than a reason to say no.
What can you actually do in my tenant
The answer comes from
The answer comes from
your directory, not from us.
Every vendor will tell you what permissions they need. Far fewer can tell you what they were actually granted.
The platform reads back from Entra the permissions and directory roles that were genuinely consented to it in your tenant, and stores them. So "what exactly can this thing do here" is answered from your own directory rather than asserted by us in a document written before onboarding.
That matters at the point somebody asks the question a year later, during an audit or a review, when whatever was agreed at the start has been forgotten by everyone involved.
Beyond Microsoft
The sources behind
The sources behind
the enrichment.
Read by the platform to make sense of what it finds. None of these touch your estate.
NVD
CVE detail, CVSS, weaknesses and affected products.
CISA KEV
The catalogue of what is being actively exploited right now.
EPSS
Exploitation probability, used to prioritise against likelihood rather than severity alone.
MITRE ATT&CK
Techniques and tactics, mapped to what we see in your estate.
MISP galaxy
Threat actor clusters.
Vendor and research intelligence
Ingested continuously from feeds, web articles and PDF reports.
Your own pen test reports
Uploaded, then hunted against the exact engagement window to answer whether we would have caught it.
Getting your data in
Collecting the logs
Collecting the logs
is half the job.
A SOC is only as good as what reaches it. Getting security logs out of whatever produced them and into Sentinel, in a shape the detections can actually use, is the part most people underestimate. It is also the part we specialise in.
Custom data connectors
Where a source has no connector, we write one. That is how something which has never been in a SIEM before ends up in the same queue as everything else.
Parsers and normalisation
Raw logs are not evidence until the fields mean the same thing across sources. We write the parsers that make a sign-in from one product comparable to a sign-in from another.
Analytical rules
The detections themselves, written for your estate and tuned against what your alerts actually turn out to be rather than against a vendor default.
Playbooks and notebooks
The automation that runs around a detection, and the hunting notebooks your own analysts can pick up and use.
Over 500solutions in the Microsoft Sentinel Content Hub
Work out of the box, because they are native to Sentinel. The connectors and parsers that do not exist yet are the ones we write.
All of it is part of the managed service and happens during onboarding. It is not a separate data-engineering engagement, and it is not a change request six weeks in.
The tool layer
How an agent
How an agent
actually does anything.
Agents do not have free run of your estate. They act through a catalogue of tools, and each step of an investigation is given only the tools that step declares.
- Synced from live tool servers
- The catalogue is populated at runtime rather than hard-coded, so it reflects what is actually reachable rather than what was true at the last release.
- Versioned, and pruned on every sync
- A tool that is no longer available does not linger in the catalogue waiting to fail in the middle of an investigation.
- Scoped per step
- Coverage spans Sentinel, Entra, Exchange and Graph, plus third-party enrichment such as reputation, URL analysis and threat intelligence lookups.
Getting connected
Delegated access,
Delegated access,
no standing credentials.
Connection is through Azure Lighthouse, so access to your workspace is delegated rather than resident. There is no permanent account of ours sitting in your tenant waiting to be somebody else’s way in.
- Where queries run
- Against your own Log Analytics workspace, through one validated read-only path. Not a copy of your data held somewhere else.
- Where your data stays
- In your tenant, on your retention. The platform reads it and writes conclusions back; it does not relocate it.
- What is written back
- The classification, the closing statement as an incident comment, the labels, and analytics rules you have approved. Nothing else.
- How you are notified
- Email, sent from the SOC mailbox through Microsoft Graph, with every send recorded against the investigation.
Questions
Connecting it up, answered.
Do we have to move off our current setup?
No. Microsoft Sentinel is the one thing we need you to have, because it is the correlation engine everything runs on. There is no second SIEM to license, no data duplicated into another lake, and no migration before anything starts working.
Does the rest of our estate have to be Microsoft?
No. Sentinel is the only requirement. Our analysts wrote the triage procedures themselves, so they are not tied to any vendor’s product, and where a step needs a tool we have not built yet we build it for your environment. On the managed service that is included, not a change request.
What access do you need to our tenant?
Delegated access through Azure Lighthouse, so no standing credentials of ours live in your tenant. Queries run through one validated read-only path against your own workspace. What we were actually granted is readable from your own directory rather than asserted by us.
What do you write into our environment?
On an incident: the classification, the closing statement as an incident comment, and the labels, all on the same ticket. Separately, analytics rules that you have approved. A new or rewritten detection rule is a draft first; deploying it is a separate, gated step.
Does our data leave our tenant?
Your Sentinel data stays in your workspace on your retention. The platform queries it through delegated access and writes conclusions back to the same ticket. There is no cross-customer learning and no model training on your data.
How do we get told when something happens?
By email, sent from the SOC mailbox through Microsoft Graph. Recipients are resolved per customer and per incident type, every send is recorded against the investigation, and replies are tracked. The portal carries the same incidents live.
What about sources outside Microsoft?
The platform reads NVD, CISA KEV, EPSS, MITRE ATT&CK, MISP galaxy and continuous vendor and research intelligence. You can also upload penetration test reports, which get hunted against the engagement window. None of these connect to your estate.
See it on your estate
Point it at your own tenant
Point it at your own tenant
and watch what it does.
An hour with a SOC analyst: what we connect to, what gets written back to a Sentinel ticket, and the permissions read straight out of your own directory rather than promised in a document.