SNARE for WINDOWS

Documentation Version 2.0 Dated 26 March 2003
(c) InterSect Alliance Pty Ltd 1999-2003

Table of Contents

> 1. Introduction
> 2. SNARE Overview
> 3. Installing and Removing SNARE
> 4. Setting the Audit Configuration
> 5. Audit Event Viewer Functions
> 6. Remote Control and Management Functions
> 7. Audit Collection and Analysis
> 8. About Intersect Alliance

> Annex A - Event Output Format
> Annex B - SNARE Registry Configuration
> Annex C - Objectives and Security Event IDs

1. Introduction

1.1 The team at InterSect Alliance have experience in working with event logging facilities and intrusion detection on a wide range of platforms including Sun Microsystems Solaris, Microsoft Windows NT and 2000, Linux, Novell Netware, IBM AIX, and even IBM MVS (ACF2 and RACF). The team also has extensive experience within a wide range of IT security tools, practices and procedures in business areas such as - Intelligence Agencies, Financial Services firms, Government Departments and Application Service Providers. This experience gives us a unique insight into how to effectively deploy host and network intrusion detection systems that support and enhance an organisation's business goals.

1.2 The development of "SNARE for Windows" will now allow for events logs collected by the Windows NT/2000 and XP operating systems, to be forwarded to a remote audit event collection facility. SNARE for Windows will also allow a security administrator to fully remote control the application through a standard web browser if so desired. SNARE has been designed in such a way as to allow the remote control functions to be easily effected manually, or by an automated process.

1.3 In the spirit of the release of the SNARE for Linux audit event module, InterSect Alliance are proud to release SNARE for Windows as an open source intiative. Other event audit modules for Linux and Solaris have been released under the terms of the GNU Public License. The overall project is called 'SNARE' - System iNtrusion Analysis & Reporting Environment.

1.4 So why put all this effort into the tools? InterSect Alliance wish to demonstrate its innovative skills in host intrusion detection, and contribute to the security of global information technology resources. Our active contributions towards IT Security separates us from many other IT Security firms that provide security services, and demonstrates our experience, flexibility and commitment to service . InterSect Alliance believe that clients will recognise our commitment, experience and skills, and acknowledge us as a uniquely qualified team of IT Security professionals.

1.5 InterSect Alliance welcomes and values your support, comments, and contributions. Our contact details are available from our contact page. Alternatively, comments may be submitted, using the mail link available from the main SNARE window.

2. SNARE Overview

2.1 SNARE operates through the actions of two complementary applications :

The "SNARE Core" service based application (snarecore.exe)
The graphical configuration and reporting tool (snare.exe)
2.2 The SNARE Core service interfaces with the Windows event logging sub-system to read, filter and send event logs from the Application, System, or the Security Event Logging sub-systems to a remote host. Note that for Windows 2000 Servers, it will also read, filter and send logs from the DNS Server, File Replication and Directory Service logs. The logs are then filtered according to a set of "objectives" chosen the by the administrator, and passed over a network, using the UDP protocol, to a remote server. The SNARE Core service is able to be remotely controlled using a standard web browser, or via a custom designed tool.

2.3 The SNARE Core service reads event log data from the three (or six - for Windows 2000 Servers) Windows event logs. SNARE Core converts the "strings" format of the event log record text format . If a SYSLOG server is being used to collect the event log records, the event record will be TAB delimited. If the SYSLOG option is not being used, the field separators will be TABs. This format, is further discussed in the section on the Snare Core output format - Annex A. The net result is that a raw event, as processed by the Snare Core service may appear as follows:

> `Test_Host MSWinEventLog 0 Security 3027 Tue Oct 08 20:30:43 2002 593 Security Administrator User Success Audit LE5678WSP Detailed Tracking A process has exited: Process ID: 656 User Name: Administrator Domain: LE5678WSP Logon ID: (0x0,0x6C52)`

2.4 Since the above event log contains a great deal of information for the average user, and in a format which doesn't lend itself to interpretation, SNARE also incorporates a graphical front end tool. The graphical tool allows for easy configuration of all the event logging parameters, as well as display of filtered event records. A screenshot of the main window, which includes the main display is shown below in Figure 1:

