Using Log Data for Effective Troubleshooting

Log data is a valuable tool for troubleshooting problems or identifying crucial clues during an incident response. But you must configure logging to capture the right information in the first place, or you won’t have it when you need it.

The Value of Logging Data

Recent events such as the Epsilon data breach illustrate why log data is so valuable. Reviewing log data can help determine how or when attackers were able to breach a network and identify exactly what information was compromised. In fact, logging key information is required by many compliance directives such as Sarbanes–Oxley and HIPAA.

But logging only works if it is enabled and configured proactively. Getting hit by a security incident and realizing logging was not enabled is like wanting to watch a recording of the Super Bowl and realizing you never set the DVR: There is no way to go back in time and set it.

If IT admins don’t configure logging or don’t log the correct events, then troubleshooting issues and responding to incidents can be like looking for a needle in a haystack. On the other hand, monitoring and logging events and activities on a computer takes up system resources and can have a significant impact on network performance. IT admins must find a balance — log enough of the information that matters, when it’s needed, without bogging down the system in the process.

Setting Up Logging

Windows Server 2008 and Windows 7 machines are capable of logging a comprehensive array of system events and activities. With these operating systems, security policy can be configured to audit account log-on events, account management, directory service access, object access, policy change, privilege use, process tracking and system events.

To configure Local Security Policy on an individual system, click the Start orb, and type “security policy” in the search bar. The Local Security Policy console will appear as a search result, and you can start the program from there (Figure 1). On a broader scale, Windows Server 2008 can be used to establish domain security policies that apply to a range of PCs.

Figure 1: Windows security policy can be configured to audit and log a variety of system events.

For each of the policy options that appear in the right pane, you can choose to log success, failure or nothing. But choose wisely. Using object access as an example, if you only log failure events, you would have a record of when someone tried to access the file or folder but failed because of not having the proper permissions or authorization. But you would not have a record of when an authorized user accessed the file or folder.

From a security incident response perspective, success auditing is often more valuable. An attacker is often able to penetrate a network or PC using cracked or stolen credentials, so the log-on and object access events would be a “success” and would not be captured if you only log failure events.

If you view the logs and see that an employee copied and deleted the company financial statement at 3 a.m. Sunday, it might be safe to assume that employee was sleeping and that perhaps his user name and password have been compromised. In any event, you now know what happened to the file and when, and it gives you a starting point for investigating how the event happened.

Both failure and success logging can provide useful information and clues, but you have to balance your monitoring and logging activities with system performance.

Audit policy enhancements introduced in Windows Server 2008 R2 and Windows 7 enable administrators to implement auditing and logging at a more granular level, such as enforcing compliance on a domain or OU (organizational unit) level, or monitoring files that are accessed by a defined group of users. That gives administrators more flexibility to audit in more detail, but on a smaller scale that will have less impact on the server or the organization as a whole.

Storing Log Data

Aside from the performance impact, you also have to consider the storage space occupied by the log data as well as the integrity of the log data. Attackers know how to cover their tracks and will modify log data to erase the evidence if given the chance.

In Windows Server 2008 R2 and Windows 7, the amount of log data is restricted only by the amount of storage space available. You need to gauge how large the log files will get and make sure you have enough disk space in the first place. You also need to set up a policy for whether old logs will be overwritten or deleted, or if you want to archive the logs on a daily, weekly or other periodic basis so that you have older data to look back on.

For performance, storage capacity and security reasons, it is recommended that log data be centralized on a dedicated server or storage array. Using a dedicated system will have less performance impact because the log files can be written to the disk without having to fight with other applications that are running for access to the drive. Locking down the log data with strict security policies will help ensure that attackers are not able to alter or delete relevant log data.

Making Sense of It All

There is no point in capturing log data if you never use it. While it is nice to have the data stored for forensic evidence for an incident response, it can also be a proactive tool to help identify that an incident is occurring.

IT administrators should review the logs regularly to establish a baseline of normal activity and to be able to identify any suspicious activity. Log data can be viewed using the Windows Event Viewer. Just expand Windows in the left pane, and select Security to view the Security events (Figure 2).

Figure 2: Windows Event Viewer lets you view the accumulated log data.

Effective, proactive monitoring of log data, even for a single PC, can be daunting; attempting to monitor a domain or network is virtually impossible without some help. Thankfully, there are a variety of log management solutions such as those available that help correlate and analyze log data to proactively identify potential issues.

Don’t wait. Log data is only useful if you capture it before you need it. Explore the audit policy options available and make sure you are logging the crucial details you need to troubleshoot problems or respond to incidents.