Securing a building is more than just a matter of installing good locks and security cameras. You also need an alarm system so that you can respond in a timely manner if someone gets past those locks and cameras. You can apply the same rule to network security. Although installing good locks (e.g., virus scanners, a firewall) on your network is an important step, it doesn't guarantee the network's safety-as evidenced by the $15 billion lost in 2000 because of security incidents. Just as burglars can defeat locks on doors, dishonest employees and malicious Internet hackers can find ways past authentication and access-control features. A good security strategy includes real-time monitoring for critical security events and periodic analysis of your systems' Microsoft Windows NT and Microsoft Windows 2000 Security logs so that you can detect and respond in a timely fashion to internal and external attacks. In fact, when reviewing the general controls of a corporation, public auditors and regulatory agencies define Security-log monitoring as a necessary best practice and a part of performing due diligence.

However, such real-time monitoring is easier said than done. True, Windows NT/2000 includes the capability to record security events. You can track logon activity, the files that users access, the programs that users run, and the operations that administrators perform. Windows NT/2000 is good at collecting security data, but your ability to make use of the OSs' audit record is complicated by the following limitations:

• No real time monitoring and notification. Windows NT/2000 has no way to notify you of suspicious activity. Event Viewer, the only native Windows NT/2000 tool for analyzing a system's Security log, is rudimentary at best. Neither OS offers a way to produce a report summarizing logon activity.
• Fragmented audit trail. Each computer on the network has its own Security log, which is isolated from every other computer's Security log. If you monitor only domain-controller Security logs, you can't get a complete picture of your network's security status. Windows NT/2000 logs many of the most important security events only on workstations and member servers. For example, a common way of breaking into servers is to use local accounts, such as the Administrator account. When you try to use a local account to connect to a server, the server handles the authentication locally and doesn't contact the domain controller. Therefore, the only way to catch attacks that target local accounts is to monitor each server's Security log. Consequently, the important security activity you need to see is scattered among all your computers; you have no way to view and analyze your network's security activity as a whole.
• Cryptic event descriptions. Certain events that indicate suspicious activity have less than obvious descriptions. For example, the Audit Account Logon Events audit-policy category, which Microsoft introduced in Windows 2000, records logon attempts that fail as a result of a good user name but a bad password. Windows 2000 records the event as event ID 675, with failure code 24 in the event's details. However, the OS's description of event ID 675 is simply "Pre-Authentication Failed," which sounds misleadingly innocuous. 
• No long-term archive. Regulatory agencies and public auditors assign a high value to the ability to follow audit trails back in time. When you discover that a user is engaging in improprieties, you might need to backtrack through months of data to fully document that user's activities and build a case. Although Windows NT/2000 provides ways to purge older activity from the Security log, it offers no way to automatically move activity to a long-term archive.
• Insecure log files. Windows NT/2000 auditing can be disabled. Depending on how you configure Windows NT/2000 to handle a full Security log on your systems, attackers can produce large quantities of "noise" events to purposely fill up the Security log prior to their activity or to flush the log afterwards, thus covering up their tracks. Persons with Administrator authority or physical access can destroy event logs or selectively delete specific event records through the use of hacker tools such as WinZapper (written by Arne Vidstrom).
• Large ratio of "noise" events. Windows NT/2000 logs a large ratio of unimportant events, such as workstations polling a domain controller for Group Policy updates.

Businesses that need a secure and reliable audit and reporting solution find themselves in a situation similar to mining gold from low-grade ore. The gold is in the ore, but there is no way to efficiently extract it without using additional technology.

With a proper implementation of LANguard Security Event Log Monitor (S.E.L.M.), you can mine the gold in your network's Security logs. LANguard S.E.L.M. provides

• real-time monitoring and alerting capabilities for all Windows NT/2000 computers on the network,
• reports based on the merged activity of all computers,
• easy-to-understand event descriptions, and
• automatic archiving.
  

To ensure proper integration with the overall Windows NT/2000 environment, LANguard S.E.L.M. uses standard Windows 2000 technology such as Microsoft Message Queuing (MSMQ), Microsoft Management Console (MMC), Microsoft Windows Installer, and Open Database Connectivity (ODBC).

Implementing network-wide monitoring with LANguard S.E.L.M. requires little effort because you don't need to install software on each computer you want to monitor. The security officer installs LANguard S.E.L.M. on only one host computer, and then simply registers all the other systems to be monitored. The product's Collector Agent then uses native Win32 APIs to collect security events from the monitored computers. The Collector Agent stores these events in a Microsoft Access database or on a Microsoft SQL Server. This ODBC architecture lets security officers use standard reporting tools, such as Crystal Decisions' Crystal Reports, to create custom reports.

