Configuring Audit Policies

Configuring Audit Policies

Windows NT 4.0, Windows 2000, and Windows XP provide several categories of auditing for security events. When designing your enterprise audit strategy, you will need to decide whether to include success and failure events for the following categories of security audit events:

• Account logon events

• Account management events

• Directory service access

• Logon events

• Object access

• Policy change

• Privilege use

• Process tracking

• System events

You can see the current status of auditing for each area by looking in the Local Security Policy Microsoft Management Console (MMC) in Windows 2000 or Windows XP or in the User Manager in Windows NT 4.0. Figure 12-2 shows how the audit policy settings are displayed in Windows 2000.

Figure 12-2. Viewing audit policy settings in the Local Security Policy MMC in Windows 2000

Auditing Account Logon Events

When a user logs on to a domain, the logon is processed at a domain controller. When you audit account logon events on all domain controllers, domain logon attempts will be recorded on the domain controller that validates the account. Account logon events are created when an authentication package validates successfully or not a user s or computer s credentials. When domain credentials are used, account logon events are generated only in domain controllers event logs. If the credentials presented are local computer credentials, the account logon events are created in the server s or workstation s local security event log.

Because an account logon event can be recorded at any valid domain controller in the domain, you must ensure that you consolidate the security log across domain controllers to analyze all account logon events in the domain.

If you define this policy setting, you can specify whether to audit successes or audit failures. Success audits generate an audit entry when an account logon attempt succeeds. Failure audits generate an audit entry when an account logon attempt fails.

Auditing successful account logon events will provide you with a record of users and computers successful logons to a domain or local computer. By auditing failed account logon attempts, you might be able to detect attempts to attack the network by compromising an account. For example, you might notice that hundreds or thousands of failed logon attempts for a given user account within the span of a few seconds. This can be a sign of a brute force attack on the user account s password.

By examining successful and failed logon attempts, you not only can determine the account or the security identifier (SID) of the account whose logon succeeded or failed, you also can detect the following information:

• Name of the computer on which the logon attempt originated. Attackers often use unprintable characters those from the extended character set in their computer names to mask their identity from the Event Viewer.

• Domain or computer name for the account being used from a workgroup computer attempting an attack.

• Type of logon attempt, which can be one of the following:

  Logon Type	Name	Description
  2	Interactive	Includes both logons from terminal service users and users who are physically at the computer
  3	Network	Generally for file and print access
  4	Batch	Initiated by a process with batch logon rights
  5	Service	Initiated by services using the logon as a service right
  6	Proxy	Has never been implemented by any version of Windows
  7	Unlock Workstation Logon	Recorded when the console of a computer is unlocked
  8	NetworkCleartext	Reserved for cleartext logons over the network
  9	NewCredentials	Initiated by using the Runas command with the /netonly switch
  10	RemoteInteractive	Recorded for Terminal Services logons
  11	CachedInteractive	Recorded when cached credentials are used to log on locally to a computer

• The process that originated the logon, which can be one of the following:

  • Advapi For API calls to LogonUser

  • Microsoft Internet Information Services (IIS) For logons using the Anonymous account or logon attempts using basic or digest authentication

  • LAN Manager Workstation Service For logon attempts using the LAN Manager (LM) protocol

  • Kerberos For calls from the Kerberos Security Support Provider (SSP)

  • KSecDD For network connections

  • MS.RActive DirectoryIU For logon attempts from the Microsoft Internet Authentication Service (IAS)

  • NT LAN Manager (NTLM) or NTLM Security Support Provider (NtLmSsp) For logon attempts using the NTLM protocol

  • Service Control Manager (SCMgr) For service logon attempts

  • Seclogon For logon attempts using the Runas command

  • User32 or WinLogon\MSGina For interactive logon attempts

• The authentication package used for the logon attempt, which can be one of the following:

  • Kerberos

  • Negotiate

  • NTLM

  • Microsoft_Authentication_Package_v10

