Fatskills
Practice. Master. Repeat.
Study Guide: CompTIA Security SY0-601 Exam: Basics of Identity and Account Management Controls
Source: https://www.fatskills.com/civil-engineering/chapter/comptia-security-sy0-601-exam-basics-of-identity-and-account-management-controls

CompTIA Security SY0-601 Exam: Basics of Identity and Account Management Controls

By Fatskills Exam Guides Team — the exam nerds behind 28,500+ quizzes and 2.1M practice questions across 500+ global exams.

⏱️ ~25 min read

Objective: Given a scenario, implement identity and account management controls.

Topics:
- identity provider (IdP)
- account type
- account policy
- geofencing
- geotagging
- geolocation

Account Types
The accounts tied to a user’s identity directly affect your organization’s level of protection. You might find it strange to think that you need to protect a system from its own users. However, internal users have the greatest access to data and, therefore, the greatest opportunity to either deliberately sabotage it or accidentally delete it. A logon banner statement should tell users that network access is granted under certain conditions and that their activities might be monitored. This helps the organization cover itself legally and reminds users that they are expected to follow security policy protocols.
IT organizations often use shared accounts for privileged users, administrators, or applications. This practice presents security and compliance risks because use cannot be attributed to a particular user, and determination of specific access rights and audit of access use is impossible. One of the first steps in providing a secure account access environment is to eliminate the use of shared accounts. Providing each set of access credentials to a single principal—either a user or a machine service—enables an organization to measure every use of data access to determine a baseline for expected and acceptable use. You can then monitor against the baseline to look for variations that indicate potential misuse of enterprise resources or data access.
A next step in providing a secure account access environment is to use a variety of account types. For example, users with administrative credentials should not rely on their privileged accounts for everyday activities such as using email because if they run into an unexpected piece of malware, the malware might gain access to those elevated privileges. Issuing an administrative user a common account for normal access and a separate administrative credential set to use when needed limits the span of control for the user’s operational account. Linux users have been doing this for some time, using sudo (superuser do) to perform administrative functions from their session account.
Certain groups and accounts are installed by default. As an administrator, you should know what these are. For example, service accounts are often installed for interaction with the operating system, and local service accounts typically interact with the Windows OS and tend to have default passwords. By knowing which accounts are installed by default, you can determine which of them are really needed and which of them can be disabled to make the system more secure. You should also know which accounts, if any, are installed with blank or well-established passwords. Common machine accounts used in web-based access systems are often targets for unauthorized access attempts, particularly when left in default or well-known configuration states.
The administrative account should be used only in administering the server. An individual using the administrative account would put a company’s entire business in jeopardy if he or she accessed a malware-infected website or opened the wrong email. In addition, generic accounts used by multiple users must be prohibited.
The security settings in many of the newer operating systems do not allow blank passwords. However, accounts in older operating systems might still have a blank password or a well-known default. For example, older routers often came with the username admin and password admin configured, and sometimes these credentials were not changed. Anyone with this easily obtained knowledge could then simply try this username and password combination.
The Windows User Account Control (UAC) technology ensures that software applications cannot perform privileged access without additional authorization from the user. In the Microsoft environment, lesser accounts may perform privileged processes by using the Run As option to specify the explicit use of a privileged account from within an unprivileged account logon. This is similar to the sudo shell operation under Linux operating systems.
Default credentials and unmonitored accounts such as the guest or admin account commonly established in older equipment and software soften security because they provide one component of access credentials to potential attackers or their tools. Replacing a default administrative account named admin with one that uses a more generic or obscure name adds another obstacle. Attackers then must break both the account name and its associated authentication keys.

Account Management
Account management is fundamental to security practices. Following good practice is important as it’s the foundation for how users and services gain access to other systems. The following sections provide general concepts around good practices as they relate to the account life cycle.