Next, LANguard S.E.L.M.'s Alerter Agent compares the collected events to a Categorization Rules table, and then classifies the events as low security, medium security, high security, or critical. The Alerter Agent sends SMTP notification of critical events to a security officer-configured email address (e.g., a pager) to inform security officers immediately of possible intrusion attempts. For each monitored computer, the security officer can specify event-collection frequency, identify normal operating times, and specify a computer security level of low, medium, or high. The security-level setting lets the Alerter Agent interpret as more severe any suspicious events on systems that host more sensitive information or processes, thus reducing the amount of false positives reported to the security officer.

Security officers can use LANguard S.E.L.M.'s enhanced event viewer or the LANguard S.E.L.M. Reporter to perform regular analysis of all security events. To ensure a proper balance between resource consumption and timely alerts, security officers can specify a different collection frequency for each computer. The Archiver Agent periodically moves older activity from the active database to an archive for long-term storage. LANguard S.E.L.M. uses MSMQ technology to maintain high-performance communication between its internal agents.

 

The heart of LANguard S.E.L.M.'s intelligent alert capability is the Event Categorization Rules node of the LANguard S.E.L.M. Microsoft Management Console (MMC) Configuration snap-in, which Figure 1 shows.

Figure 1.  LANguard S.E.L.M.'s MMC Configuration snap-in

LANguard S.E.L.M.'s default categorization rules are designed to help the product recognize and notify the security officer of important events but avoid disturbing the security officer with false alarms. The rules let LANguard S.E.L.M. look for telltale indicators, such as events that occur at unusual hours or on high-security computers. Lower-priority events don't trigger an immediate alert but are always available for daily or weekly analysis by the security officer. LANguard S.E.L.M. categorizes each event as low security, medium security, high security, or critical. To do so, the product analyzes the event ID (e.g., the event IDs that correlate to failed logon, account lockout, file access) and the characteristics-including OS, domain role, security level, and normal operating hours-of the computer on which the event occurred, and then applies the categorization rules to this information. Security officers can tailor LANguard S.E.L.M.'s categorization rules according to their network's specific characteristics. 

LANguard S.E.L.M. takes the OS into account because of several arcane differences in the way Windows NT and Windows 2000 log events. The product also recognizes the difference between workstations, member servers, and domain controllers, and interprets an event differently according to the computer's domain role.

Take network logons as an example of why the product must distinguish between OSs and domain roles. When someone connects to a computer from over the network (e.g., by accessing a shared folder), Windows NT logs event ID 528 with logon type 2, whereas Windows 2000 logs event ID 540. Because LANguard S.E.L.M. considers the OS, it can correctly identify the event ID, according to whether the event occurs on a Windows NT or Windows 2000 system. Network logons to domain controllers or servers are common and shouldn't be regarded as suspicious during normal working hours. However, users don't typically need to access resources on other users' workstations. Network logons to workstations should be considered suspicious because attackers that gain remote access to a workstation can impersonate the user of that workstation and employ that user's credentials to access other servers on the network. Consequently, LANguard S.E.L.M. classifies network logons to workstations as being of higher severity than network logons to domain controllers or servers.

Because Windows NT/2000 security activity is scattered among all computers in the domain, broad deployments of LANguard S.E.L.M. reap the most value. By deploying LANguard S.E.L.M. to monitor all workstations, member servers, and domain controllers in a network, the product can form a comprehensive security picture. In a broad deployment scenario, LANguard S.E.L.M.'s default categorization rules recognize specific scenarios, including:

• Failed logons
  
• Account lockouts
  
• After-hours account creation and group-membership changes
  
• After-hours logons to high-security systems
  
• Entry to user workstations through network logons
  
• Audit-policy changes
  
• Cleared Security logs
  
• Successful or failed file access (including access to specific filenames)

An event can be interpreted in a variety of ways, based on circumstances. Therefore, when LANguard S.E.L.M. categorizes an event, the product includes a description that specifically explains the categorization decision. The description also explains what the event might indicate and recommends further steps the security officer can take to confirm and respond to the situation.

By default, LANguard S.E.L.M. reports critical events through SMTP email, but security officers can choose for notification to occur at a lower event-security level. To stay on top of lower-severity events for which no notifications are sent, security officers can follow due diligent analysis recommendations.

 

