Section 9: The Contract the SOC Lives In - Public APIs & Sample Queries

Executive Summary: Publishing a rule, triaging INC-20419, hunting for an attacker's IP across last month, asking "is my logging still flowing?": every tenant action goes through an API. In production that API is an Azure Resource Manager resource provider; on the whiteboard it becomes /v1/... paths, with the tenant taken from the workspace's registration after ARM's RBAC check, never the URL. Rules are published with an idempotent PUT, a 24-hour dry-run and a shadow mode, and go live within 60 s. Incidents are cursor-paged and updated under ETags, and long-running work answers 202 Accepted. Each choice is defended under pushback, and the section closes with real rules and queries run against Contoso's attack.

Section 8 ended on a warning: the security system is itself a target, and every tenant action is a door into it. The interviewer picks that up. "Fine. Show me what Contoso's admin and SOC actually call." A weak answer is a list of CRUD endpoints. A strong one treats the API as the place where the earlier sections become promises to a customer: idempotency, isolation, freshness and honest asynchrony.

The Shape First: A Resource Provider, a Token-Scoped Tenant

You: "In production I'd expose this as an Azure Resource Manager resource provider. Rules, routes and retro-hunts become ARM resources under a workspace, so Azure RBAC, Azure Policy and Activity Log entries for every change come without us building them. On the whiteboard I'll drop the ARM prefix (/subscriptions/{id}/resourceGroups/{rg}/providers/<our-namespace>/workspaces/{ws}/...) and write /v1/...."

Interviewer: "Your paths don't have a tenant in them. How do you know whose rules you're editing?"

You: "Never from anything the caller types. ARM authenticates the caller and checks RBAC on the resource scope, which covers delegated access such as an MSSP working through Azure Lighthouse; our provider then takes tenantId from the workspace's own registration in the Tenant Registry, never from a path segment or body field. A /v1/tenants/{tenantId}/rules path invites the bug that ends a security company: a handler that trusts the path segment, so swapping t-4821 for another ID reads someone else's incidents. ARM paths do name the subscription and workspace, but only ARM's RBAC check decides who may touch them, and only the Tenant Registry decides whose data they hold."

That's Section 8's trust boundary applied at the front door: tenantId is assigned by the channel, never read from the request.