CompTIA Security+ SYO-401

Certification Training
9954 Learners
View Course Now!
33 Chapters +

Installing and Configuring Security Controls Tutorial

1 Installing and Configuring Security Controls when Performing Account Management

Let’s recall the basic concept covered in the previous lesson, where we discussed the need to reveal the users’ identity along with the proof for authentication to access a network as well as authorization to access the desired resources. The important question that we should consider is whether these measures are sufficient to ensure complete security? Let’s examine a few situations where a security breach can occur. • A user cannot log in because he or she has forgotten the password. The security will be breached if the solution to this issue is to write down passwords on paper. Even if you give forgot password option, it is possible for the users to try one of the previously used passwords or some very easy to remember secret phrase such as birth date or name. • A user sticks to only a single password for months, which increases the risk of password cracking. • An intruder tries to log in by entering a genuine user’s username and password repeatedly and succeeds in doing so. • An administrator performs both administrative and reviewing tasks using just a single set of credentials, which can lead to security compromise. • Two or more users share a single guest account for accessing common resources such as a network printer. • Credentials of a user who has left the company is still being accepted for logging onto the internal network. Examining the above scenarios, it is evident that the authentication and authorization are not enough to ensure 100% security. As a system administrator, you will have to take more actions by managing user accounts or credentials. This is perhaps in the form of user account policies for dictating credential or account usage rules or best practices. The access levels of users have a direct impact on the level of network protection. Although it may sound a bit odd that the network needs protection from its own users, it is also a fact that these internal users have maximum rights and privileges, sufficient to disrupt deliberately or misuse its resources even accidentally. Upon logon, by revealing a rule or statement that the access is granted to users if a few conditions are fulfilled or that their activities are monitored will help in following security policy protocols or policies and obtain legal ramifications for non-compliance. So, let us begin this lesson by exploring the best practices or polices for managing user accounts, which all users must agree upon after a fair discussion and understanding of their benefits. The following screen explains the objectives covered in this lesson. After completing this lesson, you will be able to: • Mitigate issues associated with users who have multiple accounts/roles and/or shared accounts. • Enforce different account policy settings for securing the systems. • Apply privileges to groups and individual users for access control monitoring, and • Describe the significance of reviewing and continuous monitoring of what the user actually accesses through the system.

2 Mitigate Issues Associated with users with Multiple Accounts/Roles and/or Shared Accounts

Now, you will learn how to mitigate issues associated with users with multiple account or roles, and/or shared accounts. In most organizations, it is common to have several users operating in several capacities. The most common example is of an administrator who usually has two accounts namely, administrator and standard. So, what is the issue here? Well, the issue can be the administrator, intentionally or unintentionally, may use the administrative account when it is not supposed to be used, for example, for browsing the Internet. Therefore, the best practice is to use the standard account for mundane daily tasks, while the administrator account with special privileges should be used for special administrator functions. Doing so necessitates the user to use the right account for performing the related task. It also restricts the time for which a highly privileged account is in use as well as prevents using it at the time of higher security breach or data loss, such as while browsing the Internet or doing general file transfers. In short, such distinction limits the span of operation for each of their accounts and reduce security breach. A good real-life example of such use of accounts is the pseudo or superuser-do-command that Linux users use to perform administrative tasks from their session account. Within an organization, it is also common to have users with multiple roles. For example, a user might be a helpdesk administrator as well as a services administrator. In the former role, the user has the authority to reset passwords for non-administrators and view organizational structure and user profiles. Similarly, in the latter role, the user can turn services on or off; modify settings, and access rights of various network service settings. Keeping in mind the best practice learned in the previous screen, it is suggested to create two separate administrator accounts for this user with different administrative roles. This should be namely helpdesk administrator and services administrator. Doing so enforces distinct authentication for various tasks done. Further, it prevents having just one password for each account, which increases security for the two roles. Bluntly speaking, a standard work environment should refrain from implementing a shared account. This is because, it is impossible to track and distinguish actions of individual users accessing the same account. It is vital for all users to use only their own account as per the role, so that the permissions are uniquely applied, and auditing every action of each individual becomes a hassle-free process. Therefore, a shared account should be used only for public connections or for resources with low security threat. In this topic, you will learn about account policy enforcement for exploring the best practices for access control as well as account management. With the growing number of users and systems in an enterprise, it becomes indispensable to enforce an account policy. Such a policy establishes a set of security parameters governing who can access the system or network. Therefore, you need to create account policies defining strong, but not stringent, security parameters for your systems. For example, your policy can define the minimum length of user passwords, and how often it needs to be changed. Implementing such features as a requirement is possible through account policy enforcement. Because the rules relate to passwords, they are part of the password policy. It is vital to note that account policies are a part of the policies you can configure using the Group Policy Editor. You can access this by entering g-p-e-d-i-t dot m-s-c in the Run dialog box of Windows OS. However, the rules or policy should not be stringent. There is a fine line of distinction between stringent and lenient security. If you enforce stringent security, for example in the form of long passwords, you are likely to force users to trigger a security breach. This is because the users will become uncomfortable with such policies, and shall unknowingly jeopardize the security by writing down those long passwords on paper, just to fall in the wrong hands.

