Keeping your audit logs safe and sound is super important. You want to make sure you have processes and technical controls in place to protect them and retain them for as long as needed.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 - 2023-09-26. You can download a copy from https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4 to learn more. The AWS documentation on CloudTrail log file integrity validation is also a great resource: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-intro.html

Who should care?

A few key folks who should pay attention to this control:

• Security analysts with responsibility for monitoring and investigating security incidents
• Auditors with a need to verify the integrity and retention of audit logs
• Compliance officers with an obligation to meet legal and regulatory requirements around logging

What is the risk?

If audit logs aren't properly protected, a few bad things could happen:

• Attackers could tamper with or delete logs to cover their tracks
• Logs could be accidentally deleted or corrupted, losing valuable evidence
• Failure to retain logs long enough could violate compliance mandates

This control helps prevent tampering, ensure availability, and meet retention needs to avoid those issues. The risks of unprotected logs are pretty high, as it could mean missing critical security events.

What's the care factor?

For most orgs, this should be a high priority control. Audit logs are the key to detecting and investigating incidents. Losing that visibility and auditability is asking for trouble. Regulations like PCI DSS, HIPAA, SOX etc often have strict log protection requirements too. So legal and compliance risk is another big factor.

When is it relevant?

Log protection is important for any systems that generate security-relevant audit logs. This includes authentication systems, network devices, endpoints, cloud platforms, etc. It applies across IaaS, PaaS and SaaS.

It may be less critical for lower-risk commodity systems. But in general, the more important the system and data, the more the logs matter.

What are the trade offs?

Protecting logs does require some effort and cost. A few considerations:

• Logs can get big, so secure storage ain't cheap. Need to balance retention periods with cost
• Encryption, hashing, monitoring etc to protect logs takes compute cycles
• Strict controls on log access can make them harder to use. Need to balance security with usability
• Longer retention means more data to sift through. Consider tools to help search and analyze

But for most, the security and compliance benefits will easily outweigh the costs. Skimping on this is usually penny-wise, pound-foolish.

How to make it happen?

Here are some key steps to implement this control:

1. Determine legal, regulatory and organizational requirements for log protection and retention
2. Identify systems in scope and types of logs to be protected
3. Define a log classification policy. Specify collection, retention and protection levels by log type
4. Evaluate the native log security controls available in each system (e.g. AWS CloudTrail log encryption)
5. Implement a centralized logging solution that supports secure transfer, storage and access control (e.g. Splunk)
6. Enable features like log file encryption, log file integrity validation, access logging, and write-once storage
7. Restrict access to logs based on least-privilege. Limit raw log access to those with a need
8. Put an anomaly detection tool in place to alert on signs of log tampering (e.g. guard duty)
9. Implement log backup and archival according to retention policy
10. Schedule regular testing of logging controls and log data recovery

What are some gotchas?

A few things to watch out for:

• Some logs may contain sensitive data and require extra access controls (e.g PII, PCI)
• Logs from different sources may need to be normalized to a standard format for analysis
• External facing logging endpoints need to be hardened against DDoS attempts
• Log shipping to external tools requires opening up firewall port (e.g. tcp 514 for syslog). Be narrow in scope!
• Alert fatigue from log monitoring is real. Tune alerts to avoid the noise
• Failing to cycle encryption keys and certificates used for logging can cause unexpected loss of visibility

Specific to AWS, a few key IAM permissions to consider:

• cloudtrail:GetTrailStatus - Check logging state
• cloudtrail:StartLogging - Turn on logging
• cloudtrail:PutEventSelectors - Configure what gets logged
• cloudwatch:PutMetricFilter - Create log metric filter to trigger alarms
• cloudwatch:PutRetentionPolicy - Enforce log retention periods

Docs here: https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscloudtrail.html

What are the alternatives?

For logging solutions, popular cloud-native options are AWS CloudTrail and CloudWatch, Azure Monitor and GCP Cloud Logging. Many also send logs to external SIEMs like Splunk, ELK Stack or Sumo Logic.

For log protection, most cloud platforms support encryption at rest and log validation services. Alternatively, you can use 3rd party tools for tamper detection and encryption.

While SIEM use is common, some are exploring using cloud-native log analytics tools as an alternative for certain use cases.

Explore further

To dive deeper, check out:

• CIS Benchmark - Logging and Monitoring section: https://www.cisecurity.org/benchmark/amazon_web_services/
• AWS re:Invent talk on logging best practices: https://www.youtube.com/watch?v=ewdqcQUZCPs
• NIST SP 800-92 - Guide to Computer Security Log Management: https://csrc.nist.gov/publications/detail/sp/800-92/final
• PCI SSC Information Supplement - Effective Daily Log Monitoring: https://www.pcisecuritystandards.org/pdfs/Effective_Daily_Log_Monitoring_v1-1.pdf

Hope this helps explain the importance of taking good care of your logs! Let me know if you have any other questions.

‍