How I work
The systems behind these are covered by agreements, so what follows is the reasoning rather than the artifacts: what made each one hard, what I chose, and what I turned down.
Multi-tenant SIEM architecture
Three SIEM platforms across more than 30 government-contractor clients, each chosen for the estate it had to monitor, all feeding one alert queue.
The constraint
An MSSP with more than 30 SOC customers, all government contractors under CMMC. The estates had almost nothing in common: different services, different architectures, different sites, and devices we did not own. A conventional SOC structure assumes one estate, and there were thirty.
GCC High added a limit of its own. Its management APIs lag the commercial tenant and use different URLs and parameters, so tooling that works against commercial Microsoft does not necessarily work there at all.
The decision
Three platforms, chosen per client rather than one standard, behind a single alert surface.
Sentinel took the GCC High cloud workloads, ingesting through log forwarding, Event Hubs, Defender, and connectors I built for Microsoft XDR, with Azure Arc and the Azure Monitor Agent extending reach to machines outside the tenant. On-premises servers and firewalls went through a local Kafka platform that normalised before writing to an analytics bucket, with syslog split to its own.
AlienVault took the clients outside full FedRAMP scope who were not running SentinelOne. That one is almost entirely agent-based, with API integrations to Azure, FortiGate and whichever EDR the client had, and on-premises sensors forwarding network and firewall data over HTTPS.
SentinelOne took the clients already using it for EDR. I wrote parsers and translators into its parsing engine in regex and JSON, covering whatever applications a client asked for, fed from endpoint agents and a Scalyr agent on a hardened central server. Everything was normalised before it reached the data lake.
Detection was written per platform, as analytics and fusion rules in Sentinel and STAR rules against the SentinelOne lake. One API then polled all three for alerts in near real time and pushed them into the SOC dashboard in our PSA tool, so an analyst worked a single queue.
What I rejected
Standardising on one SIEM and fitting every client to it. That is cheaper to run and it was the wrong answer here, because the estates differed in exactly the ways that decide the tool.
A cloud-native GCC High tenant, a site of on-premises firewalls with no cloud presence, and a client with SentinelOne already deployed are three different ingestion problems. Retrofitting one platform across all three means paying for the mismatch in every environment instead of choosing once per client. Architecture, tooling and scope should follow the environment rather than the other way round.
How I would know it worked
Alert latency from source to dashboard, and how long a new client took to stand up.
SentinelOne and AlienVault delivered under a minute. GCC High Sentinel delivered under five. That gap is the constraint above showing up in the numbers rather than a tuning failure, and no version of this design closes it.
A new client was onboarded in under a week, gated by their own IT team rather than by us. That figure is the real test of choosing per client: a bespoke architecture is only affordable if standing one up is routine, so every deployment was scripted and staged in advance, maintenance scripts included.
Underneath both, one criterion. An analyst worked a single queue, and if the platform behind an alert changed how they triaged it, the architecture had failed.