In this section, we discuss the overall structure of the ELS and
introduce three important elements of its design: event logs, event
sources, and events. The principal security aspect of the ELS is as
the means to audit Windows security events, for which .NET
unfortunately does not provide good support. However, the ELS is an
important tool that you should use within your own projects to record
important application events.
1. Event Logs
The ELS defines a
common format for
storing events persistently in log files. The
details of the file format and the location of the file on disk are
not important to the programmer; the ELS acts as a broker between the
source of an event (an application, device driver, etc.) and the log
file in which the event is written. The ELS supports three default
event logs, each of which has a specific purpose:
The System log
-
The System log records significant events that occur
within components of the operating system (for example, a failure
within a device driver).
The Application log
-
The Application log records events from applications (for
example, an unexpected application failure).
The Security log
-
The Security log provides a record of audited security
activity (for example, accessing a protected file).
Additional logs may supplement the three default logs, depending on
the configuration of the Windows computer; for example, a computer
configured as a Domain Name System (DNS) server will have a
DNS Server
log. Windows domain controllers will have two additional logs:
Directory Service and
File Replication Service. Programmers can
also create custom logs that store events from only their
applications or system components.
One of the most useful features of the ELS is the ability
to route
events over the network for storage by the ELS running on a remote
computer, as illustrated in Figure 1. This
feature allows you to collate related events in a single location by
designating a log server to store events on behalf of a group of
computers, typically performing related tasks. This collation allows
you to look for patterns of events that may not be visible if the
events were stored locally on each computer. Event collation is
especially useful for the Application log, where events that may not
be significant on their own (for example, an application process
terminates unexpectedly) may take on a greater meaning when seen
alongside other events (perhaps the unexpected termination indicates
a coordinated attack against a group of related computers).
Access to the event logs is restricted based on the account under
which an application is running. Table 1
summarizes the restrictions for the Application and System logs. The
LocalSystem account is used by Windows Services;
consult the Windows documentation for more details.
Table 1. Account restrictions for the Application and System logs
|
Event Log
|
Account
|
Read events
|
Write events
|
Clear events
|
|---|
|
Application
|
LocalSystem
|
✓
|
✓
|
✓
|
| |
Administrator
|
✓
|
✓
|
✓
|
| |
Domain administrators
|
✓
|
✓
|
✓
|
| |
All other accounts
|
✓
|
✓
| |
|
System
|
LocalSystem
|
✓
|
✓
|
✓
|
| |
Administrator
|
✓
|
✓
|
✓
|
| |
Domain Administrators
|
✓
| |
✓
|
| |
All other accounts
|
✓
| | |
The Security log is a special case. Only operating system components
can write events to this log based on a security audit policy.
Applications can read and clear events from the Security log only
when running under an account granted the "Manage
Auditing and Security Log" user right; consult the
Windows documentation for details of security and auditing
configuration.
2. Event Sources
An application must register an event
source before using the ELS to record events. The ELS
writes the name of the event source to the event log as part of the
event. Applications typically specify their name or the name of an
application component as the event source value.
Each event source is associated with a single event log, but
applications can register and use more than one event source if they
wish to write events to several logs; it is also possible to register
multiple event sources that are associated with a single event log to
create events with different event source values. Figure 2 illustrates how an application can register
event sources to be associated with several logs.
Event sources are persistent, which means that once an application
has registered an event source with the ELS, it is associated with
the specified log file until the event source is deleted explicitly.
Registering an event source does not provide exclusive use, and
because each event source is associated with a specific event log,
you must ensure that the event sources you use are configured as you
expect. Figure 3 illustrates what can happen if
two applications write events using the same event source.
Application #1 has registered an event source and has specified that
it should be associated with a custom log that is intended solely for
that application's events. Application #2 uses the
same event source name, and events intended for the Application event
log are inadvertently routed to Application #1's
custom log.
3. Event Structure
The ELS uses a standardized structure to
represent all events, irrespective of the log in which the event will
be stored. Figure 4 shows the part of the event
structure exposed by the .NET Framework; we provide a brief
explanation of each structural element in the following sections.
3.1. Event source name
This is the name of the event source used to log the
event. As we explained in the previous section, applications can
register multiple event sources.
3.2. Message
The message component is a human-readable
description of the event, which may be of use when trying to
determine the cause of a problem. We recommend that descriptions
should be clearly phrased and to the point, and should not contain
overly technical terms; consider using the binary data portion of an
event to include detailed information about the reasons leading to
the occurrence of an event.
3.3. Event type
The ELS defines a
set of event types, which we summarize in Table 2; the event type indicates the severity of the
issue that the event represents.
Table 2. Event types
|
Event Type
|
Description
|
|---|
|
Error
|
Error events represent significant problems that the user or
administrator should know about immediately. Errors usually indicate
a loss of data or significant impairment of functionality.
|
|
Warning
|
A warning indicates a problem that is not significant in the short
term, but which may result in future problems. For example, an
application may indicate that a disk is low on space—the
application can still write data to the disk, but if no action is
taken, the disk will fill and the application will fail.
|
|
Information
|
Information events reflect infrequent operations that have completed
successfully. For example, services may record that they have started
successfully.
|
|
Success audit
|
Success audit events are security events that occur when an audited
access attempt is successful. For example, a successful logon attempt
is a success audit event.
|
|
Failure audit
|
Failure audit events are security events that occur when an audited
access attempt fails. For example, a failed attempt to open a file is
a failure audit event.
|
3.4. Event identifier and event category
The event identifier and category are
application-specific numeric values. Applications can provide message
files that provide human-readable explanations of the event, and the
reasons leading to the event occurring; however, the .NET Framework
does not support this functionality. Consult the Windows API for
details of how to use message files.
3.5. Binary data
The event may
contain binary data that is of use to someone trying to resolve the
problem that caused this event to occur. The ELS does not interpret
the data, and the content is dependent upon the application; there
are no standardized formats or tools available to assist with the
analysis of this data.
