Auditing Windows Server

Continuously auditing the activity in your network is one of the most critical security best practice, since it helps you notice

potentially malicious activity early enough to take action and prevent data breaches, system downtime and compliance failures.

Event Logs and Event Log Forwarding

Event logs record the activity on a particular computer. When you configure auditing properly, almost all events that have security significance are logged. This makes event logs the first thing to look at during IT security investigations. Here are two important tips:

• Configure the event log size to the maximum (4GB) to minimize the chance that events will be overwritten because the log becomes full.
• Archive your event logs, so if you do detect an attack, you can look at older event logs to find out exactly when and how attackers were able to compromise the system.

Event Log Forwarding

You should also move event logs off your computers regularly, because attackers often scrub event logs to escape detection. Windows Server’s event log forwarding feature enables you to automatically forward events logs from all your computers to a designated machine (the event collector) that stores them all securely. There are two types of event subscriptions:

Source-initiated subscriptions allow you to define an event subscription on the event collector computer without defining the source computers. Then you use Group Policy to control which source computers forward events to the event collector.

Collector-initiated subscriptions allow you to create an event subscription that specifies the source computers that will forward event logs.

Auditing and Advanced Auditing

Auditing policies enable you to record a variety of activities to the Windows security log. You then can examine these auditing logs to identify issues that need further investigation. Auditing successful activities provides documentation of changes so you can troubleshoot which changes led to a failure or a breach. Logging failed attempts can spot malicious hackers or unauthorized users to access enterprise resources

Your auditing policy specifies the categories of security-related events that you want to audit. Here are the basic policy settings you can configure and what happens if you turn them on:

• Audit account logon events — Creates an event when a user or computer attempts to use a Windows Server Active Directory account to authenticate.
• Audit account management — Audits events such as the creation, deletion or modification of a user, group or computer account and the resetting of user passwords.
• Audit directory service access — Audits events that are specified in the system access control list, such as permissions.
• Audit logon events — Creates an event when a user logs on to a computer interactively (locally) or over the network (remotely).
• Audit object access — Audits access to objects such as files, folders, registry keys and printers that have their own SACLs.
• Audit policy change — Audits changes to user rights assignment policies, audit policies and trust policies.
• Audit privilege use — Audits attempts to use permissions or user rights. You can choose whether to audit successful attempts, failed attempts or both.
• Audit process tracking — Audits process-related events, such as process creation, process termination, handle duplication and indirect object access.
• Audit system events — Audits system restarts and shutdowns, and changes that affect the system or security logs.

Advanced Audit Policy

Since Windows Server 2008 R2, administrators can audit more specific events using advanced audit policy settings in the following categories:

• Account Logon — These settings control auditing of the validation of credentials and other Kerberos-specific authentication and ticket operation events.
• Account Management — These policy settings are related to the modification of user accounts, computer accounts, group membership changes, and the logging of password change events.
• Detailed Tracking — These settings control the auditing of encryption events, Windows process creation and termination events, and remote procedure call (RPC) events
• DS Access — These policy settings determine whether to track access to AD, AD changes and replication.
• Logon/Logoff — This group of settings control auditing of standard logon and logoff events.
• Object Access — These settings cover access to AD, the registry, applications and file storage.
• Policy Change — These settings control tracking of changes to policy settings.
• Privilege Use — These settings determine whether to audit privilege use attempts within the Windows environment.
• System. These settings are used to audit changes to the state of the security subsystem.
• Global Object Access Auditing. These settings are for controlling the SACL settings for all objects on one or more computers.

Audit Collection Services

Windows Server provides a tool for pulling security logs from servers running Windows Server to a centralized location in order to simplify security auditing and log analysis — Audit Collection Services (ACS). ACS is an agent-based utility that aggregates the logs into a Microsoft SQL Server database.

By default, when an audit policy is implemented on a Windows-based computer, that computer automatically saves all events generated by the audit policy to its local security log. Using ACS, organizations can consolidate all those individual security logs into a centrally managed database, and then filter and analyze the events using the data analysis and reporting tools in Microsoft SQL Server.

Windows PowerShell Logging

Administrators can use Windows PowerShell to enable or disable logging at the Windows PowerShell module level. By default, all logging in Windows PowerShell is disabled. You can enable it by setting the “LogPipelineExecutionDetails” property to “$true”; to disable it again, set the property back to “$false”.

Windows PowerShell also offers a detailed script tracing feature that makes it possible to enable detailed tracking and analysis of the use of Windows PowerShell scripting on a system. If you enable detailed script tracing, Windows PowerShell logs all script blocks to the Event Tracing for Windows (ETW) event log in the “Microsoft-Windows-PowerShell/Operational” path.