Onboarding and Offboarding
When an employee joins or leaves an organization, the process of onboarding/offboarding occurs. Onboarding is the process of creating an identity profile and the information required to describe that identity. Onboarding can also include registering the user’s assets, such as a computer and mobile devices, and provisioning them so they can be used to access the corporate network. The organization creating and managing this identity is known as the identity provider (IdP) and is responsible for authenticating the identity.
Many organizations use a self-service method through a preconfigured profile to minimize IT intervention. As part of best-practice onboarding procedures, some solutions offer integration with Active Directory, which is a simplified way to identify domain user groups that are permitted to onboard their devices. Offboarding is the opposite process: User identities that no longer require access to the environment are disabled or deactivated and then deleted from the environment, based on organizational policy. When an employee is terminated, retires, or quits, segregating and retrieving organizational data and applications can be difficult if the user’s own devices were used. BYOD policies should address how data and corporate-owned applications will be retrieved during the offboarding process. In some instances, the organization might opt for a total device wipe.
Account provisioning policies for the creation, update, and removal of accounts must be integrated into an organization’s HR process and regularly audited to ensure continued compliance. Legacy access groups should be similarly expired when they are no longer appropriate to the organization’s operational structure to eliminate potential avenues of unauthorized access through normal line-of-business operations. During separation procedures, passwords and other security credentials should be automatically expired to prevent unauthorized access when those credentials are no longer appropriate. During termination proceedings, this is typically coordinated between managers and the IT department to protect against a terminated employee carrying out retributive or exploitive actions on organizational resources.

Least Privilege
Least privilege is an access control practice in which a logon is provided only the minimum access to the resources required to perform its tasks. Remember the phrase less is more when considering security principles: Grant no more access than is necessary to perform assigned tasks. When dealing with user access, there is often a fine line between sufficient access to get the job done and too much access. An organization can manage user access by using groups and group policies. Keep this least privilege practice in mind when comparing the access control options.

Access Auditing and Reviews
User access reviews allow you to identify misapplied changes or other access control adjustments through direct assignment or inherited nesting of role access rights. In these reviews, you can find and rectify accidents or malicious attempts to gain unauthorized access rights. Periodic access reviews for access management can help ensure that the necessary personnel have access to essential systems, and unauthorized employees do not. A more formal type of user access review is called access recertification. Access recertification is typically the responsibility of the organization’s chief information security officer (CISO) because it involves stating that current access adheres to the organization’s internal policies and compliance regulations.
A common good practice is that access to high-risk applications should be reviewed quarterly and that every application should have a review conducted at least annually. A baseline must be established to account for normal line-of-business operations and should be updated regularly to reflect changes in the organization’s processes and software applications. Examples include identifying the business owners of every application and classifying the data in applications. With a baseline, you can identify unusual activity based on regular review of all accounts (including “permanent” machine and service accounts), and then disable and remove any unneeded credentials. Access reviews should also be conducted for group membership and role/group alignment for organization assignment. Based on these reviews, you can correct accidental access rights assignment through role and group membership. Users should also be notified of their access rights and the need to alert the IT staff if their access appears to be greater than allowed by their role.
Education and regular operational control reviews should be part of an organization’s continuous improvement program to ensure that users comply with security protections and understand the requirements demanded by both their acceptance and use of data access credentials. An organization needs to understand requirements in any attempt to control data access in order to conform to those requirements. Technical controls must be continuously monitored to protect against violation of policy through purposeful or accidental access. An important best practice is to make sure separation of duties among developers, data custodians, and IT administration is well defined and documented.
The purpose of continuous monitoring is to ensure that the processes for user account provisioning, life cycle management, and termination are followed and enforced. Continuous monitoring begins with knowing what user account activity should be present. Continuously monitoring user access enables you to detect unauthorized access from attackers using system backdoors and avert widescale incidents. Industry regulations might require continuous monitoring. For example, Payment Card Industry Data Security Standard (PCI DSS) compliance requires that an organization have well-defined processes in place to review and reassess security practices, even in highly dynamic business environments.
Monitoring should involve a process to record and monitor significant changes to user accounts and groups to ensure that access is not granted outside a formal approval process. Activities that should be monitored and reviewed include the business need for each active account, reconciliation of existing active accounts with account access requests, and account and privilege updates. Close attention should be paid to administrative privilege updates, which may signify compromised accounts.

