CHAPTER 18

Identity, Access, and Accounts

In this chapter, you will

•  Examine how to compare and contrast identity and access management concepts

•  Explore how to differentiate common account management practices when given a scenario

Access control and authentication are important to control who has access to computer systems and resources. Principles of controlling access and properly authenticating apply to both internal access and remote access. Remote access requirements are more rigorous, but the same principles can be applied to internal access.

Access control mechanisms work together with accounts and account policies to determine the proper level of access for users on systems. The chapter will examine authentication systems, account types, and general concepts associated with access control and authentication.

Certification Objectives   This chapter covers CompTIA Security+ exam objectives 4.1, Compare and contrast identity and access management concepts, and 4.4, Given a scenario, differentiate common account management practices. Objective 4.4 is a good candidate for performance-based questions, which means you should expect questions in which you must apply your knowledge of the topic to a scenario. The best answer to a question will depend upon specific details in the scenario preceding the question, not just the question. The questions may also involve tasks other than just picking the best answer from a list. Instead, they may involve actual simulation of steps to take to solve a problem.

Identification, Authentication, Authorization, and Accounting (AAA)

Identification is the process of ascribing a computer ID to a specific user, computer, network device, or computer process. The identification process is typically performed only once, when a user ID is issued to a particular user. User identification enables authentication and authorization to form the basis for accountability. For accountability purposes, user IDs should not be shared, and for security purposes, user IDs should not be descriptive of job function. This practice enables you to trace activities to individual users or computer processes so that users can be held responsible for their actions. Identification usually takes the form of a logon ID or user ID. A required characteristic of such IDs is that they must be unique.

Authentication is the process of verifying an identity previously established in a computer system. There are a variety of methods of performing this function, each with its advantages and disadvantages. These are the subject of the next section of the chapter.

Authorization is the process of permitting or denying access to a specific resource. Once identity is confirmed via authentication, specific actions can be authorized or denied. Many types of authorization schemes are used, but the purpose is the same: determine whether a given user who has been identified has permissions for a particular object or resource being requested. This functionality is frequently part of the operating system and is transparent to users.

Accounting is the process of ascribing resource usage by account for the purpose of tracking resource utilization. This is a basic accounting function that is still used by some enterprises.

The separation of tasks, from identification to authentication to authorization, has several advantages. Many methods can be used to perform each task, and on many systems several methods are concurrently present for each task. Separation of these tasks into individual elements allows combinations of implementations to work together. Any system or resource, be it hardware (router or workstation) or a software component (database system), that requires authorization can use its own authorization method once authentication has occurred. This makes for efficient and consistent application of these principles.

Multifactor Authentication

Multifactor authentication (or multiple-factor authentication) is simply the combination of two or more types of authentication. Five broad categories of authentication can be used: what you are (for example, biometrics), what you have (for instance, tokens), what you know (passwords and other information), somewhere you are (location), and something you do (physical performance). Two-factor authentication combines any two of these before granting access. An example would be a card reader that then turns on a fingerprint scanner—if your fingerprint matches the one on file for the card, you are granted access. Three-factor authentication would combine all three types, such as a smart card reader that asks for a PIN before enabling a retina scanner. If all three correspond to a valid user in the computer database, access is granted.

EXAM TIP    Two-factor authentication combines any two methods, matching items such as a token with a biometric. Three-factor authentication combines any three, such as a passcode, biometric, and a token.

Multifactor authentication methods greatly enhance security by making it very difficult for an attacker to obtain all the correct materials for authentication. They also protect against the risk of stolen tokens, as the attacker must have the correct biometric, password, or both. More important, multifactor authentication enhances the security of biometric systems by protecting against a spoofed biometric. Changing the token makes the biometric useless unless the attacker can steal the new token. It also reduces false positives by trying to match the supplied biometric with the one that is associated with the supplied token. This prevents the computer from seeking a match using the entire database of biometrics. Using multiple factors is one of the best ways to ensure proper authentication and access control.

Something You Are

Something you are specifically refers to biometrics. One of the challenges with using something you are artifacts as authentication factors is that typically they are hard to change, so once assigned they inevitably become immutable, as you can change fingers, but only a limited number of times and then you run out of changes. Another challenge with biometrics is that cultural or other issues associated with measuring things on a person may exist. For example, people in some cultures object to having their pictures taken. Another example is that physical laborers in some industries tend to lack scannable fingerprints because they are worn down. Some biometrics are not usable in certain environments; for instance, in the case of medical workers, or workers in clean room environments, their personal protective gear inhibits the use of fingerprint readers and potentially other biometrics.

