Security Monitoring and Alerting

[All Actors]
1. Identify and catalogue security-relevant events for applications, infrastructure, supply-chain components and AI models (e.g., authentication failures, config changes, model-drift alarms).

2. Continuously collect and time-stamp those events; normalise them into a central log or telemetry pipeline.

3. Define alert rules and thresholds (including severity, routing and escalation paths) for unauthorised access, integrity violations, performance anomalies and other high-risk conditions.

4. Send alerts to a designated response channel with enough context to support triage (actor, asset, location, action, timestamp).

5. Document investigation and response procedures that map alert severities to required actions and response-time targets.

6. Tune detection logic and threshold values regularly using threat intel, incident post-mortems and changes in architecture or business risk.

1. Inquiring with Control Owners

1.1 Conduct interviews with personnel responsible for identifying, monitoring, and alerting on security-related events within cloud infrastructure, AI processing resources, and multi-tenant compute environments to understand their event classification and risk evaluation processes for infrastructure-level AI security. Verify their understanding of alert generation systems and stakeholder notification procedures for security incidents involving compute resource compromise, data center breaches, or customer workload isolation failures.

2. Inspecting Records and Documents

2.1 Verify documented procedures exist for configuring cloud infrastructure security monitoring including hypervisor protection, GPU/TPU security, and customer workload isolation.

2.2 Confirm alerts are generated for anomalous behaviors in compute resource usage, unauthorized infrastructure access, or customer workload boundary violations.

2.3 Check for integration with centralized SIEM tools or log aggregation systems that capture infrastructure events, resource utilization patterns, and customer access activities.

2.4 Review logs to validate that high-risk infrastructure activities such as hypervisor escape attempts, unauthorized hardware access, or customer data exfiltration are appropriately flagged.

2.5 Validate roles responsible for triaging and responding to cloud infrastructure-specific security alerts including cloud operations teams, security incident response, and customer liaison teams.

2.6 Ensure monitoring includes infrastructure-specific threats such as side-channel attacks, hardware tampering, VM escape, container breakouts, and supply chain compromise of hardware components.

2.7 Verify alert thresholds are tuned for cloud infrastructure contexts to detect sophisticated infrastructure attacks while minimizing impact on customer AI workloads.

2.8 Review cloud infrastructure security monitoring including physical data center security, network infrastructure protection, and hardware security modules.

2.9 Examine cloud supply chain security event monitoring including hardware vendors, firmware updates, network equipment providers, and third-party data center services.

2.10 Validate risk evaluation frameworks used to determine additional infrastructure-specific security events requiring monitoring such as power anomalies, cooling system failures, or regulatory compliance violations.

2.11 Confirm alert notification procedures for infrastructure security incidents include appropriate stakeholders such as data center operations, customer security teams, and regulatory compliance officers.

2.12 Verify comprehensive monitoring and alerting policies are documented and enforced across cloud infrastructure.

2.13 Check native cloud security tools (e.g., AWS CloudTrail, Azure Sentinel) are configured for real-time alerts.

2.14 Ensure alerts are generated for unauthorized access attempts or privilege escalations.

2.15 Validate centralized aggregation of security logs across services and tenants.

2.16 Review responsibilities assigned for incident triage and response to cloud-native alerts.

2.17 Confirm SLAs define response times for security alerts across regions/zones.

2.18 Verify anomaly detection algorithms or ML-based alerting mechanisms are in place.