Defining what information should be logged is an essential part of any effective logging and monitoring strategy. The Logging Scope control from the Cloud Security Alliance Cloud Controls Matrix provides guidance on establishing, documenting, and regularly reviewing the events and metadata that should be captured in system logs. By carefully considering the scope of logging, organizations can ensure they have the necessary visibility into their cloud environments.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 - 2023-09-26. You can download the latest version of the CCM here. The CCM provides a comprehensive set of controls to help organizations assess the security posture of cloud providers and guide security efforts. For more background, check out the CSA CCM Overview.

Who should care?

A few key personas that should pay attention to LOG-07:

• Security analysts responsible for detecting and investigating security incidents
• Compliance officers needing to demonstrate logging aligns with relevant standards
• Architects and developers designing and implementing logging in cloud workloads
• IT managers overseeing monitoring and log management solutions

What is the risk?

Failing to capture important events and metadata in logs can lead to:

• Missed security incidents - Attacks may go unnoticed without proper logging
• Compliance violations - Regulations often specify logging requirements
• Inability to reconstruct events - Insufficient logging hampers forensic investigations
• Alert fatigue from noisy logs - Logging too much can make it hard to spot real issues

LOG-07 helps mitigate these risks by ensuring the right information is logged. However, logging alone is not sufficient - logs must also be analyzed for unusual activity.

What's the care factor?

For most cloud-using organizations, I'd rate the importance of having a well-defined logging scope as high. Logs provide invaluable security visibility. Without comprehensive logging, other security controls and processes are hampered. The consequences of insufficient logging can be severe when incidents occur.

That said, the highest level of care should be applied to systems handling the most sensitive data and critical operations. Development and test systems can potentially have a reduced logging scope.

When is it relevant?

Logging scope should be defined for any production cloud workload. It's especially important for:

• Internet-facing systems and applications
• Systems processing sensitive data
• Infrastructure and logging systems themselves

Some cases where LOG-07 may be less relevant:

• Ephemeral dev/test environments
• Isolated lab or demo systems
• Systems that don't handle production data or operations

What are the trade offs?

Logging can introduce some costs and considerations:

• Storage costs - Logs can get big, leading to increased storage spend
• Log ingestion and processing costs - Tools to analyze logs have a price
• Performance overhead - Logging activity consumes some system resources
• Development effort - Logging must be implemented in applications
• Noise and false positives - Over-logging can make it harder to identify real issues

Generally, the security benefits outweigh these concerns for key in-scope systems. But it's good to be aware of the impacts and right-size the logging approach.

How to make it happen?

1. Inventory your key systems, data, and use cases that require logging
2. Consult logging requirements from relevant standards (e.g. PCI DSS, HIPAA)
3. Engage stakeholders to define logging needs - security, compliance, ops, dev
4. Document the events and metadata that should be logged at minimum, such as:
   • Account login events (success and failure)
   • Account changes (create, modify, delete)
   • Object access attempts
   • Configuration and policy changes
   • Administrative and privileged actions
   • Authentication and authorization decisions
   • Data access, changes, and deletion
   • System events and process tracking
5. Define target log retention periods and protection needs
6. Assess existing logging capabilities of your cloud platform and 3rd party products
7. Enable and configure logging on required targets, using defined scope
8. Validate logging is working and contains required info
9. Implement processes to review logging scope at least annually and on change events

What are some gotchas?

Some considerations when implementing LOG-07:

• Cloud platform logging must usually be explicitly enabled, e.g. AWS CloudTrail
• Default logging may not be sufficient, additional configuration is often needed
• Logging from inside applications requires code changes and standardized libraries
• Logging sensitive data has privacy and compliance implications - beware of PII
• More logging means more data - have a plan to efficiently store and process logs
• Fine-grained logging may be incompatible with serverless architectures like AWS Lambda
• Logs must be strongly secured - they can provide a map to would-be attackers

What are the alternatives?

There are a few alternatives and complements to defining a logging scope:

• Rely on cloud platform's default logging configuration (often insufficient)
• Outsource entire logging process to SIEM or MDR provider
• Rely primarily on network-level monitoring and logging vs. host and application logs
• Use a workload protection platform like CrowdStrike Falcon that provides additional security telemetry beyond logs

Explore further

• NIST Guide to Computer Security Log Management
• AWS Logging and Monitoring in the Cloud
• CIS Control 8 - Audit Log Management
• ISO 27001 Logging and Monitoring Controls

?