Effective Security Monitoring

Chapter 4 from Microsoft Windows NT 4.0 Security, Audit, and Control, published by Microsoft Press

Controls should be in place to monitor whether a secure computer environment is maintained. These controls will help upper management determine whether steps have been taken to secure the systems. Some good controls include violation and exception reports that help management determine, at a glance, whether their systems are being compromised. Many times, corporations run reports that log violations; however, running these reports in itself does not satisfy this control. Either the report is gathering too much information, the proper violations are not being filtered, or no one is reviewing the reports.

These reports are another set of controls that help mitigate security risks throughout the corporation, but we often see them overlooked. Windows NT has the capability to log a great deal of information. The ability to log a lot of information is very good, however, sometimes too much information is logged and not analyzed properly. This section lists the monitoring and auditing tool that should be utilized, the data that should be gathered, and the information that should be analyzed.

On This Page

Performance Monitor
Windows NT Diagnostics
Network Monitor
Auditing

Performance Monitor

You can use the Windows NT Performance Monitor to monitor system performance, to gather vital information on system statistics, and to analyze and graphically display information. In addition, Performance Monitor can be configured to alert systems administrators when certain events occur. Alerts are critical security controls that help perform real-time monitoring. Instead of reviewing a violation report once a week and finding a security breach after the fact, alerts warn a systems administrator of a potential security violation.

Windows NT Performance Monitor utility tracks objects such as processors, memory, cache, threads, processes, and services running on the Windows NT Server. Every object has counters that keep track of specific events or activities. The Performance Monitor may be used to monitor selected security-related events. The counters' data can either be gathered and monitored over a long period of time for analysis or tracked for certain values.

Performance Monitor provides a variety of ways to view the information that is gathered for analysis. The four different types of viewing options are as follows:

• Chart

• Alert

• Log

• Report

To start the Performance Monitor control, choose Start » Programs » Administrative Tools » Performance Monitor. The Performance Monitor screen is launched.

Chart View

You will want to build charts in order to collect data related to the performance of the objects you select. This allows you to analyze the data in real time. To begin building charts, choose Edit » Add to Chart.

The fields within the dialog box are described in Table 4-1.

Table 4-1 Chart Options

Fields	Description
Computer	Choose a computer to track. You can monitor the performance of any computer in the network.
Object	Choose an object to track. Each object has its own set of counters.
Counter	For each object, choose the specific event or activity you want to track.
Instance	Some object types have several instances. For example, the processor object type will have multiple instances if a system has multiple processors. Some object types, such as Memory and Server, do not have instances. If an object type has multiple instances, each instance may be used with the same set of counters. The data is then tracked for each instance.

On the right side of the dialog box is the Explain button. Click this button to display the lower Counter Definition field. The Counter Definition field explains what each counter is measuring so you can determine if you need to add it to your chart. Click Add to start tracking the event on the chart. You can continue to add other events or click Done to close the dialog box.

Charts are important and should be used for monitoring performance, especially on highly critical machines. For example, at Fecha Manufacturing Corporation, we would recommend more chart views of system performance monitors on the database server. Choose Logical Disk » % Free Space to monitor hard drive space and ensure that the database does not get full and crash the system. Fecha should also implement Memory Available Bytes to ensure that physical memory is not too low and to avoid possible system crashes.

Alert View

Alerts track certain events and warn systems administrators when they occur. Choose View » Alert to get to the Alert screen. Choose Edit » Add to Alert to begin tracking events and alerting the administrator or security officer of the occurrence of events. The Add to Alert dialog box appears.

The procedure for adding alerts is similar to the procedure for adding charts. In addition to the tracking processes, it is possible to add high- and low-threshold values so the system will send alerts when the thresholds are met. On one system, Fecha tracks % disk space and has an alert established if available disk space is less than 20%. Table 4-2 lists the fields that are available in the Alert Options dialog box.

Table 4-2 Alert Options on the Add to Alert Dialog Box

Fields	Description
Computer, Object, and Counter	Enter the appropriate information as described previously in Chart View.
Alert If	Click on Over or Under and then enter a threshold value in the field.
Run Program on Alert	Enter the name of a custom program that will run when the threshold value is met. Also click First Time or Every Time, depending on whether the program should be run only once or every time the threshold is met.

In addition, Alerts can be further configured in the Alert Options dialog box, which you can open by choosing Options Alert. Table 4-3 presents and describes the Alert options.

Table 4-3 Alert Options on the Alert Options Dialog Box

Fields	Description
Switch to Alert View	Brings the Alert Log area into the foreground when an Alert occurs.
Log Event in Application Log	Creates an entry in the Application Log of the Event Viewer.
Network Alert	Allows a message to be sent to the specified user when an Alert occurs.
Update Time	Specifies how often the Alert Log screen is refreshed.

When counters exceed the threshold values set, the date and time of the event are recorded in the Alert Log area window. One thousand events are recorded before the oldest events are discarded.

Log View

Logging allows the system to capture data in a file and save it for later viewing and analysis. The same type of information captured in Chart View can also be captured in Log View.