Always audit both account logon success events and account logon failure events. Success events are critical in building a baseline of user behavior and can be important information in a security investigation. Failure events can be a sign of an attacker attempting to penetrate the network. By proactively monitoring failure events, you might prevent attacks in which the attacker does significant damage to the network. Table 12-1 describes common account logon events.

Table 12-1. Common Account Logon Events

Event ID	Description
672	An Authentication Service ticket was successfully issued and validated.
673	A Ticket Granting Service ticket was granted.
674	A security principal renewed an Authentication Service ticket or Ticket Granting Service ticket.
675	Kerberos preauthentication failed.
676	Authentication ticket request failed.
677	A Ticket Granting Service ticket was not granted.
678	An account was successfully mapped to a domain account.
679	An account failed to map to a domain account.
680	Identifies the account used for the successful logon attempt. This event also indicates the authentication package used to authenticate the account.
681	A failed domain account logon was attempted.
682	A user has reconnected to a disconnected Terminal Services session.
683	A user disconnected from a Terminal Services session without logging off. Terminal Services sessions can be left in a connected state that allows processes to continue running after the session ends. Event ID 683 indicates when a user does not log off from the Terminal Services session, and event ID 682 indicates when a connection to a previously disconnected session has occurred.

In addition, if the logon attempt should fail, an event ID 681 will be recorded. This event will also contain code that gives the reason the authentication attempt failed. This reason code will appear in a decimal value. Table 12-2 contains a list of the failure codes in both decimal and hexadecimal format, along with a description of each code.

Table 12-2. Event 681 Failure Reason Codes

Decimal Value	Hexadecimal Value	Reason
3221225572	C0000064	User logged on with a misspelled or bad user account
3221225578	C000006A	User logged on with a misspelled or bad password
3221225583	C000006F	User logged on outside authorized hours
3221225584	C0000070	User logged on from unauthorized workstation
3221225585	C0000071	User logged on with an expired password
3221225586	C0000072	User logged on to an account disabled by the administrator
3221225875	C0000193	User logged on with an expired account
3221226020	C0000224	User logged on with Change Password At Next Logon flagged
3221226036	C0000234	User logged on with the account locked

Auditing Account Management Events

Because anyone with access to an administrative account has the authority to grant other accounts increased rights and permissions and create additional accounts, auditing account management events is an essential part of any network security design and implementation. Unless sophisticated biometrics or similar high-security measures are employed, it might be difficult or even impossible to guarantee that the person using the administrative account is the user that the account was issued to. Similarly, auditing is one of the ways organizations can hold administrators accountable for their actions.

By enabling the auditing of account management events, you will be able to record events such as these:

• A user account or group is created, changed, or deleted.

• A user account is renamed, disabled, or enabled.

• A password is set or changed.

• A computer s security policy is changed.

Although changes to user rights appear as account management events on the surface, they are actually policy change events. If both audit policies are disabled, a rogue administrator might be able to subvert the security of a network without an audit trail. For example, if an administrator made the user account Sally a member of the Backup Operators group, an account management event would be recorded. However, if the same administrator directly granted Sally s account the Back Up Files And Folders advanced user right, an account management event would not be recorded. Changes to a computer s security policy are also recorded under account management auditing. Unexpected changes to security policy can be a prelude to the compromise or destruction of data. For example, an attacker might weaken the security policy on a computer to carry out a specific attack that requires a resource that has been disabled.

You should enable the auditing of both success and failure account management events. Success audits generate an audit entry when any account management event succeeds. Failure audits generate an audit entry when any account management event fails. Although successful account management events are more often than not completely innocuous, they provide an invaluable record of activities when a network has been compromised. For example, you can see which accounts were modified and created by the attacker. Account management failure events often indicate that a lower-level administrator (or an attacker who has compromised a lower-level administrator account) might be attempting to elevate his privilege. For example, you might see an account used for the backup service try to grant itself or another account Domain Administrator group membership. Hence, monitoring account management failures is critical. Table 12-3 contains descriptions of common account management events.

