Using Event Viewer to Configure the Security Log

pcbinary June 27, 2021 0 Comments



1. Audit Account Logon Events


This security setting determines whether the OS audits each time this computervalidates an account’s credentials.Account logon events are generated whenever a computer validates thecredentials of an account for which it is authoritative. Domain members andnon-domain-joined machines are authoritative for their local accounts; domaincontrollers are all authoritative for accounts in the domain. Credentialvalidation may be in support of a local login, or, in the case of an ActiveDirectory domain account on a domain controller, may be in support of a loginto another computer. Credential validation is stateless so there is nocorresponding logoff event for account login events.Audit Account Logon EventsIf this policy setting is defined, the administrator can specify whether toaudit only successes, only failures, both successes and failures or to notaudit these events at all.

2. Audit Account Management


This security setting determines whether to audit each event of accountmanagement on a computer. Examples of account management events include: * A user account or group is created, changed, or deleted. * A user account is renamed, disabled, or enabled. * A password is set or changed.If you define this policy setting, you can specify whether to audit successes,audit failures or not audit the event type at all. Success audits generate anaudit entry when any account management event succeeds. Failure auditsgenerate an audit entry when any account management event fails. To set thisvalue to No auditing, in the Properties dialog box for this policy setting,select the Define these policy settings check box and clear the Success andFailure check boxes.Audit Account Management

6. Audit Policy Change


This security setting determines whether the OS audits each instance ofattempts to change user rights assignment policy, audit policy, accountpolicy, or trust policy. The administrator can specify whether to audit onlysuccesses, only failures, both successes and failures, or to not audit theseevents at all (i.e. neither successes nor failures).If Success auditing is enabled, an audit entry is generated when an attemptedchange to user rights assignment policy, audit policy, or trust policy issuccessful.Audit Policy ChangeIf Failure auditing is enabled, an audit entry is generated when an attemptedchange to user rights assignment policy, audit policy, or trust policy isattempted by an account that is not authorized to make the requested policychange.

9. Audit System Events


This security setting determines whether the OS audits any of the followingevents: * Attempted system time change * Attempted security system startup or shutdown * Attempt to load extensible authentication components * Loss of audited events due to auditing system failure * Security log size exceeding a configurable warning threshold level.If this policy setting is defined, the administrator can specify whether toaudit only successes, only failures, both successes and failures, or to notaudit these events at all (i.e. neither successes nor failures).Audit System EventsIf Success auditing is enabled, an audit entry is generated each time the OSperforms one of these activities successfully. If Failure auditing is enabled,an audit entry is generated each time the OS attempts and fails to perform oneof these activities.

Audit Policy Categories


Each Windows system on your network has nine audit policy categories and 50policy subcategories, which you can enable or disable. (Windows NT has onlyseven categories; Windows 2003 has nine categories but no subcategories.) Lookat the Local Security Policy. You will see policy settings for only the maincategories: * Audit account logon events * Audit logon events * Audit account management * Audit directory service access * Audit object access * Audit policy change * Audit privilege use * Audit process tracking * Audit system eventsAn event in the Windows Security log has a keyword for either Audit Success orAudit Failure. When you enable an audit policy (each of which corresponds to atop-level audit category), you can enable the policy to log Success events,Failure events, or both, depending on the policy. All nine audit policiesgenerate Success events, but only some policies generate Failure events.Don’t fall for the recommendation to enable only Failure events for eachcategory. A common misconception is that a Failure-only audit policy willalert you to all suspicious events. In reality, many of the most importantevents in the Security log—events such as changes to critical user accountsand groups, account lockouts, and changes to security settings—are Successevents.To view a system’s audit policy settings, you can open the MMC Local SecurityPolicy console on the system and drill down to Security SettingsLocalPoliciesAudit Policy as shown below.When you open an audit policy, you may or may not be able to modify it,depending on whether the policy has been defined in a GPO that has beenapplied to the local system. In the example below, only Audit process trackingcan be changed. The other policies have been set by a group policy. If thecomputer is a member of an AD domain, then the computer automatically appliesappropriate GPOs from the domain. Any policy that is defined in a GPOoverrides policies that are defined in the system’s Local Security Policyobject and becomes the effective setting.Windows always displays the effective settings in the MMC Local SecurityPolicy console. (If you can modify a setting, then you know that the policyhasn’t been defined in any applicable GPOs that are defined in AD. When set byGroup Policy, a scroll icon appears next to the setting.) We recommend thatyou use the Local Security Policy console only to view a system’s auditpolicy—not to configure it.As with all security settings, the best practice is to use Group Policy tocentrally manage your audit policy. Using local settings can be risky: A grouppolicy could override the local policy settings. Microsoft warns you of thisbehavior on each policy’s Local Security Setting tab shown below.