3 Enforce Different Account Policy Settings for Securing the Systems

Now, let’s explore the best practices related to the main components of account policy enforcement. Credential management refers to a software product or a service designed to store, track, and manage user credentials. These solutions allow storing all online and local login credentials of a user in a local- or cloud-based container and using the same to access internal networks or Internet. Although several such solutions exist for enterprise networks with thousands of users, most of them are for end-user deployment. Newer versions of Windows come with a credential manager for simplifying the management of credentials. With the help of a proper credential manager, you allow users to have more random and longer credentials for their different accounts, without the risk of writing them somewhere, as well as without the burden of remembering them. These saved credentials can include the encrypted ones. Group policy refers to the means through which Windows systems are managed in an environment of Windows network domain. A Group Policy Object or G-P-O refers to the set of registry settings applicable to a system while booting or user login. In the vast collection of settings available in a GPO, several settings are about credentials, such as password history, account lockout, password history, and password complexity requirements. Active Directory domains rely upon Group Policy objects for storing configuration information, this even includes settings related to passwords. In addition to the local password policy, domains tend to possess their own password policy for controlling password settings. In Group Policy, the account policies settings are applicable at the domain level. These domain account policy settings act as the default local settings for any Windows-based system, which is a domain member. However, there is an exception to this rule: Another setting for account policies stated for an Organizational Unit or O-U, affects the local policy on any system, and is always considered before applying the settings. Through a group policy, a Windows administrator can ensure consistent application of configurations as well as security settings across all users in a small or big network. Proper maintenance and timely changes of these group policies allow quick auditing and reporting on "Who" did "What" type of policy object change from "Where" and "When".

4 Password Complexity as the Best Practice