Choose View » Log to access the Log View. Choose Edit » Add to Log to begin logging an object. The option to choose a computer and the objects to trace is available. Choose Options » Log to launch the Log dialog box. This dialog box will prompt for a log name. If you use an existing file, data is appended to it. Choose either Manual Update or Periodic Update in the Update Time box. If you choose Periodic Update, you can set the interval for the updates. If Manual Update is chosen and you want to get updated information, choose Options » Update Now. Click the Start button to start logging. When you want to stop logging, choose Option » Log and click the Stop Log button.

Report View

You can use Report View to capture changing information (such as processor usage) and display it in a report format. The options available to Report View are similar to Chart View, except you do not have the ability to select different graphical ways to display information.

To build a report, choose View » Report and then Edit Add to Report. The following fields can be filled as described in Chart View: Computer, Object, and Counter. A list of selected objects appears in the reporting area. As the system changes, the values are updated. Choose Options » Report to determine how often you want the options updated. Select Periodic Update for an automatic update of information and set the time interval for the updates. Each displayed value is usually an average over the last two data reads, which are separated by the length of the time interval. Choose Manual Update if you want to manually update the settings. If Manual Update is chosen and you want to get updated information, choose Options » Update Now.

Recommended Settings

Windows NT contains many objects, and each object contains many counters that you can track. As previously mentioned, tracking and logging everything is not only infeasible and inefficient, but it defeats the purpose of proper security monitoring. It is also important to remember the type of Windows NT implementation set up.

At Fecha Manufacturing Corporation, the web server has been running extremely slow and even crashing in some instances; therefore, it has begun to monitor Logical Disk % Disk Time, Processor % Processor Time, and Memory Pages/sec. This step is not to say that these three counters are the problem, but it may provide insight as to the problems Fecha is experiencing. In the event nothing is learned from the analysis, Fecha can monitor a new set of counters.

Also at Fecha, its database server contains very important, real-time data, and it must be available 24 hours a day, 7 days a week. Therefore, Fecha has implemented the same controls that are on its web server (for the database server) to monitor system performance. This step provides a control for Fecha to ensure the availability of the database server. This is because the systems administrators are able to observe when the server is getting to a critical point of low system resources.

Alerts are important controls for providing real-time monitoring and detecting possible compromises of confidentiality. For example, Fecha has alerts set on its administrative RAS server for Server Errors Logon, with a threshold of 100 bad logons. Because only the administrator should be logging in the Administrator account, when 100 bad logon attempts occur, an alert is initiated. The system administrator who receives this alert knows that someone is trying to hack in.

You can set alerts (such as Errors Logon and others) by choosing View Alert, and then choosing Server in the Object field. Send these alerts to the system administrator and security officer. Often a third-party software utility is used that will receive the alert, and then page the appropriate personnel. Table 4-4 contains a description of the counters that should be monitored for attempted security breaches.

Table 4-4 Alert Recommendations

Counter	Description
Errors Access Permissions	Indicates whether somebody is randomly attempting to access files in hopes of finding an improperly protected file.
Errors Granted Access	Logs attempts to access files without proper access authorization.
Errors Logon	Displays failed logon attempts, which could mean password guessing programs are being used to crack security on server.

Alerts are powerful Windows NT security controls that we do not see used often. Fecha implements Errors Logon on its domain controllers because this is where all authentication occurs. Fecha wants to monitor hacker attempts of logging in the domain. Fecha also is monitoring Errors Access Permissions and Errors Granted Access on its file and print server, and database server. This monitoring assists in detecting when a user might randomly be attempting to access files for which they do not have authorization. Errors Logon does not need to be monitored on these machines because all authentication takes place on the domain controllers. Fecha's web server and domain member RAS server are set to monitor all three counters because users log in and access files on those machines. Lastly, workstations monitor nothing.

You can save Chart, Alert, and Log information in files for further analysis and tracking of illicit activities (or activities that may be degrading the performance of a system). These files are critical controls in monitoring security and should be printed and reviewed on a regular basis. Again, depending on the type of Windows NT system implemented, the review basis will vary. In our experience, most clients will not review audit logs. If they do, it is not done on a regular basis.

For Remote Access Servers that allow employees to connect externally, you should review exception reports and bad logon attempts daily. You should also review these reports for any private web server that is set up. For database servers and domain controllers, weekly or biweekly reviews should be sufficient. However, real-time monitoring through the Chart and Alert views is highly recommended.

Windows NT Diagnostics

You can use the Windows NT Diagnostics utility to view various system, resource, and environment information. You can also use Windows NT Diagnostics not only to troubleshoot problems, but also to monitor possible breaches of security. You can implement these features as security controls to monitor your system. To begin using Windows NT Diagnostics, choose Start » Administrative Tools » Windows NT Diagnostics.

Choose File » Computer to pick the computer you want to diagnose. You can print a report of the various settings by choosing File Create Report**.** This step is an easier way of viewing all the data at the same time in a text file format.

Windows NT Diagnostics Information

There are nine tabs displayed in Windows NT Diagnostics and each contains in-depth information about your system. Click each tab in the dialog box to view various diagnostic information. Table 4-5 describes the information located on each tab.

Table 4-5 Windows NT Diagnostics