Time of Day and Location Restrictions
By default users can log in at any time when created with most systems. Many times, restricting logon hours is necessary for maintenance purposes. For example, say that a backup runs at 11:00 p.m. each day. In this case, you might want to be sure that everyone is off the system while the backup is occurring. As another example, say that databases get reindexed on a nightly basis. In this case, you might have to confirm that no one is changing information or locking records during the reindexing process.
Restricting logon hours is also a good way to be sure that an attacker is not logging in with stolen passwords during off-peak hours. You can restrict logon hours by days of the week, hours of the day, or both. You can also assign time-of-day restrictions to ensure that employees use computers only during specified hours. Such restrictions can be useful for organizations when users require supervision, when security certification requires it, or when employees are mainly temporary or shift workers.
Each OS is different, and the effects of a restriction may depend on whether the user is currently logged on when the restriction time begins. In a Microsoft environment, the Automatically Log Off Users setting determines whether users are forced to log off when their logon hours expire. In other environments, the user might be allowed to stay logged on, but once logged off, the user cannot log back on. The logon schedule is enforced by the Kerberos group policy setting Enforce User Logon Restrictions, which is enabled by default in Windows Active Directory environments.

Because employees have become very mobile, organizations often implement BYOD policies. Location-based policies allow organizations to permit users to access resources in both organizational and personal location settings. Location-based policies are policies based on where a user or device is located. One example is a web filtering policy that prevents inappropriate surfing in the workplace but allows employees to have unrestricted access to web content when they are outside the corporate environment. In the past, organizations often restricted access from anywhere except the corporate headquarters where everybody works. Mobile devices have eliminated some of the traditional boundaries. Say that a specific user needs to access particular systems but should be allowed to do so only when in her home country. If she is outside the country, she should be prevented from authenticating. Attributes on the user’s mobile devices can be set to protect the network and systems by allowing access only in the home country. These attributes are related to location, and many of them are made possible through the use of location-based services.

The following are three common location-based services:
- Geofencing: Geofencing is a location-based service that is used to trigger some type of action when a user exits or enters a geographic boundary. For example, a smart thermostat might turn on the air conditioning when a user’s phone enters a 3-mile radius of the home.
- Geolocation: Geolocation identifies a device based on its current geographic coordinates.
- Geotagging: Geotagging adds an identifying tag to something based on the location. For example, every photo taken with a smartphone can be tagged with the geographic coordinates where the photograph was taken.

Geolocation can be used in account policy decision making, much like the network location of an IP address. Through the use of location awareness, organizations can more intelligently protect systems. For example, an organization can prevent impossible logins, as a way of protecting authentication credentials. Say that a user logs in to a system today first thing in the morning from his home office in New York City. Then three hours later, the same user logs in to a system from Los Angeles. The organization could have high confidence that this is not possible and could, via policy, prevent the second login from succeeding; it could even disable the account or force a password reset.

Logical Access Controls
A user account holds information about a specific user, such as name, password, and the level of permission the user has in the associated access control lists (ACLs). User accounts should follow standard naming conventions and can also contain more specific information, such as the department the user works in, a home phone number, and the days and hours the user is allowed to log on to specific workstations. Groups can be created to make the sharing of resources more manageable. A group contains users who share a common need for access to a particular resource; groups can be nested in other groups to better aggregate access permissions for multiple roles. Even though the particular terms might differ from one operating system to another, they all refer to the access that a user or group account is specifically granted or denied.