Audit Policy Subcategories


What about subcategory settings? The big advantage of using subcategories isthe ability to limit the number of events that result from the relatedcategory, thus reducing (though not eliminating) unnecessary noise.You can control these policies in Group Policy under Advanced Audit PolicyConfiguration.You can also use Auditpol to determine which subcategories are being audited.If you are performing a baseline of a system, Auditpol gives you the abilityto see what is really happening. Take a look at an example of what you willsee when you use the auditpol /get /category:* command.But by default, subcategory settings will take effect only if the top-levelpolicy is undefined. However, you can reverse this behavior by enabling theAudit: Force audit policy subcategory settings (Windows Vista or later) tooverride audit policy category settings security option as shown below.Note that the default installation of this option is actually Not definedrather than Disabled, as the option’s Explain tab states. We stronglyrecommend that you set this option to be either Enabled or Disabled, forconsistent auditing across your enterprise. If this option is enabled and youset a policy subcategory, then no category policy will override it. Thesubcategory setting will take over on Windows systems. (Subcategories cannotbe set on earlier Windows versions, so only policy categories are effective onlegacy systems.) If this option is enabled but you haven’t specificallyconfigured any subcategory settings for a policy, those subcategories willfollow the main category policy. This complex hierarchy of setting prioritiescan yield unintended results.Don’t rely on the Local Security Policy console or GPMC alone to determinewhat is being audited. The Auditpol command will tell you exactly what’shappening. Just make sure that Group Policy has already been applied when youuse Auditpol. (Group Policy might take some time to replicate and to beapplied after a change).

Audit Account Logon Events


Microsoft should have named the Audit account logon events policy Auditauthentication events. On DCs, this policy tracks all attempts to log on witha domain user account, regardless of the attempt’s origination. On aworkstation or member server, the policy records any logon attempt that uses alocal account that is stored in the computer’s Security Account Manager (SAM).The policy has four subcategories: * Credential Validation * Kerberos Authentication Service * Kerberos Service Ticket Operations * Other Account Logon EventsWe’ll discuss this policy and its subcategories in detail in Chapter 4.

Audit Account Management


The Audit account management policy, which you can use to monitor changes touser accounts and groups, is valuable for auditing the activity ofadministrators and Help desk staff. This policy logs password resets, newlycreated accounts, and changes to group membership; one of the AccountManagement category’s subcategories, Other Account Management Events, logschanges to lockout and password policy. On DCs, the policy logs changes todomain users, domain groups, and computer accounts. On member servers, thepolicy logs changes to local users and groups.The policy has six subcategories: * User Account Management * Computer Account Management * Security Group Management * Distribution Group Management * Application Group Management * Other Account Management EventsWe’ll discuss this policy and its subcategories in detail in Chapter 8.

Audit Privilege Use


The Audit privilege use policy tracks the exercise of user rights. Microsoftuses the terms privilege, right, and permission inconsistently. In thispolicy’s case, privilege refers to the user rights that you find in the LocalSecurity Policy (under Security SettingsLocal PoliciesUser RightAssignment). This policy generates a lot of noise; we usually recommend thatyou leave it disabled.The policy has three subcategories: * Sensitive Privilege Use * Non Sensitive Privilege Use * Other Privilege Use EventsWe’ll discuss this policy and its subcategories in detail in Chapter 10.

