Web Application Defender's Cookbook

Recipe 13-2: Trap and Trace Audit Logging

This recipe shows you how to dynamically adjust logging details for malicious clients as a result of security violations.

Ingredients

• ModSecurity
  • IP:TRAP-N-TRACE variable
  • @streq operator
  • setvar action
  • expirevar action
  • ctl:auditEngine action

Trap and Trace Audit Logging

Recipes 1-6 and 1-7 discussed audit logging. Full audit logging is ideal, but many organizations opt to log only security-relevant transactions by configuring ModSecurity’s SecAuditEngine to RelevantOnly. This configuration reduces the amount of audit log data collected, but it is less than ideal from an incident response perspective. This recipe outlines a middle-ground logging configuration you can use to dynamically increase audit logging for suspicious clients.

Rather than setting a static global configuration for the amount of data we will audit-log for all clients, we can use conditional logging. For example, the RelevantOnly audit logging configuration is “alert-centric” and generates an audit log entry only if the client triggers one of our negative security rules. This is not ideal from a security perspective, because we do not have a full view of the client’s activities within the web application. What we can do instead is use a “trap and trace” configuration that uses the initial security alert as a trigger to place the client on a “watch list.” Doing so initiates full audit logging for this client, regardless of whether it triggers any more alerts. ...