This chapter covers the following subjects:
Access Control Models Defined: This section gets into access control models, such as MAC, DAC, RBAC, and ABAC, plus methodologies such as implicit deny and job rotation. Before creating and enforcing policies, a plan of action has to be developed, and the access control model to be used should be at the core of that plan.
Rights, Permissions, and Policies: Here, we delve into users, groups, permissions, rights, and policies that can be created on a computer network. By configuring users, templates, and groups in a smart fashion, you can ease administration and increase security at the same time. Policies can control just about anything a user does on the network or on an individual computer. And security templates make it easier than ever to implement a secure set of policies.
Controlling user access is of paramount importance. You don’t want just any Tom, Dick, or Harry to gain admittance to your computer network! The first step in controlling user access is to define who needs to have access and what they need to have access to. After this is done, an access control plan must be developed. This primarily consists of choosing an access control model. Which model you should choose depends on your organization’s procedures and written policies, the level of security you need, and the amount of IT resources at your disposal. After a model has been selected, you should implement as many safe practices as possible to bolster the model’s effectiveness. Then, you can actually implement security on the computers and network. This includes creating and organizing secure users, groups, and other network objects such as organizational units. More important, it incorporates the use of policies and Group Policy objects. By configuring computer-based policies for your users, groups, and computers, you are forcing them to abide by your organization’s rules.
Access control models are methodologies in which admission to physical areas and, more important, computer systems is managed and organized. Access control, also known as an access policy, is extremely important when it comes to users accessing secure or confidential data. Some organizations also practice concepts such as separation of duties, job rotation, and least privilege. By combining these best practices along with an access control model, a robust plan can be developed concerning how users access confidential data and secure areas of a building.
There are several models for access control, each with its own special characteristics that you should know for the exam. Let’s discuss these now.
Discretionary access control (DAC) is an access control policy generally determined by the owner. Objects such as files and printers can be created and accessed by the owner. Also, the owner decides which users are allowed to have access to the objects, and what level of access they may have. The levels of access, or permissions, are stored in access control lists (ACLs).
Originally, DAC was described in The Orange Book as the Discretionary Security Policy and was meant to enforce a consistent set of rules governing limited access to identified individuals. The Orange Book’s proper name is the Trusted Computer System Evaluation Criteria, or TCSEC, and was developed by the U.S. Department of Defense (DoD); however, The Orange Book is old (they refer to it in the movie Hackers in the 1990s!), and the standard was superseded in 2005 by an international standard called the Common Criteria for Information Technology Security Evaluation (or simply Common Criteria). But the DAC methodology lives on in many of today’s personal computers and client/server networks.
An entire set of security standards was published by the DoD in the 1980s and 1990s known as the “Rainbow Series.” Although The Orange Book is the centerpiece of the series (maybe not in the color spectrum, but as far as security content), there are other ones you might come into contact with, such as The Red Book, which is the Trusted Network Interpretation standard. Some of the standards have been superseded, but they contain the basis for many of today’s security procedures.
An example of DAC would be a typical Windows computer with two users. User A can log on to the computer, create a folder, stock it with data, and then finally configure permissions so that only she can access the folder. User B can log on to the computer, but cannot access User A’s folder by default, unless User A says so, and configures it as so! However, User B can create his own folder and lock down permissions in the same way. Let’s say that there was a third user, User C, who wanted both User A and User B to have limited access to a folder that he created. That is also possible by setting specific permission levels, as shown in Figure 11-1. The first Properties window shows that User C (the owner) has Full Control permissions. This is normal because User C created the folder. But in the second Properties window, you see that User A has limited permissions, which were set by User C.
The owner of a resource controls the permissions to that resource! This is the core of the DAC model.
Windows networks/domains work in the same fashion. Access to objects is based on which user created them and what permissions they assign to those objects. However, in Windows networks we can group users together and assign permissions by way of roles as well. More on that in the role-based access control (RBAC) section.
In a way, DAC, when implemented in client-server networks, is sort of a decentralized administration model. Even though an administrator still has control over most, or all, resources (depending on company policy), the owners retain a certain amount of power over their own resources. But, many companies take away the ability for users to configure permissions. They may create folders and save data to them, but the permissions list is often generated on a parent folder by someone else and is inherited by the subfolder.
There are two important points to remember when talking about the DAC model: First, every object in the system has an owner, and the owner has control over its access policy; and second, access rights, or permissions, can be assigned by the owner to users to specifically control object access.
Mandatory access control (MAC) is an access control policy determined by a computer system, not by a user or owner, as it is in DAC. Permissions are predefined in the MAC model. Historically, it has been used in highly classified government and military multilevel systems, but you will find lesser implementations of it in today’s more common operating systems as well. The MAC model defines sensitivity labels that are assigned to subjects (users) and objects (files, folders, hardware devices, network connections, and so on). A subject’s label dictates its security level, or level of trust. An object’s label dictates what level of clearance is needed to access it, also known as a trust level (this is also known as data labeling). The access controls in a MAC system are based on the security classification of the data and “need-to-know” information—where a user can access only what the system considers absolutely necessary. Also, in the MAC model, data import and export are controlled. MAC is the strictest of the access control models.
An example of MAC can be seen in FreeBSD version 5.0 and higher. In this OS, access control modules can be installed that allow for security policies that label subjects and objects. The enforcement of the policies is done by administrators or by the OS; this is what makes it mandatory and sets it apart from DAC. Another example is Security-Enhanced Linux (SELinux), a set of kernel modifications to Linux that supports DoD-style mandatory access controls such as the requirement for trusted computing base (TCB). Though often interpreted differently, TCB can be described as the set of all hardware and software components critical to a system’s security and all associated protection mechanisms. The mechanisms must meet a certain standard, and SELinux helps accomplish this by modifying the kernel of the Linux OS in a secure manner. Like DAC, MAC was also originally defined in The Orange Book, but as the Mandatory Security Policy—a policy that enforces access control based on a user’s clearance and by the confidentiality levels of the data. Even though The Orange Book is deprecated, the concept of MAC lives on in today’s systems and is implemented in two ways:
Rule-based access control: Also known as label-based access control, this defines whether access should be granted or denied to objects by comparing the object label and the subject label.
Lattice-based access control: Used for more complex determinations of object access by subjects. Somewhat advanced mathematics are used to create sets of objects and subjects and define how the two interact.
Rule-based access control uses labels, is part of mandatory access control, and should not be confused with role-based access control.
Other related access control models include Bell-LaPadula, Biba, and Clark-Wilson. Bell-LaPadula is a state machine model used for enforcing access control in government applications. It is a less common multilevel security derivative of mandatory access control. This model focuses on data confidentiality and controlled access to classified information. The Biba Integrity Model describes rules for the protection of data integrity. Clark-Wilson is another integrity model that provides a foundation for specifying and analyzing an integrity policy for a computing system.
Role-based access control (RBAC) is an access model that, like MAC, is controlled by the system, and, unlike DAC, not by the owner of a resource. However, RBAC is different from MAC in the way that permissions are configured. RBAC works with sets of permissions, instead of individual permissions that are label-based. A set of permissions constitutes a role. When users are assigned to roles, they can then gain access to resources. A role might be the ability to complete a specific operation in an organization as opposed to accessing a single data file. For example, a person in a bank who wants to check a prospective client’s credit score would be attempting to perform a transaction that is allowed only if that person holds the proper role. So roles are created for various job functions in an organization. Roles might have overlapping privileges and responsibilities. Also, some general operations can be completed by all the employees of an organization. Because there is overlap, an administrator can develop role hierarchies; these define roles that can contain other roles, or have exclusive attributes.
Think about it. Did you ever notice that an administrator or root user is extremely powerful? Perhaps too powerful? And standard users are often not powerful enough to respond to their own needs or fix their own problems? Some operating systems counter this problem by creating mid-level accounts such as Power Users (Microsoft) or Operators (Solaris), but for large organizations, this is not flexible enough. Currently, more levels of roles and special groups of users are implemented in newer operating systems. RBAC is used in database access as well and is becoming more common in the healthcare industry and government.
Attribute-based access control (ABAC) is an access model that is dynamic and context-aware. Access rights are granted to users through the use of multiple policies that can combine various user, group, and resource attributes together. It makes use of IF-THEN statements based on the user and requested resource. For example, if David is a systems administrator, then allow full control access to the \dataserveradminfolder share. If implemented properly, it can be a more flexible solution. As of the writing of this book, many technologies—and organizations—are moving toward a more context-sensitive, context-aware mindset when it comes to authentication and access control.
Table 11-1 summarizes the four access control models just discussed: DAC, MAC, RBAC, and ABAC.
|Access Control Model
|Every object in the system has an owner.
Permissions are determined by the owner.
|Permissions are determined by the system.
Can be rule-based or lattice-based.
Labels are used to identify security levels of subjects and objects.
|Based on roles, or sets of permissions involved in an operation.
Controlled by the system.
|Context-aware, and dynamic authentication.
Uses IF-THEN statements to allow access.
Another type of access control method is known as anonymous access control—for example, access to an FTP server. This method uses attributes before access is granted to an object. Authentication is usually not required.
In general, access control can be centralized or decentralized. Centralized access control means that one entity is responsible for administering access to resources. Decentralized access control means that more than one entity is responsible, and those entities are closer to the actual resources than the entity would be in a centralized access control scenario.
After you decide on an access control model that fits your needs, you should consider employing some other concepts. Some of these are used in operating systems automatically to some extent:
Implicit deny: This concept denies all traffic to a resource unless the users generating that traffic are specifically granted access to the resource. Even if permissions haven’t been configured for the user in question, that person will still be denied access. This is a default setting for access control lists on a Cisco router. It is also used by default on Microsoft computers to a certain extent. Figure 11-2 shows an example of this. In the folder’s permissions, you can see that the Users group has the Read & Execute, List Folder Contents, and Read permissions set to Allow. But other permissions such as Modify are not configured at all—not set to Allow or Deny. Therefore, the users in the Users group cannot modify data inside the folder because that permission is implicitly denied. Likewise, they can’t take full control of the folder.
Implicit deny will deny users access to a resource unless they are specifically allowed access.
Least privilege: This is when users are given only the amount of privileges needed to do their job and not one iota more. A basic example of this would be the Guest account in a Windows computer. This account (when enabled) can surf the Web and use other basic applications but cannot make any modifications to the computer system. However, least privilege as a principle goes much further. One of the ideas behind the principle is to run the user session with only the processes necessary, thus reducing the amount of CPU power needed. This hopefully leads to better system stability and system security. Have you ever noticed that many crashed systems are due to users trying to do more than they really should be allowed? Or more than the computer can handle? The concept of least privilege tends to be absolute, whereas an absolute solution isn’t quite possible in the real world. It is difficult to gauge exactly what the “least” amount of privileges and processes would be. Instead, a security administrator should practice the implementation of minimal privilege, reducing what a user has access to as much as possible. Programmers also practice this when developing applications and operating systems, making sure that the app has only the least privilege necessary to accomplish what it needs to do. This concept is also known as “the principle of least privilege.”
Separation of duties: This is when more than one person is required to complete a particular task or operation. If one person has too much control and completes too many portions of a task, it can become a security risk. The more people involved, the less the chance that a job can be compromised. Checks and balances are employed to make sure that the proper equilibrium of users is maintained. One example of this would be the securing of a new network. There might be one or more security administrators in charge of doing the actual planning, and a couple more doing the actual implementation, and finally another group for testing; or perhaps, a third-party company will do the testing, keeping everything on the up and up. It all depends on the size of the organization and the internal trust level (and the IT budget!).
Separation of duties can also be applied to a single user. For example, if a user on a typical Windows computer (Vista or newer) has a specific set of privileges, but the user wants to do something on the system that requires administrative access, User Account Control (UAC) kicks in and asks for the proper credentials to perform the actions of that role. If the credentials cannot be supplied, UAC blocks the action, keeping the various duties separate.
Job rotation: This is one of the checks and balances that might be employed to enforce the proper separation of duties. Job rotation is when users are cycled through various assignments to
Increase user insight as to overall operations
Reduce employee boredom
Enhance employee skill level
Increase operation security
Job rotation creates a pool of people that can do an individual job and discourages hoarding of information. It also helps to protect the purity of an operation. By cross-training people in each department, you defend against fraud and increase awareness, making it easier to detect if it does happen.
By incorporating the implicit deny, least privilege, separation of duties, and job rotation concepts, your total access control plan can be improved greatly. These access control principles can be applied both to desktop computers and to mobile devices. However, the specific way they are applied will depend on the particular operating systems and the policies—both written and computerized—of the organization you work for.
Now that we have a plan for access control, we need to implement it in a tangible way. By strategically setting up organizational units, users, and groups, and by assigning permissions according to our chosen access control model, we can create a safe, guarded working area for all employees. In so doing, we can protect the data on the network.
User accounts can be added to individual computers or to networks. For example, a Windows client, Linux computer, or Mac can have multiple users. And larger networks that have a controlling server, for example, a Windows domain controller, enable user accounts that can access one or 251more computers on the domain. In a Microsoft domain, users are added in Active Directory Users and Computers (ADUC), as shown in Figure 11-3.
ADUC can be accessed from Administrative Tools or added as a snap-in to an MMC. Users can be added in one of two places:
In the Users folder: This is located inside the domain name within ADUC.
In an OU: Organizational units can be created within the domain. These are often made to mimic the departments of a company. In Figure 11-3, there are Accounting and Marketing OUs; users can be created within these OUs.
User rights can be modified within the particular user’s Properties window. There are many more rights associated with a user account that is stored on a Windows Server domain controller than there are on an individual Windows client computer. For example, the Account tab can be configured so that the user account has an expiration date. You can see this in Figure 11-4, where at the bottom of the Properties window, we had configured Alice’s account to expire on April 1, 2020—and that was no April Fools’ prank! Immediately after that expiration date, the user couldn’t log on to the domain unless her account was reconfigured or she logged on as someone else.
Users cannot log on to a network after their account has expired. The Account Expiration date in Windows controls this.
By clicking the Logon Hours button, time-of-day restrictions can be configured so that a user can log on only at certain times throughout the week. An example of this is shown in Figure 11-5. In the figure, Alice’s user account has been configured in such a way that she can log on to the domain only between 8 a.m. and 6 p.m. Monday through Friday. If she attempts to log on at any other time, the system will deny access. These kinds of access rights are available on domain controllers.
Users can log on to the network only during their configured logon hours.
Sometimes users have more than one account. This might have been done to allow access to multiple systems or resources. There are plenty of different issues that can occur because of this. To mitigate problems that can develop from a user having two accounts, consider the consolidation of accounts, for example, utilizing a federated identity management (FIM) system, one that will incorporate single sign-on (SSO). User administration can also benefit from credential management, where passwords, certificates, and other logon credentials are stored in a special folder called a vault. A security administrator should also consider the use of roles (RBAC) and user groups.
Groups can be created to classify users and to ease administration when assigning permissions. If you refer to Figure 11-3, you see that a group is displayed with a two-headed icon (for example, the Domain Admins group). Single users are displayed with a single head, as is the case with the Administrator. By grouping users together, you can save a lot of time when assigning permissions to files and other resources; instead of assigning permissions to one user at a time, it can be done to the entire group in one shot.
Permissions such as file and printer access can be assigned to individual users or to groups. These permissions (also known as access modes) are examples of access control lists (ACLs)—specifically, file system access control lists (abbreviated as FACL or FSACL). An ACL is a list of permissions attached to an object. ACLs reside on firewalls, routers, and computers. Permissions in an ACL might allow access or deny access. It all depends on who is required to have access; then, the configuration is up to you.
In a Windows environment, ACLs are broken down into individual access control entries (ACEs); for example, the user JohnT has read access to the marketing folder. Also, Microsoft uses the term discretionary access control list (DACL) to refer to an ACL that identifies trustees who are allowed or denied access to an object. It uses the term system access control list (SACL) to refer to an ACL that enables admins to log attempts to access a secured object.
In Windows, there are two types of permissions. Sharing permissions are basic permissions including Full Control, Change, and Read, which are applied to folders only. These are often ignored in favor of the more powerful (and superseding) NTFS permissions, also called security permissions, which can secure folders and individual files. In a standard Windows folder on a domain, the types of NTFS permissions include the following:
Read & Execute
List Folder Contents
These are shown in Figure 11-6 on a Windows Server in the Properties window of a folder named “testfolder.” Note that the Administrators group has full control of the folder. Also note that you can allow particular permissions, or specifically deny those permissions. If a permission is not set to Allow, it will be implicitly denied.
In Linux, file permissions are broken down into three types: read, write, and execute (R, W, and X). They can be assigned to three different permission groups: owner, group, and all users (U, G, and O or A). These can be assigned and configured in the command-line with the
chmod command (change mode), either by group letter or by using a designated numbering system. For example, in the latter case:
R (Read) = 4
W (Write) = 2
X (Execute) = 1
These are added together to form each permission. For example, if a user was given read and write access, the number would be 6. If, however, the person was given read, write, and execute access, the number would be 7. Here’s an example of the
chmod 760 testfile
In the example we have the
chmod command followed by the numbers 7, 6, and 0, and the name of the file, “testfile” (of course, the path to that file can be more complex). The first number, 7, represents the owner permission (which in this case is equal to full access). The second number, 6, represents the group permission (in this case read and write access). The final number, 0, represents the all users (or all other users) permission, which has no access. This is just an example; the numbers could be whatever you select for the three groups. You might see 777 when all groups have all permissions, though it is not normally recommended. It is common on a web server or file server to see 755, which means that the owner has all permissions, and the group and all users have read and execute permissions. You don’t want a typical user to have write permissions on a web server! In summary, the
chmod command is a great way to assign permissions to all three groups using a single command.
To avoid access violations when working with permissions, the “least privilege” or “minimal privilege” concept should be implemented. Give the users only the amount of access that they absolutely need. Note that permissions for long-term employees could suffer from privilege creep over time. To mitigate this, consider periodic user permission reviews and evaluation of ACLs. This permission auditing procedure will ensure that users have the access to the correct data. In general, this is known as user access recertification. Consider this procedure if a company has a particularly high attrition rate (hiring and terminating of employees). This will verify that users no longer with the company cannot log on to the network and cannot gain access to resources. It also ensures that new users can gain access to necessary resources.
If you create a folder, the default action it takes is to inherit permissions from the parent folder, which ultimately come from the root folder. So any permissions set in the parent are inherited by the subfolder. To view an example of this, locate any folder within an NTFS volume (besides the root folder), right-click it, and select Properties, access the Security tab, and click the Advanced button. That brings up a window as shown in Figure 11-7. If you look at the bottom of the figure, you can tell whether or not the folder is inheriting permissions from the parent. In this case, it is inheriting permissions.
This means that any permissions added or removed in the parent folder will also be added or removed in the current folder. In addition, those permissions inherited cannot be modified in the current folder. To make modifications, you would have to disable inheritance, either by clicking the button shown in Figure 11-7 or by deselecting a checkbox on older versions of Windows Server. When you do so, you have the option to copy the permissions from the parent to the current folder or remove them entirely. To summarize, by default the parent is automatically propagating permissions to the subfolder, and the subfolder is inheriting its permissions from the parent.
You can also propagate permission changes to subfolders not inheriting from the current folder. To do so, select the Replace All Child Object Permission Entries... checkbox.
This might all seem a bit confusing, and you will probably not be asked many questions on the subject. Just remember that folders automatically inherit from the parent unless you turn off inheriting—and you can propagate permission entries to subfolders at any time by selecting the Replace option.
In a Windows environment there are two types of permissions: share permissions and NTFS permissions. By default, the more restrictive of the two sets of permissions is applied to the user. However, quite often an administrator will configure NTFS permissions to take precedence over share permissions—and effectively “ignore” the share permissions.
This subject and the previous one are actually more advanced Microsoft concepts, the type you would be asked on a Microsoft exam, and less likely to be asked on a CompTIA exam, so we’ll try to keep this simple. Moving and copying folders have different results when it comes to permissions. Basically, it breaks down like this:
If you copy a folder (or file) on the same volume or to a different volume, the folder inherits the permissions of the parent folder it was copied to (target directory).
If you move a folder (or file) to a different location on the same volume, the folder retains its original permissions. (You cannot move a folder to a separate volume; if you attempt to do so it will automatically be copied to the other volume.)
Keep in mind that when you move data within a volume, the data isn’t actually relocated; instead the pointer to the file or folder is modified. Accordingly, permissions are not really moved either, so they remain the same.
The most common type of authentication is the username/password combination. Usernames are usually based on a person’s real name. Large organizations often use firstname.lastname as the standard naming convention (for example, [email protected]) or first initial and last name ([email protected]). Smaller organizations might use the first name and last initial. The naming convention decided upon should be easy for you to implement without name confusion, and it should have the capability to be utilized for all systems on the network, including login, e-mail, database, file access, and so on.
The password is either set by the user or created automatically for the user by an administrator or system. Figure 11-8 shows an example of a password created by the administrator. However, in this case, the user is not blocked from changing the password (unless a policy was created for that purpose). Note that the second checkbox, User Cannot Change Password, is not selected. As an administrator, you also have the option to select User Must Change Password at Next Logon. A user would have to pick a password when he first logs on to the domain, one that meets whatever complexity requirements your network calls for. This with the self-service password resetting (when users reset their own passwords at regular intervals) is necessary in larger networks to ease administration and increase security. The only caveat to this is account lockouts. Unlocking accounts that were locked by the system should be done only by an administrator or system operator.
At this point, it is common knowledge that a strong password is important for protecting a user account. Nowadays, many user accounts are compromised because of laziness; laziness on the part of the user for not configuring a strong password, or lethargic complacency on the part of the administrator for not enforcing the use of strong passwords.
But what is a strong password? That depends on the organization you deal with, but generally it is broken down into a few easy-to-remember points. Passwords should comply with the following:
Contain uppercase letters
Contain lowercase letters
Contain special characters (symbols)
Should be 8 to 10 characters or more. Some organizations that have extremely sensitive data will require 15 characters as a minimum.
The weak password and vendor-set default password can lead to data breaches. Attackers use weak or known passwords to access accounts and then perform unauthorized copying, transfer, and retrieval of data from servers—collectively known as data exfiltration. Data exfiltration is also known as data extrusion, data exportation, or simply stated—data theft. Whatever you call it, the complex password, and properly configured password policies, can help to prevent it.
Changing your password at regular intervals is important as well. The general rule of thumb is to change your password as often as you change your toothbrush. However, because this is a subjective concept (to put it nicely!), many organizations have policies concerning your password that we discuss in the next section. It might need to meet certain requirements, or be changed at regular intervals, and so forth.
Here are a few more tips when it comes to user accounts, passwords, and logons:
Rename and password protect the Administrator account: It’s nice that Windows has incorporated a separate Administrator account; the problem is that by default the account has no password. To configure this account, navigate to Computer Management > System Tools > Local Users and Groups > Users and locate the Administrator account. On a Windows server acting as a domain controller, this would be in ADUC > Domain name > Users. By right-clicking the account, you see a drop-down menu in which you can rename it and/or give it a password. (Just remember the new username and password!) Now it’s great to have this additional Administrator account on the shelf just in case the primary account fails; however, your organization’s policy might call for disabling it, which can be done by right-clicking the account and selecting Disable Account. (In older Windows systems, you would access the General tab of the account and select the Account Is Disabled checkbox.) Then, you would use that separate account previously created with administrative rights as your main administrative account. If you need access to the actual Administrator account later, it can be re-enabled using the methods previously described. Alternatively, open the command-line and type the following:
net user administrator /active:yes
The way that the Administrator account behaves by default depends on the version of Windows. The Linux/Unix counterpart is the root account. The same types of measures should be employed when dealing with this account.
Verify that the Guest account (and other unnecessary accounts) is disabled: This can be done by right-clicking the account in question, selecting Properties, and then selecting the checkbox named Account Is Disabled. It is also possible to delete accounts (aside from built-in accounts such as the Guest account); however, companies usually opt to have them disabled instead so that the company can retain information linking to the account. So, if an employee is terminated, the system administrator should generally implement the policy of account disablement. By disabling the account, the employee in question can no longer log in to the network, but the system administrator still has access to the history of that account.
Use Ctrl+Alt+Del: Pressing Ctrl+Alt+Del before the logon adds a layer of security to the logon process by ensuring that users are communicating by means of a trusted path when entering passwords. This can be added in Windows 10 by going to Run and typing netplwiz (which opens the User Accounts dialog box), then going to the Advanced tab and selecting the checkbox for Require Users to Press Ctrl+Alt+Delete. Or, it can be added as a policy on individual Windows computers within the Local Group Policy Editor. It is implemented by default for computers that are members of a domain.
Use policies: Policies governing user accounts, passwords, and so on can help you to enforce your rules, as discussed in the next section. Large organizations with a lot of users usually implement a self-service password management system. This means that users reset their own passwords after a given amount of time (set in a Group Policy); the administrator does not create passwords for users.
Policies are rules or guidelines used to guide decisions and achieve outcomes. They can be written or configured on a computer. The former are more difficult to enforce, whereas the latter would have to be hacked to be bypassed. Local computer policies and network policies are what really make an access control model effective.
Password policies can be implemented to enforce the usage of complex passwords and regulate how long passwords last. They can be configured on local computers, such as Windows operating systems, by navigating to Administrative Tools > Local Security Policy. When in the Local Security Settings window, continue to Security Settings > Account Policies > Password Policy.
More important, policies can be configured for an entire network; for example, on a Microsoft domain. This would be known as a group policy and there can be more than one. A group policy can affect the entire domain or an individual organizational unit. The main group policy is known as the Default Domain Policy. Figure 11-9 shows an example of the Default Domain Policy added to an MMC. To access the Password Policy section, you would navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy.
The Default Domain Policy affects all users. This is okay for small networks, but for larger networks, separate organizational units should be created, each with its own security policy. From there, group-based privileges and individual user-based privileges can be expertly defined.
When Password Policy is selected, you see the following policies:
Enforce password history: When this is defined, users cannot use any of the passwords remembered in the history. If you set the history to 3, the last three passwords cannot be reused when it is time to change the password.
Maximum and minimum password age: This defines exactly how long a password can be used. The maximum is initially set to 42 days but does not affect the default Administrator account. To enforce effective password history, the minimum must be higher than zero. This is part of a category known as password expiration.
Minimum password length: This requires that the password must be at least the specified number of characters. For a strong password policy, set this to 8 or more (as long as other complex requirements are also set; if not, the password should be longer).
Password must meet complexity requirements: This means that passwords must meet three of these four criteria: uppercase characters, lowercase characters, digits between 0 and 9, and non-alphabetic characters (special characters).
To effectively stop users from reusing the same password, a security administrator should combine the Enforce Password History policy with the Minimum Password Age policy. The Minimum Password Age setting must be less than the Maximum Password Age setting and must be more than zero to enforce a password history policy. In addition, the security administrator might need to create a policy that states that passwords cannot be changed more than once a day: This would prevent users from changing their passwords X number of times in an attempt to bypass that password history policy.
Remember that all these policies, when enabled, affect all users to which the policy applies. If it is the Default Domain Policy (usually not recommended for configuration), it affects all users; if it is an OU policy, it affects all users in the OU.
For more information on password policies and password best practices, see the follow-ing link:
There are plenty of other policies that you can configure. You can pretty much configure any policy on a domain. You can’t configure how a person should shave in the morning, but anything computer-related can be modified and policed. One example is how many attempts a person will be allowed when typing in a password. This is known as the Account Lockout Threshold, as shown in Figure 11-10. Many companies adjust this to 3; this is known as the “3 strikes and you’re out rule.”
Another great tool is the previous logon notification. This can be configured in a policy and shows the user the last time the account logged in successfully—generally during the logon process. If users suspect that their account was compromised, they could check the previous logon notification and compare that with when they remember logging in.
It’s important to note that when logging on to a Microsoft network, the logon process is secured by the Kerberos protocol, which is run by the domain controller. This adds a layer of protection for the username and password as they are authenticated across the network. When users take a break or go to lunch, they should lock the computer. This can be done by pressing Windows+L. When doing so, the operating system goes into a locked state, and the only way to unlock the computer is to enter the username and password of the person who locked the computer. The difference between this and logging out is that a locked computer keeps all the session’s applications and files open, whereas logging out closes all applications and open files. A policy can also be configured to force locking after a certain amount of time has elapsed. Literally hundreds of policies are configurable. You could spend weeks doing it! Microsoft understands this and offers various levels of security templates that can be imported into your OU policy, making your job as an administrator a bit easier. A particular template might be just what you are looking for, or it might need a bit of tweaking. But in most cases it beats starting from scratch!
Policies can be developed on all kinds of software and systems, not just operating systems. For example, many organizations have websites, and a good portion of those organizations now set up bulletin board systems where authorized users can post messages. Bulletin boards are also known as forums or portals. Bulletin boards are often the playground for malicious activity; for example, users or bots posting spam messages. Various policies can be implemented on an interactive bulletin board system to prevent these types of problems. For example, when people first register, they would need to answer a question that requires something they know such as 2+4 = blank. The user would enter the answer (6) and continue on their merry way. Another viable option is to use CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart), which can display an image that has letters and numbers in it. The user must type the letters and numbers that they see before they can register, or perhaps to post any messages at all. This is a good deterrent for bots!
User Account Control (UAC) is a security component of Windows that keeps every user (besides the actual Administrator account) in standard user mode instead of as an administrator with full administrative rights—even if the person is a member of the administrators group. It is meant to prevent unauthorized access, as well as avoid user error in the form of accidental changes. With UAC enabled, users perform common tasks as non-administrators, and, when necessary, as administrators, without having to switch users, log off, or use Run As.
Basically, UAC was created with two goals in mind:
To eliminate unnecessary requests for excessive administrative-level access to Windows resources
To reduce the risk of malicious software using the administrator’s access control to infect operating system files
When a standard end user requires administrator privileges to perform certain tasks such as installing an application, a small pop-up UAC window appears, notifying the user that an administrator credential is necessary. If the user has administrative rights and clicks Continue, the task is carried out, but if the user does not have sufficient rights, the attempt fails. Note that these pop-up UAC windows do not appear if the person is logged on with the actual Administrator account.
If necessary, UAC can be disabled in the Control Panel. However, it is not recommended.
There are other examples of generic account prohibition that work in the same manner as UAC. Third-party tools are available for Windows and Linux. An administrator might find that UAC does not have the configurability they desire. Regardless of the type of account prohibition used, it is important to conduct user access reviews—audits of what users have been able to access over time—and continuously monitor users’ actions in this regard. We’ll discuss this mindset in Chapter 13, “Monitoring and Auditing.”
Use the features in this section to study and review the topics in this chapter.
In order to have an efficient computer network, the security administrator needs to be in control. This is still feasible, even in today’s complicated computer networks. An admin can choose from several basic access control models: discretionary access control (DAC), mandatory access control (MAC), role-based access control (RBAC), and attribute-based access control (ABAC). Probably the most common is DAC; many Windows-controlled and Linux-controlled networks utilize this model. Whatever the model, remember that they are based on subjects (users) and objects (data files and other resources).
For access control to work well, it is wise to implement certain concepts such as implicit deny, where all traffic is denied except for what a user specifically needs; least privilege, where a user is only given the permissions necessary to perform a task; separation of duties, where more than one person is required to complete a task; and job rotation, where a pool of people can work on the same individual job if necessary. Used together, an access control model can be very effective.
A lot of the concepts in the preceding two paragraphs are intangibles. To secure access to data in the technical sense, permissions and policies are your best friends. Both large and small networks can benefit from the use of permissions and groups of users: Using permissions enables a more secure system; using groups of users allows you to automate the distribution of permissions to multiple users at once. Permissions are also known as rights, access modes, and, depending on the scenario, access control lists (ACLs). The common Windows system uses a set of six NTFS permissions spanning from the ability to read files only, all the way to having full control of those files. In Unix/Linux-based systems, three types of permissions—read, write, and execute—are assigned to users, groups, and owners by way of a three-digit number and the
Access control also hinges on authentication, the most common form of which is the username/password combination. The importance of complex passwords cannot be stressed enough. An organization will often require eight to ten characters minimum, including uppercase letters, numbers, and special characters. And all of this is usually enforced by a computerized policy. Password policies such as password history, maximum password age, minimum password length, and password complexity requirements, if configured properly, can offer your users a decent level of protection. The user accounts themselves can also be secured with the use of account lockouts, time-of-day restrictions, and User Account Control.
We mentioned in the beginning of the chapter that you don’t want any Tom, Dick, or Harry to get access to your data. If you don’t control access to your data, it is the equivalent of allowing the three stooges into your servers. You’d be surprised how many companies disregard best practices for access control. But when it comes to this layer of security, a little bit of planning and a modest piece of automated configuration can go a long way.
Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 11-2 lists a reference of these key topics and the page number on which each is found.
|Key Topic Element
|Example of discretionary access in Windows
|Summary of access control models
|Example of implicit deny on a Windows folder
|User account expiration date
|Time-of-day restrictions for a standard user
|Password Policy on a Windows Server Domain Controller
Define the following key terms from this chapter, and check your answers in the glossary:
Complete the Real-World Scenarios found on the companion website (www.pearsonitcertification.com/title/9780134846057). You will find a PDF containing the scenario and questions, and also supporting videos and simulations.
1. Which of the following is the strongest password?
2. Which of these is a security component of Windows?
D. Control Panel
3. What key combination helps to secure the logon process?
4. Which of the following is the most common authentication model?
A. Username and password
C. Key cards
5. Which of the following access control methods uses rules to govern whether object access will be allowed? (Select the best answer.)
A. Rule-based access control
B. Role-based access control
C. Discretionary access control
D. Mandatory access control
E. Attribute-based access control
6. When using the mandatory access control model, what component is needed?
7. Which of the following statements regarding the MAC model is true?
A. Mandatory access control is a dynamic model.
B. Mandatory access control enables an owner to establish access privileges to a resource.
C. Mandatory access control is not restrictive.
D. Mandatory access control users cannot share resources dynamically.
8. In the DAC model, how are permissions identified?
A. Role membership.
B. Access control lists.
C. They are predefined.
D. It is automatic.
9. Robert needs to access a resource. In the DAC model, what is used to identify him or other users?
10. A company has a high attrition rate. What should you ask the network administrator to do first? (Select the best answer.)
B. Review group policies.
C. Review Performance logs.
D. Review the Application log.
11. Your company has 1000 users. Which of the following password management systems will work best for your company?
A. Multiple access methods
B. Synchronize passwords
C. Historical passwords
D. Self-service password resetting
12. In a discretionary access control model, who is in charge of setting permissions to a resource?
A. The owner of the resource
B. The administrator
C. Any user of the computer
D. The administrator and the owner
13. Jason needs to add several users to a group. Which of the following will help him to get the job done faster?
D. Access control lists
14. How are permissions defined in the mandatory access control model?
A. Access control lists
B. User roles
C. Defined by the user
D. Predefined access privileges
15. Which of the following would lower the level of password security?
A. After a set number of failed attempts, the server will lock the user out, forcing her to call the administrator to re-enable her account.
B. Passwords must be greater than eight characters and contain at least one special character.
C. All passwords are set to expire after 30 days.
D. Complex passwords that users cannot change are randomly generated by the administrator.
16. Of the following access control models, which uses object labels? (Select the best answer.)
A. Discretionary access control
B. Role-based access control
D. Mandatory access control
E. Attribute-based access control
17. Which of the following methods could identify when an unauthorized access has occurred?
A. Two-factor authentication
B. Session termination
C. Previous logon notification
D. Session lock
18. What would you use to control the traffic that is allowed in or out of a network? (Select the best answer.)
A. Access control lists
C. Address Resolution Protocol
D. Discretionary access control
19. In an attempt to detect fraud and defend against it, your company cross-trains people in each department. What is this an example of?
A. Separation of duties
B. Chain of custody
C. Job rotation
D. Least privilege
20. What is a definition of implicit deny?
A. Everything is denied by default.
B. All traffic from one network to another is denied.
C. ACLs are used to secure the firewall.
D. Resources that are not given access are denied by default.
21. In an environment where administrators, the accounting department, and the marketing department all have different levels of access, which of the following access control models is being used?
A. Role-based access control (RBAC)
B. Mandatory access control (MAC)
C. Discretionary access control (DAC)
D. Rule-based access control (RBAC)
22. Which security measure should be included when implementing access control?
A. Disabling SSID broadcast
B. Time-of-day restrictions
C. Changing default passwords
D. Password complexity requirements
23. Which password management system best provides for a system with a large number of users?
A. Locally saved passwords management system
B. Synchronized passwords management system
C. Multiple access methods management system
D. Self-service password reset management system
24. You administer a bulletin board system for a rock and roll band. While reviewing logs for the board, you see one particular IP address posting spam multiple times per day. What is the best way to prevent this type of problem?
A. Block the IP address of the user.
B. Ban the user.
C. Disable ActiveX.
D. Implement CAPTCHA.
25. Your organization has enacted a policy where employees are required to create passwords with at least 15 characters. What type of policy does this define?
A. Password length
B. Password expiration
C. Minimum password age
D. Password complexity
26. Users are required to change their passwords every 30 days. Which policy should be configured?
A. Password length
B. Password recovery
C. Password expiration
D. Account lockout
27. You want to mitigate the possibility of privilege creep among your long-term users. What procedure should you employ?
A. Mandatory vacations
B. Job rotation
C. User permission reviews
D. Separation of duties
28. A security administrator implements access controls based on the security classification of the data and need-to-know information. Which of the following would best describe this level of access control?
A. Least privilege
B. Mandatory access control
C. Role-based access control
D. Implicit deny
29. Which of the following access control models would be found in a firewall?
A. Mandatory access control
B. Discretionary access control
C. Role-based access control
D. Rule-based access control
30. You are consulting for a small organization that relies on employees who work from home and on the road. An attacker has compromised the network by denying remote access to the company using a script. Which of the following security controls did the attacker exploit?
A. Password complexity
C. Account lockout