Figure 1: Main Window

3. Installing and Running SNARE

Snare Installation
3.1 SNARE is available in zip to format, and has been designed with an installation wizard to allow for easy installation and configuration of all critical components. The zip file includes the two major components, namely:

> a. SnareCore.exe The SNARE Core service is contained in the "snarecore.exe" binary. This binary contains all the programs to read the event log records, filter the events according to the "objectives", provide a web based remote control interface, and provide all the necessary logic to allow the binary to act as a service defined in Windows NT/2000 or XP.

> b. Snare.exe. This binary only contains the programs to provide for the SNARE front end (GUI) functions, as shown in Figure 1. However, the graphical user interface will not be of significant use, unless the SNARE Core service has also been installed.

3.2 Installation of the two main components (SNARE core and SNARE front end) is undertaken as follows:

> a. Download the "install.zip" file from the Intersect Alliance website.
> b. As "Administrator", double click the "install.zip" file. This is a self extracting archive, and will not require winzip or other programs.
> c. A series of screens will then be displayed, requesting that various parameters be set. Read these settings carefully, using this manual as reference. Most of the references are discussed later in this guide, so it pays to read this guide first, before installaing the software. Of importance, however, is the fact that the installation wizard will prompt the user to allow SNARE to make automatic changes to the Windows event log sub-system so as it may work correctly. It is strongly recommended that this setting be accepted, otherwise SNARE may not work correctly. This dialog is shown in Figure 2 below.
> d. Once the all of the installation process has completed the system should be rebooted so that all configurations are applied correctly.

Figure 2: SNARE Setup Dialog

Running SNARE
3.3 Upon installation of the SNARE front end, an "Intersect Alliance" menu item will installed off the "Program" main Windows menu. The SNARE GUI front end launch menu is then available from Programs->Intersect Alliance->Snare. If the menu launcher is not available, the SNARE front end may be started by typing snare on the command line, in the directory {drive}:\Program Files\Intersect Alliance\.

3.4 The SNARE Core service must be running, if the events are to be passed to a remote host. The Snare Core is a service, and may be checked that it is running by selecting the Services item in Control Panel on older Windows NT hosts, or by selecting Services from the Control Panel->Administrative Tools->Computer Management->Services. The service must be running for events to be sent to a remote host. If it is not, then select "start" and "automatic", so that the service is started automatically when the host is rebooted.

4. Setting the Audit Configuration

4.1 The configurations for SNARE are stored in the system registry. The registry is a common storage location of configuration parameters for Windows programs, and other applications. The registry location contains all the details required by SNARE to successfully execute. Failure to specify a correct configuration will not "crash" the SNARE Core service, but may result in selected events not being able to be read, and the system not working as specified. Note: Manual editing of the registry location is possible, but care should be taken to ensure that it conforms to the required SNARE format. Also, any use of the graphical SNARE front end or the web based remote control utility tool to modify selected configurations, will result in manual configuration changes being overwritten. Details on the configuration format for the registry can be viewed in Annex B - SNARE Registry Configuration

4.2 The most effective and simplest way to configure the SNARE Core service is to use the SNARE graphical front end tool. The audit configuration window can be selected from the Setup -> Audit Configuration menu, or directly from the associated toolbar button.

Auditing Control
4.3 The initial audit configuration parameters to consider are:

> a. The hostname, IP address and UDP port of the remote collection server,
> b. The requirement to incorporate a SYSLOG header, and
> c. Whether SNARE is to automatically set the necessary audit parameters for effective auditing. Note that it is recommended that these two parameters as shown in Figure 3 below via the checkboxes be selected.

4.4 These three parameters are shown in the Auditing Configuration window, shown in Figure 3 below. Note that Figure 3 also includes the display of the current "objectives". This is discussed later in the documentation.

Figure 3: Audit Configuration Window

