ASVS 5.0 V16.4.2 requires that logs are protected from unauthorized access and cannot be modified. It is a Level 2 requirement. In practice that means restricted read access, append only writes for the application, and a way to detect after the fact that something changed.
Why it matters
An attacker who gets code execution wants two things: data, and a clean exit. Deleting or editing logs delivers the second. Meanwhile logs often hold user identifiers, internal hostnames and the odd token someone logged by mistake, so open read access is its own exposure.
Auditors ask the same two questions every time. Who can read the logs, and can anyone change them?
How to implement it
Split the permissions by role. The application identity can write. A small group of responders can read. Nobody edits.
On a host with local files, the app account should own nothing it can rewrite after rotation:
# logs are written by the service, readable by the security group only
install -d -o svc-app -g sec-read -m 0750 /var/log/app
chattr +a /var/log/app/audit.log # append only (ext4); root can still clear it
The append flag helps, but root can clear it, which is why shipping logs off the host (see V16.4.3) matters.
For object storage, use write once retention. On AWS S3 that is Object Lock in compliance mode; the policy below denies delete for everyone except a break glass role:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Principal": "*",
"Action": ["s3:DeleteObject", "s3:DeleteObjectVersion"],
"Resource": "arn:aws:s3:::example-audit-logs/*",
"Condition": {"StringNotEquals": {"aws:PrincipalArn": "arn:aws:iam::111122223333:role/break-glass"}}
}]
}
Add integrity checking: hash chaining or signed digests per file, so a gap or edit is detectable. Log administrator access to the logs too.
How to test it
- Log in as the application service account and try to delete and truncate a log. Both should fail.
- Log in as a normal developer without the security group and try to read the audit log. Expect permission denied.
- In the log store, attempt to delete an object younger than the retention period.
- Edit a copy of a signed log file and run your verifier. It should report the change.
Keep screenshots or command output as evidence.
Evidence an auditor will ask for
Plan the evidence while you build. A short package works well: the permission listing for the log store, the retention and lock configuration, an export of who accessed the logs in the last quarter, and a record of one tamper test with its result. Regenerate it on a schedule so it never goes stale.
Access reviews and break glass
Review who can read logs every quarter and remove anyone who changed roles. Have a documented break glass path for deletion, for the rare legal or privacy case, that needs two approvers and creates its own audit entry. Deletion that cannot happen at all is not realistic because privacy requests exist, so the requirement is controlled and visible modification, never silent modification.
Common mistakes
- World readable log directories (mode 0644 files in a 0755 directory).
- Giving the app account delete rights for rotation, which also lets an attacker clear traces.
- Keeping the only copy on the compromised host.
- Letting every engineer into the logging platform with an admin role.
Quick check
Does chattr +a alone satisfy the requirement?
No. A privileged attacker can remove the flag. Pair it with off host shipping and retention locks.
