Detections
Analytics

1.1.1.2.2.5 Set 'Audit account management' to 'Success, Failure'

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

This policy setting determines whether to audit each account management event 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. Organizations need to be able to determine who creates, modifies, or deletes both domain and local accounts. Unauthorized changes could indicate mistaken changes made by an administrator who does not understand how to follow organizational policies, but could also indicate a deliberate attack. The following table includes the important security events that this policy setting records in the Security log. These event IDs can be useful when you want to create custom alerts to monitor any software suite, such as MOM. Most operational management software can be customized with scripts to capture or flag events that are based on these event IDs. Table 4.4 Account Management Events Event ID Event description 624 A user account was created. 627 A user password was changed. 628 A user password was set. 630 A user account was deleted. 631 A global group was created. 632 A member was added to a global group. 633 A member was removed from a global group. 634 A global group was deleted. 635 A new local group was created. 636 A member was added to a local group. 637 A member was removed from a local group. 638 A local group was deleted. 639 A local group account was changed. 641 A global group account was changed. 642 A user account was changed. 643 A domain policy was modified. 644 A user account was automatically locked. 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. Note: SECURITY_DISABLED in the formal name means that this group cannot be used to grant permissions in access checks. 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 The security descriptor of administrative group members was set. Note: Every 60 minutes on a domain controller, a background thread searches all members of administrative groups (such as domain, enterprise, and schema administrators) and applies a fixed security descriptor on them. This event is logged. 685 Name of an account was changed. If audit settings are not configured, it can be difficult or impossible to determine what occurred during a security incident. However, if audit settings are configured so that events are generated for all activities the Security log will be filled with data and hard to use. Also, you can use a large amount of data storage as well as adversely affect overall computer performance if you configure audit settings for a large number of objects. If failure auditing is used and the Audit: Shut down system immediately if unable to log security audits setting in the Security Options section of Group Policy is enabled, an attacker could generate millions of failure events such as logon failures in order to fill the Security log and force the computer to shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an attacker can overwrite part or all of their activity by generating large numbers of events so that the evidence of their intrusion is overwritten.

Solution

To implement the recommended configuration state, set the following Group Policy setting to Success, Failure.

Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\Audit account management

Impact- If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.

See Also

https://workbench.cisecurity.org/files/42

Item Details

Category: AUDIT AND ACCOUNTABILITY

References: 800-53|AU-12, CCE|CCE-3427-2

Plugin: Windows

Control ID: 7d7140a6827582f7f0886eaf157eca2a2ba75e184257283dfce5b5f4a8a6188d