4.5 The hostname field can be used to override the name that is given to the host when Windows is first installed. Unless a different name is required to be sent in the processed event log record, leave this field blank, and the SNARE Core service will use the default host name set during installation. Note that executing the command hostname on a command prompt window will display the current host name allocated to the host. The "Syslog" function is a UNIX based service that allows for event records to be processed remotely, but has the requirement that the event records need to be in a specific format. This feature will allow the event log record to be formatted so as to be accepted by a Syslog server. In order to effectively audit events, there are a number of parameters which would need to be automatically or manually set. These are:

> a. Event Log Retention. There is a risk in event auditing, that the Windows event logs may fill up. If this is the case, then no further events are able to be read, and the auditing function effectively stops. If the "Automatically set audit configuration" checkbox has been set (see Figure 3), then SNARE will set all the event logs to overwrite the logs as required. This will therefore prevent the event log sub-system from "stopping".
> b. Auditing of Categories. If the "Automatically set audit configuration" checkbox has been set (see Figure 3), then the system will also select the required event log parameters to meet those objectives (see below) which have been set. This will alleviate any problems associated with ensuring that the correct audit event categories have been selected, based on those event IDs which are required to be filtered.
> c. Setting of file system auditing. In order for Windows to collect file accesses, not only must the correct audit category be selected, but also the correct file system parameteres must also be set. The checkbox titled "Automatically set file system audit configuration" (see Figure 3) will automatically set these parameters, based on the objectives (see below) which have been set. It is highly recommended that this checkbox be selected.

4.6 A major function of the SNARE system is to filter events. This is accomplished via the advanced auditing "objectives" capability. Any number of objectives may be specified, and are display within the Audit Configuration window. A listed objective may be viewed or edited within the "Create or Edit an Objective" window, as shown in Figure 4.

Figure 4: "Objectives" Window

4.7 Each of the objectives provides a high level of control over which events are selected and reported. Events are selected from a group of high level requirements, and further refined using selected filters. Only Windows "Security Event Log" events are contained within the high level groups. Details on which Windows Event Log event IDs are used to generate the following objectives can be found in Annex C - Objectives and Security Event IDs:

> a. Logon of Logoff.
> b. Access a file or directory.
> c. Start or stop a process.
> d. Use of user rights.
> e. Account administration.
> f. Change the security policy.
> g. Restart, shutdown and system.
> h. Any event(s).

4.8 Note that the groups above are provided to service the most common security objectives, that are likely to be encountered. If other event types are required, then the "Any event(s)" objective will allow fully tailored objectives to be set. From each of these groups, a criticality level can be applied. These criticality levels are critical, priority, warning, information and clear. These security levels are provided to enable the SNARE user to map audit events to their most pressing business security objectives, and to quickly identify the criticality of an event, via the coloured "buttons" on the SNARE graphical user interface, as shown in Figure 1.

4.9 The following filters can be applied to incoming audit events:

> a. Filter on the "Event ID Search Term" field
> Each event contains a unique number known as the "Event ID". If the objective "Any event(s)" is selected, then the user is able to filter on the event id field. If multiple events are required, the user may enter the event IDs as a comma separated string, as follows: "562,457,897". Selecting the wildcard character "*" will select all events. Use this wildcard character with caution, since ALL events will collected and passed to the remote host. For all other objectives, this search field is greyed out and automatically set by the objective.

> b. Filter on "Non-header Search" field
> This allows the user to further refine a search based on the event record payload. If for example, it was required to search file a file being opened for reading, then the objective "Access a file or directory" would be selected, and the actual directory would be entered into this field as follows: "C:\Example\*". This would ensure that any files or directories below the directory "C:\Directory" would be subject to audit and trapped. Note that this field will search all the fields (except the header part) of an event record. There is NO need to use the wildcard character in this field, as it is automatically added to the start and end of this search term when the objective is saved. Important. If setting a file search parameter, it is important that the FULLY QUALIFIED directory name be entered, for the SNARE system to set the apropriate auditing. For example: C:|TEMP|SECRET\* will work, but SECRET* will not.

