A System and Device Log File Example (Windows) - Security

Not every operating system or application logs the same types of information. To know what to configure, where to find logs, and what information within the logs is useful requires knowledge of the specific system. However, looking at an example of the logs on one system is useful because it gives meaning to the types of questions that need to be asked. Windows and Unix logs are different, but for both I want to be able to identify who, what, when, where, and why. The following example discusses Windows logs.

NOTE  Performing a security evaluation or audit on one operation system can be daunting. Imagine the situation when one operating system hosts another. Today's mainframe systems often do just that, hosting Unix or Linux. For insight into auditing such a system, see the paper "Auditing Unix System services in OS/390" at http://www-1.ibm.com/servers/eserver/zseries/zos/racf/pdf/toronto_03_
2001_auditing_unix_system_services.pdf.

Windows audit logging for NT, XP, and Windows 2000 is turned entirely off by default. (Log activity is collected for some services, such as IIS, and system and application events are logged.)

Windows Server 2003 has some audit logging turned on by default, and those settings are shown in Figure 8-1. An administrator can turn on security logging for all or some of the categories and can set additional security logging by directly specifying object access in the registry, in a directory, and in the file system. It"s even possible to set auditing requirements for all servers and desktops in a Windows 2000 or Windows Server 2003 domain using Group Policy (a native configuration, security, application installation, and script repository utility).

FIGURE 8-1 Windows security audit policy
(Windows Server 2003 default)

Even when using Windows Server 2003, it's important to understand what to set because the Windows Server 2003 default policy logs the bare minimum activity. Needless to say, turning on all logging categories is not appropriate either. For example, in Windows security auditing, the category Audit Process Tracking would be inappropriate for most production systems because it records every bit of activity for every process -- way too much information for normal drive configurations and audit log review. However, in a development environment, or when vetting custom software to determine that it only does what it says it does, turning on Audit Process Tracking may provide just the amount of information necessary for developers troubleshooting code or analysts inspecting it.

Audit events are logged to a special local security event log on every Windows NT (and above) computer that is configured to audit security events. Event logs are located in the %windir%system32config folder. In addition to security events, many other events that may provide security or activity tracking information are logged to the application log, the system log, or, on a Windows 2000 and above domain controller, the DNS Server log, Directory Service log, or File Replication Service log. These logs are shown in Figure 8-2. In addition, many processes offer additional logging capabilities. For example, if the DHCP service is installed, it, too, can be configured to log additional information such as when it leases an address, whether it is authorized in the domain, and whether another DHCP server is found on the network. These events are not logged in the security event log; instead, DHCP events are logged to %windir%system32dhcp.

FIGURE 8-2 Windows Server 2003 domain event logs

Many services and applications typically can have additional logging activity turned on, and that activity is logged either to the Windows event logs, to system or application logs, or to special logs that the service or application creates. IIS follows this pattern, as do Microsoft server applications such as Exchange, SQL Server, and ISA Server. The wise systems administrator, and auditor, will determine what is running on systems in the Windows network and what logging capabilities are available for each of them. While much log information relates only to system or application operation, it may become part of a forensics investigation if it is necessary or warranted to reconstruct activity. A journal should be kept that includes what information is being logged on each system and where it is recorded.

Many of the special application logs are basic text files, but the special 'event logs' are not. These files have their own format and access to them can be managed. While any application can be programmed to record events to these log files, events cannot be modified or deleted within the logs.

NOTE  Some time ago, a utility was developed to delete an event from the security log, but when it was used, log files were corrupted. This provided evidence that an attack had occurred, at least.

Event logs do not automatically archive themselves, must be given a size, and may be configured, as shown in Figure 8-3, to overwrite old events, halt logging until manually cleared, or in Security Options, stop the system when the log file is full. Best practices advise creating a large log file and allowing events to be overwritten, but monitoring the fullness of files and archiving frequently so that no records are lost.

FIGURE 8-3  Log file configuration

Auditable events produce one or more records in the security log. Each record includes event-dependent information. While all events include an event ID, a brief description of the event and the event date, time, source, category, user, type, and computer, other information is dependent on the event type. Figure 8-4 shows the successful Administrator account local logon to the domain controller. Note the inclusion of the Client IP address, represented in Figure 8-4 as the local address.

FIGURE 8-4  Viewing an event

Log File Summarization and Reporting

Early security and systems administrator advice emphasizes that logs must be reviewed on a daily basis and assumes that there is time to do so. We now know that except in unusual circumstances that does not happen. Today's best practice advises that the following actions be taken:

• Post log data to external server.
  
• Consolidate logs to a central source.
  
• Apply filters or queries to produce meaningful results.

Posting log data to an external server helps to protect the log data. If a server is compromised, attackers cannot modify the local logs and cover their tracks. Consolidating logs to a central source makes the data easier to mange -- queries only need to be run on one batch of data. The Unix utility syslog, when utilized, enables posting and consolidation of log data to a central syslog server. A version of syslog is available for Windows.

The downside, of course, is that network problems may prevent events from being posted, and a successful attack on the syslog server can destroy or call into question the validity of security events for an entire network.

Four other techniques for log consolidation are listed here:

• Collect copies of security event logs on a regular basics and archive them in a SQL database such as Microsoft SQL Server, and then develop SQL queries to make reports or use a product such as Microsoft's LogParser to directly query this database or any log type.
  
• Invest in a third-party security management tool that collects and analyzes specific types of log data. Examples of such tools are Microsoft's MOM (Windows) and NetIQ.
  
• Develop a Security Information Management (SIM) system or an integrated collection of software that attempts to pull all log data from all sources -- security logs, web server logs, IDS logs and so forth -- for example, Guardnet's neuSECURE, netForensics, or Itellitatics' Network Security Manager (NSM).
  
• Use or add the log management capabilities of systems management tools such as IBM's Tivoli or Enterasys Dragon.