Tab	Description
Version	Click this tab to view the current version and build the operating system.
System	Click this tab to view BIOS and processor information.
Display	Click this tab to view video adapter and display information.
Drives	Click this tab to view information about disk drives, including whether they are NTFS volumes and whether security is preserved.
Memory	Click this tab to view Paging, Physical, and Kernel memory Information.
Services	Click this tab to view what services are running or stopped.
Resources	Click this tab to view the settings of hardware devices in the system.
Environment	Click this tab to view the system environment variables.
Network	Click this tab to get detailed network information such as: General—Displays current network settings, such as workgroups or domain, network version, logon domain, logon server, and name of the current user. Use this page to view your current logon account in case you forget whether you logged on as an administrator or regular user. Transports—Displays a list of current network transport protocols and the addresses of the network adapters to which they are bound. Settings—Shows the current value of network parameters, such as session timeouts, buffers, caches, pipes, and encryption. Statistics—Shows current statistics for the network, such as bytes received, requested, and transmitted, as well as many other parameters.

Click the Refresh button to get the latest statistical information on pages with values that require more frequent updates.

Recommended Settings

Windows NT Diagnostics contains helpful monitoring information for maintaining a system. It is not feasible to monitor every variable within the system.

Table 4-6 indicates some statistics that are important to monitor for security reasons. Click the Network tab and then click the Statistics button to access these statistics. These statistics are critical in monitoring system security. Although these settings are important, they are very similar to those discussed in the "Performance Monitor" section. If the Performance Monitor alerts have been set, these controls are redundant.

Table 4-6 Windows NT Diagnostics

Statistic	Description
Server Password Errors	This statistic tracks the number of failed logon attempts to the server. This value may indicate that someone is running a password-guessing program in an attempt to crack the security on the server.
Server Permission Errors	This statistic is the number of times that clients have been denied access to files they were trying to open. This value may indicate that somebody is randomly attempting to access files in hopes of getting at something that was not properly protected.

Network Monitor

The Network Monitor utility monitors network traffic to and from the server at the packet level. You can capture Network traffic for later analysis, which will make it easier to troubleshoot network problems.

Note: Network Monitor comes with Windows NT 4.0 Server. This utility can only be used to monitor packets of information that are sent from or received by the computer where you are running the program, including broadcast and multicast frames. This section discusses the Network Monitor that comes with Windows NT 4.0 Server.

Tip Microsoft System Management Server includes an advanced Network Monitor utility. This version allows users to capture frames sent to and from any computer on the network, edit and transmit frames on the network, and capture frames from remote computers running Network Monitor Agent (included in Windows NT Workstation 4.0 and Windows 95) on the network.

To use this tool, choose Start » Administrative Tools » Network Monitor. The Network Monitor dialog box appears.

Capturing Data

To begin capturing data that is being transmitted over the network, choose Capture » Start. It is also possible to enable dedicated capture mode, which will capture data with the screen minimized, thereby freeing resources for capturing data.

To view captured data, choose Capture » Stop and View or choose Capture » Stop and then Capture » Display Captured Data. Both methods will invoke the Captured Data screen.

The Network Monitor gathers a great deal of information. The data gathered can be filtered so only the relevant information is displayed. To filter data, choose Capture » Filter, which displays the Capture Filter dialog box.

The information can be filtered by protocol or by network address. Filtering is an important feature that you can use as an Effective Security Monitoring control. As previously said, systems administrators will turn on Network Monitor and will then be inundated with tons of information, most of which they will not go through. Filtering allows the system administrator to be creative and come up with good expressions to capture the correct data. The Capture Filter dialog box shows the filter's decision tree. A decision tree is a query-like structure that graphically represents the filter expression. In a decision tree, statements are linked together by colored AND, OR, and NOT tabs. Combined, these statements specify the kinds of data you want to capture or display. The Capture Filter dialog box has four main categories, which are described in Table 4-7.

Table 4-7 Network Monitor Capture Filter

Category	Description
Expression	Shows the expression line that you want to locate or add to the display filter's decision tree. It changes as you select items in other areas of the dialog box. This category cannot be edited directly.
Address	Specifies the address you want to find.
Protocol	Specifies the protocols you want to find or filter.
Property	Specifies the protocol properties to filter.

To filter the information by protocol, double-click on Protocol Expression and the Protocol Expression dialog box appears. For example, Fecha Manufacturing Corporation may want to monitor all the FTP requests to its internal web server. It can create an expression to do just that and then review the information on a daily basis.

The network addresses monitored can also be filtered in a similar manner. Double-click an address to launch the Address Expression dialog box. In the Station 1 and Station 2 boxes, select the computer addresses between which you want to monitor traffic, or that you want to locate. In the Direction box, select the arrow key that indicates the traffic direction that you want to monitor or locate. Click the Edit Address button to edit the currently selected network address.

The Address Database dialog box is a list of all network addresses captured and their friendly names. The friendly name would be the NetBIOS machine name if available, or one assigned by an administrator. Use this dialog box to add or delete addresses or to save addresses in a file for later use. The Address List displays the following information about each computer: a friendly name, the 12-digit hexadecimal network address, the address type, the name of the vendor who created the network card, and an additional comment.

The Address database is first created when you start capturing data. After capturing data, choose Capture » Find All Names to associate the captured computer addresses with the friendly names of the computers from which the frames have been captured. Then choose Capture » Address to display the names that have been added to the Address Database. To use these addresses to design a filter in the future, click the Save button to save it to a file.