> c. Filter on User.
> An event record may be selected or discarded based on a userid, or partial match of a userid. If no users are entered, AND the "Include users" radio button has been selected, then ALL users are assumed to be audited. Take care to ensure that if it is required to audit all users that the Exclude radio button is NOT selected. If a term is entered in this field, then the event record will be trapped or discarded based on whether the "Include" or "exclude" radio buttons have been selected. There is NO need to use the wildcard character in this field, as it is automatically added when the objective is saved.

> d. Event Type
> Windows allows for five different audit event types, namely Success Audit, Success Failure, Error, Warning and Information. If it is unclear which type of event is required, then selecting all of the check boxes will ensure that no events are lost. Note that if no check boxes are selected, then NO events will be trapped.

> e. Event Logs
> Windows collects a number of logs from a number of event logs. In Windows servers all six event logs may be found, but on Workstation installations only three of these event logs (System , Security and Application) are found. If in doubt, there will be no harm done in selecting all event log types, except that SNARE Core will now read from, and attempt to filter, from all the selected event logs, and this will have some slight negative performance impact. Note that if any objective except for "Any event(s)" is selected, then this item is greyed out, as it is set automatically.

4.10 Once the above settings have been finalised, clicking "Save" will save the configuration to the registry. However, to ensure the SNARE Core service has received the new configuration, the SNARE Core service MUST be restarted via the "Save and Apply" or via "Apply and Restart Audit" menu item or the corresponding toolbar button.

5. Audit Event Viewer Functions

5.1 The main SNARE window also contains the events that have been filtered. Events collected, which meet the filtering requirements as per the Audit Configuration , will be displayed in the main window. This display is NOT a display from the event log file, but rather a temporary display from a "named pipe" connection from the SNARE front end to the Snare Core service. Once the SNARE front end is started the display will be clear, since filtered events are not written to a local disk. A key feature of the Snare Core Service is that events are not stored locally on the host (except for events stored natively in the Windows event log), but rather sent out over the network to a remote host.

5.2 A summary version of the event is displayed on the main window. For more details on a specific event, the relevant row from the main window can be selected using the mouse. A pop-up window will then display more comprehensive details related to the event. Some of the event details are event context dependant; and these are the "Data String" and "Expanded String" boxes. The event details window is shown in Figure 5. The string fields which are displayed depend entirely on the event that is being displayed. Once an event window is displayed, other events may be displayed by selecting the "Up" or "Down" key.

5.3 The fields shown in the event window relate to the parameters of the system call that was filtered.

Figure 5: Event Details Window

5.4 The main window event list may be cleared from the menu by selecting the item Activity->Clear all Current Events, or from the corresponding button from the toolbar. Note that clearing the main event viewer, DOES NOT clear the Windows event log files.

6. Remote Control and Management Functions

6.1 The SNARE Core service is a separate standalone component of the SNARE system, as described in the section on SNARE Overview. However, the SNARE graphical front end can be used to control a number of aspects of its operation. Primarily, the audit configuration can be developed and set using the graphical tool, as described in the previous sections. However, two other functions are available to manage the SNARE Core service.

6.2 The SNARE Core service can be restarted directly from the menu item Activity->Apply and Restart Audit. This will instruct the SNARE Core service to re-read all the configuration settings, clear the buffers and restarts the service. This function is useful when changes to the audit configuration have simply been saved, without being "applied". The user can therefore select when to activate a new configuration by selecting this menu item, or its corresponding button on the toolbar.

6.3 The SNARE Core service status can be viewed by selecting the View->Audit Status... menu item, or its corresponding toolbar button. This will display whether the SNARE Core service is active, along with a number of statistical parameters which are displayed on the screen. The audit status window is shown in Figure 6 below. the "eventlog counter" entry shown in Figure 6 shows the Windows internal event counter, and is only reset when the Windows Security event log file is cleared.

Figure 6: Audit Status Window

6.4 A significant function of the SNARE Core service is its ability to be remote controlled. This facility has been incorporated to allow all the functions normally available through the front end SNARE tool, to be also available through a standard web browser. The SNARE Core service employs a custom designed web server to allow configuration through a browser, or via an automated custom designed tool. Figure 7 below shows a web browser connecting to a SNARE agent:

Figure 7: Remote Control Window

6.5 The functions available through the web browser are identical to those available through the SNARE front end. In either case, the actual remote control parameters may be controlled in a similar fashion as the audit configuration. The parameters which may be set for remote control operation are shown in Figure 7 and discussed in detail below:

> a. Allow Remote Control. Selecting this check box will allow the SNARE agent to be remote controlled by a remote host. This host may be independant from the central audit collection server. If the remote control feature is unselected, it may only be turned on by using the SNARE front end tool on the hosted in which the SNARE agent has been installed.

> b. Allow Remote Control from IP Address. Remote control actions may be limited to a given host. This host, entered as an IP address in this checkbox, will only allow remote connections to be effected from the stated IP address. Note that access control based on source IP address is prone to spoofing, and should be considered as a security measure with other countermeasures.

> c. Set Password. A password may be set so that only authorised individuals may access the remote control functions. If accessing the remote control functions through a browser or custom designed tool, note that the userid is "snare", and the password is whatever has been set through this setting. Note that this password is not encrypted.

> d. Web Server Port. Normally, a web server operates on port 80. If this is the case, then a user need only type the address into the browser to access the site. If however, a web server is operating on port (say) 8085, then the user needs to type http://mysite.com:8085 to reach the web server. The default SNARE Core web server port may be changed using this setting, if it conflicts with an established web server. However, care should be taken to note the new server port, as it will need to be placed in the URL needed to access the SNARE agent.

7. Audit Collection and Analysis

7.1 The team at Intersect Alliance have produced a series of toolsets that enable remote control, collection, analysis and of output from all SNARE agents, including Windows, Linux and Solaris, as well as applications such as web servers. The details of this toolset is only available on request from Intersect Alliance, and is custom designed to suit a customer's requirements. The toolsets are based on the Snare tools, available from the Intersect Alliance web site.

8. About Intersect Alliance

8.1 InterSect Alliance is a team of leading information technology security specialists in both the "technical" and "policy" areas. In particular, Intersect Alliance are noted leaders in key aspects of IT Security, including host intrusion detection. Our solutions have and continue to be used in the most sensitive areas of Government and business sectors. Intersect Alliance consult and contract to number of agencies in Australia and in Asia Pacific, for both the business and Government sectors.

8.2 The Intersect Alliance business strategy includes demonstrating our committment and expertise in IT security by releasing Open Source products such as SNARE. Intersect Alliance intend to continue releasing tools that enable users, administrators and clients worldwide to achieve a greater level of productivity and effectiveness in the area of IT Security, by simplifying, abstracting and/or solving complex security problems.

8.3 Visit the Intersect Alliance website for more information.

A. Event Output Format

The SNARE Core service reads data from the Windows operating system via the Event Logs. It converts the binary audit data into text format , and separates information out into a series of TAB delimited tokens. The token delimiter may be specified as something other than TAB, but ONLY if a SYSLOG header has been added. A 'token' is simply data, such as "date" or "user". Groups of tab separated tokens make up an audit event, which may look something like this, depending on whether the SNARE Core service has SYSLOG header functionality active:

> Test_Host MSWinEventLog 0 Security 3027 Tue Oct 08 20:30:43 2002 593 Security Administrator User Success Audit LE5678WSP Detailed Tracking A process has exited: Process ID: 656 User Name: Administrator Domain: LE5678WSP Logon ID: (0x0,0x6C52)

The format of the event log record is as follows:

> a. Hosntame (as entered using the SNARE front end).
> b. Null entry.
> c. Criticality. This is determined by the Alert level given to the objective by the user, and is a number between 0 and 4, as detailed in the registry setting in Annex B.
> d. SourceName. This is the Windows Event Log from which the event record was derived. In the above example, the event record was derived from the "security" event log.
> e. Null entry.
> f. DateTime. This is the date time stamp of the event record.
> g. EventID. This is the Windows Event ID.
> h. SourceName. This is the Windows Event Log from which the event record was derived. In the above example, the event record was derived from the "security" event log.
> i. UserName. This is the Window's user name.
> j. SIDType. This is the type of SID used. In the above example, it is a "user" SID, but it may also be a "computer" or other type of SID.
> k. EventLogType. This can be anyone of "Success Audit", "Failure Audit", "Error", "Information", or "Warning".
> l. ComputerName. This is the Windows computer name.
> m. CategoryString. This is the category of audit event, as detailed by the Windows event logging system.
> n. DataString. This contains the data strings.
> o. ExpandedString. This contains the expanded data strings.

