Auditing and Logging

Examine how your application uses auditing and logging. Besides preventing repudiation issues, regular log file analysis helps identify signs of intrusion. Table 5.10 shows the most common auditing and logging vulnerabilities.

Table 5.10: Common Auditing and Logging Vulnerabilities

Vulnerability	Implications
Failing to audit failed logons	Attempted break-ins go undetected.
Failing to secure audit files	An attacker can cover his or her tracks.
Failing to audit across application tiers	The threat of repudiation increases .

Review the following questions to help verify the approach to auditing and logging by your application:

• Have you identified key activities to audit?

• Have you considered how to flow original caller identity?

• Have you considered secure log file management policies?

Have You Identified Key Activities to Audit?

Your design should define which activities should be audited . Consider the following:

• Do you audit failed login attempts?

  This allows you to detect break-in and password-cracking attempts.

• Do you audit other key operations?

  Check that you audit other key events, including data retrieval, network communications, and administrative functions (such as enabling and disabling of logging).

Have You Considered How to Flow Original Caller Identity?

Your design should ensure that activity is audited across multiple application tiers. To do so, the identity of the original caller must be available at each tier .

• Do you audit across application tiers?

  Examine whether each tier audits activity as it should.

• How do you synchronize multiple logs?

  Log files may be needed in legal proceedings to prove crimes committed by individuals or to settle cases of repudiation. Generally, auditing is considered most authoritative if the audits are generated at the time of resource access and by the same routines that access the resource. Verify that the application design factors in log file synchronization and logs some form of request identifier to ensure that multiple log file entries can be correlated and related back to a single request.

• How do you flow the original caller identity?

  If you do not flow the original caller identity at the operating system level, for example, because of the limited scalability that this approach offers, identify how the application flows the original caller identity. This is required for cross-tier auditing (and potentially for authorization).

  Also, if multiple users are mapped to a single application role, check that the application logs the identity of the original caller.

Have You Considered Secure Log File Management Policies?

Check whether your application design factors in how log files are backed up, archived, and analyzed. Log files should be archived regularly to ensure that they do not fill up or start to cycle, and they should be regularly analyzed to detect signs of intrusion. Also ensure that any accounts used to perform the backup are least privileged and that you secure any additional communication channels exposed purely for the purpose of the backup.