LANguard S.E.L.M. relies on the security officer to select the proper security level for each monitored computer. When registering a workstation, the security officer should consider the user assigned to the workstation. The workstations of users who have access to important resources-administrators, for example-and users who conduct financial transactions should be configured as high security. Other workstations that might be classified as high security are those that are located in the computer room and those that host a critical process, such as the corporation's physical-access system. The workstations of users who have little access to critical information or processes should be configured as low security. The medium security classification can be used for the workstations of typical users who fall between these two extremes.

Given domain controllers' important security role, security officers should classify these computers as medium security or high security. Typically, computers in the demilitarized zone (DMZ-e.g., email gateways and Web servers) should be classified as high security, as should servers that host human resources, financial, or resource and development data. Application and database servers usually host important information or processes and should typically be classified as medium security or high security. Low- and medium-security levels should be used for file servers that host general departmental information. Companies that have an existing information security-classification system can use that system to identify user workstations and servers that are involved with confidential data.

 

The frequency at which LANguard S.E.L.M. collects events from each monitored computer has an impact on the computers' CPU utilization and on the network's overall bandwidth. Obviously, the higher a computer's security level, the more frequently the computer will be queried, but the computer's role also affects collection frequency. A high-security workstation, for example, is usually less important than a high-security server. Table 1 shows recommended collection frequencies according to a system's domain role and security level. Given the number of workstations in most corporate environments, querying workstations less often will result in the greatest network-bandwidth savings.

Technically, a well-automated attack on a poorly configured system could let an intruder gain Administrator authority on the computer and clear the log before LANguard S.E.L.M.'s next collection. However, Windows NT/2000 faithfully records a specific event whenever the log is cleared-even when auditing has been disabled-and by default LANguard S.E.L.M. classifies that event as a critical event on every system. Therefore, make it a policy never to clear a Security log manually on computers monitored by LANguard S.E.L.M.. (This policy is best practice in any case because it ensures that events are never lost and preserves accountability among administrators.)  By default, LANguard S.E.L.M. automatically clears the Security log each time the program collects events, so manually clearing the log is never necessary.

Windows NT/2000 requires a configured maximum log size for each computer. When the log reaches this preset limit, the OS stops logging activity. Thus, if the log fills up between LANguard S.E.L.M.'s collections, important activity could be lost. Security officers should configure each system's maximum Security-log size according to LANguard S.E.L.M.'s collection frequency for that computer and the amount of activity on the computer. For systems with a high LANguard S.E.L.M. collection frequency, even an unreasonably small log won't have an opportunity to fill up. However, given today's available disk sizes, there is little point in setting a small log size. Security officers can remove any uncertainty simply by using a standard Windows NT/2000 event-log size of between 5MB and 10MB. In an Active Directory (AD) environment, security officers can easily use a Group Policy Object (GPO), linked to the domain root, to configure Windows 2000 computers with a standard log size. Security officers must manually configure Windows NT computers as well as Windows 2000 computers that aren't managed by AD.

Windows NT/2000 can be configured to crash when the Security log fills up. For extremely critical high-security computers or to meet legal auditing requirements (e.g., on systems that control wire transfers), this setting might be necessary. However, to minimize the possibility of such a crash, security officers should set such a large log size and short LANguard S.E.L.M. collection interval so as to guarantee that the computer can't process enough activity to fill the log before the next LANguard S.E.L.M. collection.

 