Something You Have

Something you have specifically refers to security tokens and other items that a user can possess physically. One of the challenges with using something you have as an authentication factor is that you have to have it with you whenever you wish to be authenticated, and this can cause issues. It also relies on interfaces that may not be available for some systems, such as mobile devices, although interfaces, such as one-time password (OTP) generators, are device independent. OTP generators generate new passwords on demand, against a known sequence that is known only to the OTP generator and the OTP element on the system accepting the password.

One of the challenges of something you have is the concept of something you lost, such as left in a briefcase, at home, etc. Just as leaving your key ring with your office key can force a return trip back home to get it, so can leaving a dongle or other security element that is something you have in nature. And if something you have becomes something you had stolen, the implications are fairly clear—you don’t have access and you have to re-identify yourself to get access again.

Something You Know

Something you know specifically refers to passwords. The most common example of something you know is a password. One of the challenges with using something you know as an authentication factor is that it can be “shared” without the user knowing it because knowledge can be duplicated without the owner’s knowledge. Another concern with “something you know” elements is that because of the vast number of different ones a typical user has to remember, they do things to assist with memory. Repeating passwords, slight changes such as incrementing the number from password1 to password2, or writing them down, these are all common methods used to deal with the password sprawl, yet they each introduce new vulnerabilities.

Another form of authentication via what you know is called identity driven authentication. In identity driven authentication, you contact someone to get access, they will respond with a series of challenge questions. Sometimes the questions are based on previously submitted information, sometimes the questions are based on publically known information, such as previous addresses, phone numbers, cars purchase/licensed, etc. Again, the proper respondent will know these answers, while an imposter will not. These tests are timed and if the respondent takes too long, as in performing lookups, they will fail.

Something You Do

Something you do specifically refers to a physical action that you perform uniquely. An example of this is a signature; the movement of the pen and the two-dimensional output are difficult for others to reproduce. This makes it useful for authentication, but challenges exist in capturing the data, as signature pads are not common peripherals on machines. Something you do is one of the harder artifacts to capture without specialized hardware making it less ubiquitous as a method of authentication.

Somewhere You Are

One of the more discriminant authentication factors is your location, somewhere you are. When using a mobile device, GPS can identify where the device is currently located. When you are logged on to a local, wired desktop connection, it shows you are in the building. Both of these can be compared to records to see if you are really there, or should be there. If you are badged into your building, and at your desk on a wired PC, then a second connection with a different location would be suspect, as you can only be one place at a time.

EXAM TIP    Be able to differentiate between the five factors for authentication: something you are, have, know, or do, or somewhere you are. These are easily tested on the exam. Be sure you recognize examples for each factor to match to a scenario-type question.

Federation

Federation, or identity federation, defines policies, protocols, and practices to manage identities across systems and organizations. Federation’s ultimate goal is to allow users to seamlessly access data or systems across domains. Federation is enabled through the use of industry standards such as SAML, discussed in Chapter 19.

Single Sign-on

Single sign-on (SSO) is a form of authentication that involves the transferring of credentials between systems. As more and more systems are combined in daily use, users are forced to have multiple sets of credentials. A user may have to log in to three, four, five, or even more systems every day just to do her job. Single sign-on allows a user to transfer her credentials, so that logging into one system acts to log her into all of them. This has an advantage of reducing login hassles for the user. It also has a disadvantage of combining the authentication systems in such a way that if one login is compromised, they all are for that user.

Transitive Trust

Security across multiple domains is provided through trust relationships. When trust relationships between domains exist, authentication for each domain trusts the authentication for all other trusted domains. Thus, when an application is authenticated by a domain, its authentication is accepted by all other domains that trust the authenticating domain.

It is important to note that trust relationships apply only to authentication. They do not apply to resource usage, which is an access control issue. Trust relationships allow users to have their identity verified (authentication). The ability to use resources is defined by access control rules. Thus, even though a user is authenticated via the trust relationship, it does not provide access to actually use resources.

A transitive trust relationship means that the trust relationship extended to one domain will be extended to any other domain trusted by that domain. A two-way trust relationship means that two domains trust each other.

EXAM TIP    Transitive trust involves three parties: If A trusts B, and B trusts C, in a transitive trust relationship, then A will trust C.