Let’s now take a look at best practices for passwords. A password policy acts as both a set of rules belonging to the organizational security policy for stating the password requirements of both users and devices, and as a tool enforcing password rules. It usually contains requirements for password history, minimum password length, minimum password age, maximum password age, and any other kind of complexity. When it comes to complexity setting, it often enforces having at least three out of four character types such as symbols, numbers, uppercase letters, and lowercase letters in a password. Simultaneously, it prohibits using real name, username, dictionary or common words, and email address as a part of a password. This is in practice by the Local Group Policy on Windows 7 and 8, when you select Password must meet complexity requirements in the Group Policy Object Editor. Generally, the more difficult or complex a password is, the tougher it is to break that password. However, this also means more difficulty for the user to remember it. Therefore, it is essential to achieve a good balance between the two extremes. Now, let’s explore the best practice for password length. Similarly, when it comes to defining the length of a password, it is fairly safe to have passwords of more than 12 characters, although it is a common practice to have a minimum eight characters. Passwords more than 15 characters are believed to be more secure. As a rule of thumb, the more characters along with some complexity of character type, the more resistant a password is to guessing or cracking attacks, especially brute force attacks. Considering that a standard brute force attack makes ten thousand attempts per second, having just eight characters as a combination of upper case, lower case, digits, and symbols can make the brute force attack take almost 19,000 years to be successful. Oh! That’s next to impossible to allow somebody to crack your password, right? So, this is the biggest benefit of enforcing a complexity requirement together with at least eight characters for passwords. Passwords should be strong enough to resist discovery through attack but easy enough for the person to remember. One of the security loopholes is to keep and use the same password for a very long time. The longer the same password is in use, the more are the chances for it to be hacked. Therefore, every password needs to expire. As a common rule, an acceptable duration for using a password is 90 days after which a new password must be in use. However, Microsoft recommends 42 days, for enforcing a strong password usage across the units of organization. Nevertheless, the length and time for a password to expire can vary as per the risk and threat levels. Except for the exam sake, changing a password because of its age is not the core idea. This is because a long and complex password can exist for a long time, as it is quite strong. A password is strong if it has eight or more diverse characters but not names, email addresses, and common words, includes a minimum of three types of characters, and is changed every 90 days. Password expiry should also be enforced if it has been reused, is apparently insecure, does not comply with company password policy, or is likely to be compromised by an intruder. With the expiration date, it is recommended to set minimum number of days to change the passwords. If you keep this setting at a too low value, let’s say a day; a user can change the new password to other phrase instantly, which is something that even a hacker might want to do. Therefore, consider setting this duration of at least two days. One of the assurances in the business world is that users will forget their password at some point of time. This usually happens shortly after changing the password, although it can occur even after a long holiday or weekend. Now, there are two ways to regain this password back: Recover and change. Truly speaking, password recovery is not an ideal security solution. This is because recovering a password demands reversing the password storage mechanism or fetching it in multiple ways. This is likely to expose the passwords to administrators, which is not ideal from security viewpoint. Therefore, when a password is forgotten, changing or resetting it, is an ideal security solution. Because a password is not stored on a majority of operating systems and that only its hash value is retained, the administrator can change the password that a user has forgotten. With this new value, the user can logon and instantly change that value to a new password that is easy to remember. Another way to reset the password is to give the option of forgot password. By clicking on forgot password link, you can verify the user’s identity and then allow the user to enter a new password and forget the forgotten password forever. Moreover, you as a system administrator must also ensure recovery of any deleted accounts apart from recovering any forgotten passwords. A critical password policy to apply, is the password history setting. This setting ensures prevention of using the same passwords by keeping the already used passwords. You can consider enabling this setting if you want to keep the users away from changing their password to an already used one. The value of this setting indicates the number of passwords that should be remembered or kept in the record in the form of a hash value. For highest level of security, it is recommended to set it to 24. This means that a user needs to use 24 unique passwords before he or she can reuse them. If allowed, password reuse for a long period increases the chance of identifying that password via brute-force attacks. Therefore, allowing password reuse significantly decreases the effectiveness of a good password policy. Therefore, simply determine what the company policy on password reuse is and set up the password history setting accordingly to enforce that policy. Forbidding the reuse of already used passwords and necessitating regular password changes at every 90 days help in maximizing security of a system depending upon passwords as the chief means of authentication. Let’s now look at the security parameters at the user account level. Account disablement or expiration automatically disables an account or causes it to expire on a specific day and at a specific time. It is perhaps a highly secure feature of an operating system available for user accounts, especially for temporary workers. For example, you may have female employees going on wedding or maternity leaves. In this case, you should disable their user accounts until they return. This is because all its settings and data through folders need to be kept intact. Similarly, you may create domain user accounts for interns or contractors. In this case, you must ensure that these accounts automatically expire after a predetermined date so that the user can no longer access the domain. Note that these examples convey you two extreme policies namely, disabling and removing the account. While the accounts are temporarily disabled in the former example, the latter example shows the removal of temporary accounts. In case there are chances of a terminated contractor to come back to work, consider disabling the account as opposed to removing it. It is a good policy not to rename or reuse the account of a terminated or leaving user. However, you may disable the account for such users as per the company policy, for keeping the associated data for a certain period. For example, your organization might have a policy to keep disabled accounts for 60 days after which you can remove it. Between the two extremes of disabling and removing an account, lies the requirement of locking the account. An account lockout automatically disables a user’s account when a logon attempt is made but fails repeatedly perhaps due to incorrect password. Locking the account becomes essential to prevent a would-be attacker from guessing the password values repeatedly until a match is found. Account lockout is often set to lock an account after three to five consecutive failed attempts to login, within a short period of say, 15 minutes. Once locked, an account may remain disabled permanently until an administrator intervenes to restore it. Let’s now see how to configure the account lockout security parameter. Configurable at local or domain level, the lockout policy has three values to set. Account lockout duration – This setting determines the time for the system to unlock the account. In case of Windows, this duration ranges from 0 to 99,999 minutes. If it is set to zero, you need an administrator to unlock the account explicitly, before using it again. Account lockout threshold – This setting determines the number of incorrect attempts to be made before locking the account. In case of Windows, this number ranges from 0 to 999. If it is set to zero, the account shall never be locked. It is vital to note that the attempts made to come out of the password-protected screensaver is equal to those made after pressing the Ctrl + Alt + Delete combination, and when the system boots. Reset account lockout counter after – This setting indicates the time for which the user waits between consecutive failed login attempts. For instance, if the set account lockout threshold is set to 3, and this setting to 5, the user can wait for five minutes after a failure attempt, and then try again just to gain five more attempts before locking the account. The value of this setting can be from 0 to 99,999 minutes and is only applicable if the account lockout threshold is set. Further, the reset time should not be greater than the account lockout duration value. A generic account refers to any account shared for enabling multiple users to log on for accessing a system, resource, or a network. Such accounts can be of guests, anonymous users, and temporary users. Although a generic account makes it easier to access the system, it comes with key issues. First in the form of shared password going against the security policy, and second in the form of dreadful auditing due to non-clarity of who did what. Therefore, just like shared accounts, all other generic accounts should be avoided. According to the generic account prohibition security parameter, no generic, anonymous, or shared accounts are allowed on systems and private networks where security is of utmost importance. It is possible to track each activity of each user only when each of them has a unique account so that an administrator can hold them accountable for violating any policy of the company.

