Introducing the NT Security Log

Your best and last defense

Your overall security strategy depends on the Windows NT Security Log, which is your final layer of defense for catching violators who've 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.

You can see that no matter how you configure your settings and archival process, you can still lose events. 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.

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 be able to research 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 so that you can develop your case against them.

Several strategies are available to meet your needs and required security level. One strategy that is usually appropriate for servers in medium-level-security commercial environments maintains a 12-month contiguous audit trail and requires low maintenance. You can watch how your log grows to determine how much log space you'll need to accommodate a month's activity. For example, on one server, I determined that 7MB will accommodate the average activity for 30 days. However, 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 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.

Before you develop your security strategy, 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 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 subsequently clear the log, NT won't take advantage of the newly added space.

You'll also want to keep your event-log size, wrapping settings, and archival process private to prevent intruders from filling your log. To keep this information less public, I recommend that you set the Registry key RestrictGuestAccess of type REG_DWORD to 1 in HKEY_LOCAL_MACHINESYSTEM CurrentControlSetServicesEventLogLogName 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) which 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" at http://technet.microsoft.com/ cdonline/content/complete/windows/ winnt/winntas/technote/scmnt4.htm.)

Finally, you can configure NT to immediately crash if it inadvertently fills the event log, but use this procedure for only extremely high-security 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.

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 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
My next article will 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 the author information about your favorite event-log tools (preferably shareware), and he'll put together a tour of the best tools that administrators are using. You can also send him your tips about how to get the most out of your NT Security Log.]