Chapter 18: Security Logging | Secure Messaging with MicrosoftВ® Exchange Server 2003 (Pro-Other)

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. There are three primary features necessary for a usable auditing system:

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.
You must be able to correlate 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.
Log files must support some type of protection so that they re not 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. All modern operating systems provide operating system-level protection to prevent the event logs from being tampered with by unauthorized users.

Microsoft Windows maintains several event log files: the application log, the security log, the system log, and logs for specific system components (like Active Directory and IIS) that may or may not be present on individual machines. Applications add events to the application log. Device drivers and the operating system modify the system log. Entries in the security log are generated by various system components when a machine s administrator decides to monitor specific security- related events, like logon successes and failures.

The point of our interest is the security log, also known as the audit log. This log is a powerful tool that tells us what happened, when it happened, and under whose account it happened , which makes it much easier to pinpoint suspicious or malicious behavior. 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 automated tools can assist the people assigned to the task.

How Windows Auditing Works

Audit logs in Windows 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 Microsoft Windows 2000 Server and Windows Server 2003 installation. 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 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. In fact, applications and components have even more freedom than that ”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. Applications call a system routine, ReportEvent, to log events.

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 security log files. (Note that all log files have access control lists (ACLs) that can be set to give finer-grained control over who can read and modify the application, system, and component-specific 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:

Launch the policy editor; expand the Computer Configuration Windows Settings Security Settings Local Policies node.
Select User Rights Assignment.
In the right-hand pane, double-click Manage Auditing And Security Log.
In the Security Policy Settings dialog box, select the Define These Policy Settings check box, and then click Add.
In the Add User Or Group dialog box, enter the user or group name to which you want to grant event log management power.
Click OK, and then repeat steps 4 and 5 for other groups.
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.

Note	Microsoft Knowledge Base article 323076 describes the details of how to set event log security using the Security Descriptor Definition Language (SDDL). With SDDL, you can apply finely detailed permissions for reading, writing, and clearing the logs.

What Windows Puts in the Event Logs

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

Table 18-1: Audited Security Event Types Logged by Windows Server 2003
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 an account holder attempts to exercise a user right
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.