MODULE 14
User Account Management
Now that we’ve discussed identification, authentication, and authorization in depth, we need to take a look at actually managing user accounts. User accounts facilitate user access to systems and data. They allow us to map logical identities and assign rights, privileges, and permissions to the actual user who sits at the keyboard. In this module, we’re going to discuss some of the general principles of user account management. We’ll look at some of the details involved with managing rights, permissions, and privileges for both users and groups. We’ll also look at policy requirements, which usually involve passwords and day-to-day account management.
Managing User Accounts
Managing user accounts may not require a full-time security person in a small organization, but in organizations with a large user population, or even in medium-sized organizations, account management may be a full-time job. Day-to-day functions must be considered when provisioning user accounts. Provisioning is the entire process of creating accounts, assigning them to users or groups, assigning those accounts permissions, and ensuring that users are creating passwords that meet organizational policy requirements. User accounts are managed through a lifecycle: provisioning, use, and deactivation. During the lifecycle, accounts are created and deleted, disabled, and sometimes modified as user conditions change. We’re going to look at different considerations of managing user accounts, including using multiple and group accounts, as well as enforcing account policies on users. We’ll also look at how privileges are assigned to accounts.
Account Policy Enforcement
The first few topics we’ll discuss address enforcing different account policy settings. Remember from our discussions on policy in Module 4 that the organization sets policies to direct how systems and data are accessed. Account policies are the organization’s means of ensuring that accounts are created and maintained in a uniform fashion across the organization. Although there certainly should be a written account policy for the organization, technical policy settings should be in place to implement these policies within the system. For example, Windows has several account policy settings that you can use to enforce certain restrictions on user accounts. We will look at these periodically as we progress through this module. In the following sections, we will look at different aspects of policy enforcement, including managing user accounts and credentials, password policies, and circumstances that may require user accounts to be locked out or disabled. Figure 14-1 shows some of the technical policy settings in Windows that are used to manage accounts. We’ll look at some of these areas in more detail in this module.
Figure 14-1 Windows Server 2012 security policies
Credential Management
Credentials are used to identify and authenticate users and include authenticators such as user accounts and passwords, smart cards, and biometrics. Credential management is the overall management process used to control credentials and ensure that they are created and used properly. There are two primary ways of managing credentials: centralized and decentralized management.
Central account management involves the use of an overall enterprise accounts database, typically integrated into various systems in the network. Microsoft Windows Active Directory is an example of a centralized accounts and credential database. Credentials are stored within this database and managed by one authority within the organization. Under centralized credential management, all accounts are managed using a uniform set of policy requirements. For example, a central account policy may require that all organizational user accounts consist of a last name and first initial. It may also require that passwords meet certain requirements. Normally, centralized credential management is preferred, since it makes it much more efficient to handle user account and access issues.
Decentralized credential management may be used in smaller organizations or in organizations that are either functionally or geographically separated. In a decentralized scheme, the accounting department, for example, may manage all of its own user accounts, separately from the organization. Other departments may perform this function the same way; there may be separate user account databases for engineering, marketing, and production. Each department would be responsible for its own unique account policy requirements. One problem with decentralized management is the lack of interoperability of accounts between departments. If a user required access to a resource in the accounting department, for example, but her user account resided in the marketing department, then she might have to have two separate user accounts, one in each department. She would also likely have different account and password requirements to meet. Examples of decentralized accounts databases would include those that are unique to a single Windows system, a Windows workgroup environment, or a standalone Linux system. Each of these accounts databases resides only on the system or host; the databases are not distributed across the entire enterprise network. Decentralized credential management also can create problems with account synchronization when accounts are trusted across different security domains.
Credentials can be managed on either a centralized or decentralized basis.
Group Policy
The concept of group policy can often be confusing, because it can mean two different things. In the Microsoft Windows world, group policy describes how different system and environmental settings are pushed down to different users and computers. Even though it’s called group policy, it doesn’t necessarily use groups as its logical policy unit. Group policy settings can be pushed down to individual users, individual computers, groups of users, entire domains, or even geographically separated sites. These policy settings might include limitations on user rights, software settings, network settings, and so on. Figure 14-2 demonstrates how group policies are managed in Windows Active Directory.
Figure 14-2 Managing Windows’ Group Policy
The other meaning of group policy is that, whenever possible, users should be managed in defined logical groups, by functional, geographical, or security requirements. In other words, users in the accounting department can be placed in a logical accounting group, which would be used to manage all of their resource needs and security requirements. Managing users by groups enables administrators to assign users to resources and grant privileges and permissions more efficiently. For example, the users group, where normal users without special privileges reside, is different than the administrators group, where users requiring administrative level privileges might be placed.
Logical groups should be used to manage common user functions and security requirements whenever possible.
Password Length and Complexity
We’ve all been told about the necessity to have strong passwords. But what makes up a strong password? In the early days of computers and the Internet, people used their dog’s and children’s names, birthdays, and other common, easy-to-remember things as passwords. Passwords were usually very short, five or six letters at best, and normally made up of letters of the alphabet. As malicious hackers came on the scene, however, they quickly learned that passwords could be defeated and guessed by simple mathematics (since short passwords did not yield a lot of different combinations to try) or by guessing the user’s password by learning different characteristics about them and their personal lives.
Today, we are trying to get away from simple usernames and passwords as means of identification and authentication, but we’re still a long way from that. Although businesses and government agencies are using multifactor methods such as smart cards, PINs, and biometrics, the average user is still using username and password combinations in many of their applications, including users in the business world. So we still have to account for the possibility that passwords will be stolen and cracked by malicious entities. To make it harder for hackers to steal and crack passwords, we have created password construction rules that make password guessing and brute-forcing more difficult. Password cracking is a subject we will dive into in Module 15, but for now we’ll cover the basic rules of password construction, which deal with length and complexity.
A password consists of several linear characters. In the early days, the character space of the password—the number of possible characters—made them easy to guess, because passwords were usually no more than four or five characters long. If, for example, the password was constructed of only numbers, then a four-character password would have only 10,000 possible combinations. This might seem difficult for a human to guess, but a computer could crack this password in seconds. Even if you added one more character, the password would have 100,000 possibilities—still very easy for computer to figure out. Today, the general rule is that the longer the password the better, because the different combinations of password possibilities is far more difficult to crack. These days, most organizations recommend, and sometimes require, a password length of at least 14 to 20 characters. Even a password this long, however, if it used only numbers or letters, could be easily broken by a computer in a matter of minutes or hours. That’s where complexity comes in.
Password complexity takes into account the numbers of character sets that can be used to construct a password. In a four-character password that used only numbers, for each possible character, there would be only 10 possibilities (digits 0–9). If you added another character set, such as all lowercase letters of the alphabet, the number of potential characters would increase to 36 possibilities per character (digits 0–9, and lowercase alphabetic letters a–z). Obviously, this would increase the character space and the complexity of the password. A four-character password would increase from 10,000 possible combinations to 1,679,616. Again, this sounds like an awful lot of combinations, and it would be very difficult for a human to crack this password in a reasonable amount of time. However, understand that computers can attempt thousands of combinations per second, so it wouldn’t take very long for a four-character password, even with this many combinations, to be cracked.
Although it goes a long way toward increasing the character space of a password, adding more character sets, as you can see, also increases the number of password combinations. Rather than using only numbers and lowercase letters, most organizations also require the use of uppercase letters and special characters. Adding those two character sets increases the character set even more. Ideally, we want users to construct passwords that are not only longer in length, but that use at least one of each of those four character sets, preferably at least two of each. As you’ll see in Module 15, malicious hackers can defeat even complex passwords, however.
The more complex a password, the more likely the user won’t be able to remember it, and that means he’ll probably write it down; this is something to consider when requiring complex passwords. Users must be trained on how to develop secure passwords that they can remember without compromising them by writing them down. Many users find that constructing a password from a phrase, such as the first letter of every word of a common phrase that is easy to remember, is a viable solution to this problem.
Password complexity consists of increased length and character sets. Both contribute to the character space (number of possible combinations) and a password’s security.
Password Reuse and History
Two essential elements of your account policy are restricting password reuse and maintaining a password history. It does no good to require users to change their password periodically, if they are only going to change it to the same password they have been using for years. A password reuse setting in your account policy would prevent users from reusing the same password they have used for a certain number of passwords. For example, setting your password reuse policy to 10 would prevent users from using their last 10 passwords. That way, they are forced to use an entirely new and different password.
This is made possible by the password history, which stores the user account’s passwords for a certain number of password change cycles. If the password policy history is set to 10, for example, the system would store the user’s last 10 passwords. Beyond this setting, the user can, of course reuse a password, but setting stringent password aging requirements would prevent the user from reusing passwords for a particular period of time. If, for example, passwords are required to be changed every 90 days, and the password history is set to 10, then the soonest a user could reuse a password would be 900 days. By that time, the user probably won’t even remember the old passwords, so odds are an old password won’t be reused. Figure 14-3 shows a Windows Server 2012 password policy management console, which includes password history settings and complexity requirements.
Figure 14-3 Managing password policies in Windows Server 2012
Password use should be limited so that users cannot continually reuse old passwords.
Account and Password Expiration
Accounts and passwords shouldn’t be set to last forever; in most cases, they should be at least manually reviewed to see if they are still required. Some accounts and passwords, however, should be set to expire. Accounts for temporary workers, for example could be set to expire after a predetermined period of time, such as 90 days. These accounts could be reviewed shortly before the time period expires to see if they are still needed. Passwords, on the other hand, should be set to expire for everyone in the organization, to include administrators and even senior executives, because, over time, passwords could become cracked by malicious hackers, lost, or otherwise compromised. We’ll discuss attacks on passwords in depth within Module 15, but for now, you need to know that password expiration shortens the amount of time that an attacker may have to crack a password and use it. Depending on password length and complexity, it can take an inordinate amount of time to crack. The idea is to make sure the passwords expire before they are cracked.
When the password is set to expire, the system should notify users a certain number of days (set by the system’s account or password policy) ahead of time so that they have ample opportunity to change to a new password. If a user does not change her password within the allowed amount of time, her account should be locked, so that she cannot use the account again until the password is changed. This forces the user to change her password, and when she again creates a new password, the expiration time for that password is reset. In addition to password expiration times, some systems even set a minimum time that users are forced to use their passwords before they are allowed to change them; this prevents users from rapidly changing passwords and cycling through their password histories to reuse passwords they have used previously.
Disabling Accounts
Accounts may be temporarily disabled for various reasons. The organization may not want to revoke, retire, or delete the account permanently, since the user may need it at a later date. Perhaps a user has repeatedly input an incorrect password—the system would automatically disable the account to prevent its compromise, in case an attacker is attempting to brute-force the account. Or an account may be temporarily disabled if a user is on vacation—or if he is under investigation for a crime involving the computer. The user may not be allowed to use the account during either of these two circumstances, so the account would be manually disabled until management determines that it can be re-enabled.
For whatever reason, disabling an account should prevent its use for a set duration. It should require that the account be re-enabled by a separate user with administrative privileges, and a documented reason as to why the account has been both disabled and re-enabled. It may be organizational policy to disable an account for a predetermined amount of time after a user has left the organization; in those cases, policies should also set a time after which the account will be permanently deleted.
Accounts should be disabled temporarily whenever a user does not need access to the system. They should not be permanently deleted until you determine that a user will never need access to the system again.
Account Lockout
Account lockout is a part of an account policy that is used to protect user accounts from being compromised. Many accounts are disabled after a particular number of incorrect password attempts. The account can be locked for predetermined period of time, such as an hour or two, or until an administrator manually re-enables the account. This prevents brute-force password attacks. Account lockouts also normally show up in audit logs and could alert the administrator to a potential attack—or, at minimum, a user who is having issues with his account or password. Most account lockout thresholds are set to a small number, usually between three and ten, which is enough to prevent a brute-force attack but forgiving of a user who may have simply forgotten or mistyped his password. Figure 14-4 illustrates the default lockout policy settings in Windows.
Figure 14-4 Default lockout policy settings in Windows
You should always set account lockout as part of your organization’s account policy. If account lockout is not set, a malicious user could use brute-force techniques to guess a password and access an account.
Account and Password Recovery
Account and password recovery should be considered when you’re developing account policies and procedures. In Windows, the account identifier is known as the security identifier, or SID. In UNIX- and Linux-based systems, account identifiers are known as user identifiers, or UIDs.
If an account is simply disabled, it can easily be re-enabled whenever management or policy dictates. If the account has been deleted, accidentally or intentionally, recovering it may be more difficult. Simply re-creating an account isn’t the same thing as re-enabling it. Even if you were to re-create the account with the same username, the identifier that the system uses for it will be different. The system uses identifiers to assign privileges and allow access to different areas of the system. Re-creating an account means that you’ve actually created a different account, so the user rights and privileges used on the original account would not apply to the new account—you must completely reassign them from scratch.
You can also recover an account by restoring part of the account database from a backup. This isn’t always the preferred method, however, because it is difficult to restore only discrete pieces of the database pertaining to the user account. Typically, the entire database might have to be restored, which would also undo any other changes that were made since the account was lost or deleted.
Password recovery typically occurs only if the password has been stored somewhere offline, such as in a secure file or container. Often, organizations will record highly sensitive passwords for system services or critical personnel and store them in secured and encrypted files or in a secure container, such as a safe, for example. If passwords have not been stored offline, recovery could be difficult if a system goes down. Some older systems might store passwords in plaintext, which is highly undesirable, but it might make passwords easier to recover. The best way to “restore” a password is simply to create a new one. This is especially true of the password has been lost and may have been compromised.
Managing Privileges with User Accounts
Although we mention privileges specifically, understand that this also applies to rights (abilities to perform actions on the system) and permissions (authorized actions that applied to various shared resources, such as files and folders). Privileges are generally assigned on an individual basis to user accounts or to logical groups that have been created for common functional and security needs. We’ll look at both of these methods and discuss the need to review and monitor privileges periodically to ensure that they’re being used appropriately.
User-assigned Privileges
One of the reasons we create individual user accounts is because it enables us to assign the accounts particular rights, permissions, and privileges. User accounts allow users to identify and authenticate themselves to the system, access and interact with resources, and perform our daily jobs. Set up properly, these accounts also enable us to trace the actions performed by the user account to the physical user. When a user requires access to a system or resource, we assign specific privileges to her user account. When a user requires access to yet another resource, we assign her even more privileges. At some point, users may no longer require access to certain resources or privileges to perform actions on the system. When that happens, we can also reduce the user’s privileges or revoke certain permissions.
These types of actions occur on a daily basis with most user accounts in large organizations. However, you’ll find that many user accounts have common functional needs and security requirements. Managing privileges on an individual user account basis can be inefficient and difficult. Although certain user account privileges need to be administered on an individual basis, the preferred way of managing privileges is by assigning them to user groups, which is discussed next.
Group-based Privileges
On a system, a group is a logical collection of user accounts that have common functions, access, and/or security needs. The most efficient way to assign user privileges, rights, and permissions is to assign them to groups. This allows the appropriate privileges to be assigned to the entire group of users only once, rather than assigning privileges to individual user accounts each time new users require the same privileges. User accounts can be placed in and removed from groups easily, without changing the privileges. You can assign user accounts to multiple groups to reflect different functional and security needs.
One disadvantage to group-based privileges is that a user account may be placed in a group and eventually forgotten about. Later, if the organization does not want a user to have certain privileges, when you examined the individual user account, you wouldn’t see the group privileges there. Another disadvantage is that group permissions are often cumulative. For example, if a user is assigned to the administrators group, he usually has elevated privileges. If he is assigned to a functional group as well, such as accounting or marketing, he may use his administrative level privileges to affect certain transactions that are not authorized.
Group membership should be examined closely, as well as cumulative permissions and the continuing need to have them. Reviewing privilege requirements and continuously monitoring them is important, as we’ll discuss next.
Use groups to assign user privileges and permissions to resources whenever possible. This makes the process much more efficient and secure.
User Access Reviews
You should periodically review access to systems and resources for several reasons. First, compliance with any organizational access control policy may require periodic review. Second, users often are transferred within an organization, they may be hired or terminated, or they may be promoted or demoted. In all of those cases, users likely don’t require the same access to systems and data. Unfortunately, if access is not reviewed on a periodic basis, users may move around within the organization and retain privileges even when they no longer need them. This is a problem commonly called privilege creep, and it violates the principle of least privilege.
Some highly sensitive systems or data should require periodic access reviews to ensure that unauthorized users have not been inadvertently given inappropriate permissions to sensitive data. Access reviews involve reviewing audit logs, object permissions, access control lists, and policies that specifically direct who should have access to systems and data and under what circumstances. That’s another reason it’s a good idea to document exactly who has access to sensitive systems and data and when that access will expire; it makes access reviews a great deal easier.
Continuous Monitoring
Continuous monitoring is a topic we will revisit throughout this book. Continuous monitoring is a form of auditing that involves examining audit trails, such as logs and other documentation, to ensure accountability for actions any user performs. With continuous monitoring, we can continuously check to ensure that systems and data are being accessed properly and by authorized personnel. Monitoring may involve automated means or manual review of logs or documentation. In any event, we’re looking for signs of improper access by unauthorized persons or unauthorized actions authorized people may take, such as unauthorized use of account privileges; use of accounts by unauthorized users; unauthorized creation, deletion, or modification of data; and so on. Continuous monitoring enables us to be sure that users are performing only the authorized actions they are allowed to perform on the network. This supports the security concepts of authorization and non-repudiation, as well as accountability. Figure 14-5 shows the different options available for auditing in Windows, a necessary part of reviewing user access and continuous privilege monitoring.
Figure 14-5 Audit policy settings in Windows
The organization should review the need for higher level privileges on a frequent basis and continually monitor the use of those privileges. This ensures accountability and prevents security incidents from occurring.
Account Management Considerations
Two important considerations in managing accounts are the use of multiple accounts, usually by one individual, as well as the user of shared accounts, which may be used by multiple individuals. Remember that user accounts, as a general rule, should be tied to a single individual. This ensures that actions can be traced to a particular user, establishing accountability and enforcing non-repudiation, one of the elements of security we discussed in Module 3. Non-repudiation means that a user cannot deny that she took an action. Assigning a single user account to one particular user ensures non-repudiation because we can audit the use of that particular account to show what actions the user has taken.
Nevertheless, in some circumstances, the use of multiple user accounts, or even shared accounts, may be required. In these cases, we have to balance this functionality with security.
Multiple Accounts
Normal user accounts are allowed to perform typical user actions, such as editing documents, checking e-mail, and performing daily work. Higher level account privileges on the host or network may be required by administrative-level or privileged users because of their duty or job position requirements. But if we assign the normal user account higher level privileges, it increases the potential for bad things to happen. First, the user could routinely abuse his privileges. Second, if a malicious entity obtains the user’s account and password, she could perform harmful actions using those elevated privileges. Finally, if the user is logged into the system with that privileged account, any malware or software that requires elevated user privileges can take advantage of that account, potentially taking harmful and sometimes unknown actions on the system.
The answer to this problem is through the controlled use of multiple accounts—in other words, a user would have a normal user account with lower level privileges, plus a second user account with very specific higher level privileges. The user would use her lower level account to perform routine duties—actions such as accessing e-mail and files, editing documents, and other actions that require no special privileges. When the user needs to use higher level privileges, such as creating accounts, installing devices, and updating software, she could authenticate to the privileged account and log out of the account when the action is complete. This way, the user restricts her use of the privileged account only to the times when it is needed, and she is not constantly authenticated as a privileged user. This reduces the attack surface on the system or network and the possibility of those privileges being abused. It also makes it easier to hold the user accountable for any actions performed using those privileges by auditing those particular accounts.
Some general rules for maintaining multiple accounts include the following:
Using different login names, different passwords, and different permissions and privileges for both accounts.
Different group assignments should be made for those accounts, plus a higher degree of auditing of their use.
Users should not stay logged into the system using privileged accounts; they should be allowed to log into them only when they need them.
Users should have to follow a process of logging in and authenticating to the system with those accounts before they are allowed to use them.
Users should be allowed to perform only certain actions while they are logged into those accounts and should be required to log out when they’re done.
Multiple accounts, particularly privileged ones, should be documented and reviewed periodically to determine whether they are still needed and to ensure that they are being used properly.
Shared Accounts
In a shared account, several users can log in using the same username and password for the account—in other words, several people can access the same account. You can quickly see how sharing accounts could cause issues with accountability and non-repudiation. If someone used that account to change file permissions, delete data, or even create another user account with elevated permissions, who would you trace the action to? The abuser could be anyone who has access to the account and knows its username and password. Even strictly auditing the account would not tell you who actually used it.
In general, the use of shared accounts (also sometimes referred to as generic or group accounts) should be avoided at all cost; however, sometimes you must make exceptions because of critical functionality requirements. For example, shared accounts can be used for a particular resource or system that does not allow the use of multiple accounts to access and use it—perhaps only one account can be used to access it. Usually these are older systems, and users must all use the same account to use the resource. Another example is a system that must be available constantly, such as a military weapons system or another system that requires that any user be able to access the console or desktop of the system immediately. Suppose, for example, that the operator of a military weapons system steps away from the system desktop and locks it. If an enemy were to attack suddenly, the situation might call for another operator to access the system immediately to initiate defensive actions. If the system is locked and the second user can’t access it or must wait for the other user to return, the response would be delayed, potentially costing lives. Very particular circumstances can require the use of shared accounts.
Although they should be avoided whenever possible, shared accounts should be carefully controlled if they are used. Anyone who has access to the shared account should be documented and briefed on its care and use. Some systems may allow a user to be logged in as a normal user and then authenticate to the shared account. In this case, the system may audit the use of the shared account, the time it is used, the actions performed with it, and the authenticating user, thus ensuring accountability. If the system does not have this capability, users should have to log their use of a shared account manually, as well as what actions they took while using it. These manual and system logs should be scrutinized carefully and often to make sure that people are using the account for its intended purpose, and securely.
Shared or generic accounts should be used as minimally as possible. When their use is absolutely required, shared accounts must be documented, audited, and carefully controlled.
Module 14 Questions and Answers
Questions
1. Which of the following methods are used to manage user credentials? (Choose two.)
A. Standalone
B. Centralized
C. Decentralized
D. Active Directory
2. Which of the following is used in a Windows Active Directory network to push policies down to individual users and computers?
A. Account policy
B. Group policy
C. Rights, permissions, and privileges
D. Password policy
3. Which of the following terms describes the number of possible combinations in a password?
A. Character space
B. Character set
C. Complexity
D. Length
4. Which of the following is used to prevent the reuse of passwords?
A. Disabling accounts
B. Account lockout
C. Password complexity
D. Password history
5. Which of the following factors determines how often passwords should expire and be reset?
A. Password history
B. The minimum amount of time the user is required to use the same password
C. The time and effort it may take for a hacker to crack the password
D. Account lockout duration
6. Which of the following should be done to a user’s account when the user is under investigation for an indefinite period of time?
A. The account should be deleted.
B. The account should be locked.
C. The password for the account should be changed.
D. The account should be disabled.
7. Which of the following is the primary way to defeat brute-force attacks on passwords?
A. Account deletion
B. Account lockout
C. Password changes
D. Password history
8. Several users in the accounting department each require the same levels of access to the accounting server and its share data. Which of the following is the most efficient way to grant access to these users?
A. Create a logical group, assign the group the appropriate permissions to the resources, and then add the individual accounting user accounts to the group.
B. Assign each accounting user the appropriate permissions to the resources.
C. Create a logical group, assign the group the appropriate permissions to the resources, assign the appropriate permissions also to each individual user account, and then add the individual accounting user accounts to the group.
D. Create a logical group, then assign the appropriate permissions to each individual user, and then add those user accounts to the group.
9. Which of the following are the best ways to ensure that user accounts are being used appropriately and securely? (Choose two.)
A. Periodically review assigned privileges.
B. Allow users to maintain their privileges indefinitely, even during promotion or transfer.
C. Continuously monitor accounts, through auditing, to ensure accountability and security.
D. Ensure that users permissions stay cumulative, regardless of which group or job role they occupy.
10. Which of the following should usually be avoided and, if used, carefully documented and controlled?
A. System accounts
B. Multiple accounts
C. Shared accounts
D. Individual accounts
Answers
1. B, C. Centralized and decentralized methods are used to manage user credentials in an organization.
2. B. Group policy is the method used to push security policy elements to individual computers and users in a Microsoft Windows Active Directory structure.
3. A. Character space describes the number of possible combinations in a password.
4. D. The password history setting in the account policy is used to prevent the reuse of older passwords.
5. C. The time it might take a hacker to crack a password, based on complexity and other considerations, is usually the primary factor that drives how long the password can be valid before it expires and must be changed.
6. D. If a user is under investigation, this may mean only a temporary suspension of his access to systems and data. Under this circumstance, the account should be disabled until management deems otherwise.
7. B. Account lockout is best way to prevent brute-forcing a user account and password, since a malicious user can attempt to log in only a few times before the account is locked.
8. A. The most efficient way is to create a logical accounting group, assign that group the appropriate permissions to the accounting server resources, and then add the individual accounting user accounts to the group.
9. A, C. Periodic reviews and continuous monitoring are two ways to ensure that accounts and privileges are used in accordance with organizational policy and in a secure manner.
10. C. Shared or group accounts should be avoided, and, if used, they should be thoroughly documented and carefully controlled.