Log files are a crucial source of forensic evidence that can help detect and respond to security incidents. It's important to ensure log files are protected from unauthorized access and tampering. The LOG-09 control from the Cloud Security Alliance Cloud Controls Matrix provides guidance on how to keep your logs safe and sound.

Where did this come from?

CSA Cloud Controls Matrix v4.0.10 - 2023-09-26

The Cloud Security Alliance (CSA) is a not-for-profit organization that promotes best practices for securing cloud computing. One of their key publications is the Cloud Controls Matrix (CCM), a cybersecurity control framework for cloud service providers and cloud consumers. You can download the latest version of the CCM from https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4.

The LOG-09 control is part of the Logging and Monitoring domain in the CCM. It maps to several other industry standards, such as:

• NIST SP 800-53 Rev. 5 AU-9
• ISO/IEC 27002:2022 A.8.10
• PCI DSS 3.2.1 Requirement 10.5.5

For more information on logging best practices in AWS, check out the AWS Logging and Monitoring Whitepaper.

Who should care?

This control is relevant for:

• Security engineers responsible for designing and implementing logging solutions
• Compliance officers who need to ensure audit records are protected as required by relevant standards and regulations
• IT auditors testing the effectiveness of log protection controls
• Incident responders who rely on log data for forensic investigations

What is the risk?

Logs contain sensitive information about your systems and users. If an attacker gains unauthorized access to your logs, they could:

• Delete log entries to cover their tracks and avoid detection
• Modify log entries to misdirect investigations or implicate innocent parties
• Leak log data containing sensitive business information or Personally Identifiable Information (PII)

The LOG-09 control aims to prevent log tampering and unauthorized access through a combination of technical controls and auditing processes. When implemented effectively, it significantly reduces the risk of logs being compromised. However, it's not a silver bullet - determined attackers with privileged access may still find ways to circumvent the controls.

What's the care factor?

Log protection should be a high priority for any organization that takes security and compliance seriously. Logs are often the only record of what happened during a security incident. If you can't trust your logs, you're flying blind.

Failure to adequately protect logs can result in:

• Delayed incident detection and response
• Inconclusive forensic investigations
• Audit failures and compliance violations
• Reputational damage and loss of customer trust

Of course, the Care Factor™️ ultimately depends on your threat model and risk appetite. A small business with a brochure website probably doesn't need to go all out on log protection. But for a cloud service provider or a business dealing with sensitive data, robust log protection is a must-have.

When is it relevant?

The LOG-09 control is relevant for any system that generates security audit logs, which should be pretty much everything these days.

Some common examples where log protection is crucial:

• Authentication systems logging successful and failed login attempts
• Cloud platforms logging administrative actions and configuration changes
• Applications logging errors, warnings and debug information
• Firewalls and Intrusion Detection Systems logging blocked traffic and alerts

Log protection may be less relevant for ephemeral systems like serverless functions that only live for a few seconds and don't generate persistent logs. But even then, you should still consider how to secure any centralized log aggregation and storage systems.

What are the trade-offs?

Implementing robust log protection comes with some costs and challenges:

• Encrypting logs at rest and in transit adds latency and consumes CPU cycles
• Granular access controls and approval workflows for log management can slow down investigations and troubleshooting
• Retaining tamper-evident logs (e.g. Write-Once-Read-Many storage) for long periods gets expensive at scale
• Logging every action in detail can generate massive volumes of data to store and analyze

As with all security controls, it's about striking the right balance between security, performance, usability, and cost. Don't go overboard logging everything to the max if you don't really need to.

How to make it happen?

Here's a high-level checklist for implementing the LOG-09 control:

1. Identify which systems generate security audit logs and what events they log
2. Categorize logs based on sensitivity and criticality
3. Define roles and responsibilities for log management (e.g. who can view, modify, delete)
4. Implement access controls and approval workflows in your log management system, ideally with multi-factor authentication
5. Configure your logging pipeline to encrypt logs in transit (e.g. TLS) and at rest (e.g. KMS)
6. Use an append-only storage system for high-value logs to prevent deletion (e.g. Amazon S3 Object Lock)
7. Enable versioning on log storage to track changes and prevent accidental deletion
8. Set up alerts for suspicious log management activities (e.g. bulk deletion, access from unexpected location)
9. Regularly review log access and change logs to detect anomalies
10. Test your log protection controls periodically (e.g. try to modify or delete a log entry)

For more detailed guidance, check out the NIST SP 800-92 Guide to Computer Security Log Management.

What are some gotchas?

Some common pitfalls to watch out for when implementing log protection:

• Giving too many people unrestricted access to modify or delete logs for operational convenience. Apply least privilege!
• Forgetting to secure log backup and archival systems with the same rigor as production log storage.
• Allowing logs to be sent over insecure unencrypted channels (e.g. syslog over UDP without TLS).
• Neglecting to test log tampering scenarios and incident response procedures before an actual incident occurs.

When using AWS services for logging, be aware of the granular IAM permissions needed, such as:

• cloudtrail:GetTrailStatus - to check if CloudTrail logging is enabled
• s3:GetBucketVersioning - to check if S3 bucket versioning is enabled
• s3:PutObjectLegalHold - to place legal holds on S3 objects and prevent deletion
• logs:CreateLogGroup - to create new CloudWatch log groups
• logs:PutRetentionPolicy - to configure log retention policies in CloudWatch
• kms:Encrypt - to encrypt logs using KMS keys

Refer to the AWS CloudTrail, Amazon S3, and Amazon CloudWatch Logs documentation for more details on IAM policies.

What are the alternatives?

While the LOG-09 control prescribes some specific best practices, there are other ways to achieve the same security outcomes:

• Instead of using a separate log management system, you could build tamper-evident logging directly into your application. For example, by signing log entries with a private key and publishing the signatures.
• Hardware Security Modules (HSMs) can provide even stronger protection for log signing and encryption keys compared to software-based key management.
• Blockchain-based immutable ledgers are an emerging approach for tamper-proof logging, though they come with scalability and complexity challenges.

Ultimately, the right approach depends on your specific requirements, constraints, and existing tooling. The key is to have some form of log protection in place, rather than leaving logs wide open.

Explore further

• NIST SP 800-92 Guide to Computer Security Log Management: https://csrc.nist.gov/publications/detail/sp/800-92/final
• CIS Critical Security Controls v8 - Control 8: Audit Log Management: https://www.cisecurity.org/controls/v8
• AWS Logging and Monitoring Whitepaper: https://docs.aws.amazon.com/whitepapers/latest/logging-monitoring-aws/logging-monitoring-aws.pdf
• AWS re:

‍