Account Types

To manage the privileges of many different people effectively on the same system, a mechanism for separating people into distinct entities (users) is required, so you can control access on an individual level. It’s convenient and efficient to be able to lump users together when granting many different people (groups) access to a resource at the same time. At other times, it’s useful to be able to grant or restrict access based on a person’s job or function within the organization (role). While you can manage privileges on the basis of users alone, managing user, group, and role assignments together is far more convenient and efficient.

User Account

The term user account refers to the account credentials that are used when accessing a computer system. In privilege management, a user is a single individual, such as “John Forthright” or “Sally Jenkins.” This is generally the lowest level addressed by privilege management and the most common area for addressing access, rights, and capabilities. When accessing a computer system, each user is generally given a user ID—a unique alphanumeric identifier he or she will use to identify himself or herself when logging in or accessing the system. User IDs are often based on some combination of the user’s first, middle, and last names and often include numbers as well. When developing a scheme for selecting user IDs, you should keep in mind that user IDs must be unique to each user, but they must also be fairly easy for the user to remember and use. Because the user ID is used to identify the person who performed specific actions, it is important to not have generic or shared credentials. Either of these situations makes traceability to an authorized user difficult if not impossible.

EXAM TIP    Having unique, nonshared user IDs for all users of a system is important when it comes time to investigate access control issues.

With some notable exceptions, in general a user wanting to access a computer system must first have a user ID created for him on the system he wishes to use. This is usually done by a system administrator, security administrator, or other privileged user, and this is the first step in privilege management—a user should not be allowed to create his own account.

Once the account is created and a user ID is selected, the administrator can assign specific permissions to that user. Permissions control what the user is allowed to do on the system—which files he may access, which programs he may execute, and so on. While PCs typically have only one or two user accounts, larger systems such as servers and mainframes can have hundreds of accounts on the same system.

Account policy enforcement is an important part of user credential systems. Managing credentials begins with policies that state the desired objectives. Key elements of the policy include elements such as prohibition against sharing accounts and against generic accounts not assigned to a user. For users that have multiple roles, multiple accounts may be necessary, but these need to be delineated by policy rather than on an ad hoc basis. Credential management rules, such as password policy, should be enacted, including lockout and recovery procedures. When users no longer are authorized, such as when they leave the firm or change jobs, the accounts should be disabled, not removed.

Shared and Generic Accounts/Credentials

Shared accounts go against the specific premise that accounts exist so that user activity can be tracked. This said, there are times that shared accounts are used for groups like guests. Guest accounts are covered in the next section. Sometimes the shared accounts are called generic accounts and exist only to provide a specific set of functionality, such as in a PC running in kiosk mode, with a browser limited to accessing specific sites as an information display. Under these circumstances, being able to trace the activity to a user is not particularly useful.

A common form of a shared account is one created to run nightly batch operations. As every action must be associated to a user account, a shared account in the name of a batch user can be used to run batch jobs. This is a generic set of credentials, not actually associated with a single person, but rather is associated with a particular type of process (i.e., batch jobs, backups, etc.). These credentials are maintained by administrators, but are reserved for specific uses, such as executing batch jobs. Because these accounts are in essence local, and are being used to run tasks, they can be restricted in function, not permitted to log in for instance, thus lowering their usefulness for an attacker.

Guest Accounts

Guest accounts are frequently used on corporate networks to provide visitors access to the Internet and to some common corporate resources, such as projectors, printers in conference rooms, and so forth. Again, like generic accounts, these types of accounts are restricted in their network capability to a defined set of machines, with a defined set of access, much like a user visiting the company’s public-facing website via the Internet. As such, logging and tracing activity have little to no use, so the overhead of establishing a unique account does not make sense.

Service Accounts

Service accounts are accounts that are used to run processes that do not require human intervention to start, stop, or administer. From running batch jobs in the data center to executing simple tasks that an organization must complete for purposes of regulatory compliance, many reasons exist for running processes with service accounts that don’t require an account holder. From a security perspective, administrators can configure service accounts to minimize risks associate with them. For example, in Windows systems, administrators can prevent service accounts from logging in to the system. This limits some of the attack vectors that can be applied to these accounts. Another security provision that can be applied to service accounts that run batch jobs at night is to restrict when they can run. Any service account that has to run in an elevated privilege mode can also be designated to receive extra monitoring and scrutiny.

Privileged Accounts

