ASVS 5.0 V16.4.3 requires that logs are securely transmitted to a logically separate system used for analysis, detection, alerting and escalation. The goal is stated in the requirement itself: if the application is breached, the logs are not compromised. It is a Level 2 requirement.
Two ideas are in there. Transport must be protected, and the destination must sit outside the blast radius of the application: different credentials, different administrators, ideally a different account or tenancy.
Why it matters
Local logs die with the host. Containers are deleted, disks are wiped, and an intruder with root can rewrite history. A copy on another system, with separate access control, gives defenders a record the intruder cannot reach.
The same system is where detection runs. Logs that nobody correlates do not alert anyone. Shipping them is what makes alerting and escalation possible.
How to implement it
Pick a collector that runs outside the app trust zone and forward over TLS with server verification, and mutual TLS where you can. Buffer on disk so a network blip does not drop events.
A Fluent Bit output to a central syslog or HTTP endpoint with TLS verification on:
[OUTPUT]
Name forward
Match *
Host logs.internal.example
Port 24224
tls On
tls.verify On
tls.ca_file /etc/ssl/certs/log-ca.pem
tls.crt_file /etc/fluent-bit/client.pem
tls.key_file /etc/fluent-bit/client.key
Retry_Limit False
Design rules that make the separation real:
- The app writes, the log platform stores. The app identity has no read or delete rights on the destination.
- The log platform is administered by a different group, with its own SSO and multi factor authentication.
- Alert rules live in the log platform, not in the app config.
- Monitor the pipeline itself. An alert for "no logs from service X for 10 minutes" catches a silenced shipper.
How to test it
- Generate a known event, such as a failed login with a unique marker, and find it in the central system within your expected delay.
- Capture traffic between the shipper and collector and confirm it is encrypted. Try pointing the shipper at a collector with an untrusted certificate; it should refuse to send.
- Using the app's credentials, try to delete or edit records in the log platform. Expect denial.
- Stop the shipper and confirm the missing log alert fires.
- Simulate host compromise: delete local logs, then confirm the central copy is intact.
Delivery guarantees
Decide what happens when the destination is down. A shipper with a disk buffer can hold hours of logs. Set a buffer size that matches the longest outage you accept, and alert when the buffer fills above half. Without that, an attacker who can take down the log platform for an hour also gets an hour of unlogged activity.
Time, order and identity
Sync clocks across systems with a trusted time source so events from different hosts line up. Tag each event with the host, service and environment, and sign or authenticate the shipper identity so records cannot be forged by a third party who finds the collector address. Sequence numbers per source let the log platform notice gaps.
Escalation paths
The requirement names escalation, not just storage. Write down who gets paged for which detection, and test the path. A quarterly game day where you plant a harmless but alert worthy event, such as a canary account login from an odd country, proves the whole chain from application to human. Keep the result as evidence alongside your configuration.
What to ship
Ship authentication events, authorization denials, administrative actions, input validation failures, control failures, and errors. Do not ship secrets or full personal data; scrub before sending, because the central store becomes a high value target and should hold the least sensitive version of the truth that still supports investigation.
Common mistakes
- Sending logs in clear text over UDP syslog across a shared network.
- Disabling certificate verification because the collector uses a private CA.
- Using the same cloud account and admin role for the app and the log store.
- No alert on pipeline silence.
- Shipping only application logs and leaving out infrastructure and authentication logs.
A reference layout
A common layout has three tiers. Applications write to standard output or a local socket. A node agent on the same host reads that stream and forwards it over mutually authenticated TLS. A central collector, run in a separate account or network segment, accepts the traffic, writes it to immutable storage, and feeds the detection engine. Each hop has its own credentials, and the application never holds credentials for the central tier beyond a write capability on the agent.
Review the layout against the question the requirement asks: if an attacker owns the application and its host, what can they do to the central logs? The honest answer should be nothing beyond adding more events. If the answer includes deleting, reading other tenants' data or silencing alerts, the separation is not yet logical in the sense the standard means.
Quick check
Is a second folder on the same server enough?
No. Logically separate means a different system with different access control, so a compromise of the application does not reach the logs.
What should the app identity be allowed to do on the log platform?
Write only. No read, no delete, no change of retention.
