When
Ideally daily, but at least weekly, depending on your audit policy.
Why
Taking the mystery and confusion out of understanding what's in logs will help administrators recognize what's happening on their system.
Strategy
The Security Reference Monitor (SRM) runs in the kernel and is the component that checks each object access to ensure the access is allowed in the object's DACL (Discretionary Access Control List). It initiates an audit event if that access is being audited in the object's SACL (System Access Control List.).
By default, security logging is turned off. Configure audit policy settings from the Group Policy Object Editor. If you are logging successful account logon audit events on a domain controller, be aware that workstation logon attempts do not generate logon audits. Only interactive and network logon attempts to the domain controller itself generate logon events. In sum, account logon events are generated where the account lives; logon events are generated where the logon attempt occurs. Note that if your administrator has set domain-level auditing policies, those policies override local settings.
The event log service starts automatically when you start Windows. All users can view application and system logs. Only administrators can access security logs. The administrator can also set auditing policies in the registry that cause the system to halt when the security log is full. Auditing directory and file accesses can only be enabled for those on NTFS volumes; FAT-formatted volumes lack auditing attributes.
A computer running any version of Windows records events in three kinds of logs: application, security and system. A computer running Windows configured as a domain controller records events in two more logs: directory service and file replication service. A computer configured as a Domain Name System (DNS) server also records events in the DNS server log.
The types of events you can log include: user and process logon and logoff; access to data or devices associated with the system; use of access rights by users and processes; changes to user accounts and groups; changes of access rights to system data and resources; shutdown or restart of the system, registration of trusted logon processes, or other activities affecting system security; execution of processes and tracking; and policy changes.
The event viewer displays five types of events: error, warning, information, success audit, and failure audit. The options for the auditing settings are: success, failure, and no auditing. An event contains the following fields: date, time, user, computer, event ID (a number), source (the software that logged the event, which can be either a program name such as "SQL Server," or a component, like a driver), type (event severity classification: error, information, or warning in the system and application logs; success audit or failure audit in the security log, represented by a symbol.), and category (used primarily in the security log). You can filter and search, but you have to know the keywords the viewer uses to be able to do so.
To see the logs: From the start menu, go to programs, administrative tools, event viewer, log, security. You'll see rows of records giving you general info.
More information
Microsoft provides a list of the most common event IDs for Windows 2000. Because the event IDs aren't vague enough, to add further confusion, note that the same numbered event IDs for the end user computer, the domain controller, and the file server are all different, i.e., 528 in the end user log is not the same event in the domain controller log. The Threats and Countermeasures Guide provides a reference to some security settings available in Windows. It's a companion guide for The Windows Server 2003 Security Guide and the Windows XP Security Guide. If anyone knows where there is a definitive list of event IDs, let me know.
About the author
Shelley Bard, CISSP, CISM, is a senior security network engineer with Verizon Federal Network Systems (FNS). An information security professional for 17 years, Bard has briefed and written infosecurity assessments and technical reports for the White House and Department of Defense, special interest groups, industry and academia. Please e-mail any comments to securityplanner@infosecuritymag.com.
Note: Opinions expressed in this column are those of Shelley Bard and don't necessarily reflect those of Verizon FNS.