5 Account Disablement as the Best Practice

In this topic, you will learn about the best practices for monitoring access control for user accounts. A majority part of access control involves monitoring access to the network or system as well as ensuring effective implementation of the company’s access control model and policies. There are four best practices for monitoring access control, namely, group-based privileges, user assigned privileges, user access reviews, and continuous monitoring. As the name indicates, group-based privileges are obtained for being a group member. Think of it as being a member of the report creators group due to which it is possible to have access to all resources required by report creators. This makes it easier for an administrator to give permissions at once to all group members, instead of individually assigning to each of them. Group-based access control gives the same level of access to a resource or object to every member. Many operating systems allow granting group-based privileges, including Linux and Windows. In Unix or Linux, each object to which a group has access, offers three types of permissions, namely, for the owner, for the owner’s group, and for other users, such as Everyone or World. Group management in Windows is through Access Control Lists or ACLs. Each object possesses an access control list containing Access Control Entries or A-C-Es. Every such entry is for either a user or a group. In case of a group, all members are denied or granted the associated permissions on the resource or object. For group-assigned privileges, it’s vital to ensure that those privileges do not breach the principle of least privilege. Therefore, it’s vital to monitor the assigned privileges regularly. Further, you should ensure that you want to grant all members the same access to that object. If not, simply change the permissions. Regardless of the operating system, giving full access to a user in one group and denying the same to another group to which that same user belongs, the result is deny access. Keeping in mind that group permissions are cumulative, if a user is a member of two groups and one of them has a more liberal access, the user shall enjoy the most liberal access. The exception to this rule is, where the denying permission is set. Therefore, in case of any access difficulty after the user is added to a new group, you might want to look for conflicting permissions as the first thing. User-assigned privileges refer to permissions denied or granted on per user basis. As the name indicates, a user assigns the desired privileges or access rights to other users. For example, you can create a file in Windows and change the access permissions or privileges associated with it by allowing only a few users to write it, and others to read it. Having user-assigned privileges is a standard feature of operating systems, following discretionary access control, such as Windows and Unix. While all objects have an owner with specific privileges in Linux, an access control entry in access control list grants or denies permissions to a user. The best example of user-assigned privilege management is a workgroup or peer-to-peer network, where access is as per individual needs. Such access is also common in government and private companies, where patented techniques need protection. In most cases, user-based privilege management is usually for specific sections of a network, or for some resources. Such a policy is time-consuming and tough to handle for administrators. Moreover, it does not work efficiently in big environment, where group-based privilege management is a more efficient approach. Once the user access is assigned appropriately, it is critical to review the granted access regularly. Access review refers to a process of identifying whether a user’s access level is still suitable. This is because, the roles of people tend to change over a period of time within an organization. This necessitates the need to review user accounts, and find out if they still require the current access level. For example, a network administrator looking over the domain controller is now asked to look after the remote access servers. In this case, he should no longer access the domain controller. Does this remind you of something? Well, this is closely connected to the concept of least privileges. In short, account review ensures that there are no leftover privileges for the users from former job roles. Security involves holding users answerable for their actions. This accountability is ensured only if each user uses its own unique account and is enforced to offer strong authentication credentials. Furthermore, every account must possess clear authorization and access control restrictions. Last but not the least, all activities of each user must be made available for review through an auditing or logging mechanism. With these things in place, it becomes easier to carry out access reviews for finding out whether users perform appropriately or violate company policies.

