Viewing Effective Security Settings
In the console from which group policy settings are managed, double-click the Group Policy object.
In the console tree, click Security Settings. Expand the following items:
Computer Configuration
Windows Settings
Security Settings
Double-click a security policy node (such as Account Policies), and then click a security area (such as Password Policy).
Double-click the security attribute that is to be viewed (such as Minimum Password Length). Note that security settings reflect both local policy and the policy in effect on the system. These may not be the same if the computer is inheriting group policy settings.
Security-Relevant Events
This subsection describes all types of security-relevant events and what administrator action (if any) to take in order to maintain security. Security-relevant events that may occur during operation of Windows 2000 must be adequately defined to allow administrator intervention to maintain secure operation. Security-relevant events are defined as events that signify a security related change in the system or environment. These changes can be grouped as routine or abnormal. The routine events are already addressed in subsection "Security Functions". For example a new person joins the organization, the administrator would setup a new account. Abnormal events are those that do not occur on regular basis or are a result of limits being reached as set by the Administrator. The security relevant events are based on the security functions.
Audit trail overflow
Description of event: The audit log has reached its maximum capacity due to (1) reaching the pre-defined maximum log size, or (2) running out of disk space.
Security Impact: Audit information cannot be recorded in the Security log. As a result, important audit information may be irretrievably lost.
Required Activities:
Archive the audit log.
Clear the audit log.
Re-examine the maximum log size requirements to ensure it is appropriate for current operations and make the necessary corrections.
Review audit requirements to ensure only relevant audit information is collected.
Review and make necessary adjustments to audit maintenance procedures to ensure the frequency of audit archives is sufficient to meet requirements without the need for system downtime or loss of audit data.
Depending on mission impact, consider setting the registry to halt the system when the audit log gets full. This will prevent further activities on the system without the benefit of being audited, however it can impact operations if audit maintenance is not followed on a regular basis.
Examine disk space requirements and make necessary adjustments by extending the disk volume, relocating the log file to a larger disk or partition, or replacing the disk drive with one of larger capacity.
Note: Procedures for archiving event logs are provided in the "Archiving an Event Log" subsection. Procedures for relocating an event log file are provided in the "Change the default Event Viewer log file location" subsection.
Review audit trails for suspected malicious or illicit activity (use of audit archives and filtering)
Description of event: Suspicion of malicious or illicit activity by either a known user or an unknown entity.
Security Impact: The risk implications depend on the type of activity that is under suspicion, keeping in mind that further investigations may reveal the underlying intent of the activity and either elevate or reduce the expected level of risk. Suspected activities could include; attempts to guess or brute force account passwords, unauthorized or suspicious object access attempts, unusual login hours, account activity while user is not expected to be logged in, unexpected modification of files or loss of data, etc.
Required Activities:
First, consult the Security Manager.
Once the suspect account has been identified, use the event viewer filtering tool in the Security Log Properties applet to filter through the logs for all event activities captured for that account.
Note: Detailed instructions are provided in the "Audit Management" subsection (filtering the security log).
Disable the account, if warranted, based on Security Manager's recommendations.
Note: Procedures for disabling the account are provided in the "Disabling and enabling user accounts" subsection.
Review the archived audit logs for any previous activity by the suspect account.
If suspect account is unknown, but data tampering is suspected, audit the group Everyone for access to all objects or types of objects suspected of being targets of tampering. Monitor the audit logs to determine if tampering is occurring and by whom.
Note: Procedures and recommendations for auditing object access are provided in the "Enabling Object Auditing" subsection.
User account is disabled due to exceeded limit of unsuccessful login attempts
Description of event: User account has been locked due to exceeding the established number of allowable failed login attempts.
Security Impact: Locked account impedes user from accomplishing required tasks. This incident could be the result of an attempt to guess the user account's password.
Required Activities:
Consult the account owner to verify whether the account lockout was due to his/her attempts to log in.
If the user has forgotten his/her password, set a new default password that must be changed as soon as the user logs in. Unlock the account to allow the user to log in.
Note: Procedures for unlocking a user account are provided in the "Configuring Account Lockout Policies" subsection.
If the account lockout is verified to not have been the result of user (account owner) actions, it is an indication of a possible compromise attempt. Do not unlock the account until the audit logs have been reviewed to determine if there is other suspicious activity that may be related. This includes previous attempts against the same account and failed login attempts against other user account during a common period of time. Make sure to check for any successive failed login attempts followed immediately by a login success to the same account. This could indicate a success on the part of the intruder to gain user access. Check the logon event record for the logon type to determine if the attempts were local, or network based and for possible clues as to the source (Domain name, machine name, etc.). Make sure to consult and follow direction from the Security Manager throughout this entire process. Unlock the account only under Security Manager approval.
Temporary user accounts are required (such as for contractor support)
Description of event: Accounts are needed for individuals requiring access to network resources on a temporary and limited basis. These individuals may be contractors, or simply personnel from another part of the local organization who require temporary access to resources for which they are not normally authorized.
Security Impact: Potential for unauthorized access. If access requirements are not properly assessed and implemented temporary users may gain access to resources for which they are not authorized, or may continue to have access to resources beyond the required period of time.
Required Activities:
Consult resource owners to determine resource access requirements for temporary users.
Consult Security Manager to ensure temporary users have been properly cleared for access.
Create user groups for each type of temporary access required and assign the minimum privileges required for the temporary accounts to perform required tasks.
Note: Procedures to create group accounts and assign the appropriate privileges are provided in the "Creating and Maintaining User and Group Accounts" and the "Configuring User Rights" subsections.
Set permissions on resources to be accessed by group members to allow only the minimum access requirements for the temporary accounts to perform required tasks. For example; they may only need read access to certain documents, not write or delete.
Note: Procedures to set permissions on resources are provided in the "Setting Access Controls on Files, Folders, Shares, and Other System Objects in Windows 2000" subsection.
Audit the activities of the temporary account groups.
Note: Procedures to audit activities are provided in the "Local Policies" subsection (Configuring Audit Policies).
Create the temporary accounts. Set their initial password to expire on first logon, requiring the user to create a new password.
Note: Procedures to create accounts and set password options are provided in the "User Accounts" subsection.
As determined by the data owners, management, and the Security Manager, set logon time restrictions on the temporary accounts.
Note: Procedures are provided to set logon time restrictions in the "Configuring Logon Hours" subsection.
As determined by the data owners, management, and the Security Manager, set an expiration date on all temporary accounts that is adequate for the amount of time the accounts will be required.
Note: Procedures are provided to set an expiration date on accounts in the "Set an account expiration date" subsection.
Security relevant Service Pack or Hot fix updates are available
Description of event: The latest Service Pack or Hot fix addressing security concerns is made available by Microsoft.
Security Impact: The security fixes may address serious issues that should be corrected immediately, depending on how a system is being used, where it sits on the network, and the applications that it supports. On the other hand, security fixes may have an adverse impact on the applications being used and should therefore be thoroughly evaluated before being applied within operational environments.
Required Activities:
Review the security update descriptions to first determine if they are relevant and essential to current operations.
If the security updates are considered essential to current operations security, establish a process for testing the updates prior to operational implementation. This can be accomplished by testing the updates within a staging area. The staging area should consist of an isolated lab environment with sufficient resources to effectively emulate the local systems. The intent is to identify and mitigate any incompatibility associated with a proposed security update prior to its implementation, thus minimizing any risks to operations, services, users, or data within the operational network.
Once tested and verified, apply approved security updates.
Note: Procedures for applying Service Packs and Hotfixes are referenced Windows 2000 Security Configuration Guide.
Record all system changes in configuration control records and update system build specifications to include implementation of security updates.
User joins a different part of the organization, requiring access changes
Description of event: A user joins a different element of the organization, requiring changes to account privileges, object access, group membership, and/or Domain membership.
Security Impact: Changes in a user's area of responsibility may require access changes. Otherwise, the user may retain access to resources outside his/her realm of responsibility.
Required Activities:
Review the user's new access requirements with department managers and the Security Manager to establish network service and resource requirements.
If the user is joining a different network domain, remove the account from the current domain and create a new account in the new domain. This may involve different administrators.
If the change occurs within the same domain, remove the user from any group accounts the user no longer has a need for.
Assign the user appropriate groups, providing access to necessary resources.
Remove unneeded privileges and assign any new required privilege sets. Typically, this is best accomplished through group memberships.
Set a new password for the user. Set it to require the user to change the password at the next logon. This will force the user to change the password to one of his/her own.
Note: Procedures for all of the above recommendations are provided in the "Creating and Maintaining User and Group Accounts" subsection.
User leaves organization
Description of event: A user leaves the organization and no longer requires access to network resources.
Security Impact: Potential for unauthorized access. If access authorizations are not promptly and properly removed, the user account may continue have access to network resources beyond the time the employee leaves the organization.
Required Activities:
Verify that the user has not encrypted any essential files or directories. If so, make sure they can be decrypted before deleting the user account.
Review any resources that may have permissions set for only this user, and change permissions as appropriate.
Once verified by appropriate department managers and the Security Manager, delete the user account.
User forgets password
Description of event: The user has forgotten his/her account password.
Security Impact: The user cannot log in and is unable to gain necessary resource access and perform required tasks.
Required Activities:
First verify that the user is authorized access. This is to ensure that the request is not a social engineering attempt.
Set a new password for the user. Set it to require the user to change the password at the next logon. This will force the user to change the password to one of his/her own.
Note: Procedures to set password options are provided in the "User Accounts" subsection.
Recovery of user encrypted files
Description of event: A user is unable to access his/her encrypted information, or leaves the organization without decrypting data required by the organization.
Security Impact: Valuable information could be inaccessible to the organization.
Required Activities:
If users are unable to decrypt previously encrypted data, or if an employee suddenly leaves the organization, a recovery agent - a user designated to recover encrypted files - can recover encrypted files on a computer using a recovery policy. Recovery policies are in the Computer Management console's Group Policy snap-in. EFS will not work if a recovery policy does not exist; thus, emptying the Encrypted Data Recovery Agents folder disables EFS. Windows 2000 Professional creates a default recovery policy locally for all standalone computers, and the local administrator is the recovery agent.
In order to recover encrypted files, the recovery agent must log onto the computer and decrypt the files.
If a user does not have access to the certificate and private key, he or she must rely on another recovery agent. Users back up the encrypted files using Backup or a similar backup utility. Then, they e-mail the backup files to a recovery agent, who then decrypts the files using the recovery agent's own recovery certificate and then e-mails the files back to the user.
To protect the recovery certificate and its associated private key, recovery agents should remove the recovery certificate from the Certificate Manager after they export it to a backup file, as described in the previous subsection. Doing so prevents other people from gaining access to the recovery certificate and private key. Recovery agents can identify the certificate to be removed because the Certificate Manager describes its intended purpose as "File Recovery". After exporting the recovery certificate to a PFX file, they can remove it from the Certificate Manager; this ensures that the exported PFX file contains the only copy of the private key. They should put the PFX file in a safe place and import it into the Certificate Manager only when they must recover encrypted files on the computer.
In a Windows 2000 domain, the server administrator creates recovery policies at the domain, the organizational unit, or the computer level. In this case, the default recovery agent is the domain administrator. Domain administrators should secure the recovery certificate and associated private key by exporting it and then deleting it from the Certificate Manager. The exported PFX file should then be stored in a safe place. Also, in a Windows 2000 domain, administrators can create additional recovery certificates and designate certain users as recovery agents.
Incorrect time
Description of event: The computer does not keep current time. This could be due to a number of issues, such as; the computer was moved to a location outside the original time zone; the system bios is not maintaining time; daylight savings time has taken effect and computer has not adjusted; the computer has acquired its time from a source that has the incorrect time.
Security Impact: Audit record on the affected system will not reflect the actual time that events took place.
Required Activities:
Check the BIOS battery to make sure it is charged. If it is not, replace the battery and set the proper time on the computer.
If the problem is due to a time zone change, set the correct time zone on the computer and reset the time to the proper time zone settings.
On the Date/Time Properties applet, click on the Time Zone tab and make sure the "Automatically adjust clock for daylight saving changes" box is checked.
Note: Procedures for accessing the Date/Time Properties applet are provided in the "Set the date and time" subsection.
- Set the computer to get its time from a reliable timeserver.
Quota limit reached
Description of event: The administrator is alerted that a user's quota limit is being reached.
Security Impact: If the option of denying disk space to users who exceed their quota limit is selected, the user will receive an "out of disk space" message and will not be able to write additional data to disk. This result in a denial of service (storage) condition for the user by not allowing the user the ability to store work related information.
Required Activities:
Consult the user and review his/her disk space requirements.
Ask the user to delete unnecessary files, or move them to a back up location.
Alternatively, increase the user's disk quota if it is deemed appropriate.
Note: Procedures for all of the above recommendations are provided in the "Managing disk quotas" subsection.
It is necessary to revoke a user's access to objects and/or to the user's privileges
Description of event: It is necessary to immediately revoke a user's security attributes and revoke a user's access to objects.
Security Impact: It may be necessary to revoke access to certain objects and/or to remove certain privilege capability from a user due to changes in responsibilities and access requirements or due to concerns of misuse. Continued access may allow the user access to unauthorized data or may pose a risk to the data due to misuse. Additionally, the user may perform privileged actions for which he/she is no longer authorized or trusted.
Required Activities:
Review permissions on pertinent objects and remove or change the users access permissions as appropriate.
Review the user's group memberships and remove the user from any group that provides privileges that are no longer required by the user.
Review the User Rights Assignment policy and make sure the user is not specifically granted the undesired privileges.
Force the user to re-authenticate to the network by logging the user off of the network.
Note: Simply ending a user's active session (as described in the "Disconnecting a user or users from a share or active session" subsection) will disconnect the user, however, the user will still be able to re-establish the session. To avoid this, it will be necessary to locally log the user off of from the computer.