• Introduction to Auditing
• Auditing Features on Windows NT Server
• Developing an Audit Plan
• Implementing Audit Policies on Windows NT Server
• Sample Auditing Implementations
• Summary

24

Auditing Windows NT Server

Does auditing sound to you like something accountants do to you at income tax time? This chapter is about a different kind of auditing. Specifically, I discuss Windows NT's built-in functions to record certain events that might be of interest to you as a system administrator. Some examples of things that might be interesting to you include the following:

• Someone trying multiple times to log into several of the accounts on your system (hackers?).
• A service that is routinely failing to start up when it is supposed to or stopping in an unplanned manner.
• Someone trying to use privileged system functions (those that you normally restrict to yourself).
• A person logging on or off the system at unusual hours.
• The number of people logging on or off the system at various hours, to determine the number of users you are supporting at different times of the day or days of the week.
• A person using a sensitive right (such as administrator privileges) that has been granted to him.
• Certain files or other resources (objects) being accessed by various individuals.

As you will see later in this chapter, Windows NT enables you to monitor a fairly large number of events that can occur in your system. However, in this era of information overload, you need to determine which events are important enough for you to monitor, given your particular security and reliability needs. In super top secret environments, almost no effort is too much to expend on security. However, in a small company development environment, you might not have infinite amounts of time to devote to reading through log files.

This chapter is designed to address this central issue for auditing: What is good enough for you? The chapter starts with a general introduction to the concepts behind auditing. Next, I cover the things that Windows NT can monitor for you if you so desire. These first two sections prepare you for perhaps the most important section of this chapter, which deals with audit planning. Of course, for your plans to be useful, you have to implement them, and that is what the next section of this chapter is about. Finally, I put together some samples of how I might approach auditing in several different environments (not that I am necessarily right, but it does give you a couple different opinions to consider).

Introduction to Auditing

Certain people view auditing as strictly something designed to detect and potentially stop hackers and other security risks. Certainly that is the focus of several classified government agencies, and rightly so. Audit trails that are carefully reviewed can enable people to detect new ways users are probing the information in a computer that have never been used before. Hackers are just like virus writers[md]they sit up all night thinking of new ways to hack.

However, I would like you to also consider a broader use for auditing that might interest even those of you who implicitly trust everyone who has access to your server. The first audit records were not written by people trying to stop Internet hackers. Instead, they were people dealing with early computers that just halted in the middle of executing a program. Because there were no fancy computer monitors back in that era (or any monitors, for that matter), people had little idea where their program halted. After many frustrating attempts to solve problems by trial and error, people started to record progress that was being made in their applications to output devices such as printers (or paper tape). When applications crashed, they simply traced the progress through these checkpoints to determine where the problems occurred.

As operating systems grew and become more capable, the auditing capabilities were built into the operating system. This is especially important for multi-user operating systems, where you need to know who caused the problem and what they were doing at the time to prevent it from happening again. Eventually, auditing was expanded beyond the "finding who caused the crash" stage to provide additional helpful information. It became a tool to record usage of the computer and its various resources. It was also extended to perform the security monitoring tasks mentioned earlier.

A general purpose operating system distributed to a large number of users now has to support a wide range of auditing. It has to cover the security angle to meet the needs of those super-secret environments, but also provide usage metering for people concerned with efficiently using their resources and planning for the future. Others might be concerned with only a light level of security (who is using system administrator privileges). Windows NT has to meet this wide range of challenges and also enable the users to pick from various forms of auditing to suit their individual needs.

Auditing Features on Windows NT Server

This section discusses auditing as it is implemented under Windows NT. I like the way Windows NT implements auditing for the following reasons:

• It integrates all the various forms of auditing (operating system events, security events, and application events) into a single system for review and monitoring. It can be difficult to find time to review your log files, and having all the information in one place displayed by one user interface makes life much easier.
• It is highly automated, with a fair level of basic information recorded automatically using the default system installation procedures.
• It is highly customizable, enabling you to pick exactly what you want and need based on your environment.
• You can interface applications that you develop locally with the auditing subsystem, thereby extending auditing to meet specialized needs, or integrate all your auditing activity into a single system.
• It is self-cleaning. I have gone into several computer systems where people have used up many tens of megabytes of disk space with logs that they never even knew existed (database and middleware log files, for example). These logs were so large that no one would ever bother to go through them (although UNIX does have utilities that let you see only the last x lines in the file).

For smaller server environments, it is often difficult to get a lot of formal training on your operating systems. What basic training you do get does not emphasize the finer features of the operating system, such as auditing. Therefore, I thought it would be useful to go over the auditing options that are available to you. The first set of events that are audited deal with operating system events:

• Services that fail to start
• Hardware conflicts detected
• Start of key services such as the Event Viewer
• Print jobs completed
• Anonymous logon requests such as WWW
• Disks nearing or completely out of space
• Access requests to the CD-ROM drive when there is no CD in the drive

The second area you can monitor involves system security events such as these:

• Activation of remote access server (RAS) processes
• Use of special privileges by the users
• User logon and logoff
• Failed logons
• Access to certain objects (for example, the auditing setup)
• Policy changes
• System shutdown and restart
• User and group management activities

Finally, the most expandable area involves Windows NT's capability to audit events within applications on the system:

• Setting up BackOffice applications such as Exchange Server or SQL Server
• Starting up BackOffice components
• Other events that you build into your applications or system scripts using the Software Development Kit (SDK) routines