6 Best Practices for Monitoring Access Control for User Accounts

Let’s now look at the last best practice for monitoring access control. Continuous monitoring refers to an ongoing audit of what a user literally accesses. Such monitoring is essential for detecting breaches and preventing insider threats. For instance, the human resources assistant needs access to files related to different employees. However, if the assistant is accessing a file without a genuine work-based reason, it is against security. Detecting this breach is possible only via continuously monitoring access. Continuous monitoring is meant for user accountability via user access reviews. It is quickly becoming a standard for security contracts and government regulations for getting a more comprehensive synopsis of security and compliance with security policies. This is because continuous monitoring signifies equal monitoring for all users, right from the moment they step into any logical or physical premises until they depart as well as consistent tracking of all activities, resources, and services on all devices. Such a comprehensive monitoring approach for auditing purpose increases the probability of grabbing evidence for abuse or violations.

8 Summary

Let us summarize the topics covered in this lesson. • Users with multiple accounts and/or multiple roles should use their corresponding account for performing respective tasks. • Under no circumstances should a work environment allow to use shared, anonymous, or generic accounts. • Credential management involves a software product or a service for storing, tracking, and managing user credentials safely. • Active Directory domains rely upon Group Policy Objects or GPOs for storing configuration information, including the settings related to passwords. • Password management includes managing requirements for users to create complex passwords and addresses issues of expiration, reuse, recovery, history, and length. • Changing a forgotten password is a more secured option than recovering it. • It is a good security policy to lock the account if the user trying to login submits a wrong password consecutively. • Four best practices for monitoring access control are in use namely, group-based privileges, user assigned privileges, user access reviews, and continuous monitoring. • User access review helps in identifying whether a user’s access level is still suitable. • Continuous monitoring refers to an ongoing audit of what a user literally accesses, helps detect any kind of security breach with proper evidence. With this we conclude this lesson, ‘Installing and Configuring Security Controls when Performing Account Management.’ The next lesson is, ‘Utilizing General Cryptography Concepts.’

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*