Table 12-3. Common Account Management Events

Event ID	Description
624	A user account was created.
627	A Password Change Attempted; this event records both successful and failed attempts.
632	A security-enabled global group member was added.
633	A security-enabled global group member was removed.
634	A security-enabled global group was deleted.
635	A security-disabled local group was created.
636	A security-enabled local group member was added.
637	A security-enabled local group member was removed.
638	A security-enabled local group was deleted.
639	A security-enabled local group was changed.
641	A security-enabled global group was changed.
642	A user account was changed.
643	A domain policy was changed.
644	A user account was locked out; when an account is locked out, two events will be logged at the primary domain controller (PDC) emulator operations master. A 644 event will occur, indicating that the account name was locked out. Then a 642 event will be recorded, indicating that the user account is now locked out. This event is logged only at the PDC emulator.
645	A computer account was created.
646	A computer account was changed.
647	A computer account was deleted.
648	A local security group with security disabled was created.
649	A local security group with security disabled was changed.
650	A member was added to a security-disabled local security group.
651	A member was removed from a security-disabled local security group.
652	A security-disabled local group was deleted.
653	A security-disabled global group was created.
654	A security-disabled global group was changed.
655	A member was added to a security-disabled global group.
656	A member was removed from a security-disabled global group.
657	A security-disabled global group was deleted.
658	A security-enabled universal group was created.
659	A security-enabled universal group was changed.
660	A member was added to a security-enabled universal group.
661	A member was removed from a security-enabled universal group.
662	A security-enabled universal group was deleted.
663	A security-disabled universal group was created.
664	A security-disabled universal group was changed.
665	A member was added to a security-disabled universal group.
666	A member was removed from a security-disabled universal group.
667	A security-disabled universal group was deleted.
668	A group type was changed.
684	Set the security descriptor of members of administrative groups.
685	A name of an account was changed.

Auditing Directory Service Access

You can audit changes to the Active Directory directory service by enabling directory service auditing. Although enabling auditing of account management events will record changes to user, computer, and group objects, you might need to track changes to other objects or attributes in Active Directory. For example, you might want to record changes to Active Directory infrastructure components, such as site objects, or changes to the Active Directory schema. Another common set of objects to audit in Active Directory are the enterprise Certification Authority (CA) objects stored in the configuration container when you install a Windows 2000 enterprise public-key infrastructure (PKI).

To audit successful or failed changes to Active Directory objects or attributes, you not only must enable directory services auditing on all domain controllers, but you must also configure the system access control list (SACL) for each object or attribute you want to audit. In addition to recording changes to Active Directory objects and attributes, directory service auditing also records Active Directory events such as replication. Consequently, enabling directory service auditing for successful events will greatly increase the number of events recorded in the security event log. Besides resulting in an increase in log file size, this will also make it more difficult to locate meaningful events without the assistance of sophisticated tools to parse the security event log.

If you define this policy setting, you can specify whether to audit successes or failures. Success audits generate an audit entry when a user successfully accesses an Active Directory object that has a SACL specified. Failure audits generate an audit entry when a user unsuccessfully attempts to access an Active Directory object that has a SACL specified.

Because Active Directory is a multiple master database, meaning that changes can be written on any domain controller, you must ensure that you enable directory service auditing on all domain controllers. The best way to ensure this is to create an audit policy Group Policy object (GPO) at the domain level.

All directory service events, both successful and failed, will have the event ID 565 in the security event log. You will have to examine the details of each 565 event to see if it was successfully or not successfully completed.

Auditing Logon Events

By enabling the auditing of logon events, you can track every time a user logs on or logs off a computer. The event will be recorded in the security event log of the computer where the logon attempt occurs. Similarly, when a user or computer connects to a remote computer, a logon event is generated in the security event log of the remote computer for the network logon. Logon events are created when the logon session and token are created or destroyed.