Privileged accounts are any accounts with greater than normal user access. Privileged accounts are typically root- or administrative-level accounts and represent risk in that they are unlimited in their powers. These accounts require regular real-time monitoring, if at all possible, and should always be monitored when operating remotely. Administrators may need to perform tasks via a remote session in certain scenarios, but when they do, they first need to identify the purpose and get approval.

EXAM TIP    For the exam, understand the different account types and how they differ, and remember that the principle of least privilege means limiting a user to the least amount of privilege they need to perform their job. Administrator or root accounts can always perform an action, but if a user lacking elevated privileges can perform it as well, then the user is a better choice to perform the action. You should never use elevated privilege unless necessary to do a task.

General Concepts

Account management, frequently called privilege management, is the process of restricting a user’s ability to interact with the computer system. A user’s interaction with a computer system covers a fairly broad area and includes viewing, modifying, and deleting data; running applications; stopping and starting processes; and controlling computer resources. Essentially, controlling everything a user can do to or with a computer system falls into the realm of account management.

Least Privilege

One of the most fundamental principles in account management is least privilege. Least privilege means that an object (which may be a user, application, or process) should have only the rights and privileges necessary to perform its task, with no additional permissions. Limiting an object’s privileges limits the amount of harm that it can cause, thus limiting the organization’s exposure to damage. Users may have access to the files on their workstations and a select set of files on a file server, but they have no access to critical data that is held within the database. This rule helps an organization protect its most sensitive resources and helps ensure that whoever is interacting with these resources has a valid reason to do so.

Onboarding/Offboarding

Onboarding and offboarding refer to the processes of adding personnel to a project or team and removing personnel from a project or team. During onboarding, proper account relationships need to be initiated, including the establishment of accounts. Newly onboarded members should be put into the correct access control groups based on their needed permissions and assigned tasks, and when they are offboarded, they should be removed from the access control groups, and have their account disabled. This is one way in which access control groups can be used to manage permissions and can be very efficient when users move between units and tasks.

Permission Auditing and Review

As with all security controls, an important aspect of security controls that are used to mitigate risk is an auditing component. Just as it is important to periodically verify all users with accounts on the system are still valid users of the system from a business perspective, it is equally important to periodically perform permission auditing and review. Permission auditing and review is an action that verifies the user accounts on the system are all needed, justified, and actually represent real authorized users. As users can come and go from groups, it is important to audit periodically to ensure that they have not retained permissions granted to a group they no longer belong to.

Usage Auditing and Review

Logs are the most frequently used auditing component, and with respect to privileged accounts, logging can be especially important. Usage auditing and review is just that, an examination of logs to determine user activity. Reviewing access control logs for root-level accounts is an important element of securing access control methods. Because of the power and potential for misuse of administrative- or root-level accounts, they should be closely monitored, particularly the use of an administrative-level account on a production system.

EXAM TIP    Logging and monitoring of failed login attempts provides valuable information during investigations of compromises.

A strong configuration management environment will include the control of access to production systems by users who can change the environment. Root-level changes in a system tend to be significant changes, and in production systems these changes would require approval in advance. A comparison of all root-level activity against approved changes will assist in the detection of activity that is unauthorized.

Time-of-Day Restrictions

Creating time-of-day restrictions for access can solve many account management problems. For the majority of workers who work set shifts, having a system whereby their accounts are not active during their nonworking hours reduces the surface of user accounts available for attackers to use. This is even more important for privileged users, as their elevated accounts offer greater risk, and if an authorized user of an account is not working, there is no reason to have it authorized. As with all policies, provisions need to be made for change and emergencies, whereby authorized users can obtain access when needed, even if outside normal working hours.

Recertification

User accounts should be recertified periodically as necessary. The process of recertification can be as simple as a check against current payroll records to ensure all users are still employed, or as intrusive as having users come re-identify themselves. The latter method is highly intrusive, interrupting people’s work schedules as they have to physically visit the security office, identify themselves, and have their account reactivated. This may be warranted for high-risk accounts, as it ensures there is a legitimate person associated with each account. The process of recertification ensures that only users who need accounts have accounts in the system.

Standard Naming Convention