Because the first thing you would want to do if you were trying to do something illegal is cover your trail, the auditing information in Windows NT is fairly well-protected inside the operating system (it doesn't have even the old, relatively obvious auditing registry keys you had in NT 3.51). The bad guys can't just delete a file and be done with it. You can, however, make a copy of the current log file to save error conditions or document unauthorized activity. This is especially important when you use the automatic overwrite features in the Windows NT auditing system.

Developing an Audit Plan

Now that you have at least a basic understanding of the sort of auditing information Windows NT can provide for you, it is time to figure out what you need to audit. It can be a somewhat tricky balancing act between controlling your volume of work (these logs can get very large on even a moderately active server), need for security (which you might not appreciate until you have a security problem), and the need to recover from problems. An absolute, simple answer would be nice; however, it turns out to be a balancing act that is unique to your particular situation, as shown in Figure 24.1.

Figure 24.1

Balancing needs for auditing.

The way I like to approach any such planning task is to go through and list the factors that I considered in the front of the plan document (usually right after some form of introductory paragraph explaining what I am doing). This is useful because it forces me to put things on paper and strain a little bit to try to consider every possible angle and factor that might influence the actual plan itself. I then would list what I plan to do. It is a good exercise to go back and review how well your actions satisfied the needs you identified in the factors section.

Let me start with some of the factors you might want to consider when making your audit plan. You will probably be able to come up with a number of additional factors that are more pertinent to your environment. Also, some of these might have absolutely no bearing on your environment. My suggestions for factors that you might consider include the following:

• Are you going to be connected to the Internet or another network that has users who are beyond your control and might possibly be hostile towards your computers or data (hackers and virus writers are hostile in my mind)? This would tend to lead toward much higher security monitoring than nice, isolated local area networks.
• What levels of access do your users have to your system? If all they access is a mail system or client/server database, your auditing requirements might be lighter than a server that has most of its directories exported or available through FTP. Even greater access security issues would come up if you let users actually log into your server through utilities such as Telnet (see Chapter 16 for more discussion of user management topics).
• What are your chances of having hardware or other system problems that might not be noticed for some time? This might lead you to retain your audit information longer than in an environment where you are checking the logs daily for any indication of problems.
• How much time do you have to review audit information? You have to factor this reality check into any auditing plans you make.
• How important is it for you to document the usage of your server? In some organizations, information systems people are constantly required to justify their benefits to the company. In these environments, it might be important to record information on the number of logons per day, for example.
• Do you have a large number of servers under your care? If so, you might not be logged into any one server very often. This might lead you to want more information in the audit logs so that you can look for performance or loading problems.
• How important is it for you to monitor the status of your applications? Some server administrators are also responsible for server-based applications such as databases or Web servers. In this case, it might be useful to build your applications to use the SDK to record information in the NT audit trail so that you can see application-internal problems or status messages.
• Do you need to record successful events (such as logons) or only times when these events failed? If you are not interested in usage statistics, failures might be all you need, and failures is a much shorter list to review than successes.
• Do you need to monitor system availability (up-time statistics)? If so, the shutdown and restart statistics can be very helpful at the end of the month when you are frantically trying to calculate up-time for the monthly report.

Finally, never underestimate the value of experimentation. Why not run full auditing on your server for a week or so and see how it goes? Look for those audit events that are most useful. Also look for those that occur frequently or convey little useful information. Try turning off a few parameters to see if this produces an audit trail that seems useful for you. Eventually, with a little bit of trial and error, you will get to an audit plan that meets your needs.

Implementing Audit Policies on Windows NT Server

Now that I have covered the "what to do" discussion of auditing, it is time for the "how to do it" discussion. The truly practical among you can rejoice that I am now leaving the theory world and getting down to business. A good place to start would be what I consider to be the heart of auditing under Windows NT[md]the Event Viewer. You access the Event Viewer through the Start menu, as shown in Figure 24.2.

Figure 24.2

The Event Viewer interface.

The Event Viewer both displays auditing results and enables you to perform most of the control functions for NT auditing. Figure 24.3 shows the Event Viewer interface. This is a clean, data-driven interface that focuses on the actual logged information. The control functions are located on the menu across the top. The columns you see here remain the same for all the event types that are monitored. You can maximize or minimize this display as desired.

Figure 24.3

The Log menu of the Event Viewer.

The following information is captured in these audit records:

• Date of the event
• Time of the event (to the second)
• Source of the event (for example, service)
• Category of the event (for those audits that have been categorized)
• Event number (a code you can reference)
• User ID that caused this event (not applicable on system start-up events and other events generated by the operating system with no user interaction)
• Computer identifier that caused the event (in multicomputer environments)
• Domain in which the event occurred
• A reason for the event (such as a logon that failed because of an Unknown user name or bad password)
• Additional information specific to the event (such as the logon type attempted for a failed logon)
• Type of event. This is not a text column; instead, the type of event is conveyed by an icon picture. The types of events you might see include errors, warnings, information, success audits, and failure audits.

The first key concept to grasp with the Event Viewer is that this one interface displays all three types of Windows NT audit records: system events, security events, and application events. You select which of these event types is displayed using the Log menu (see Figure 24.4). The Event Viewer remembers the type of log you were looking at the last time you used this utility and displays this same log type when you next start it. To determine which log is displayed at any given time, you simply look at the title. The title contains two useful bits of information. First is the type of auditing performed. The other is the machine whose audit log is being displayed. Once of the nice features for administrators who are in charge of multiple systems is the ability to select various Windows NT computers for which you want to display the audit log. Of course, you have to have the appropriate trust relationships established with these machines, but it is worth it if you have several systems to keep track of.

Figure 24.4

The Event Detail dialog.

Although these columns provide a good deal of useful summary information, they are not everything you would want or need to solve a really nasty problem. They are useful to scan through quickly to see if you have any real problems or if your log is just full of routine information messages and expected conditions. To get the full details about a particular event that catches your interest, all you have to do is double-click that event. When you do, you see a detailed display dialog, as shown in Figure 24.5.

Figure 24.5

The security log.

This dialog echoes the information contained on the summary display, along with several other useful bits of information. The exact details depend somewhat on the event encountered. For example, in Figure 24.5 where I intentionally typed in a bad password, you can see a text description of the reason and even the logon authentication package used. Some events display data in the bottom text area that can give you clues as to the state and activities that were occurring to cause the event. I always like to screen-print messages that I might have to take action on (or copy them down if screen printing is too much of a problem).

The next log to review is the security log, which is shown in Figure 24.6. Again, you see the same basic columns as in the system log. You get detailed information about a particular event by double-clicking it just as in the system log. The key differences for this log are the icons that you see at the left edge of the display, the use of the Category field, and the fact that the User column is often the most important bit of information displayed.

Figure 24.6

The Event Viewer Filter dialog box.

The two icons you typically see are a key (indicating success, which could be bad in the case of a hacker accessing something he shouldn't have) and a lock (indicating that the system stopped the user from doing something). It is normal to see a few failures every now and again (for example, I have so many passwords that I have trouble keeping them all straight). What you are really looking for is several failures occurring in a short period of time, which might indicate hacking. You can also scan through the Category list for events that are of interest to you (for example, logon/logoff events). Finally, the User column can help you zero in on the activities of a particular user that you might be keeping your eye on.

One thing I considered a bit strange about the Event Viewer display was the fact that they did not allow you to sort on any of the categories in the multicolumn listbox display by simply clicking the column heading (such as Category). You can find this type of control on the My Computer utility on your desktop. This would make it really easy to sort the list by user, for example, and see who is being naughty and nice. You do have some of this functionality by using the Filter option on the View menu. This gives you a dialog (see Figure 24.7) that enables you to focus on a particular category, user, and so forth. You have to be somewhat careful because you don't see events that don't match your input criteria but might be important to you (use the Clear button on the Filter dialog to view all events). This is an interesting technique to keep in your inventory when you have to audit a large number of events.

Figure 24.7

The Event Viewer application log.

The final log is the application log, shown in Figure 24.8. This is perhaps the least-exploited log in its basic form. About the only applications I have loaded that make good use of this log are the Microsoft BackOffice applications, and even they could make greater use of it. I like the concept of being able to record application events in one central point as opposed to dozens of different log files scattered all over the system (I have had to deal with these files before, and they can be a bit of a pain). The software development kits from Microsoft enable programmers to interface to these audit files. You might want to consider this if you have any input into the application development at your facility.

Figure 24.8

The Event log Settings dialog box.

The best way to get used to these logs is to run your system for a while and review the events that get recorded. You should be especially sensitive to the icons displayed on the far left side of the list of events, because these help you sort out the problems from the routine items. The next issue you have to deal with is controlling the event log itself. The control over the size of the data and time it is retained is set using the Log Settings option of the Log menu (see Figure 24.9).

Figure 24.9

The Event Viewer's View menu.

You set each of the log record sizes separately as controlled by the drop-down listbox. The first thing you set is the maximum size of the log. Basically, I accept the default and adjust it only if I am retaining information for too long a period or too short a period. The next feature you set here is the one that controls the Windows NT auditing log self-cleaning feature. I really like this because I have seen some really huge log files that someone (like me) forgot to clean out. Your options are to overwrite as needed, to overwrite events only if they are more than a certain number of days old, or to never overwrite (to manually clear the log). Again, remember that you have to set this up for each of the three logs (system, security, and application) used by NT's auditing.

One final set of controls you have in the Event Viewer tool is shown in Figure 24.10. I have already covered the All Events and Filter Events options. This menu also gives you the option of displaying the events from earliest to latest or latest to earliest event. The Find dialog looks similar to the Filter dialog, but instead of limiting what is displayed, it takes you to the records that meet your input criteria. The Detail option is similar to double-clicking a particular event. Finally, Refresh updates the display with any new events.

Figure 24.10

Selecting the Audit option in User Manager.

The system audit events are pretty clear as to what you would want to record (you almost always would want to know if your serial port has an interrupt conflict). The same goes for application events, because you would have to add them to your applications to get anything to go in there other than a few of the BackOffice products that are currently using this portion of the auditing system. However, the security logging mechanisms need finer control to accommodate the wide variety of environments that are out there. If you were to audit everything imaginable in security, your log file would be so large that you would have to write an application just to filter out the events that might possibly be of interest (which would not be all that difficult, actually). However, some groups that I work with do not even want to waste the disk space for security auditing because everyone has full access to all resources and therefore these records have no meaning (small software development environments can be fun in this regard).

NT's auditing system accommodates this wide range of needs through the User Manager utility. This is another of the administrative tools that are available to you (refer back to Figure 24.2). I guess it was a toss up as to whether to put all auditing controls in the Event Viewer or to put all the features involved with user security in the User Manager. Microsoft chose the latter option. To access the controls for security auditing, choose the Audit option from the Policies menu in User Manager (see Figure 24.11).

Figure 24.11

The Audit Policy dialog box.

The Audit option displays the Audit Policy dialog shown in Figure 24.12. The radio buttons are important because they make the basic selection as to whether you perform any of these detailed security auditing functions. If you select to perform these security auditing actions, you are given two basic choices for auditing. The first column of checkboxes enables you to audit when users perform the functions listed successfully (such as logging on with the correct user ID and password). The second column of checkboxes enables you to audit when users fail when trying to perform a function. You can greatly reduce the number of events recorded if you look only for failures. This catches hackers or people trying to access a resource for which they lack permission. However, if you are trying to gather statistics on usage or logging all (legal) access to a resource, you would want to use the first column's checkboxes. Of course, if you want a lot of information, you can audit both successes and failures.

Figure 24.12

The Audit Policy dialog box.

Splitting the security auditing features into these seven categories enables you to pick the items that meet your needs and ignore the others, which can also reduce the number of log file entries you have to review. The categories you have to choose from are as follows:

• Logon and Logoff.
• File and Object Access: This can be very detailed, but it works only for NTFS file systems that have access rights (FAT is a pretty open storage mechanism designed for nonsecure DOS environments).
• Use of User Rights: This refers to rights that have been granted to a user or group (for example, performing system administrative functions with a personal NT account).
• User and Group Management: This catches when someone alters the privileges of another account or creates an account to perform some bad activities and then deletes it.
• Security Policy Changes: This is another area where the whole security picture of your system can be changed and therefore is a common audit function.
• Restart, Shutdown, and System: This can be useful for recording down time and determining when serious problems such as power outages occurred.
• Process Tracking: This captures some very detailed information such as process activation and indirect object access.

As you can see, you can set up a lot with NT auditing. The interface that controls and reviews the auditing information is also a clean and simple one. The challenge is often to make the time to review the log. In summary, your steps in setting up auditing on an NT Server should include the following:

1. Determine the factors that affect your auditing needs.
2. Develop an audit plan.
3. Use Event Viewer's Event Log Settings dialog to control the amount of information retained in each of the logs.
4. Use the User Manager's Audit Policy dialog to control which security auditing features are implemented on your system.
5. Make time to review the logs using Event Viewer.

Sample Auditing Implementations

Now that you are an expert in setting up auditing on Windows NT, here are a few sample auditing configurations that I might set up. Think of them as food for thought when you go through setting up your auditing. For purposes of this discussion, I construct three possible scenarios:

• The small server in a low effort environment.
• A middle-of-the-road corporate server with some sensitive information.
• A server with a fair amount of sensitive information.

For my first scenario, I consider a small server in an environment where not much effort can be expended on administering the server. Perhaps this is a nice, secure development environment that exists on an isolated LAN where everyone has access to all data that is stored on the server. You can limit the user's ability to access directories containing applications just so they don't accidentally destroy something. Also, you can use FAT file systems for compatibility with other operating systems loaded on this machine (for example, DOS/Windows 3.11).

Under this scenario, I recommend using the default audit settings in Windows NT. The log files take up 512KB each, which is not a lot in most server systems. The security auditing features under User Manager are turned off (set to Do Not Audit). However, this seems like a very good way of doing business for this low security environment. Note that you still get a full set of auditing on the system log recording problems that you might have with processes or conflicts. You also get whatever application log entries the applications you install on your system support.

The next scenario is a middle-of-the-road scenario. I think of this as a typical office server that might serve as a file server, print server, mail server, and application server. The information stored in the user's directories is not top secret or sensitive personnel information (perhaps just a bunch of spread sheets and word processing documents). You want some form of security to ensure that hackers do not mess with another user's data (such as the marketing plans of a competing salesperson), but you don't have a lot of time to devote to this auditing function. Perhaps you are responsible for all the servers in your building, for example.

In this case, I would probably set up the NT auditing to maintain the default log size unless I run into problems with it. This is pretty good for most of the work I have done. I would set it up to keep log entries for 30 days on the Event Log Settings panel. The biggest changes from the default would be to set up some basic auditing functions in the Audit Policy dialog in User Manager. I would typically record failure of logons, failure of file and object access, success and failure of user and group management functions, success and failure of security policies changes and restarts and shutdowns. This assumes that I have a good security setup (I am using NTFS and therefore can isolate user access to appropriate directories or have disabled the average user's ability to log on at the console) and that I just want to catch changes that might occur. I also want to catch any time there are several failures trying to log onto the system or access a particular resource. This might be a sign of someone trying to hack a password for another user's account (most of the places I have worked have standard naming conventions for accounts, so all the hacker needs to do is guess the password to gain access to information). Finally, I would plan a time once a week or so to review log information. Again, I would look at the icons on the left of the Event Viewer display to see stop signs and padlocks, which indicate potential problems.

The final environment you might have to support is a server that contains some really sensitive information. Perhaps you are dealing with top-secret government information. Perhaps you are dealing with bank or personnel records that must be safeguarded. Another possibility is that you are just processing sensitive company information on a server that is open to access from the Internet or is connected to a customer's network. In any event, you would be under a lot of pressure to make sure that you keep everything as safe as possible.

I would attack this problem by setting up the audit log to retain a few megabytes of information in the security log section. I would retain events for at least 30 days. You should check your local record retention requirements to see if you are required to retain the records for longer periods. I might also consider saving log files once a month to disk. That way you have the option of going back in time to see how long suspicious activity has been taking place and what the impacts on security might have been.

As to Audit Policies set up under User Manager, I would probably set up the full spectrum for at least the failure option. I would set up success auditing for at least the logon, user rights, user and group management, security policy change, and shutdown/restart options. This assumes that NTFS is being used for disk storage on disks that store sensitive information. It also assumes that you have set up your user and group structure correctly with emphasis on controlling access for such things as directories that are shared to only the appropriate groups. You might want to review your event log every day or two because you need to take action fairly quickly if you detect suspicious activity.

I hope these samples help you when you formulate your auditing setups. Remember again that these are just samples. Every environment has its own unique problems that need to be solved. Also, you might have more or less time to spend on the job than I typically do, so that has to be weighed against the information benefits of more detailed auditing. Finally, think of this as an ongoing process. If you find that you are getting too much or too little information, alter your policies until you have something that works for you. You should also review your auditing policy every time the use of your system changes. For example, if you add a personnel group or start keeping financial records in a new database, you might have to increase your auditing and security features.

Summary

Auditing brings up some interesting concepts that you have to consider as an NT Server administrator. You are not just a simple MS-DOS/Windows 3.1 PC user anymore without a care in the world about security. You are also not within a mainframe environment with its large staff of specialists, which usually includes a dedicated security staff. You are somewhere in-between. Often you are expected to provide the easy, intuitive access to data found on the Windows PC and the tight security found on mainframes. The auditing features of Windows NT make this task a little easier.

The key points to remember are that you use the Event Viewer to review results from all of the various forms of auditing: system, security, and application. It also sets up the retention parameters for the audit logs. The Audit Policy dialog in User Manager is used to set up most of the security auditing features under Windows NT. The application auditing feature can be designed into your applications if you want to have one central location for auditing information. Taken together, the environment is fairly easy to work with and provides a good deal of auditing information.