Because Terminal Services logons are treated as interactive logons, creating a terminal server session remotely will cause a logon event to be recorded. If you enable logon events on a computer running Terminal Services, you will need to differentiate between console logons and Terminal Services logons.

Logon events audit logon attempts from users as well as those from computers. You will see separate security event log entries for both the computer account and the user account if a network connection is attempted from a Windows NT, Windows 2000, or Windows XP computer.

Only the user account logon event is recorded when a user logs on to the domain from a Microsoft Windows 95 or Microsoft Windows 98 computer. Windows 95 and Windows 98 computers do not have computer accounts in the directory and consequently do not generate computer logon event entries for network logon events.

Logon events can be useful for tracking attempts to log on interactively at servers or to investigate attacks launched from a particular computer. Success audits generate an audit entry when a logon attempt succeeds. Failure audits generate an audit entry when a logon attempt fails.

A subtle but very important difference between auditing account logon events and logon events exists. Account logon events are recorded on the computer that authenticates the account, whereas logon events are created where the account is used. For example, if a user uses her domain account to log on to the network on a computer that is part of the domain, an account logon event will be recorded on the domain controller that performed the authentication of the account and a logon event will be recorded on the computer the user used to log on to the network.

On domain controllers that have logon events audited, only interactive and network logon attempts to the domain controller itself generate logon events computer logon attempts are not audited. Success audits generate an audit entry when a logon attempt succeeds. Failure audits generate an audit entry when a logon attempt fails.

You should always enable both successful and failed logon attempts. Successful logon attempts will provide a baseline record of a user s logon behavior that can be useful in identifying suspicious behavior. Similarly, a record of successful logon events is essential evidence in any computer investigation. By tracking failed logon events, your organization might be able to prevent network attacks or further damage to a network by proactively responding to suspicious behavior. For example, suppose that in a weekly review of a server s audit logs you notice many failed logon attempts with various user accounts. Upon further investigation, you notice that even though the server is located in a physically secure area, the logon attempts have been made at the console of the server. In this situation, you can respond proactively to the suspicious behavior, prevent damage to information, and start an investigation into the possible compromise of physical security. Table 12-4 contains descriptions of common logon events.

Table 12-4. Common Logon Events

Event ID	Description
528	A user successfully logged on to a computer.
529	The logon attempt was made with an unknown user name or a known user name with a bad password.
530	The user account tried to log on outside the allowed time.
531	A logon attempt was made by using a disabled account.
532	A logon attempt was made by using an expired account.
533	The user is not allowed to log on at this computer.
534	The user attempted to log on with a logon type that is not allowed, such as network, interactive, batch, service, or remote interactive.
535	The password for the specified account has expired.
536	The Netlogon service is not active.
537	The logon attempt failed for other reasons.
538	A user logged off.
539	The account was locked out at the time the logon attempt was made. This event is logged when a user or computer attempts to authenticate with an account that has been previously locked out.
540	Network logon succeeded.
682	A user has reconnected to a disconnected Terminal Services session.
683	A user disconnected a Terminal Services session without logging off.

Auditing Object Access

When you enable object auditing, called File And Object Auditing in Windows NT, you can track successful and failed attempts at accessing file, print, and registry resources. As with directory services auditing, when you enable object auditing, you will also need to configure the SACL for each resource you want to audit. Figure 12-3 displays where auditing is enabled on a file in Windows XP.

A SACL is comprised of access control entries (ACEs). Each ACE contains three pieces of information:

• The security principal (user, computer, or group) to be audited

• The specific access type to be audited, called an access mask

• A flag to indicate whether to audit failed access events, successful access events, or both

If your organization has clear business reasons for recording access attempts on files, registry keys, or printers, you should enable object auditing and create the appropriate SACL on the resource. When configuring file auditing, you should decide in advance what types of actions on a file you want to track. For example, opening a text file, changing one line, and saving the file will create more than 30 events in the security event log in Windows XP when all actions are logged. (This occurs when you select to audit Full Control on a file.)