Triggers, which are conditions that must be met before an action occurs, can also be set. For example, Fecha wants to capture data on its web server when a specific Telnet command is issued. Fecha sets up a trigger that starts Network Monitor, capturing data if a pattern (such as a code or sequence used by a hacker) is found. Triggers are good controls because they work on set conditions.

Choose Capture » Triggers to launch the Capture Trigger dialog box.

Table 4-8 describes the options that are available in the Capture Trigger dialog box.

Table 4-8 Capture Triggers

Option	Description
Nothing	Indicates that no triggers are set.
Pattern Match	Initiates a trigger when a particular pattern occurs.
Buffer Space	Initiates a trigger when a specified percentage of the capture buffer is filled.
Pattern Match Then Buffer Space	Initiates a trigger when a particular pattern occurs, and then a specified percentage of the capture buffer is filled.
Buffer Space Then Pattern Match	Initiates a trigger when a specified percentage of the capture is filled, and then a particular pattern occurs.

In the Trigger Action box, specify the actions you want to occur when the trigger conditions are met. You can choose to Stop Capture by clicking the Stop Capture radio button or by clicking Execute Command Line and typing the name of a command or executable file.

Choose Tools » Identify Network Monitor Users to identify who else in the network has installed and is using Network Monitor. Only the Network Monitor tool will be detected; other network monitoring tools will not.

It is possible to use the Network Monitor Agent services on other Windows NT computers to capture statistics on those computers and have them sent to the server running Network Monitor. Network Monitor Agent is a service that would run on those workstations.

Recommendations

Network security control is extremely important for confidentiality. If other users run an installation of Network Monitor on their computers, they could use it to watch packets on the network and capture valuable information. To protect a network from unauthorized use of Network Monitor, this tool provides security controls such as password protection and the ability to detect other installations of itself on the local segment of the network. To change the password, click Start Setting Control Panel. Double-click the Monitoring Agent applet and then click the Change Password button.

FTP and Telnet send passwords over the network in clear text, that is, readable without requiring any additional interpretation like deciphering; therefore, someone monitoring the network can capture and view these passwords.

Network Monitor will detect other Network Monitor installations and display the information about them, such as the name of the computer, user, adapter address, and whether the utility is running, capturing, or transmitting information. However, it cannot detect third-party monitoring software and/or equipment. Be aware that other third-party software may be sniffing data. This is why it is important to secure the data as it traverses the network.

Auditing

Auditing is an important component of the Effective Security Monitoring controls. Auditing means measuring the system against a predefined system setting to ensure no changes have occurred. Changes may indicate possible security breaches. If no auditing is being conducted, then the Effective Security Monitoring controls will not be satisfied and thus confidentiality, integrity, and availability of data is at risk.

Auditing takes time and effort to implement and it uses a lot of resources; therefore, many corporations do not even turn on auditing on their Windows NT systems. The audit services of a Windows NT operating system provide a chronological record of events in the audit logs. These logs support individual accountability by recording user actions. The audit log is also potential evidence for legal or administrative actions. It also serves as an assurance tool, revealing how well the security mechanisms are working.

All audit events are logged and can be viewed through Event Viewer; thus, you can trace the security threats to their origin and rectify the weaknesses. However, effective audit options must be enabled in order to achieve this.

System Auditing

System auditing tracks system-level events such as logons and file and directory access. To enable System auditing choose Start » Administrative Tools » User Manager for Domains » Policies » Audit. The following dialog box appears:

Audit events are recorded in the Security Log. The Security Log can be viewed in the Event Viewer discussed later in the section entitled, "Event Viewer." If the Do Not Audit option is highlighted, all Windows NT auditing is disabled and the Security Log will generate no entries.

Recommended System Auditing Settings

Click the Audit These Events button to enable the auditing system to track the events. You can choose from a variety of events, and you can choose to audit the success and/or failure of these events. However, tracking all events will consume a lot of resources so you need to carefully decide what to audit.

Auditing is a critical and important security control that you need to plan and think through carefully. The recommendations made here may not fit all corporations exactly, so use them only as a guide. We will use Fecha Manufacturing Corporation and its Windows NT environment to recommend what we believe are baseline security configurations.

Because the file and print, database, and web servers are members of the domain, the following audit policies set on the domain controller level for the entire domain affect all these servers: Logon and Logoff, Use of User Rights, User and Group Management, and Security Policy Changes.

Fecha has determined that it wants to enable auditing of the Logon and Logoff server for failure on all Windows NT machines that authenticate users, which are the domain controllers and the RAS server. This is because Fecha wants to audit when a hacker may be trying to guess a user's password and gain access to the system. Successful logons and logoffs do not need to be audited in Fecha's environment because Fecha has no need to control users who are properly authenticating.

Fecha audits the failure of Use of User Rights on the machines with User Account Databases so administrators can determine which users have been attempting to do things beyond their privilege. For example, a user may try to take ownership of files they do not have access to in order to edit them. Or, a user who somehow got physical access to a Primary Domain Controller (PDC) might try to log in locally. For similar reasons, Fecha audits Security Policy Changes for success and failure. Administrators will then be able to review which individuals may be trying to establish trust relationships or modifying their user rights.

