The NT Security Log - Your Best and Last Defense

By R. Franklin Smith

On This Page

Log Size
Event-Log-Maintenance Strategies
Many Systems, Many Logs
Stay Tuned

Your overall security strategy depends on the Windows NT security log, which is your final layer of defense for catching violators who made it past your previous layers of authentication and access control. The NT security log tracks what objects your users access and how, and which programs they run. You can monitor a user's actions, even when the user holds administrative access rights. This audit trail lets you detect suspicious activity from both outsiders and insiders and provides you with important evidence to use against intruders.

You might find that getting the most benefits out of your security log is challenging, but I can show you how to maximize your NT security log's potential. Let's start with some tips on the log's overall care and feeding.

Log Size

Before you start auditing activities, you need to correctly configure your log and archival process to avoid data gaps. The NT Event Viewer's log settings dialog box specifies a maximum size for the three NT event logs—system, application, and security. As NT records events in the security log, the log grows until it reaches its threshold size. You can select Overwrite Events as Needed to discard the oldest events as NT records new events, as Screen 1 shows. However, programs can fall into infinite loops, which results in NT creating log entries for each program iteration. You'll need to see what events caused this condition, not just a log full of identical events, so I usually don't choose this option. If you select Do Not Overwrite Events (Clear Log Manually), NT stops recording events when the log reaches its threshold and doesn't resume recording until you manually clear the log. I don't like this option because you must clear the log before it fills, and you can't keep a constant amount of history online. If you choose the Overwrite Events Older than X Days option, NT records events until it fills the log. When the log is full, NT discards events older than the set number of days as needed to accommodate new events. If the log becomes full of events younger than the set number of days, NT stops recording events until some events expire. Unfortunately, NT doesn't warn you that your available log space is running out. If you're recording events at a sufficient frequency, you might lose important activity records regardless of the log settings.

Screen 1 Event Log Settings

Event-Log-Maintenance Strategies

Unless you use an event-log management product that monitors the log in realtime and relays events to a central log server, you need to formulate a combination of log settings and archival procedures to avoid losing events. You must also consider how far back in time you need to record events in your security log because you might discover perpetrators who have been engaging in improprieties for an unknown period. You want to be able to sufficiently document their actions to develop your case against them.

Several strategies are available to meet your needs and required security level. One strategy that is appropriate for many medium-level-security commercial environments uses a long, contiguous audit trail and requires low maintenance. However, you might find maintaining a contiguous event log difficult because you can still lose events no matter how you configure your log and archival process. For example, if you set the log to automatically overwrite, NT might discard older events before you can archive or view the log. If you don't set the log to overwrite, you might lose new events between the time the log fills and when you clear the log. If savvy intruders know your log settings, the intruders can use this information to try to fill the log to cover their tracks.

To illustrate my internal network security strategy, set up an internal application server (requiring medium security) to maintain a contiguous, 12-month audit trail. I determined that 7MB will accommodate the average activity for 30 days on this particular system, but I don't have a rule of thumb to give you to determine this size. The amount of log space you consume daily depends on the size and activity of your system; the event categories you enable for auditing in the Start menu's Programs, Administrative Tools, User Manager for Policies, Audit dialog box; and especially the level of object auditing you're using. Therefore, I set the maximum log size to 14MB to accommodate a month of unusually high activity. I also set the event-log wrapping to overwrite events older than 3 days because nobody checks the system from Friday evening until early Monday morning. If a process goes awry during the weekend and starts pouring events into the log, NT overwrites older events up to the 3-day threshold and stops logging at that point. By the time I come in Monday, I can at least get a clue as to what happened between Friday evening and Monday morning. I perform full backups every night out of a 30-tape rotation, and on the first Monday of every month, I back up out of a 12-tape rotation. Before each backup, I use the NT Scheduler service and Dumpel from the Microsoft Windows NT Server 4.0 Resource Kit to archive the event log to a directory on the server, then the backup archives the directory to tape. If I keep a minimum of 30 days of activity online and archive once a month, I can research through 12 months of activity and avoid manually repeating work. When you need a particular month's activity, just restore the previously dumped EVT file and use Event Viewer to open it. This method doesn't fit all scenarios, but you can use the same archival frequency and tape rotation scenario to determine the method that best suits your security requirements.

You must remember a few more important facts about log settings and security. When you change the maximum event-log size, the change doesn't take effect immediately. This delay is especially significant to remember when you're increasing the log size. After you change the size, you're given the option to save the log. If you don't clear the log, NT won't take advantage of the newly added space. You also need to keep your event-log size, wrapping settings, and archival process private because intruders can use this information against you to try to fill the log. To help keep this information less public, I recommend you set the Registry key RestrictGuestAccess of type REG_DWORD to 1 in HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \EventLogLogName to restrict guest access to all three event logs. You need to make sure the Registry keys' permissions grant set-value authority to administrators only. You can also use the Security Configuration Manager (SCM) that Service Pack 4 (SP4) includes to manage log settings, as Screen 2 shows, and to restrict access to event logs. (For more information about SCM, see the Microsoft TechNet article "MS Security Configuration Manager for Windows NT 4". Finally, you can configure NT to immediately crash if NT inadvertently fills the event log, but use this procedure only for extremely high-security commercial and military configurations. To recover from the NT crash, the administrator must reboot, archive, and clear the log; reset a flag in the Registry; and reboot a second time.

Screen 2 Security Configuration Manager

You need to know a final fact about NT's security log—the Event Viewer is the only tool that NT includes to get information from the logs. Unfortunately, this tool is inadequate for performing analysis and for tracking and automating security checks. I have a few favorite utilities for these processes, but many event-log tools are available to meet these needs. For more information about log analyzers, see Mark Joseph Edwards, "The Handy Security Toolkit Revisited," October 1999, and Gary Kessler, "Add Fuel to Your Firewall," October 1999.

Many Systems, Many Logs

Keep in mind that each NT system maintains an event log. NT records events on the system as the OS perceives them, which results in a very fragmented audit record for the enterprise and affects how you configure your security event log. You must make sure that you use consistent and appropriate log settings to configure each class of systems. Most administrators make a standard SCM template with the appropriate security settings for each system type they manage, such as domain controllers, workstations, and application servers. For each template, be sure to include your desired settings for the three security logs. In future articles, I'll discuss the most useful locations for you to use each audit category on, such as on domain controllers, member servers, or workstations. I'll also look at utilities that help you merge and correlate data from logs scattered throughout your network.

Stay Tuned

In March, I'll look inside the security log and dive into NT auditing. I'll examine three audit categories—logon/logoff, object access, and process tracking—and tackle topics such as whether auditing will slow down your system, how you can prevent or detect tampering with the security log, and how you can effectively track logon activity throughout your domain's many systems. Until next time, make sure that you have a comprehensive system that keeps a dependable and contiguous audit trail and that minimizes your manual work.

[Editor's Note Email me information about your favorite event-log tools (preferably shareware), and I'll put together a tour of the best tools that administrators are using. For that matter, send me your tips about how to get the most out of your NT security log.]

About the Author

R. Franklin Smith, president of Monterey Technology Group, provides Windows NT security training and consulting. You can reach him at rsmith@montereytechgroup.com .

Click to Order