Windows NT/2000 file auditing lets security officers enable auditing on selected files for specific types of access. Windows NT/2000 file auditing is most useful for monitoring how users are accessing documents such as Microsoft Excel and Microsoft Word files. However, this type of auditing can also be used to monitor for such things as changes to folders that contain executables or unauthorized attempts to access database files. Security officers can audit failed or successful attempts to open a given file or folder for read, write, delete, and other types of access. (To monitor changes to an object, enable auditing for successful writes. To monitor users who try to read files they aren't authorized to read, enable auditing for failed reads.) Note that Windows NT/2000 logs potential, not definite, changes: Object audit events are trapped at the time an application opens the object for the requested types of access. For example, a user might open a Word document for read and write access but simply close the document without making any changes. In that case, Windows NT/2000 will log an open event (event ID 560) and a close event (event ID 562) to show that the user opened the object for write access.

As you would expect, LANguard S.E.L.M. includes categorization rules for all object events. But LANguard S.E.L.M. also provides the capability to promote object-access events that are connected with important (as specified by the security officer) files or directories. This ability lets a security officer enable auditing for as many files and folders as he or she wishes, but at the same time configure LANguard S.E.L.M. to pay special attention to crucial files and folders. The security officer simply configures auditing for all desired objects, then configures LANguard S.E.L.M. to promote to critical status all events that are connected with specified file or folder names.

Windows NT/2000 does a good job of recording successful and failed access to objects, but object auditing is the most laborious type of auditing to analyze because of the volume of information that it typically produces. To detect important file-level activity without spending hours perusing Security logs, security officers should combine LANguard S.E.L.M. with a well thought-out object-auditing configuration. When configuring object auditing, a security officer must consider three vectors:

• Which objects to audit
  
• Which subjects (i.e., users or groups) to track for each object
  
• Which types of access to audit for each subject

When deciding which objects to audit, security officers should remember that LANguard S.E.L.M. can be configured to pay special attention to a subset of those objects. Therefore, the primary consideration is conservation of system resources. The more objects audited, the more CPU time, network bandwidth, and disk space consumed.

When deciding which users or groups to track for a given object, the best choice is usually the Everyone group. Limiting the subjects might expose a company to claims of unfairness or targeting if the Security log is ever used as part of a personnel action. Using groups other than Everyone as subjects is risky because important access events can be missed if someone is accidentally granted object access.

Deciding which types of access to audit deserves extra consideration. First, this vector is an important throttle for controlling how much "noise" is logged. Generally, any type of successful read access should be ignored; otherwise the log will quickly become saturated with innocuous events. Successful write attempts are useful when you need to know who might have changed an object or need to detect suspicious changes to objects (e.g., HTML, image, or Active Server Pages-ASP-files on a Web server) that should be updated only under controlled circumstances. Auditing failed read or write attempts can identify unauthorized users who tried to open an object but were successfully prevented by the object's access control list (ACL).

The one situation in which limiting auditing to a specific group (rather than the Everyone group) is useful is when the security officer wants to be alerted when an object's ACL fails to prevent an inappropriate user from accessing an object in a certain way. For example, a financial services company might have both an investment banking and a brokerage practice. To prevent insider trading, the brokers should never be able to access the investment bankers' Access database. To implement a failsafe, the security officer can configure Windows NT/2000 to audit successful read attempts by the Brokers group on the investment-banking database. That way, even if the database's ACL is accidentally weakened or a broker is accidentally added to the Investment Bankers group, Windows NT/2000 will detect the broker when he or she accesses the database. If the security officer has configured LANguard S.E.L.M. to promote events connected with the filename of the investment-banking database, the security officer will be notified as soon as the access occurs.

This example demonstrates the importance of properly limiting the users, groups, and types of access that you configure Windows NT/2000 to audit. You can configure LANguard S.E.L.M. to monitor only specific objects, but the types of access (e.g., failed read, successful read, failed write, successful write) that the product tracks are dependent on the types of access you configure in Windows NT/2000. Therefore, you should try to configure only the necessary types of Windows NT/2000 auditing, depending on which types of access you want LANguard S.E.L.M. to consider critical. For example, suppose you want to monitor a file payroll.xls for failed reads. If you turn on Windows NT/2000 auditing for all types of access, then configure LANguard S.E.L.M. to monitor for payroll.xls events, LANguard S.E.L.M. will alert you not only when someone accesses the file for a failed read, but every time anyone accesses the payroll.xls in any way. To prevent this overload of alerts, you need to enable Windows NT/2000 auditing for failed reads only.

 

One of the problems inherent in the Windows NT/2000 Security log is a lack of administrator accountability. Although Windows NT/2000 records Administrator activity (e.g., account maintenance, privilege use), the Security log is always vulnerable to an administrator who decides to clear the log, disable auditing, or shut down the system and tamper directly with the log file by booting a DOS 3.5" disk.

A secure installation of LANguard S.E.L.M. can address those problems and enforce accountability. LANguard S.E.L.M.'s default configuration provides prebuilt administrator activity reports and recognizes log clearing and audit-policy changes as critical events. Because LANguard S.E.L.M. frequently collects events from high-security computers to a physically separate database, securing the product installation simply means physically securing the computer that hosts the LANguard S.E.L.M. database. The computer should also be hardened against network attack, according to the recommendations in documents such as the National Security Agency's (NSA's) Security Recommendation Guides for Windows NT/2000 (available for free at www.nsa.gov).