When working with logical controls, two models exist for assigning permissions and rights:
- User-based model:
In the user-based model, permissions are uniquely assigned to each user account. For example, in a peer-to-peer network or a workgroup, access may be granted based on individual needs. The user-based access type is also found in government and military situations and in private companies where patented processes and trademark products require protection. User-based privilege management is usually implemented for specific parts of the network or specific resources. This type of policy is time-consuming and difficult for administrators to handle, and it does not work well in large environments. You will find that creating groups and assigning users to those groups makes the administration process much easier.
- Role- or group-based model: When working with groups, remember that no matter what OS you are working with, if you give a user full access in one group and deny access in another group, the result is deny access. However, group permissions are cumulative. Therefore, if a user belongs to two groups and one of them has more liberal access, the user will have the more liberal access, except where the deny access permission is involved. If a user has difficulty accessing information after he or she has been added to a new group, the first item to check for is conflicting permissions.
When assigning user permissions, remember that if one of the groups to which the user is assigned has liberal access and another group has no access, the result is no access.
Access control over large numbers of user accounts can be more easily accomplished by managing the access permissions on each group; those permissions are then inherited by the group’s members. In this type of access, permissions are assigned to groups, and user accounts become members of the groups based on their organizational roles. Each user account has access based on the combined permissions inherited from its various group memberships. These groups often reflect divisions or departments of the company, such as human resources, sales, development, and management. In enterprise networks, groups can also be nested. Group nesting can simplify permission assignment if you know how to use hierarchical nesting. On the other hand, group nesting can complicate troubleshooting if you do not know what was set up for each level or why and, thus, do not know where a deny or allow permission is assigned.

Account Policy Enforcement
As the number of systems and users grows in an organization, account policy enforcement becomes critical. An organization should set account policies that define strong security for its systems. Account policies are a subset of the policies that are configurable in group policy.
Credentials must be assigned for specified time periods, with an automatic failover to access denial if they are not renewed to ensure that provisioned accounts are used and then cease to operate. This is often necessary in workforces of short-term or temporary workers, whose accounts could otherwise be left intact and unmonitored after the workers rotate to new positions. Such an account presents a target for brute-force types of attacks on logon passwords, whereby the login attempts can be spread over a long period of time to avoid detection of the potentially many failed logins.
The Account Expires attribute specifies when an account expires and can be used to enhance security. For example, temporary or contract workers should have user accounts that are valid for only a certain amount of time. This way, when an account expires, it can no longer be used to log on to any service. Statistics show that many temporary accounts are never disabled. Limiting the time an account is active for such employees should be part of the policies and procedures. In addition, user accounts should be audited on a regular basis and deprovisioned or reprovisioned based on role changes.
Every credential, whether a simple logon password, certificate, token, or smart card, should carry a built-in lifetime that ensures termination of that credential, even if it is lost or forgotten. Auditing procedures need to reveal long-term inactive accounts and machine accounts that should be routinely expired and reestablished to protect against long-term attacks and limit exploitation if they are compromised during the normal period of use.
In Windows environments, Active Directory domains use Group Policy Objects (GPOs) to store a wide variety of configuration information, including password policy settings. Domain account policy settings control password settings. These settings are contained within the default domain GPO and applied at the domain level. The domain may contain Organizational Units (OUs) that have their own defined account policy. In these situations, the OU policy will be enforced but only when the user logs on locally to the machine (for example, not into the domain).
Of course, passwords are often used to gain access to services and resources, so password length, duration, history, and complexity requirements are all important to the security of a network. When setting up user accounts, it is important to carefully plan policies.
In organizations that use Windows Active Directory Domain Services (AD DS) or a similar directory service architecture for enterprise management, group policy assignment of access controls can mandate that security configuration technical controls be applied based on organizational unit or domain membership to handle all accounts within an organization or to establish default configuration settings.

Password Complexity
Passwords that contain only alphanumeric characters are easy to compromise by using publicly available tools. Passwords should therefore contain additional characters and meet complexity requirements. Windows specifies the following criteria for a strong password:
- The password may not contain the user’s account name or full name value.
- The password must contain three of the following: uppercase letters, lowercase letters, numbers, nonalphanumeric characters (special characters), and any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase.
Complexity requirements can be enforced when passwords are changed or created. These requirements, combined with a minimum password length of eight, ensure that there are at least 218,340,105,584,896 different possibilities for a single password, which means a brute-force attack would be difficult—though not impossible.

Account Expiration
In the normal course of business, you might sometimes create domain user accounts for a short duration. This type of account is useful for contractors or temporary employees, for example. With this kind of user, accounts should automatically expire after a specified date. When an account expires, the user then is no longer allowed to log on to the domain, and the operating system displays an error message, informing the user that the account has expired.

