Missing Cloud Logging and Monitoring

Missing Cloud Logging and Monitoring refers to the failure to enable, configure, and actively monitor the logging and auditing capabilities provided by cloud platforms. Without comprehensive logging of cloud API calls, resource changes, network flows, and data access events, organizations lack the visibility needed to detect active threats, investigate security incidents, and maintain compliance with regulatory requirements in cloud environments.

Cloud environments generate vast amounts of security-relevant telemetry through services like AWS CloudTrail, GCP Cloud Audit Logs, and Azure Activity Logs. These services record every API call made to cloud services, providing a complete audit trail of who did what, when, and from where. However, many organizations fail to enable these services across all accounts and regions, do not centralize logs for cross-account correlation, fail to configure alerting on security-critical events, or allow log data to be modified or deleted by compromised accounts.

The ephemeral and dynamic nature of cloud resources makes logging even more critical than in traditional environments. Auto-scaling groups create and destroy instances continuously, serverless functions execute and terminate in milliseconds, and infrastructure-as-code deployments can change hundreds of resources simultaneously. Without comprehensive logging, security-relevant events disappear with the resources that generated them, making forensic investigation of cloud-based incidents extremely difficult or impossible.

Logging gaps in cloud environments manifest in several ways. At the most fundamental level, cloud audit logging services may not be enabled—AWS CloudTrail is not enabled by default in new accounts for management events in all regions, and data events (S3 object access, Lambda invocations) require explicit configuration. Organizations using multiple cloud accounts may have logging enabled in their primary account but not in development, staging, or newly provisioned accounts, creating blind spots that attackers can exploit.

Even when logging is enabled, critical gaps often remain. Network flow logs (VPC Flow Logs, GCP VPC Flow Logs, Azure NSG Flow Logs) may not be enabled on all VPCs and subnets, preventing detection of network-based attacks and lateral movement. DNS query logging may be disabled, preventing detection of DNS-based data exfiltration and command-and-control communication. S3 access logging may be disabled on sensitive buckets, preventing detection of unauthorized data access. CloudWatch Logs or equivalent services may not capture application-level logs from EC2 instances, containers, or serverless functions.

Monitoring gaps are equally dangerous. Organizations may collect logs but fail to analyze them. Without SIEM integration, threat detection rules, and active monitoring by a security operations team, logs become a compliance checkbox rather than a security control. Attackers operating in environments with logging but no monitoring can take their time to enumerate resources, escalate privileges, and exfiltrate data, confident that no one is watching the logs until long after the breach is discovered through other means.

• Inability to detect active cloud infrastructure attacks including IAM privilege escalation, resource manipulation, and data exfiltration in real time
• Extended dwell time for attackers who operate undetected for months in cloud environments without monitoring, maximizing the scope of data compromise
• Impossible or severely impaired incident response and forensic investigation due to missing audit trails for cloud API calls and resource changes
• Compliance failures under frameworks like SOC 2, PCI-DSS, HIPAA, and FedRAMP that require continuous monitoring and audit logging of cloud environments
• Inability to detect configuration drift where cloud resources are modified from their intended secure configuration without any audit trail
• Missing evidence for legal proceedings or insurance claims when cloud-based breaches cannot be fully documented due to logging gaps

1. Enable cloud audit logging across all accounts, regions, and services. For AWS, configure an organization-level CloudTrail trail that logs management events and data events for critical services (S3, Lambda, DynamoDB) across all accounts and regions. For GCP, ensure Cloud Audit Logs are enabled for all services with both admin activity and data access logging. For Azure, enable Activity Logs and Diagnostic Settings for all subscriptions and resources.
2. Enable network-level logging: VPC Flow Logs on all VPCs and subnets, DNS query logging, load balancer access logs, and WAF logs. Configure these to capture both accepted and rejected traffic flows. Use traffic mirroring for deep packet inspection on sensitive network segments.
3. Centralize all cloud logs into a dedicated security logging account or SIEM platform (Splunk, Elastic SIEM, Chronicle, Sentinel). Implement cross-account log aggregation to correlate events across organizational boundaries. Ensure the logging account has restricted write-only access and cannot be modified by compromised accounts in other organizational units.
4. Implement log integrity protection: enable CloudTrail log file validation, configure S3 Object Lock on log storage buckets to prevent deletion, use AWS CloudTrail Lake or equivalent for tamper-evident log storage, and restrict IAM permissions that could disable logging or modify log configurations.
5. Deploy cloud-native threat detection services: AWS GuardDuty, GCP Security Command Center, Azure Defender for Cloud. These services analyze cloud logs using machine learning and threat intelligence to detect common attack patterns including cryptocurrency mining, credential compromise, and data exfiltration.
6. Define and implement alerting rules for security-critical events: root account usage, IAM policy changes, security group modifications, CloudTrail configuration changes, S3 bucket policy modifications, new regions activated, and unusual API call patterns. Integrate alerts with your incident response workflow.

Audit logging coverage by enumerating all cloud accounts, regions, and services in use and verifying that audit logging is enabled for each. For AWS, check CloudTrail configuration: aws cloudtrail describe-trails and aws cloudtrail get-trail-status across all regions. Verify data event logging is enabled for S3, Lambda, and other critical services. Check for organization-level trails that ensure new accounts are automatically covered. Use tools like Prowler or ScoutSuite to automate logging configuration audits against CIS Benchmark requirements.

Test log completeness by performing security-relevant actions and verifying they appear in the centralized logging system with complete context. Create and delete IAM users, modify security groups, access S3 objects, invoke Lambda functions, and verify each action is logged with the actor identity, action, resource, timestamp, and source IP. Measure the latency between action execution and log availability in the SIEM to ensure real-time detection is feasible.

Validate monitoring and alerting by simulating attack scenarios and measuring detection time. Perform actions that should trigger alerts: create IAM access keys for the root account, disable CloudTrail logging, make an S3 bucket public, launch instances in unusual regions, and make API calls from IP addresses outside known ranges. Verify that each scenario triggers the expected alert within the defined SLA. Test log integrity protections by attempting to delete or modify log files from a compromised (non-logging) account and verifying the attempt is blocked and alerted on.