Establishing a standard naming convention for account names, and systems, is a topic that can stir controversy even among professionals who seem to agree on most things. One advantage of having a standard naming convention is that it enables users to extract meaning from a name. For example, having server names with dev, test, and prod as part of the name can help to prevent inadvertent changes by a user because of the misidentification of an asset. The standard name also helps those doing account maintenance functions as it provides easily seen information on the account by way of its name. By the same token, a naming convention that identifies privilege level, say appending SA to the end of usernames with system administrator privileges, results in two potential problems. First, it alerts adversaries to which accounts are the most valuable. Second, it creates a problem when the person is no longer a member of the system administrators group, as the account must be renamed.

One aspect that everyone does agree on is the concept that a naming convention should leave room for future accounts. The simplest example is in numbering of accounts. For instance, for e-mail accounts, an organization’s convention may be to use first initial plus last name, plus a single digit if two or more people have the same name, such as jsmith2@yourorg.com. Will the organization ever have more than nine John Smiths? Maybe not, but the pool might also include Joan Smiths and Jack Smiths. And the pool is further diluted by the fact that the organization inactivates old accounts and does not reuse them. So, you need to plan ahead to ensure your organization’s naming convention supports future growth and change.

Account Maintenance

The job of a traffic cop may seem boring to you, until you discover that roughly half of all arrests of felons occur during routine traffic stops. Account maintenance is somewhat analogous—no, we aren’t catching felons, but we do find errors that otherwise only increase risk and, because of their nature, are hard to defend against any other way. Account maintenance is the routine screening of all attributes for an account. It involves determining questions such as whether the business purpose for the account is still valid (i.e., is the user still employed?), whether the business process for a system account is still occurring, and whether the actual permissions associated with the account are appropriate for the account holder. Best practice indicates that account maintenance be performed in accordance with the risk associated with the profile. System administrators and other privileged accounts warrant greater scrutiny that normal users. Shared accounts, such as guest accounts, also require scrutiny to ensure that they are not abused.

To ensure that certain high-risk situations do not occur, such as unauthenticated guest accounts being granted administrator privilege, you can configure an automated check that monitors the accounts on a regular basis. In Active Directory, for example, administrators can configure a setting that automatically notifies them anytime a user is granted domain admin privilege. And it is also important to note that account maintenance is a joint responsibility. The job of determining who has what access is actually one that belongs to the business, not the security group. The business side of the house is where the policy decision on who should have access is determined. The security group merely takes the steps to enforce this decision.

Group-Based Access Control

Group-based access control refers to managing access control using groups of users rather than user by user. This can be much more efficient and less prone to error in large enterprises. Under privilege management, a group is a collection of users with some common criteria, such as a need for access to a particular data set or group of applications. A group can consist of one user or hundreds of users, and each user can belong to one or more groups. Figure 18-1 shows a common approach to grouping users—building groups based on job function. Role-based access control (RBAC), discussed in Chapter 20, is implemented via groups in a modern OS.

Figure 18-1   Logical representation of groups

By assigning a user membership in a specific group, you make it much easier to control that user’s access and privileges. For example, if every member of the engineering department needs access to product development documents, administrators can place all the users in the engineering department in a single group and allow that group to access the necessary documents. Once a group is assigned permissions to access a particular resource, adding a new user to that group will automatically allow that user to access that resource. In effect, the user “inherits” the permissions of the group as soon as she is placed in that group. As Figure 18-2 shows, a computer system can have many different groups, each with its own rights and privileges.

Figure 18-2   Group management screen in Windows

As you can see from the description for the Administrators group in Figure 18-2, this group has complete and unrestricted access to the system. This includes access to all files, applications, and data. Anyone who belongs to the Administrators group or is placed in this group will have a great deal of access and control over the system.

EXAM TIP    Placing users in groups and managing groups can reduce account management workload and complexity on large systems and domain environments.

Location-Based Policies

In organizations with multiple locations, there may be situations where user access does not translate across different locations. A doctor may have access rights in one clinic’s system, but not another he is working in. There is also the issue of whether a user accessing the system via remote access should have the same rights and privileges as a user with local access. Location-based policies for access control are risk-based access decisions that are best addressed by examining the business rationale, including risks and rewards for access control at different locations for a user. Once the policies are defined, they can be enforced via the specific access control mechanisms in place.

EXAM TIP    While policies seem to be less technical and just something extra for management to do, they are the basis for all of the technical actions performed, and as such are foundational to security. Without a policy dictating what is desired, you have no basis to enforce proper actions.

Account Policy Enforcement