B. SNARE Windows Registry Configuration Description

Details on the audit configuration are discussed in the Audit Configuration section. The purpose of this section is to discuss the makeup of the configuration items in the registry. The SNARE configuration registry key is located at HKEY_LOCAL_MACHINE\SOFTWARE\Intersect Alliance\AuditService , and this location may not be changed. If the configuration key does not exist, the Snare Core service will create it during installation, but will not actively audit events until a correctly formatted objective(s) is present.

SNARE can be configured in several different ways, namely:

> a. Via the graphical tool (Recommended), or
> b. Via the remote control interface (Recommended), or
> c. By manually editing the configuration file (NOT Recommended).

The format of the audit configuration registry subkeys is discussed below.

`[Config]` | This subkey stores the delimiter and clientname values.
`Delimiter` | This is of type REG_SZ and stores the field delimiting character, ONLY if syslog header has been selected. If more than one char, only first char will be used. If none set, then comma will be used. This is a HIDDEN field, and only available to those users that wish to set a different delimiter when using the SYSLOG header. This selection option will not be found in the SNARE front end or the web pages.
`Clientname` | This is the Hostname of the client and is of type REG_SZ. If no value has been set, "hostname" command output will be displayed. Must be no more than 100 chars, otherwise will truncate.
`Audit` | This value is of type REG_DWORD, and determines whether SNARE is to automatically set the system audit configuration. Set this value to 0 for no, or 1 for Yes. Will default to TRUE (1) if not set. The audit configuration includes selecting the audit categories and the retention policy on ALL event log files.
`FileAudit` | This value is of type REG_DWORD, and determines whether SNARE is to automatically set the file system audit configuration. Set this value to 0 for no, or 1 for Yes. Will default to TRUE (1) if not set.
`[Objective]` | This subkey stores all the filtering objectives.
`Objective#` `(where # is a serial number)` | This section describes the format of the objectives. Objectives are of type REG_SZ, of no greater than 1060 chars, and is composed of the following string (the figures in the brackets represent the maximum size of the strings that can be entered): Criticality(DWORD);Event Type (DWORD);Event Log Type(DWORD);EventID Match (char [256];General Match[512]);UserMatchType(DWORD);User Match[256] Criticality - an integer between 0 and 4 that indicates the severity of the event. 0 is "clear", 4 is "critical. Critical = 4, Priority = 3, Warning = 2, Information = 1, Clear = 0 User Match Type: =0 (Include users that match user search term type; =1 for Exclude) Event Type: Success = 16, Failure = 8, Error = 4, Information = 2, Warning = 1. (These numbers cannot be zero, since the "atoi" function returns 0 if the argument is not an integer. Also, these values are checkboxes, hence any or all ot these may be selected). Event Log Type: Security = 32, System = 16, Application = 8, Directory Service = 4, DNS Server = 2, File Replication = 1. (These cannot be zero, since the "atoi" function returns 0 if the argument is not an integer. Also, these values are checkboxes, hence any or all ot these may be selected). The match terms (EventID Match, General Match and User Match) are the filter expressions, and is again defined to be any value which includes DOS wildcard characters. Note that these are NOT regular expressions. NOTE: Semicolons are actually "TAB" characters.
`[Network]` | This subkey stores the general network configurations.
`Destination` | This sub key is of type REG_SZ and should be a maximum of 100 characters. It details the IP address or hostname which the event records will be sent.
`DestPort` | This value is of type REG_DWORD, and determines the Destination UDP Port number. This value must be in 1-65535 range. Will default to 514 if a SYSLOG header has been specified.
`Syslog` | This value is of type REG_DWORD, and determines whether a SYSLOG header will be added to the event record. Set this value to 0 for no SYSLOG header. Will default to TRUE (1) if not set.
`SysloDest` | This is of type REG_DWORD and determines the SYSLOG Class and Criticality. This value will default to 13 if not set, or out of bounds.
`[Remote]` | This subkey stores all the remote control parameters.
`Allow` | "Allow" is of type REG_DWORD, and set to either 0 or 1 to allow remote control If not set or out of bounds, will default to 0/NO (ie; not able to be remote controlled).
`WebPort` | This value is the web server port, if it has been set to something other than port 80. It is of type REG_DWORD. If not set or out of bounds, it will default to port 8080.
`WebPortChange` | This value is of type REG_DWORD, and set to either 0 or 1 to signal whether the web port should be changed or not. 0 = no change.
`Restrict` | This value is of type REG_DWORD, and set to either 0 or 1 to signal whether the remote users should be restricted via IP address or not. 0 = no restrictions.
`RextrictIP` | This is of type REG_SZ and is the IP address set from above.
`AccessKey` | This value is of type REG_DWORD and is used to determine whether a password is required to access the remote control functions. It is set to either 0 or 1, with 0 signifying no password is required.
`AccessKeySet` | This is of type REG_SZ, and stores the actual password to be used.