Figure 12-3. Configuring auditing on a file in Windows XP

Exercise caution when auditing Read & Execute permissions on executable files because this type of auditing will cause a large amount of events to be logged. Antivirus software will cause thousands of object access events each time the system is scanned if Full Control auditing is enabled.

You should define only the actions you want enabled when configuring SACLs. For example, you might want to enable Write and Append Data auditing on executable files to track the replacement or changes to those files, which computer viruses, worms, and Trojan horses commonly do. Similarly, you might want to track changes or even the reading of sensitive documents.

Before implementing the auditing of files, registry keys, and printers, you should ensure auditing the resource does not impact the performance of the server and the resource in such a way that it disrupts business processes.

By enabling the auditing of object access, you can record the successful and failed attempts at accessing files, folders, registry keys, and printers. Success audits generate an audit entry when a user successfully accesses an object that has a SACL specified. Failure audits generate an audit entry when a user unsuccessfully attempts to access an object that has a SACL specified. Table 12-5 contains descriptions of common object access events.

Table 12-5. Common Object Access Events

Event ID	Description
560	Access was granted to an already existing object.
561	A handle to an object was allocated.
562	A handle to an object was closed.
563	An attempt was made to open an object with the intent to delete it.
564	A protected object was deleted.
565	Access was granted to an already existing object type.

Auditing Policy Change

Auditing policy changes will enable you to track changes in three areas:

• User rights assignment

• Audit policies

• Domain trust relationships

Although the name audit policy change implies that this event records the security policy of computers, this event is recorded when account management auditing is enabled with event ID 643. Changes to the assignment of user rights are recorded when policy changes are audited. An attacker can elevate her own privileges or those of another account for example, by adding the Debug privilege or the Back Up Files And Folders privilege. Policy change auditing also includes making changes to the audit policy itself as well as changes to trust relationships.

You should enable the auditing of both successful and failed policy changes to track the granting and removal of user rights and changes to the audit policy. Successful and failed attempts generate an audit entry when an attempt to change to security policies, user rights assignment policies, audit policies, or trust policies is successful. Table 12-6 contains descriptions of common policy change events.

Table 12-6. Common Policy Change Events

Event ID	Description
608	A user right was assigned.
609	A user right was removed.
610	A trust relationship with another domain was created.
611	A trust relationship with another domain was removed.
612	An audit policy was changed.
671	Security policy was changed or refreshed. ( -- in the Changes Made field means that no changes were made during the refresh.)
768	A collision was detected between a namespace element in one forest and a namespace element in another forest.

Auditing Privilege Use

By enabling privilege use auditing, which is called Use Of User Rights in Windows NT 4.0, you can record when user and service accounts use one of the user rights to carry out a procedure, with the exception of a few user rights that are not audited. These rights are the exceptions:

• Bypass Traverse Checking

• Debug Programs

• Create A Token Object

• Replace Process Level Token

• Generate Security Audits

• Back Up Files And Directories

• Restore Files And Directories

Windows 2000 and Windows XP have a Group Policy setting under Security Options named Audit Use Of Backup And Restore Privilege, which enables you to audit the use of the Back Up And Restore Files And Folders privilege.

Privilege use auditing will detect events associated with many common attacks. These types of events include the following:

• Shutting down a local or remote system

• Loading and unloading device drivers

• Viewing the security event log

• Taking ownership of objects

• Acting as part of the OS

  In Windows NT 4.0, only the local use of the Take Ownership right is audited. If you need to enable the use of the Take Ownership right for remote objects, you will need to enable object auditing on the remote computers. Windows 2000 and Windows XP do this automatically.

