Programming .Net Security

2017-07-07 02:10:07

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.

20.1.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; we show you how to create custom logs in Section 20.2.5 later in this chapter.

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 20-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).

Figure 20-1. Event sources can use the ELS to write events to logs that are stored locally or on another computer

Access to the event logs is restricted based on the account under which an application is running. Table 20-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 20-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.

20.1.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. We demonstrate how to create an event source in Section 20.2.2.

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 20-2 illustrates how an application can register event sources to be associated with several logs.

Figure 20-2. Applications can create several event sources in order to write events to more than one log file

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. We demonstrate how to create and delete event sources in Section 20.2.

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 20-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. See Section 20.2.2 for details of how to check the configuration of an event source.

Figure 20-3. Registering an event source does not guarantee exclusive access to the registered name

Event sources provide functionality not supported in the .NET Framework; for the purposes of this book, an event source is simply a name that is associated with a specific log file. Consult the Windows API reference for full details of event source features.

20.1.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 20-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.

Figure 20-4. The structure of an event exposed by the .NET Framework

20.1.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.

20.1.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.

20.1.3.3 Event type

The ELS defines a set of event types, which we summarize in Table 20-2; the event type indicates the severity of the issue that the event represents.

Table 20-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.

20.1.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.

20.1.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.