![]() |
![]() |
All Products | Support | Search | microsoft.com Home | |
![]() |
![]() | ||
TechNet Home | Site Map | Events | Downloads | Personalize | Worldwide | |
![]()
![]() |
![]() |
![]() 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.
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:
To start the Performance Monitor control, choose Start » Programs »
Administrative Tools » Performance Monitor. The Performance Monitor screen
is launched.
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
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.
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
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
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.
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.
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.
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
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.
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.
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
Click the Refresh button to get the latest statistical information on
pages with values that require more frequent updates.
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
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.
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
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
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.
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 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 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.
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
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:
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.
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
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
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.
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:
Table 4-12 Registry Options
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
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
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:
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.
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
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
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
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
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
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.
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.
Last updated
Monday, January 17, 2000 |
![]() |
![]()
![]() ![]() Click to order |
![]() |