The key method used to control access to most systems is still one based on passwords. In conjunction with a strongly enforced account policy that prohibits sharing of passwords and credentials, use of passwords forms the foundation to support the concept that each user ID should be traceable to a single person’s activity. Passwords need to be managed to provide appropriate levels of protection. They need to be strong enough to resist attack, and yet not too difficult for users to remember. An account policy can act to ensure that the necessary steps are taken to enact a secure password solution, both by users and by the password infrastructure system.

Credential Management

Credential management refers to the processes, services, and software used to store, manage, and log the use of user credentials. Credential management solutions are typically aimed at assisting end users to manage their growing set of passwords. There are credential management products that provide a secure means of storing user credentials and making them available across a wide range of platforms, from local stores to cloud storage locations.

Group Policy

Microsoft Windows systems in an enterprise environment can be managed via Group Policy objects (GPOs). GPOs act through a set of registry settings that can be managed via the enterprise. A wide range of settings can be managed via GPOs, including numerous settings that are related to security, including user credential settings such as password rules.

Password Complexity

Every organization should have defined password complexity requirements that passwords must meet. Typical requirements specify that the password must meet the minimum length requirement and have characters from at least three of the following four groups: English uppercase characters (A through Z), English lowercase characters (a through z), numerals (0 through 9), and nonalphabetic characters (such as !, $, #, %).

EXAM TIP    You may be aware of new research from NIST that indicates that password complexity rules designed to force entropy into passwords do so at the risk of other, less-desirable password behaviors by users, such as writing them down or versioning them with an increasing number element. The latest NIST guidance (Special Publication 800-63B, June 2017) is that long passphrases offer the best protection. However, SP 800-63B, was published after CompTIA released its Security+ exam objectives, so for the exam, you should know the tried and true password complexity requirements listed here.

Expiration

Account expiration should occur when a user is no longer authorized to use a system. This requires coordination between those who manage access control lists and accounts and those who manage the need for access. The best solution is to have those who manage users also manage account expiration because they are better situated to know when an employee transfers, quits, or otherwise no longer requires an account. This first line of management should be the first line of notification to the security team as to the disposition of permissions. HR should be the backstop, not the primary. Having first-line management initiate permissions issues also enables the proper transfer of permissions when a person departs to someone who takes over the responsibility for the digital assets. Who assumes ownership over files that the previous person was sole owner of? This is a business decision and best managed by those closest to the business.

To manage temporary and contract worker accounts, Windows systems offer a built-in feature that allows you to create a temporary user account that will expire automatically on the date you specify. Upon reaching the expiration date, the user account expires and the user is unable to log on to Windows after that date.

Recovery

Account recovery seems like one of those esoteric topics until you lose the password on your laptop and have no way back in. The same is even more serious if you lose administrator account passwords to key elements of your infrastructure. Having a recovery plan for accounts should something happen to the person who knows the password is important for the enterprise to continue after the loss of that resource. Rather than focus on all the ways one can lose the resource—fired, left on own accord, stepped in front of a bus, coma, and so on—focus on a simple recovery method, such as keeping a list of accounts and passwords in a safe governed by a senior executive. PKI systems have key recovery mechanisms that can be used when emergencies happen. Account recovery is no different; you need to have a plan, and practice executing that plan to prepare for the emergency before the time comes when you need it. Because if you wait until you need the plan, it is too late to create it.

From a technical perspective, recovery is simple. Use a second administrator-level account, reset the lost password, and force it to be changed once the user logs back in. This requires some planning as you need to have the second administrator account before you need to use it. And you need a system by which a user can contact an administrator and after proving their identity to have their account reset. For some cases, this entire process can be automated, using previous security questions for proving identity and scripts to run the rest.

Disablement

Account disablement is a step between the account having access and the account being removed from the system. Whenever an employee leaves a firm, all associated accounts should be disabled to prevent further access by the ex-employee. Disabling is preferable to removal as removal may result in permission and ownership problems. Removing an account can orphan items that remain without other forms of ownership, making it more difficult to share the former employee’s files. Periodic audits of user accounts to ensure they still need access is also a good security measure. Disabling an account is reversible, but it prohibits the account from being used until the issue that resulted in the disabling is resolved. Account disablement can be an automatic response from a security system if it detects that the account is under attack, say a brute force password-guessing attack.

Lockout

Account lockout is akin to disablement, although lockout typically refers to temporarily blocking the user’s ability to log in to a system. For example, if a user mistypes her password a certain number of times, she may be forced to wait a set amount of time while her account is locked out before attempting to log in again. These lockouts can be automated on most systems and provide a series of increasing time hurdles for an attacker, while minimizing the inconvenience to legitimate users who have credential problems. We might mistype our password a couple of times, so at worst a minimal lockout hits a legitimate user on rare occasion. An attacker, trying a set of possible passwords, will hit the lockouts multiple times. Lockout after three attempts allows a reasonable error rate and balances risk.

EXAM TIP    Accounts have many facets that are governed by both action and policy. Remember policy directs actions, and the specifics of the question give the context by which you can choose the best answer. There is a lot of detail in this section and it is all testable in this manner.

Password History

Password history refers to passwords previously used by an account. It is good security policy to prohibit reuse of passwords, at least for a set number of passwords. In Windows, under Local Group Policy, you can set three elements that work together to manage password history:

•  Enforce password history Tells the system how many passwords to remember and does not allow a user to reuse an old password in that list

•  Maximum password age Specifies the maximum number of days a password may be used before it must be changed

•  Minimum password age Specifies the minimum number of days a password must be used before it can be changed again

The minimum password age is to prevent a user from changing their password 20 times in a row to recycle back to the previous or current password.

Password Reuse

Password reuse is a bad idea in that it reopens an exposure to an adversary who has previously obtained a password. Official guidance is passwords should not be reused for at least a year, and for at least a half dozen changes, whichever comes last. Practically, we should never reuse passwords, for a single account or between accounts. As breaches have released many e-mails and passwords into the open domain, people should never expect old passwords to be secure. Adopting a policy of no reuse makes good sense from a risk perspective. This is to minimize the opportunity for an adversary to take advantage of a reuse case. As described in the previous section, you can restrict password reuse in Windows under Local Group Policy.

Password Length

Password length is critical to password-based security. The true strength of a password lies in its entropy or randomness. The higher the entropy or randomness, the greater the keyspace that must be searched for random matching. Password length and complexity are the easiest way to increase entropy in a password. Recent research has shown that passphrases of 20 characters or more are easier to remember, are not typically written down, and can provide the required entropy to be effective. The only problem is that not all systems take passphrases. That being said, the current standard is at least 10 characters with numbers, mixed case, and special characters, and 12-character length is preferred.

EXAM TIP    Passwords and password policies are prime targets for questions. Although all aspects of the policies are important, the specifics of the scenario will shift focus to one particular aspect, so focus on the scenario to provide the context for your answer.

Chapter Review

In this chapter, you became acquainted with the breadth and depth of identity and access management systems. The chapter opened with a description of identification, authentication, authorization, and accounting. It then looked at multifactor authentication, including the five factors of something you are, something you have, something you know, something you do, and somewhere you are. The next topics covered were federation, single sign-on, and transitive trust.

The next section covered types of accounts, including user accounts, shared or generic accounts, guest accounts, service accounts, and privileged accounts. The general concepts around authentication and authorization were covered, including least privilege, onboarding/offboarding, permission audits and review, usage auditing and review, time-of-day restrictions, recertification, standard naming conventions, account maintenance, group-based access control, and location-based policies.

The chapter finished with a discussion of account policy enforcement. In this section, the topics of credential management, group policy, password complexity, expiration, recovery, disablement, lockout, password history, reuse, and length were covered.

Questions

To help you prepare further for the CompTIA Security+ exam, and to test your level of preparedness, answer the following questions and then check your answers against the correct answers at the end of the chapter.

1. Which of the following is an account you might use to run processes that do not require human intervention to start or stop?

A. Guest account

B. Process account

C. Service account

D. Root account

2. A friend of yours who works in the IT department of a bank tells you that tellers are allowed to log in to their terminals only from 9 A.M. to 5 P.M., Monday through Saturday. What is this restriction an example of?

A. User auditing

B. Least privilege

C. Time-of-day restrictions

D. Account verification

3. What is the process of ascribing a computer ID to a specific user known as?

A. Authentication

B. Validation

C. Authorization

D. Identification

4. You are working with a group to develop a new multifactor authentication system for your organization. Which of the following is not a valid category of authentication factors you might use?

A. Something you know

B. Something you see

C. Something you are

D. Something you do

5. Your organization is revamping its account management policies and you’ve been asked to clarify the difference between account disablement and account lockout. Which of the following statements best describes that difference?

A. Account disablement removes the user and all their data files; account lockout does not.

B. Account lockout typically only affects the ability to log in; account disablement removes all privileges.

C. Account lockout is permanent; account disablement is easily reversible.

D. Account disablement requires administrative privileges to execute; account lockout can be performed by any user.

6. Which of the following would most likely be the hardest password to crack?

A. An eight-character password based on a common dictionary word

B. A six-character password using only uppercase letters

C. A seven-character password using a completely random mix of letters, symbols, and numbers

D. An eight-character password using only lowercase letters

7. What are accounts with greater than “normal” user access called?

A. Privileged accounts

B. System accounts

C. Superuser accounts

D. Audit accounts

8. You’ve been tasked to make sure every account on your mail server belongs to a valid, active employee. What is this process often called?

A. Recertification

B. Privilege auditing

C. Password cracking

D. Payroll auditing

9. In a meeting discussing account management, one of your colleagues suggests you manage access control using collections of users rather than on a user-by-user basis. Your colleague is suggesting you use which type of access control?

A. Least privilege access control

B. Location-based access control

C. Group-based access control

D. Privilege-based access control

10. When a user no longer needs or is no longer authorized to use a system, which of the following should occur?

A. Account recovery

B. Account deletion

C. Account reset

D. Account audit

11. Your organization trusts authentication of accounts from a partner organization and your partner organization trusts authentication from your organization. What is this relationship known as specifically?

A. Two-way trust relationship

B. Transition trust relationship

C. Authentication validation relationship

D. Account auditing relationship

12. Which of the following defines policies, protocols, and practices to manage identities across systems and organizations?

A. Transitive trust

B. Single sign-on

C. Identity federation

D. Account management

13. Which of the following would not be considered “something you are” when discussing authentication factors?

A. Fingerprints

B. Voice

C. PIN code

D. Retina pattern

14. In which of the following scenarios might it be acceptable to use a shared account?

A. On a server maintained by different personnel

B. On a publicly accessible PC running in kiosk mode

C. If the account is used only to administer e-mail accounts

D. If the account is used by the CEO and her assistant

15. The processes of adding a person to a project or team and removing a person from a project or team are known as:

A. Account creation and account disablement

B. Intake and outflow

C. Onboarding and offboarding

D. Account auditing and account review

Answers

1. C. Service accounts are used to run processes that do not require human intervention to start, stop, or administer.

2. C. Time-of-day restrictions are often used to limit the hours during which a user is allowed to log into or access a system. This helps prevent unauthorized access outside that user’s normal working hours.

3. D. Identification is the process of ascribing a computer ID to a specific user, computer, network device, or computer process.

4. B. Something you see is not one of the categories of authentication factors.

5. B. Account disablement is a step down from removing an account completely. While the account (and associated data files) still exist on the system, the account itself is disabled and has no privileges to access the system. Account lockout typically only affects logon privileges. Performing a temporary account lockout is a common approach to thwarting brute force password-guessing attacks.

6. C. Of the examples, C would be the most difficult to crack because it is random and is composed of letters, symbols, and numbers—a much larger character set to brute force.

7. A. Privileged accounts are any accounts with greater than normal user access. Privileged accounts are typically root- or admin-level accounts and represent risk in that they are unlimited in their powers.

8. A. Recertification is the process of ensuring users are still employed and still require accounts.

9. C. Group-based access control manages access control using groups of users rather than user by user.

10. B. Account disablement should occur when a user no longer has authorized use privileges on the system. Account deletion can mess with permissions.

11. A. When two domains trust each other, this is known as a two-way trust relationship. In this case, your organization trusts the partner organization and they trust your organization in return. An extended trust is a nonsense distractor.

12. C. Federation, or identity federation, defines policies, protocols, and practices to manage identities across systems and organizations. Federation’s ultimate goal is to allow users to seamlessly access data or systems across domains.

13. C. The authentication factor category “something you are” specifically refers to biometrics. These are uniquely identifying characteristics associated with individuals that typically do not change.

14. B. In general, shared accounts should be avoided when possible, but in situations where creating individual accounts is neither practical nor feasible and tracking user activity is not critical, shared accounts can be the solution. A publicly accessible PC running in kiosk mode is a good use of a shared account, as you wouldn’t be able to issue individual accounts to each person who uses the kiosk and tracking specific user activity is not critical.

15. C. Onboarding and offboarding refer to the processes of adding personnel to a project or team and removing them from a project or team.