Forgotten Passwords
If a user forgets a password, administrators should not be able to recover the old password. Instead, they should verify the proper identity and issue new credentials. When a user forgets a password, the user will need to perform a password reset. Password resets are also performed when a new account is created to set an initial password. Password resets can take place in several ways, ranging from an in-person visit with an IT staff member to a fully automated self-service utility. If the identity of the user requesting a password reset is not properly verified, an attacker could easily pose as a user and gain access to that user’s password. Reset mechanisms should first verify the user’s identity. Common verification methods include using predetermined challenge/response questions set during account creation, emailing recovery information, or texting a code to the user’s mobile phone.

Account Lockout
Account lockout policy settings help prevent attackers from guessing users’ passwords and decrease the likelihood of successful attacks on a network. An account lockout policy disables a user account when an incorrect password is entered a specified number of times over a certain time period. Account lockout policy settings control the threshold for this response and the actions to be taken when the threshold is reached.

The figure below shows the Windows local security policy settings for the account lockout policy and associated values.



Windows local security policy settings for the account lockout policy

The Account Lockout Duration Policy setting determines the number of minutes that a locked-out account remains locked out before it is automatically unlocked. The available range is from 1 through 99,999 minutes. A lockout duration value of 0 specifies that the account will be locked out until an administrator explicitly unlocks it. The lockout threshold can be set to any value from 0 to 999. If the lockout threshold is set to 0, accounts will not be locked out due to invalid logon attempts. The Reset Account Lockout Counter After setting determines the number of minutes that must elapse from the time a user fails to log on before the failed logon attempt counter is reset to 0. If the account lockout threshold is set to a number greater than 0, this reset time must be less than or equal to the value of account lockout duration. A disadvantage of configuring these settings too restrictively is that users might have to make excessive help desk calls. General best practices dictate that you lock out user accounts after three to five failed login attempts to prevent programs from deciphering the passwords on locked accounts through repeated brute-force attempts.

Password Age and History
The Maximum Password Age setting determines the number of days that a password can be used before the system requires the user to change it. You can set passwords to expire after any number of days between 1 and 999, or you can specify that passwords never expire by setting the number of days to 0. Microsoft operating systems use both a maximum password age and a minimum password age. If the maximum password age is set, the minimum password age must be less than the maximum password age. When the maximum password age is set to 0, the minimum password age can be any value between 0 and 998 days. Consider the following suggestions related to password age:
- Set the maximum password age to a value between 30 and 90 days, depending on the environment.
- Try to expire the passwords between major business cycles to prevent work loss.
- Configure a minimum password age so that you do not allow passwords to be changed immediately. This way, an attacker has a limited amount of time in which to compromise a user’s password and gain access to network resources.

The figure below shows the Windows Local security policy settings for the password policy and associated values.



Windows local security policy settings for the password policy

Password history or reuse is an important concern in any organization. When allowed to do so, users tend to reuse the same password over a long period of time. The longer the same password is used for a particular account, the greater the chance that an attacker will be able to determine the password through brute-force attacks. Allowing users to reuse old passwords greatly reduces the effectiveness of a good password policy.
Most operating systems have settings that manage the password history and do not allow users to reuse a password for a certain length of time or before a certain number of password changes. The Enforce Password History setting in Windows operating systems determines the number of unique new passwords that must be associated with a user account before an old password can be reused. Specifying a low number for this setting allows users to continually use the same small number of passwords repeatedly. Configure the server to not allow users to use the same password this way. Setting Enforce Password History to 24 helps mitigate vulnerabilities caused by password reuse.