Fecha also wants to audit User and Group Management for success and failure on all Windows NT machines that authenticate users, because it is important to know which individuals modified or attempted to modify the User Account Database (only administrators and account operators have this capability). For example, an account operator may have added a user without following the corporate security policy and a security officer wants to know who performed this procedure.

File and Object Access auditing is enabled for failure on the domain controllers, remote access servers, and file and print servers, as well as for failure and success on the database server. This is because Fecha wants to be able to implement Object auditing on these servers, especially the servers that contain critical business data, such as the database server. (Discussions on the objects that should be audited are in the "Recommended File and Directory Auditing" section.) In addition, Fecha has determined that the cost of a virus outbreak would be too high and so will also enable auditing the success and failure of write access for program files such as files with .EXE and .DLL extensions. Therefore, whenever a program file is written to, an audit event will be generated stating which user wrote to the file.

The Restart, Shutdown, and System audit feature is selected for success and failure on all machines except workstations because workstations can be restarted as many times as necessary and no security implication exists. This audit feature provides administrators a log of the individual who committed the shutdown or restart. If a machine is down, an administrator will want to check the Event Viewer and see who shut down the box.

Lastly, the Process Tracking audit event does not need to be enabled for success or failure under normal circumstances. Perhaps during a troubleshooting scenario this might be useful, although it does fill the log quickly.

Table 4-9 presents the Audit Policy features, a description of the features, and how auditing should be implemented.

Table 4-9 Domain Users' Audit Policy

Audit Feature	Description	Domain Controller	RAS Server	File and Print	Database	Web Server	Workstation
Logon and Logoff	Enables auditing of logon/off attempts, and breaking of network connections to servers.	Select Failure	Select Failure	Do not select	Select Failure	Do not select	Do not select
Use of User Rights	Enables auditing of attempts to user rights that have/have not been granted.	Select Failure	Select Failure	Do not select	Do not select	Do not select	Do not select
User and Group Management	Enables auditing of creation, deletion, and modification of user and group accounts.	Select Success Select Failure	Select Success Select Failure	Do not select	Do not select	Do not select	Do not select
Security Policy Changes	Enables auditing of granting or revoking rights to users or groups, and establishing or breaking trust relationships with other domains.	Select Success Select Failure	Select Success Select Failure	Do not select	Do not select	Do not select	Do not select
File and Object Access	Enables the ability to turn on the auditing of access to a directory or file that is set for auditing.	Select Failure	Select Failure	Select Failure	Select Success Select Failure	Do not select	Do not select
Restart, Shutdown, and System	Enables auditing of shutdowns select and restarts of the computer, the filling of the Audit Log, and the discarding of audit entries if the Audit Log is already full.	Select Success Select Failure	Select Success Select Failure	Select Success Select Failure	Select Success Select Failure	Select Success Select Failure	Do not select
Process Tracking	Enables auditing of the starting and stopping processes.	Do not select	Do not select	Do not select	Do not select	Do not select	Do not select

File and Directory Auditing

File and Directory auditing, like System auditing, provides good controls for security monitoring. File and Directory auditing allows you to monitor what resources are being accessed. For files and directories deemed critical, this is extremely important. Reviewing the reports is also very important. Without reviewing the reports, the security controls will not be effective. File and Directory auditing tracks detailed activity for selected users on individual files and directories. For each directory or file, you can define users or groups to audit.

File and Directory auditing is granular because it is possible to choose to track a specific user's access to a specific directory or file. This type of auditing helps minimize the events that are tracked and reduces the use of system resources, such as the disk space required to store the auditing events.

To enable File and Directory auditing, choose Start, Programs, Windows NT Explorer, highlight a directory, right-click the object to open its drop-down menu, and then choose Properties. The Properties dialog box appears. If you highlight a file, right-click it and choose Properties from its drop-down menu, the File Properties dialog box appears. Click the Security tab and then click the Auditing button. A Directory Auditing dialog box appears.

The dialog box for Directory auditing differs slightly from the dialog box for File auditing. The Directory Auditing dialog box contains two additional options: Replace Auditing on Subdirectories and Replace Auditing on Existing Files. These options are described in the following table:

Fields	Description
Directory	Displays the logical drive and NTFS directory to which auditing is to be applied. Multiple directories can be simultaneously selected.
Check Box	Description
Replace Auditing on Subdirectories	Allows the user to make changes and apply them to all subdirectories. By default, this option is not selected.
Replace Auditing on Existing Files	Allows the user to make changes and apply them to the files in the directory. This option is enabled by default because auditing applied to the directory affect the files in that specific directory.
Section	Description
Name	Displays the name of the user or group accounts and the type of auditing enabled. If multiple directories are selected, the auditing displayed will be common to the selected files.
Button	Description
Add	Opens the Add Users and Groups dialog box.
Remove	Deletes the selected account from the Names list.

The Replace Auditing on Existing Files check box is not a state; it is an option that you can execute at a specific time. If it is checked, all files within the directory inherit audit settings at that moment and the box becomes unchecked. The files will not inherit permissions again until this box is rechecked.

To view the audit events that were logged, choose Start » Programs » Administrative Tools » Event Viewer » Log » Security. To save these events to an external file (that is, if you need to archive them or open them in another application), choose Log » Save As.