You should enable the logging of failed privilege use events at a minimum. Failed use of a user right is an indicator of a general network problem and often can be a sign of an attempted security breach. You should enable the success use of privileges if you have a specific business reason do so. Success audits generate an audit entry when exercising a user right succeeds. Failure audits generate an audit entry when exercising a user right fails. Table 12-7 describes common privilege use events.

Table 12-7. Common Privilege Use Events

Event ID	Description
576	Specified privileges were added to a user s access token. (This event is generated when the user logs on.)
577	A user attempted to perform a privileged system service operation.
578	Privileges were used on an already open handle to a protected object.

Auditing Process Tracking

Process tracking auditing enables you to have a detailed record of the execution of processes, including program activation, process exit, handle duplication, and indirect object access. Process tracking, at a minimum, will generate an event for the activation and exit of every process. Thus, by enabling the auditing of success events, a large number of events will be recorded in the security Event Viewer.

Enabling process tracking is excellent for troubleshooting applications and learning about how applications work; however, you should enable process tracking only if you have a clear business reason. You will also likely need an automated method of parsing event logs to successfully analyze log files where process tracking has been enabled. Success audits generate an audit entry when the process being tracked succeeds. Failure audits generate an audit entry when the process being tracked fails. Table 12-8 contains descriptions of common process tracking events.

Table 12-8. Common Process Tracking Events

Event ID	Description
592	A new process was created.
593	A process exited.
594	A handle to an object was duplicated.
595	Indirect access to an object was obtained.

Auditing System Events

By enabling the auditing of system events, you can track when a user or process alters aspects of the computer environment. Common system events include clearing the security event log of events, shutting down the local computer, and making changes to the authentication packages operating on the computer.

You should enable the successful auditing of system events to record system restarts. An unexpected system reboot might be an indicator that a security compromise has occurred and generally will be a sign of some sort of problem, security related or not. Success audits generate an audit entry when a system event is executed successfully. Failure audits generate an audit entry when a system event is attempted unsuccessfully.

Successful attempts at clearing the security event log are recorded regardless of whether system event auditing is enabled. Table 12-9 contains descriptions of common system events.

Table 12-9. Common System Events

Event ID	Description
512	Windows is starting up.
513	Windows is shutting down.
514	An authentication package was loaded by the Local Security Authority (LSA).
515	A trusted logon process has registered with the LSA.
516	Internal resources allocated for the queuing of security event messages have been exhausted, leading to the loss of some security event messages.
517	The security log was cleared.
518	A notification package was loaded by the Security Accounts Manager (SAM).

How to Enable Audit Policies

You can enable audit policies in Windows 2000 and Windows XP locally by using the Local Security Policy MMC or by applying security templates. You can also apply audit policies to Windows 2000 and Windows XP computers remotely by using Group Policy. The following steps explain how to enable an audit policy locally by using the Local Security Policy MMC, and Figure 12-4 shows what you will see onscreen when doing so. To enable an audit policy in Windows XP, follow these steps:

1. Open the Local Security Policy MMC.

2. Double-click Local Policies to expand it, and then double-click Audit Policy.

3. In the right pane, double-click the policy that you want to enable or disable.

4. Click the Success and Fail check boxes to designate which the audit policies you want to enable.

5. Close the MMC.

   

   Figure 12-4. Configuring the audit policy by using the Local Security Policy MMC

Table 12-10 contains the audit policies that you should enable to track security events. For object access and directory service events, you will also need to configure the SACL on the objects or on the attributes of each object that you want to track operations on.

Table 12-10. Baseline Audit Policy

Audit Policy	Events to Audit
Audit Account Logon Events	Success, Failure
Audit Account Management Events	Success, Failure
Audit Directory Service Access	Success, Failure
Audit Logon Events	Success, Failure
Audit Object Access	Success, Failure
Audit Policy Change	Success, Failure
Audit Privilege Use	Failure
Audit Process Tracking	None
Audit System Events	Success, Failure

For detailed information on configuring audit policies by using security templates and Group Policy, see Chapter 11, Configuring Security Templates.