Event Logging Best Practices

Event log management and response might be one of the most neglected areas of security management. Many security managers rely on users or security bulletins from operating system and application vendors to decide when it's time to take action on a possible security compromise. By the time these announcements have hit the Internet, it's usually too late for administrators to react. Assets have already taken a hit, and damage has already been done.

NOTE

This fact, by the way, is the number one reason you should have CSA installed on all your systems. Customers who had CSA deployed during all the largest attacks, including Code Red, Nimda, Sasser, and Slammer, suffered no downtime at all.

The problem to be solved in this section is how to become proactive in searching out logs to recognize early signs that your network might be the target of an attack or that an attack might be in progress.

ASA/PIX Security Appliance messages aren't going to be your best source to determine whether your network assets are under attack. CSA logs are the best source for that. It's recommended that, along with CSA, you get a software package called Event Monitor. Event Monitor consolidates all your CSA alarms in a hierarchal interface, much like a spreadsheet. All like events are sorted together, and you can expand the event to a detailed level. By using this tool, you can recognize whether a new attack is underway because you will likely see groupings of the same error messages with different destination IP addresses. In most cases, these events give you enough information to understand whether you can do anything to help stop the attack at the perimeter. With new features in CSA 4.5, if the CSA Management Center senses multiple "like" messages, it assumes a worm or mutating virus is in the network and generates a rule to quarantine the infected hosts.

Remember, defense in depth is all about layers of defense.

Here is a simple example of how you could have manually used the CSA logging information to increase your layers of defense when Slammer hit.

CSA protected the hosts and servers by recognizing that a buffer overflow took place in the SQL process and that malicious code was attempting to run from the overflowed buffer. Because SQL uses UDP port 1433, security administrators could have done the following to increase the security posture of their environment:

• Security administrators could have written a custom CSA rule to stop SQL (UDP/1433) traffic on machines that don't rely on UDP 1433.

• Security administrators could have written access rules stopping UDP/1433 traffic on the perimeter.

• If the traffic was coming from a single source, security administrators could have written access rules stopping traffic from that source. CSA 4.5 does this automatically.

ASA/PIX Security Appliance syslogs tend to be more focused on functions of the firewall. The security appliance syslog has seven different severities or classes of syslog messages, as follows:

• Alert messages, Severity 1

• Critical messages, Severity 2

• Error messages, Severity 3

• Warning messages, Severity 4

• Notification messages, Severity 5

• Informational messages, Severity 6

• Debugging messages, Severity 7

Table A-1 classifies ASA/PIX Security Appliance syslog messages and provides a description for each class.

Table A-1. ASA/PIX Syslog Message Classes

Message Classes	Description
Alert	These messages indicate that action has been taken by the security appliance to resolve a problem or that action needs to be taken by the administrator because of an interface failure, unit standby failure, or bad cables. An administrator should always follow up on an alert message.
Critical	These messages indicate that traffic has been blocked or dropped, that spoofed traffic has been detected, or that flags are invalid in traffic. An administrator should usually follow up on critical messages.
Error	These error messages are specific to security appliance resources such as xlate failures and translation slot failures. An administrator should always follow up on error messages.
Warning	These messages are generally warnings about connection problems. Many of these problems might be cleared up by the protocols on either end, but an administrator might have to follow up on these warning messages.
Notification	These messages are a mix of notifications of what a security appliance logged-in user is doing on the machine and some messages about Java and ActiveX blocking. An administrator should look at these messages to ensure that unauthorized changes are not being made to the security appliance.
Informational	These messages describe connections being built and torn down through the security appliance. In most cases, these messages don't need to be audited by an administrator unless users report that they are having problems with specific connections or services.
Debugging	These messages are mostly related to IPSec. An administrator uses these messages when bringing up an IPSec tunnel for the first time. For the other debug messages, refer to the Security Appliance technical documentation on the Cisco website.

NOTE

You can find all syslog messages and the proper responses in the ASA/PIX Security Appliance technical documentation at http://www.cisco.com/go/pix or http://www.cisco.com/go/asdm.