Recommended File and Directory Auditing Settings

To audit files and directories on a particular server, the File and Object Access audit event option must be enabled in the Audit Policy for that server. Selecting to audit events relating to file and directory access is a critical control and should be carefully thought out and planned. Table 4-10 lists some important audit recommendations for the Fecha database server's data files.

These settings are for domain users. Because auditing takes up a lot of resources, Fecha has decided that it is only cost-effective to audit these data files because they contain critical business information. Fecha does not want to audit the Windows NT system files on its domain controllers because only administrators have access to those files.

Fecha audits failure on read because it wants to know who attempted to access a file they should not have. In addition, Fecha wants to know who successfully deletes and attempts to delete any data files. Lastly, because the Change Permissions and Take Ownership items are very sensitive, Fecha audits who completes and attempts to complete those operations.

Table 4-10 Data Files Audited for Domain Users' Access

Item	Success	Failure
Read	Do not select	Select
Write	Do not select	Do not select
Execute	Do not select	Do not select
Delete	Select	Select
Change Permissions	Select	Select
Take Ownership	Select	Select

Registry Auditing

Auditing the Registry is an important aspect of auditing because the Registry contains important system configurations. Noting any changes that take place in the Registry is crucial for maintaining the integrity, confidentiality, and availability of your systems. You can audit changes made to specific Registry keys. If someone manages to gain physical access to a domain controller or if there are many administrators in a corporation, it is highly recommended to implement Registry auditing as a security control to determine who made the modifications.

Registry auditing is set up in the Registry Editor utility. To launch the Registry Editor, choose Start » Run, and type REGEDT32.EXE. Choose Security » Auditing and the Registry Key Auditing dialog box appears.

Click the Add button to add a user, and then set the Success or Failure options in the Events to Audit area. Table 4-11 describes these Registry options.

Table 4-11 Registry Auditing Options

Permissions	Description
Query Value	Attempts to read the settings of a value entry in a subkey.
Set Value	Attempts to set the value in a subkey.
Create Subkey	Attempts to create a new key or subkey within a selected key or subkey.
Enumerate Subkey	Attempts to identify all subkeys within a key or subkey.
Notify	Attempts to receive audit notifications generated by the subkey.
Create Link	Attempts to create symbolic links to the subkey(s).
Delete	Attempts to delete selected keys or subkeys.
Write DAC	Attempts to modify the discretionary access control (DAC) list for the key.
Read Control	Attempts to read security information within selected subkey.

To view the audit events that were logged, choose Start » Programs » Administrative Tools » Event Viewer » Log » Security. To save events to external files, if you need to archive them or open them in another application, choose Log » Save As.

Recommended Registry Auditing Settings

To audit the Registry, the File and Object Access audit event must be enabled in Audit Policy. If changes to a particular key by a user or application are to be audited, you can turn on auditing for that key. Sometimes it is prudent to audit only those events that fail. Auditing successful events may produce many entries that the Security Log will quickly fill up. As with File and Directory auditing, careful planning should take place before you turn on Registry auditing.

Table 4-12 provides recommendations for Fecha's Registry auditing scenario. These recommendations are not comprehensive, so just use them as a guide when you set up your Registry auditing policies. Fecha administrators want to be able to log who made Registry modifications that may bring the system down or make harmful system changes. Therefore, Fecha implemented its Registry auditing settings on the Administrators and Domain Admins groups. In addition, to monitor individuals who obtain physical access to the domain controllers and attempt to make changes to the Registry, Fecha will audit the Everyone group. The following Registry keys and their existing subkeys should be audited:

• HKEY_LOCAL_MACHINE \System

• HKEY_LOCAL_MACHINE \Software

• HKEY_CLASSES_ROOT

Table 4-12 Registry Options

Item	Recommendation
Query Value	Do not select
Set Value	Select Success and Failure
Create Subkey	Select Success and Failure
Enumerate Subkeys	Do not select
Notify	Do not select
Create Link	Select Success and Failure
Delete	Select Success and Failure
Write DAC	Select Success and Failure
Read Control	Do not select

Printer Auditing

Windows NT Server provides the ability to secure and audit printer access. These controls can also be important depending on where employees print and what is being printed. Color printers that are on the network but only to be used by the marketing department, for example, should have the proper permission on them. In addition, they should have auditing controls so you can track any attempt by unauthorized users. Printer auditing can audit the success or failure of attempts by users to print, change job settings for documents, pause print jobs, restart print jobs, and reorder and delete documents in the print queue. In addition, it is possible to audit user attempts to share printers, delete printers, change printer permissions, and change printer ownership.

Choose Start » Settings » Printers. Double-click the printer you want to audit. Choose Printer » Properties, click the Security tab, and then click the Auditing button to access the Printer Auditing dialog box.

Table 4-13 presents and describes the printer options to audit:

Table 4-13 Printer Audit Options

Option	Description
Print	Printing documents
Full Control	Changes to document settings, pausing, restarting, moving, and deleting documents
Delete	Deleting a printer
Change Permissions	Changing printer permissions
Take Ownership	Taking ownership of a printer

Recommended Printer Auditing Settings

To audit printers, the File and Object Access audit event must be enabled in the Audit Policy.