C. Objectives and Security Event IDs

The SNARE application has a number of in built "objectives". These objectives have been designed to "trap" certain Security Log event IDs, and have been designed to enable the user to create some of the more common objectives without having to know which objectives they require.

a. Logon of Logoff. This will trap the following events: "528,529,530,531,532,533,534,535,536,537,538,539,540,541,542,543,544,545,546,547,672,673,674,675,676,677,678,680,681,682,683"
b. Access a file or directory. This will trap the following events: "560,561,562,563,564,565,566,594,595"
c. Start or stop a process. This will trap the following events: "592,593,594,595"
d. Use of user rights. This will trap the following events: "576,577,578,608,609"
e. Account administration. This will trap the following events: "624,625,626,627,628,629,630,631,632,633,634,635,636,637,638,639,640,641,642,643,644,645,646,647,648,649,650,651,652,653,654,655,656,657,658,659,660,661,662,663,664,665,666,667,668,669,670"
f. Change the security policy. This will trap the following events: "516,517,608,609,610,611,612,613,614,615,616,617,618,620,643"
g. Restart, shutdown and system. This will trap the following events: "512,513"

Note that some of the above events will only be generated on Windows 2000 hosts. The above events will be generated by turning on selected audit categories, on the Windows audit sub-system. The following paragraphs detail the event IDs, and the categories to which they belong.

> Audit Privilege Use (Success and Failure) will generate:
> 576;Special privileges assigned to new logon
> 577;Privileged Service Called;
> 578;Privileged object operation;

> Audit Process Tracking (Success and Failure) will generate:
> 592;A new process has been created
> 593;A process has exited
> 594;A handle to an object has been duplicated
> 595;Indirect access to an object has been obtained

> Audit System Events (Success and Failure) will generate:
> 512;Windows NT is starting up
> 513;Windows NT is shutting down
> 514;An authentication package has been loaded
> 515;A trusted logon process has registered
> 516;Loss of some audits;
> 517;The audit log was cleared
> 518;A notification package has been loaded

> Audit Logon Events (Success and Failure) will generate:
> 528;A user successfully logged on to a computer.
> 529;The logon attempt was made with an unknown user name or bad password.
> 530;The user account tried to log on outside of the allowed time.
> 531;A logon attempt was made using a disabled account.
> 532;A logon attempt was made using an expired account.
> 533;The user is not allowed to log on at this computer.
> 534;The user attempted to log on with a logon type that is not allowed.
> 535;The password for the specified account has expired.
> 536;The Net Logon service is not active.
> 537;The logon attempt failed for other reasons.
> 538;A user logged off.
> 539;The account was locked out at the time the logon attempt was made.
> 540;Successful Network Logon.
> 541;IPSec security association established.
> 542;IPSec security association ended.
> 543;IPSec security association ended.
> 544;IPSec security association establishment failed.
> 545;IPSec peer authentication failed.
> 546;IPSec security association establishment failed.
> 547;IPSec security association negotiation failed.
> 682;A user has reconnected to a disconnected Terminal Services session.
> 683;A user disconnected a Terminal Services session without logging off.

