Orca Security: ITDR for the Cloud

What it is

Orca's ITDR explainer, most of whose argument the existing summary already carries. What it adds beyond that summary is a small set of concrete points: a threat-report statistic, a sharp AD-vs-cloud distinction, an evaluation checklist, and a note on response-automation calibration.

The AD-vs-cloud ITDR trap

The page's most useful distinction — absent from the summary — is that most ITDR material describes a different problem than cloud teams face. Traditional ITDR protects on-prem Active Directory and watches for Kerberoasting, golden-ticket forgery, DCSync, and lateral movement between domain-joined endpoints, with telemetry from domain controllers and host agents. Cloud ITDR works on the CSP control plane (AWS IAM, Entra ID, Google Cloud IAM), where attacks are API calls and role assumption, identities are mostly machines, and telemetry comes from CloudTrail / Azure Activity Logs / GCP audit logs — no endpoint involved. The warning: an AD-trained team that equates ITDR with watching domain controllers will miss cloud identity attacks entirely, because those attacks never touch an endpoint.

Supporting stat the summary omits: the page cites CrowdStrike's 2026 Global Threat Report finding 82% of detected intrusions were malware-free, its argument for why identity, not malware, is the attack surface.

What to do

If you're evaluating an ITDR product, the page's checklist is the actionable part:

• Multi-cloud control-plane coverage (AWS/Azure/GCP), not one provider or on-prem AD.
• Machine/non-human identities as first-class (service accounts, access keys, OAuth apps, workload identities).
• Per-identity behavioral baselining, not just static rules.
• Attack-path/blast-radius context so alerts are ranked, not fired flat.
• Real-time response (revoke sessions, rotate/disable keys, quarantine) with confidence thresholds gating disruptive actions.
• Threat-intel enrichment (known-bad IPs, leaked-credential feeds, MITRE ATT&CK mapping) and SIEM/SOC integration.

Caveats

The page states its own automation limit: auto-revoking on a clear impossible-travel-plus-escalation signal is safe and reversible, but tearing down a production service account on a weak signal causes outages — so disruptive actions should be gated behind confidence thresholds and human approval. This is a vendor explainer with no CVEs, commands, or version boundaries; it ends in an Orca demo pitch.