Auditing printers is not a common practice that we see because it consumes system resources. However, in some circumstances (such as when a printer is dedicated to printing checks), it is a security control to audit anyone who may attempt to print a check. For example, Fecha's file and print server has a check printer, FechaCHECK that only the accounting group should use. Table 4-14 details how all print attempts are audited in such an example.

Table 4-14 Printer Audit Recommendations

Printer	Name
FechaCHECK	Everyone
Option	Success	Failure
Print	Do not select	Select
Full Control	Select	Select
Delete	Do not select	Select
Change Permissions	Select	Select
Take Ownership	Select	Select

Remote Access Server (RAS) Auditing

Windows NT Server can log the activities of remote users accessing Remote Access Servers. Auditing events that may indicate attempts to break into your system through a dial-up connection can be viewed with Windows NT Event Viewer.

Before auditing can take place, a parameter must be enabled in the Registry. Changing this Registry value is outlined in the following steps:

1. Choose Start » Run and then type REGEDT32.EXE in the text field.

2. Select the HKEY_LOCAL_MACHINE window.

3. Open the following key: SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters

4. Highlight Parameters and double-click Enable Audit in the right pane.

5. Make sure the value in the DWORD value is 1.

Caution: Monitoring and auditing RAS is important from a network security control perspective as intruders often attempt to dial in and breach system security.

Fecha Manufacturing Corporation, as do most of our clients, has a RAS server for allowing its employees to dial in from remote locations. This is a critical server for Fecha, because most employees dial in to check e-mail and access data files from home or from the road. RAS creates another point of entry and should be audited appropriately to mitigate this risk. Although many RAS audit messages appear in the Event Viewer, Fecha will filter only two important audit messages:

"The user has connected and failed to authenticate on port portname. The line has been disconnected."

"The user connected to port portname has been disconnected because there was a transport-level error during the authentication conversation."

By reviewing the Event Viewer for these particular messages, Fecha will be monitoring for attempts to guess user names and passwords.

Event Viewer

The Event Viewer is the tool within Windows NT that you can use to review audited events. Event Viewer has three logs that record system, security, and application-related events, known as the System Log, the Security Log, and the Applications Log, respectively. These are critical controls for monitoring security. Many times, systems administrators turn on auditing, record events, and then never look at the logs. Reviewing the logs and following up on any discrepancies is an important part of the control. Without it, the security control is ineffective. In addition, where other controls cannot be used (such as when files cannot be properly secured), Security Logs and the review thereof can be a compensating control that will help mitigate the risks.

The System Log records errors, warnings, or information generated by the Windows NT Server system.

The Security Log can record valid and invalid logon attempts and events related to the use of resources such as creating, opening, or deleting files and other objects.

The Application Log records errors, warnings, and information generated by application software such as an electronic mail or database program.

The System and Application Logs can be viewed by anyone. Only systems administrators or users with the Manage Auditing and Security Log user right can view the Security Log. For security control, the Security Log is the critical log. If a system administrator had to choose between which logs to review, the Security Log should be top priority.

To start Event Viewer, click Start » Programs » Administrative Tools Event Viewer. Then choose Log » System » Security, or Application to view one of the three different sets of logs.

You can choose from a variety of ways to view the information in all the logs. Choose View » All Events to see everything that has been logged. If this is too much information to analyze, choose View » Filter events to see only certain events.

When you choose View » Filter Events, you can analyze events from certain days or only certain types of events. For example, if Fecha Manufacturing Corporation wanted to see only error messages that occurred on January 15, 1999, you would click the Events On button in the View From box, and then type 1/15/99 in the Date field and 12:00:00 AM in the Time field. Then you would click Events On in the View Through box, type 1/15/99 in the Date field and 11:59:59 PM in the Time field. Lastly, you would check the Error option in the Types field. In addition, audited events can be filtered by Source, Category, User, Computer, and Event ID (described in Table 4-15).You can also view this information in the Event Detail dialog box. Double-click an event to get its event detail.

The information contained in the Event Detail dialog box is summarized in the Table 4-15.

Table 4-15 Detailed Event View

Item	Description
Date	The date the event was generated.
Time	The time the event was generated.
User	The account name translation of the subject's SID that generated the event. This username will be the impersonation ID of the client if the subject is impersonating a client, or it will be the username of the primary ID.
Computer	The computer name for the computer where the event was generated.
Event ID	A unique, module-specific ID of the specific event.
Source	The name of the system that submitted the event. For security audits this will always be Security.
Type	The audit type indicating whether the audited security access attempt was successful or unsuccessful.
Category	A classification of the event by the event source.

You can filter, view, and sort events by their category. The category of the event is also listed in the Event Detail information. Table 4-16 shows categories of events and their definitions. The events in the parentheses are the actual titles of the events listed in the Audit Policy dialog box. To view this dialog box, choose Start » Program » User Manager for Domains » Policies » Audit Policy.

Table 4-16 Event Viewer Categories