Audit System Events


The Audit system events policy logs several miscellaneous security events. Thepolicy has five subcategories: * Security State Change * Security System Extension * Security Integrity Events * IPsec Driver Events * Other System EventsWe’ll discuss this policy and its subcategories in detail in Chapter 12.

Using Event Viewer to Configure the Security Log


Aside from using Event Viewer to view security events, you use it to configurethe maximum size of the Security log. Right-click Security in the left pane,then select Properties to open the Log Properties dialog box shown below.Windows will not grow the log beyond the size you specify. Nowadays you canset log sizes very large – even in gigabytes.No matter which maximum size you configure, the log will eventually reach it.You can configure Windows to do one of three things at that point. Don’tchoose the Do not overwrite events (Clear logs manually)option; if you do,Windows will just stop logging events when the log reaches its maximum size.(Although you can use the CrashOnAuditFail option to configure Windows tocrash when logging stops, we don’t recommend this approach for most commercialscenarios. See http://support.microsoft.com/kb/823659 for details aboutCrashOnAuditFail.) The Archive the log when full, do not overwrite eventsoption is also useful, perhaps for a small group of servers, but you will needto attend to it periodically so that the logs don’t fill the storage locationto capacity. However, this feature is no substitute for a full log-managementsolution that moves logs to separate and secured archive.That leaves the Overwrite events as needed (oldest events first) option,which we select for nearly every project. (This is where log-managementapplications come into play: You’ll need one if you want to store a largequantity of events from multiple servers. You can learn about good log-management applications during the sponsor presentations in our monthlySecurity log webinars, which you can find atwww.ultimatewindowssecurity.com/securitylog.)Note that the Log Properties dialog box also displays the log file’s locationand current size, as well as various dates and times that are associated withthe log. From this dialog box, you can also clear the log. When you clear theSecurity log, Windows immediately logs event ID 1102. Although this eventfalls under the Audit system events category, Windows always logs the event,regardless of your audit policy. When you clear the log, Event Viewer givesyou the option of saving a copy first.You can use Event Viewer to dump the Security log to a file, either in theprocess of clearing the log or independently. Right-click Security in the leftpane and select Save As to choose the format in which to save the log. If youspecify event file (EVTX) format, Event Viewer will save a copy of the log inthe same EVTX format that the live log uses. If you use this format, you’llneed to use a tool that supports EVTX files, such as LogParser or the EventViewer itself. You can also specify comma-separate value (CSV) or tab-delimited (TXT) format.Note that when you save the Security log, Windows requires you to save it to alocal volume of the server. You can subsequently copy the file elsewhere onthe network, but the dump application programming interface API that EventViewer uses can save the log only to a local volume. By default, Event Viewerstores the Security log as %systemroot%System32WinevtLogsSecurity.evtx,but you can change the location by editing the registry. Microsoft usuallywarns against editing the registry and encourages you to back up the systemfirst. That being said, here’s the procedure: 1. Open a registry editor 2. Navigate to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventlogSecurity subkey 3. Set the File value to any path name on the local system. (The File value is data type REG_EXPAND_SZ, so you can include environment variables in the path name.)Why would you want to change the location of the log file? Perhaps you want tooffload the file I/O that is associated with the Security log to a differentvolume.Event Viewer occasionally will report that the Security log is corrupt andwill refuse to display it. Usually, all you need to do to make the problem goaway is close and re-open Event Viewer.

Security Log Integrity


The Security log is fairly secure. To erase events or otherwise tamper withthe Security log or audit policy, you need physical access to the targetsystem, Administrator authority to that system, or Write access to a GPO thatapplies to that system.Larger IT departments should implement separation of duty between operationsand security-monitoring staff. To protect the integrity of Security logs fromrogue administrators, you must export events from the Security log, asfrequently as possible, to a separate server that is both physically andlogically out of reach of the local server’s administrator and otheroperations staff. Security-monitoring staff then can monitor the securityactivity that the servers report and can review the activity of operationsstaff, as needed.

Leave a Reply

Your email address will not be published. Required fields are marked *