Chapter 17: Security Logging

Do not go where the path may lead, go instead where there is no path and leave a trail.

—Ralph Waldo Emerson

Understanding Security Logging

The purpose of logging systems is to create a persistent record of events that have occurred. This record is useful for auditing and forensic investigations of things like penetration attempts and security compromises.

Microsoft Windows maintains three log files: the application log, the security log, and the system log. Applications add events to the application log. The system log is modified by device drivers and the operating system. The security log is generated and modified when a machine’s administrator decides to monitor events, like logon successes and failures.

There are three primary features necessary for a usable auditing system. First, an auditing system must generate persistent records. It is impossible to monitor all key systems simultaneously and in real time, so some analysis has to be performed after the fact. You’ll need an event history recorded in a file or database. Second, you must be able to combine the different log files to build a consistent, continuous record of all events ordered by time of occurrence. When something terrible happens, a single log file might not tell the whole story. Your detective work is made much easier by combining multiple logs at a point in time and cross-referencing events. Finally, your log files must not be editable by just anyone; you can’t catch someone if he or she can erase all evidence of his or her visit from the log files.

Audit logs are a powerful tool. They tell you what happened, when it happened, and under whose account it happened. However, this tremendous benefit is lost if you never look at the logs. Admittedly, manually reviewing audit logs is a time- consuming, boring, thankless job. It has to be done for problem analysis or as an institutional practice (some organizations require manual audits of logs on secured systems), but the people assigned to the task can be assisted by automated tools.

How Windows 2000 Auditing Works

Audit logs in Microsoft Windows 2000 are handled by the Event Log service. The service uses the EventLog key in the registry. There are three default subkeys, Application, System, and Security; these are the three systemwide audit logs in every Windows 2000 installation.

Applications call a system routine, ReportEvent, to log events. What a particular application logs, and what the event log messages say, is completely up to the application developer. Event logs are specific to a single machine, and the events themselves are stored in a set of binary files on the local machine.

By default, the log files are located in the \%Systemroot%\System32\Config\ directory. The security log file is named SecEvent.evt, the application log is AppEvent.evt, and the system log file is named SysEvent.evt. (Windows 2000 also maintains additional logs for Active Directory, Domain Name System, and the File Replication Service, among others—any application or component is free to create its own event log file.)

By default, only the administrator and members of the Domain Admins and Enterprise Admins groups have the Manage auditing and security log right, which allows holders to manage auditing and the associated log files. You can specify who should have this right by using the domain Group Policy editor to modify the set of accounts that holds this right using this procedure:

1. Launch the policy editor; expand the Computer Configuration | Windows Settings | Security Settings | Local Policies node.

2. Select User Rights Assignment.

3. In the right-hand pane, double-click Manage Auditing And Security Log.

4. In the Security Policy Settings dialog box, select the Define These Policy Settings check box, then click Add.

5. In the Add User Or Group dialog box, enter the user or group name to which you want to grant event log management power.

6. Click OK, then repeat steps 4 and 5 for other groups.

7. Click OK in the Security Policy Settings dialog box.

When you give an account this power, you are essentially giving the user a way to tamper with the system and security logs, where all the security-sensitive events go. I therefore recommend being stingy with this access.

What Windows 2000 Puts in the Event Logs

Table 17-1 describes the most interesting of various security event types for which auditing can be enabled on Windows 2000 systems.

Table 17-1: Audited Security Event Types Logged by Windows 2000

Event Category	What Initiates the Event
Logon	When a user logs on or off a machine
Account logon	When a machine validates a user account; typically this is when a domain controller validates a domain account that is being used to log on elsewhere
Object access	When an audited object is accessed in a manner being monitored
Directory service access	When an Active Directory object is accessed
Privilege use	When a user right is exercised
Process tracking	When an application starts or terminates, or performs an action that is being tracked
System events	When an event that affects system security occurs, including rebooting or shutting down the system
Policy change	When an auditing policy, security policy, or user rights policy is changed

It’s important to understand a few subtleties about the auditing system. First, the event log entry for an action is written before the action occurs. For example, the log entry for a process creation request is generated before the process is ever created. Second, remember that the event log entries fall into two categories: successes and failures. The patterns in which these occur can be just as important as the events themselves—one common indication of an attack is a set of failed attempts (for example, to log on as a particular account) followed by a success.