Category	Definition
Account Management (User and Group Management)	These events describe high-level changes to the Security Account Database (creating a new user or changing a user account).
Detailed Tracking (Process Tracking)	These events provide detailed tracking of subject information. Subject information includes program activation, handle duplication, and indirect object access.
Logon/Logoff (Logon and Logoff)	These events describe a single logon or logoff attempt and whether successful or unsuccessful. Included in each logon description is an indication of what type of logon was requested or performed (interactive, network, service).
Object Access (File and Object Access)	These events describe both successful and unsuccessful access to protected objects.
Policy Change (Security Policy Changes)	These events describe high-level changes to the security policy database, such as the assignment of privileges or logon privileges.
Privilege Use (Use of User Rights)	These events describe both successful and unsuccessful attempts to use privileges, including a special case when privileges are assigned.
System Event	These events indicate that something affecting the security of the entire system or the Audit Log occurred.

Event logs eventually get full and items will be deleted. To save events to external files (that is, if you need to archive them or open them in another application), choose Log » Save As. Event logs can also be manually cleared, but be sure the information is not needed because it cannot be retrieved after clearing the logs.

Maintenance of log files is a critical security control that is usually overlooked. Systems administrators take the time to review and implement audit settings. However, a good hacker can create problems that cause the logs to fill quickly and if the proper settings are not set, the logs will overwrite previous log information, essentially erasing the hacker's tracks or crashing the system, causing a denial-of-service attack. Therefore, it is critical that the log parameters for size and event recording for each log are set appropriately. Choose Log » Log Settings to open the Event Log Settings dialog box.

Click on Change Settings for the drop-down list to choose settings for the Security, Applications, or System Log. The options are the same for all three. Table 4-17 describes the options available within the Event Log Settings dialog box.

Table 4-17 Event Log Settings Options

Option	Description
Maximum Log Size	This option allows you to choose the log size. The default maximum size of a log is 512K. However, it can be increased to accommodate more auditing.
Overwrite Events as Needed	This option allows each new event to replace the oldest event if the log is full.
Overwrite Events Older than x Days	This option is the best choice to use in conjunction with a regular archive policy. The default is 7 days.
Do Not Overwrite Events	This option ensures a complete Audit Log. When selected, the log must be cleared manually.

Recommended Event Viewer Settings

Event logging begins at boot time. If all options in the Audit Policy dialog box, including Process Tracking, are enabled, Windows NT can log a significant amount of activity to the Event Log, thereby filling the log. It is possible to enable system halting when the log gets full. If the system is not set to halt or crash when the Audit Log is full, it will wrap and overwrite older entries. However, you can set when Windows NT will start overwriting older events in the Event Log Wrapping section of the Event Log Settings dialog box. Table 4-18 lists some general recommendations for the Event Log Wrapping option on all Windows NT implementations.

Table 4-18 Event Log Wrapping Setting Recommendations

Log	Overwrite Policy Setting
Security Log	Overwrite events older that 14 days
System Log	Overwrite events older that 14 days
Application Log	Overwrite events as necessary

In addition, Table 4-19 lists the recommended sizes for the log files based on the type of Windows NT implementation. The sizes are also based on estimates that are large enough to contain two weeks of data. For example, five to ten megabytes is large enough to contain two weeks of Security Log audit events.

Table 4-19 Log Settings Size Recommendations

Log	Domain Controller	File and Print Server	Database Server	Web Server	RAS Servers	Workstation
Security Log	5-10 MB	2-4 MB	2-4 MB	2-4 MB	5-10 MB	1 MB
System Log	1-2 MB	1-2 MB	1-2 MB	1-2 MB	1-2 MB	1 MB
Application Log	1-2 MB	1-2 MB	1-2 MB	1-2 MB	1-2 MB	1 MB

However, in our experience, for the Security Log, we have noted that the best practice is to make sure that the size of the log is big enough to hold 14 days of events online. This may mean providing bigger spaces for your logs depending on what Windows NT server is being audited and what audit features have been implemented. For example, on a Windows NT domain controller, the log-size setting will probably be set to a bigger size. On the other hand, for a Windows NT workstation, for which no auditing has been implemented, the log size will be very small. Setting the correct log size can only come with testing and experience.

Windows NT provides the "Crash On Audit Fail" flag in the Registry key located in SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail. When this flag is set to 1 and the system cannot for any reason log an audit record, the system is brought down. If this flag is not set (set to 0), and the Audit log is full, an alert message is displayed to the system administrator warning that the Event log is full. This security feature is a double-edged sword and should be thought out carefully. Hackers like to generate lots of audit messages, fill the Audit log so that it cannot accept any more messages and then commit malicious acts, which are not logged. If the flag is set, the system will halt when the log is full and the hacker cannot commit any malicious acts. However, setting the flag and halting the system also invokes a denial-of-service attack.

Securing the Audit Logs

Auditing the system is not enough. In addition, the logs that hold the auditing information should be secured and maintained. In other words, security controls should be placed on the actual log files themselves to ensure confidentiality and availability when they are needed. If the files are not protected properly, a hacker may perform some activities and then delete the logs to cover the trail. The following files are the log files, which can be found in the systemroot\System32\CONFIG directory.

**APPEVENT.EVT—**Application Events Log

**SECEVENT.EVT—**Security Events Log

**SYSEVENT.EVT—**System Events Log

The best way to secure these files is to create an auditor group that has access to these files, and then take it away from all other groups. The people assigned to the auditor group will be responsible for maintaining the data within the logs.