Password Length and Rotation
Making the password length at least 8 characters and requiring combinations of uppercase and lowercase letters, numbers, and special characters is good practice. In Windows operating systems, the Minimum Password Length setting determines the least number of characters that can make up a password for a user account. You can set a value of between 1 and 14 characters, or you can establish that no password is required by setting the number of characters to 0.
In most environments, an 8-character password is recommended because this is long enough to provide adequate security but still short enough for users to easily remember. Adding complexity requirements helps reduce the possibility of a dictionary attack. Although longer passwords are more effective against attacks, requiring long passwords can lead to account lockouts due to mistyping and can actually decrease security because users might be more likely to write down their passwords. User education on the proper way to create long passwords that they can easily remember is the best solution.
The key aspects of password control include required complexity, password length, and account lockout/expiration terms. Password policies help secure a network and define the responsibilities of users who have been given access to company resources. You can use the account lockout policy to secure a system against attacks by disabling the account after a certain number of attempts for a certain period of time.
Require users to change passwords every 30 to 90 days, depending on how secure the environment needs to be. Remember that the more often users are required to change passwords, the greater the chance that they will write them down, potentially exposing them to unauthorized use.

Quiz:

1. Your corporate policies require the use of passphrases rather than passwords. Which of the following technical controls could be put in place to best promote the use of passphrases? (Select two.) A. Lockout B. Length C. History D. Complexity

2. Your account policies require employees to change their passwords every 30 days. The employees, however, continue to create passwords that are susceptible to dictionary attacks, and they are just alternating between two passwords with each change. Which of the following policies would be the best choices for fixing this? (Select two.)

3. What is the term for disabling, deactivating, or deleting a user identity from the environment based on company policy when the user leaves the company? A. Least privilege B. IdP C. Onboarding D. Offboarding

4. Every photo taken with a smartphone at an investigation firm includes data on the geographic coordinates where the photograph was taken. What term describes this action? A. Geofencing B. Geosynchronous C. GPO D. Geotagging

5. Ramone, a user in your organization, is a member of the accounting group, which has full access permission to a folder named Private Information Assigned. Ramone also belongs to the sales group, which has deny access permission assigned to the same private information folder. What can Ramone do to the private information folder? A. Nothing B. Everything C. Save files to the folder D. Save files to the folder and delete files in the folder

Answer 1: B and D. Length would ensure longer choices, and complexity would ensure the use of special characters and mixed case. Answer A is incorrect as a lockout would lock the user out after a specified number of incorrect attempts. Answer C is incorrect as history would enforce the allowed number of times a new password must be used before an old password can be reused.
Answer 2: C and D. A history policy determines the number of times a user must create new passwords before being able to reuse a previous one, so it prevents a user from alternating between two passwords. For example, a history setting of 30 would mean the user could not reuse the same password until the 31st password change. Complexity would help prevent password cracking. Answers A and B are incorrect. While length seems viable, complexity is a better choice, given the dictionary attacks. Lockout is related to requiring an account reset (based on too many invalid passwords, for example).
Answer 3: D. Offboarding means that identities of users who no longer require access to the environment are disabled or deactivated and then deleted from the environment, based on organizational policy. Onboarding is the opposite process, so answer C is incorrect. Answer A is incorrect because least privilege is an access control practice in which a logon is provided only the minimum access to the resources required to perform its tasks. Answer B is incorrect because the organization creating and managing identity, known as the identity provider (IdP), is responsible for authenticating the identity.
Answer 4: D. Geotagging adds an identifying tag to something based on location. For example, every photo taken with a smartphone is tagged with the geographic coordinates of where the photograph was taken. Geolocation can be used in account policy decision making, much like the network location of an IP address. Answer A is incorrect because geofencing is used to trigger some type of action when the user exits or enters a geographic boundary. Answer B is incorrect because the term geosynchronous describes a satellite that follows the pattern of the earth’s orbit. Answer C is incorrect because Active Directory (AD) domains use group policy objects (GPOs) to store a wide variety of configuration information, including password policy settings.
Answer 5: A. No matter what OS you are working with, if you give a user full access in one group and deny access in another group, the result is deny access. However, group permissions are cumulative. Therefore, if a user belongs to two groups, and one has more liberal access, the user will have the more liberal access, except where the deny access permission is involved. If a user has difficulty accessing information after he or she has been added to a new group, the first item to check for is conflicting permissions. Therefore, answers B, C, and D are incorrect.