> Audit Account Logon Events (Success and Failure) will generate:
> 672;An authentication service (AS) ticket was successfully issued and validated
> 673;A ticket granting service (TGS) ticket was granted.
> 674;A security principal renewed an AS ticket or TGS ticket.
> 675;Pre-authentication failed.
> 676;Authentication Ticket Request Failed
> 677;A TGS ticket was not granted.
> 678;An account was successfully mapped to a domain account.
> 680;Identifies the account used for the successful logon attempt.
> 681;A domain account log on was attempted.
> 682;A user has reconnected to a disconnected Terminal Services session.
> 683;A user disconnected a Terminal Services session without logging off.

> Audit Account Management Events (Success and Failure) will generate:
> 624;User Account Created
> 625;User Account Type Change
> 626;User Account Enabled
> 627;Password Change Attempted
> 628;User Account Password Set
> 629;User Account Disabled
> 630;User Account Deleted
> 631;Security Enabled Global Group Created
> 632;Security Enabled Global Group Member Added
> 633;Security Enabled Global Group Member Removed
> 634;Security Enabled Global Group Deleted
> 635;Security Disabled Local Group Created
> 636;Security Enabled Local Group Member Added
> 637;Security Enabled Local Group Member Removed
> 638;Security Enabled Local Group Deleted
> 639;Security Enabled Local Group Changed
> 640;General Account Database Change
> 641;Security Enabled Global Group Changed
> 642;User Account Changed
> 643;Domain Policy Changed
> 644;User Account Locked Out
> 645;Computer object added
> 646;Computer object changed
> 647;Computer object deleted
> 648;Security Disabled Local Group Created
> 649;Security Disabled Local Group Changed
> 650;Security Disabled Local Group Member Added
> 651;Security Disabled Local Group Member Removed
> 652;Security Disabled Local Group Deleted
> 653;Security Disabled Global Group Created
> 654;Security Disabled Global Group Changed
> 655;Security Disabled Global Group Member Added
> 656;Security Disabled Global Group Member Removed
> 657;Security Disabled Global Group Deleted
> 658;Security Enabled Universal Group Created
> 659;Security Enabled Universal Group Changed
> 660;Security Enabled Universal Group Member Added
> 661;Security Enabled Universal Group Member Removed
> 662;Security Enabled Universal Group Deleted
> 663;Security Disabled Universal Group Created
> 664;Security Disabled Universal Group Changed
> 665;Security Disabled Universal Group Member Added
> 666;Security Disabled Universal Group Member Removed
> 667;Security Disabled Universal Group Deleted
> 668;Group Type Changed
> 669;Add SID History (Success)
> 670;Add SID History (Failure)

> Audit Object Access (Success and Failure) will generate:
> 560;Access was granted to an already existing object.
> 561;A handle to an object was allocated.
> 562;A handle to an object was closed.
> 563;An attempt was made to open an object with the intent to delete it.
> 564;A protected object was deleted.
> 565;Access was granted to an already existing object type.
> 566;Object Operation

> Audit Policy Change (Success and Failure) will generate:
> 608;A user right was assigned.
> 609;A user right was removed.
> 610;A trust relationship with another domain was created.
> 611;A trust relationship with another domain was removed.
> 612;An audit policy was changed.
> 613;IPSec policy agent started
> 614;IPSec policy agent disabled
> 615;IPSec policy changed
> 616;IPSec policy agent encountered a potentially serious failure
> 617;Kerberos policy changed
> 618;Encrypted data recovery policy changed
> 620;Trusted domain information modified
> 768;A collision was detected between a namespace element in two forests.

> Audit Directory Service Access (Success and Failure) will generate:
> 565;Information about accessed objects in AD