Notifications
Clear all
Topic starter
02/08/2026 11:29 am
TL;DR: CloudTrail can record every API call and still miss the actions that matter unless detections are built around tampering, IAM drift, unused-region activity, and network exposure changes, according to Panther. Correlating cloud telemetry with identity context turns noisy logs into actionable signals, especially when human and automation identities behave differently.
NHIMG editorial — based on content published by Panther: Cloud Infrastructure Monitoring: Best Practices for Modern SOC Teams
By the numbers:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job
Questions worth separating out
Q: How should security teams detect cloud activity that is trying to hide in normal volume?
A: Focus on state-changing events that alter visibility or trust, not on every API call.
Q: Why do IAM changes matter so much in cloud monitoring?
A: Because IAM drift is often the bridge between a foothold and persistence.
Q: What do organisations get wrong about multi-cloud performance monitoring?
A: Organisations often compare environments using inconsistent measurements, which makes the data hard to trust.
Practitioner guidance
- Prioritise logging tampering detections Create immediate alerts for StopLogging, trail deletion, trail modification, and disabled cloud threat detectors.
- Correlate IAM drift with deployment context Flag roles, policies, and access keys created or changed outside your infrastructure-as-code workflow.
- Treat exposure changes as containment triggers Escalate internet-facing security groups, public storage changes, and overly broad egress rules as high-confidence exposure events.
What's in the full article
Panther's full blog covers the operational detail this post intentionally leaves for the source:
- Python-based detection logic for CloudTrail, identity provider, and pipeline correlation
- Examples of Organization Profiles and environment baselines used to suppress expected noise
- Case examples showing how teams reduced false positives while adding new cloud sources
- Implementation detail on how Panther AI groups related alerts for triage
👉 Read Panther's blog on cloud infrastructure monitoring best practices →
CloudTrail drift and evasion: what IAM teams need to catch early?
Explore further
02/08/2026 12:44 pm
Cloud detection fails when teams treat telemetry as the control rather than the input. The article correctly shows that API volume alone does not equal detection value. The governing mistake is assuming more logs create more visibility, when the real problem is prioritisation around the few actions that change trust, exposure, or observability. Practitioners should anchor cloud monitoring to control-plane disruption, not to data collection volume.
A question worth separating out:
Q: How do teams decide when a cloud exposure change is an incident?
A: Treat it as an incident when the exposure change creates a new path for access, exfiltration, or lateral movement and cannot be explained by an approved change record. Public storage, broad egress, and internet-open security groups deserve immediate review when they appear outside normal maintenance.
👉 Read our full editorial: Cloud detection needs identity context to catch drift and evasion
