Comparing Identification, Authentication, and Authorization

A key part of any access control system is the identification and authentication of individuals. If you can’t identify individuals, everyone is anonymous. If everyone is anonymous, there is no way you can control access to different resources. Either everyone has access or no one does.

However, if you are able to differentiate between different users, you can grant access to some users while denying access to other users. This process starts with identification. In many authentication systems, the identity of a user is simply the user’s name.

Figure 2-1 shows the overall process of identification, authentication, and authorization. The user professes an identity with a username and validates the identity by providing authentication information. An authentication system verifies the credentials. Then access controls (such as permissions) authorize the user to access resources such as files stored on a server. If these three steps don’t come together, the user is not able to access resources protected with access controls.

Figure 2-1   Identification, authentication, and authorization

Just because someone knows a username doesn’t mean they are authenticated. They must also prove their identity by providing authentication data, such as a password or fingerprint. Similarly, just because a user can log on with a username and password doesn’t mean they can access everything on a system or a network. Administrators authorize access by configuring rights and permissions to users based on their proven identities.

Exploring Authentication

Authentication is the process of users proving they are who they claim to be. A common method is by having a user provide a logon name to profess an identity and then using a password for authentication.

For example, Figure 2-2 shows a challenge screen where a user must provide account credentials. The username provides the identification, and the password provides the authentication.

Figure 2-2   Username and password for identification and authentication

While you’ve probably used a password to authenticate to a system, you might not have used all possible authentication mechanisms. The following sections cover the different authentication methods.

Three Factors of Authentication

As shown in Figure 2-3, most authentication falls into one of three primary types or factors:

Figure 2-3   Three factors of authentication

•  Something you know (type 1)   This includes knowledge, such as passwords, personal identification numbers (PINs), your mother’s maiden name, or even personal information such as the name of your first pet.

•  Something you have (type 2)   This includes items such as smart cards, hardware and software tokens, and proximity cards.

•  Something you are (type 3)   This includes the use of biometrics, such as fingerprints and retina scans.

Something You Know

The simplest type of authentication is something you know and includes passwords, PINs, and other information known by an individual. Passwords can typically include multiple character types, such as uppercase letters, lowercase letters, numbers, and special characters. A PIN is typically only numbers.

Passwords have the following classifications:

•  Static password   A static password stays the same over a period of time. Each time a user logs on to a session, they use the same password.

•  One-time or dynamic password   One-time passwords are used only once per session. Many hardware tokens generate new passwords every 60 seconds that users can enter as a one-time password. The “Something You Have” section, later in this chapter, explains hardware tokens in more depth.

•  Cognitive password Information that a user would know, such as the name of a first pet, a first employer, and a favorite color, is combined to create a cognitive password. Users enter this information during a registration process. Later, the authentication system challenges the user with these questions in specific situations. For example, many authentication systems register information about the user’s computer, and if they detect the user is accessing the account from a different system, they challenge the user with cognitive password questions. If the user can give the same information when accessing the account at a different computer, the system authenticates the user.

•  Passphrase   A passphrase is a long string of characters that has meaning to the user. Users typically code these to make them more complex. For example, you can create a passphrase of IWillPassTheSSCPExam from the statement I will pass the SSCP exam. If a system forces a user to use all four character types (uppercase letters, lowercase letters, numbers, and special characters), a user can change it to IWi11P@$$The$$CPExam. Both are long passwords of 20 characters, but relatively easy to remember. In the second example, the letter l is replaced by the number 1 in each instance, the a is replaced by @, each s or S is replaced by $, and the first letter in every word is capitalized. Even as complex as it is, most people could easily commit this 20-character passphrase to memory.

Password Policies Many organizations implement written password policies providing rules for users on passwords. The policy identifies the minimum requirements. Administrators enforce the password policy using a technical control. For example, Windows Group Policy includes Password Policy settings that administrators can configure to apply to all users in a domain.

Figure 2-4 shows the Windows Local Group Policy Editor with the Password Policy selected. The following list describes the Password Policy settings:

Figure 2-4   Password Policy within Windows Local Group Policy

•  Enforce password history   This setting remembers previous passwords that a user has created and prevents the user from reusing the same passwords. As configured, it prevents a user from reusing any of the last 12 passwords they’ve created.

•  Maximum password age   This setting defines when users must change their password. As configured, it requires users to reset their password every 30 days.

•  Minimum password age   This setting defines how long users must wait before changing their password again. As configured, it prevents users from changing their password until 1 day has passed. This setting works with the password history setting. If set to 0, users can change their password 12 times in a couple of minutes and get back to their original password.

•  Minimum password length   This setting enforces the character length of the password. As configured, it requires users to create passwords at least 12 characters long.

•  Password must meet complexity requirements   When enabled, this setting requires users to create complex passwords that include at least three of the four character types—uppercase letters, lowercase letters, numbers, and special characters.

•  Store passwords using reversible encryption   Some legacy systems require storing passwords with reversible encryption. However, this is not recommended because it makes it easier for attackers to discover the password. This setting should be disabled unless otherwise required.

A popular method to create strong passwords is to use a password manager such as KeePassXC. It will create and store complex passwords within a database. As long as you use a strong master password to open the application, it keeps your passwords relatively secure. This is much better than storing all your passwords in a file named passwords.

Passwords are the least secure method of authentication; however, you can increase password security by following some basic guidelines:

•  Use strong passwords   A strong password includes a combination of different character types, such as uppercase letters, lowercase letters, numbers, and symbols. A strong password also needs to be sufficiently long. However, sufficiently long is a moving target. They should be at least 8 characters long, but many security professionals recommend passwords of 12 characters, 15 characters, or more. Strong passwords do not include usernames, logon names, children names, pet names, or any words found in a dictionary (of any language).

•  Don’t write down passwords   If a password is only in a person’s head, it can’t be read. On the other hand, if a user writes it down on a yellow sticky note and sticks it beneath a keyboard, an attacker can find it.

•  Change passwords often   Many security professionals have historically recommended changing passwords at least every 90 days. Some organizations require users to change their passwords more often, such as every 30, 45, or 60 days. However, newer recommendations from the National Institute of Standards and Technology (NIST) indicate this isn’t useful and should be avoided, as discussed in the following section.

•  Don’t use the same password on multiple systems   Unfortunately, attackers have been successful at hacking into systems and downloading huge databases that include user credentials. Attackers then try these credentials on other sites. If users have the same credentials on multiple sites, it becomes easier for attackers to compromise their accounts.

•  Never give out your password   Many social engineering attacks can easily be avoided if users understand and follow this simple rule. Because social engineers frequently try to get passwords simply by requesting them, security professionals often repeat this password policy rule to end users.

•  Audit passwords Many organizations use technology such as built-in operating system tools or third-party applications to verify that passwords are strong and that users change them regularly. A password audit ensures that passwords are strong (never blank), are of a minimum length, and have been changed within a given time period (such as 90 days). This is much more effective than a security professional trying to verify that all user passwords are strong and changed regularly.

•  Use a credential management system   Credential management systems provide a storage space for users to keep their credentials. For example, Windows systems include the Credential Manager tool, which allows users to store different username/password pairs and certificates used for authentication. Similarly, there are many password wallet or password vault apps that allow users to store multiple passwords within a single application. For example, KeePassXC is a free open source utility that allows users to store usernames and passwords within a secure encrypted database. Users open the database by entering a single master password or key file.

NIST Password Recommendations NIST Special Publication (SP) 800-63B, titled “Digital Identity Guidelines,” provides some newer recommendations related to passwords (also known as “memorized secrets” in NIST lingo) that are counter to what conventional wisdom has told us in the past. While SSCP test item writers may take a while to catch up with these recommendations, many organizations are starting to implement them.

Following conventional wisdom, a strong password is of sufficient length and complex, using multiple character types. However, when password policies force users to create complex passwords, users have responded in predictable ways. For example, imagine Joe typically uses a password of “password” for online sites. However, a password policy forces him to use all four character types. If Joe is a typical user, he will likely create a password of “Password1!”.

Instead of forcing users to create overly complex passwords that are difficult to remember, SP 800-63B recommends the following actions:

•  Users should be encouraged to create passphrases   As an example, a passphrase of ICanCountTo6 is a simple password to remember. However, because it has 12 characters and uses a variety of character types, it is difficult to crack.

•  Passwords should be a minimum of 8 characters   While longer passwords can be required, NIST recommends using multifactor authentication (described later in this chapter) for accounts that need more security.

•  Passwords should never be stored in cleartext   Passwords should be salted and hashed with a strong hashing algorithm such as Secure Hash Algorithm 3 (SHA-3). Salts are random bits added to a password, and NIST recommends a salt of at least 32 bits A hashing algorithm reduces the salted password to a string of hexadecimal characters. For example, SHA-3(256) creates a hash 256 bits long.

•  Users should be able to create passwords with as many as 64 characters   Because passwords should never be stored, users should be able to create long passwords. For example, ILoveTheHolidaySeasonEspeciallyWhenItSnows is an easy password to remember (especially for someone who loves the holiday season), but with so many characters, it is unlikely to be cracked by any method. Additionally, the password length is not relevant if it is salted and hashed.

•  Blacklisted passwords should be blocked   A password system should check user passwords against a blacklist of known simple passwords such as 12345678, password, password1, qwertyui, and so on. Blacklists should also include words in a dictionary.

•  No other complexity requirements should be imposed on users Users should be required to create passwords of at least 8 characters and not use passwords in the blacklist. However, they should not be required to create overly complex passwords. Instead, the salted hash should provide the complexity.

•  Passwords should not be set to expire   Users should not be required to change their passwords periodically. The only reason they should be required to change their password is if there is evidence of compromise.

Something You Have

Organizations that want to increase the security of authentication often use the next factor: something you have. Smart cards, hardware and software tokens, and proximity cards are some examples.

Smart Cards A smart card is a small card about the size of a credit card that has an embedded certificate used to identify the user. The user inserts the card into a smart card reader that reads the data on the card to identify and authenticate the user. Because it’s easy for a user to lose a smart card, most smart card authentication systems require users to enter a PIN or a password in addition to using the smart card.

Hardware Tokens and One-time Passwords A hardware token is a small device that displays a number. The number changes periodically, such as every 30 seconds, and the user enters the number for authentication. This number is a one-time password because the user can only enter it once. You’ll often see this called a dynamic password to contrast it with a static password that stays the same. A one-time password reduces the risk of an attacker capturing the password and reusing it.

Authentication servers know the number displayed on the token, as shown in Figure 2-5. A user typically authenticates via a website by entering the username, password, and the number displayed in the token, which is sent to the authentication server. If the user enters the correct number, it proves that the user has the token. As long as the user entered the correct username and password, this provides authentication. As with smart cards, hardware tokens are typically used with another factor of authentication. In this example, the user entered a password and the number displayed on the token.

Figure 2-5   Token used for token-based authentication

Hardware tokens can use either a synchronous dynamic password or an asynchronous dynamic password:

•  Synchronous dynamic password   A token using a synchronous dynamic password changes the password at specific times, such as every 60 seconds. This requires the token and the server to be synchronized with the same time.

•  Asynchronous dynamic password   A token using an asynchronous dynamic password doesn’t require exact clock synchronization. Instead, it uses another method to create one-time dynamic passwords. As an example, the user can enter a PIN into the device, which prompts the token to generate a one-time password.

Software Tokens and One-time Passwords Software tokens are being used more and more today. These use open source protocols such as the open-standard Time-based One-Time Password (TOTP) protocol or the HMAC-based One-Time Password (HOTP) protocol to create one-time passwords. Google Authenticator and Symantec’s VIP Access are two examples of software tokens.

The TOTP protocol creates synchronous dynamic passwords based on time. The HOTP protocol creates asynchronous dynamic passwords. Instead of using a chronological time, HOTP uses an incrementing counter combined with a secret key, known by both the server and the token. HOTP creates a hash using the hash message authentication code (HMAC) and then reduces this hash to a six- to eight-digit HOTP value. Because HOTP uses an incrementing counter, these one-time passwords remain valid until used.

One-time Password In Everything (OPIE) is another type of one-time password used in networks. OPIE is based on S/KEY, a one-time password system used on some UNIX systems. The goal of both OPIE and S/KEY is to generate an asynchronous password known to both a client and a server and used in a single session. Both S/KEY and OPIE combine the user’s real password with other data, and use a hashing algorithm such as Message Digest 5 (MD5) to create a one-time password.

Proximity Cards A proximity card includes data electronically embedded within the card. It doesn’t have power, but does have an inductor that can be electrically excited when it passes through a magnetic field. This provides enough power for the proximity card to transmit data to a nearby receiver. For example, some credit cards have this technology embedded within them. When you pass the card over the proximity card reader, it activates the card’s electronics and transmits your data to the card reader.

Many organizations issue identification badges to employees, which they show to security guards for identification, and some identification badges include proximity card capabilities. For example, an employee can wear the badge for identification and also use it to open doors by passing the badge in front of a proximity card reader.

Something You Are

Biometrics are used to provide authentication as something you are by identifying unique characteristics of a person, such as a fingerprint. Users register the biometric value and associate it with an identity such as a username. Later, users authenticate by entering the username and presenting the biometric value. For example, a user can place their finger in a fingerprint scanner. The following list shows some of the biometric methods used for authentication:

•  Fingerprints and thumbprints Fingers and thumbs have unique patterns that law enforcement personnel have used for decades to identify individuals. Many IT systems now use fingerprints and thumbprints for authentication. As an example, many laptops and small devices include a fingerprint scanner. However, some fingerprint scanners can be tricked with a picture of a fingerprint or even a duplicate fingerprint transferred to and from a gummy bear.

•  Palms   A palm scanner can measure the vein pattern in a person’s palm using an infrared scanner. Users don’t need to touch the scanner, but instead just hover their hand over the scanner.

•  Retina   A person’s eyes have a pattern of blood vessels at the back of the eye, and a retina scan uses an infrared light to measure that pattern. While retina scans are very accurate, people object to them because they can reveal medical conditions. Also, retina scans typically require physical contact with the scanner.

•  Iris   The area surrounding the eye’s pupil is the iris, which is almost as unique as the retina. Iris scans are more acceptable to users because they don’t require physical contact and cameras can take pictures of the iris from a distance. However, lighting can affect the accuracy of an iris scan, and some iris scanners can be tricked with a high-quality picture.

Behavioral biometrics identify behavioral traits of an individual. For example, keystroke dynamics measures the pattern and rhythm as a user types on a keyboard. Similarly, handwriting analysis can sometimes verify that a specific person wrote a note. However, these methods aren’t as reliable for authentication as biometric methods that focus on a person’s physical characteristics.

One of the challenges with biometrics is the potential for errors. When considering a biometric authentication system, it’s important to understand the different error types and the accuracy of the system. Refer to Figure 2-6 while reading the following error rate definitions:

Figure 2-6   Biometric error rates

•  False Rejection Rate (FRR)   Also called a type 1 error, FRR refers to the percentage of times a biometric system falsely rejects a known user. Instead, the system indicates that the user is unknown.

•  False Acceptance Rate (FAR)   Also called a type 2 error, FAR refers to the percentage of times a biometric system falsely identifies an unknown user. Instead, the system indicates the user is a known user.

•  Crossover Error Rate (CER)   Also called the Equal Error Rate (EER), CER identifies the point where the FAR and FRR of a biometric system are equal or cross over each other on the chart. A lower CER indicates a better-performing biometric system.

Multifactor Authentication

Multifactor authentication uses two or more factors of authentication. This can be any combination of two of the three factors (something you know, something you have, and something you are) or a combination of all three factors.

Some examples of multifactor authentication include the following:

•  A smart card (something you have) and a PIN (something you know)

•  A fingerprint (something you are) and a password (something you know)

•  A hardware token (something you have) with a username and password (something you know)

A key point is that the different authentication methods must use different factors. For example, using a password and a PIN is not multifactor authentication because it uses two authentication methods of the same type, something you know.

Two-Step Verification

Many organizations have implemented two-step verification using HOTP and/or TOTP. Google 2-Step Verification is one example. If you have a Google account, you’ll often be asked for your username, password, and something else, such as a six-digit code, as a second step. Google sends this code to your phone via text, a voice phone call, or a Google mobile app.

Imagine that you registered your smartphone number with Google. Later, when you log on to your Google account with your tablet device, Google notifies you that it has sent a code to your smartphone and prompts you to enter the code. You then look at your phone to get the code and enter the code onto your tablet. If you use your tablet frequently to log in to Google, this can get tedious quickly. However, Google 2-Step Verification allows you to set an option to skip the verification on that device or computer. It records information about your device so that it can identify it later. The next time you log on with the tablet, it won’t challenge you for the code again.

However, if Hacker Harry somehow gets your password and tries to log in to your Google account, Google 2-Step Verification will challenge him to provide the code. Google will send you the verification code telling you to use this to log on. Hacker Harry won’t have your phone, so he won’t see the code and he won’t be able to log on. This also gives you a strong indication that your password may have been compromised. Change it as quickly as you can.

When using two-step authentication in this scenario, your smartphone is using a software token and operating as a hardware token in the something you have factor. Unless you have your smartphone with you, you won’t be able to log on.

Other vendors have similar processes but name them slightly differently. Amazon uses Two-Step Verification (spelling out Two and using initial capitalization), while Google uses 2-Step Verification (using the number 2 and initial capitalization). Microsoft names its process generically as two-step verification.

Reviewing Identification

A username is a primary method of identification, but it’s important to realize that there are more methods. Further, many of these methods are used for both identification and authentication.

Biometric systems are effective at accurately identifying individuals using a one-to-many search. As an example, the TV show Person of Interest showed many security technologies, including face-recognition technologies, which use cameras to capture the facial characteristics of a person and then search a database of many faces to find a match. In this fictional show, they used face-recognition technologies to track activity of different people. Similarly, many passport-free border crossings use iris scans to identify individuals.

In contrast, biometric systems used for authentication use a one-to-one match. For example, if a user claims an identity with a username and then authenticates with a fingerprint, the authentication system compares the user’s fingerprint against the fingerprint associated with the user.

Smart cards can also be used for identification. A user inserts the smart card into a reader for identification and then enters a PIN for authentication. For example, the U.S. government uses Common Access Cards (CACs) and Personal Identity Verification (PIV) cards, which are specialized types of smart cards. They include a photo, which users can also present for identification.

Single Sign-on Authentication

With single sign-on (SSO), a user authenticates once and then the system uses the same credentials for the entire session. This includes when the user accesses any resource in the organization, or with a trusted partner. This increases security because users have to remember only a single set of credentials and are less likely to write them down.

Consider the alternative in an organization that has seven servers that any user can access but where each server requires a different username and password. Users have to memorize seven sets of credentials. Even if the usernames are the same on each server, it is almost impossible to ensure that the passwords remain the same on all systems unless the passwords are never changed.

However, if the organization implements an SSO system, users would need to remember only a single username and password. This provides convenience for the users. Additionally, with fewer centralized user accounts, it decreases the administrative workload. For example, it is easier for administrators to implement password policies with a centralized SSO system. Of course, the major drawback of an SSO system is that if an attacker obtains a user’s credentials, the attacker can access multiple systems. The following sections discuss some commonly used SSO systems.

Kerberos

Windows domains and Linux/UNIX realms use Kerberos as the underlying protocol for SSO. A user can log on to the domain at the beginning of the workday, and the system uses the same credentials to access any resources in the domain.

Kerberos is a vendor-neutral authentication protocol originally developed at the Massachusetts Institute of Technology (MIT) for UNIX realms. It uses a complex process of issuing tickets to authenticated accounts and then uses the tickets to access resources. Microsoft has adapted Kerberos for its Windows domains since Windows 2000.

The Kerberos server issues different types of tickets used for authentication, and is often referred to as a ticket-granting server. Kerberos uses symmetric keys and symmetric encryption (also called secret key cryptography) to protect the confidentiality of the Kerberos transmissions, and you’ll also see the Kerberos server referred to as a Key Distribution Center (KDC).

The following steps and Figure 2-7 provide an overview of how Kerberos works:

Figure 2-7   Kerberos ticket-granting process

1.   The client (the user’s computer) sends an authentication request to the Kerberos server. This includes the user’s login ID or username, but not the user’s password.

2.   After verifying the user’s login ID with a database (such as Microsoft Active Directory), the Kerberos server creates a symmetric key that will be known only to the client and the Kerberos server. It encrypts this symmetric key using a hash of the user’s password. It also encrypts a time-stamped ticket-granting ticket (TGT) with a separate key, and sends both the encrypted symmetric key and encrypted TGT to the client.

The client decrypts the symmetric key with a hash of its password. It can then use this symmetric key to encrypt traffic between the client and server. Note that this verifies the password too. If the client doesn’t know the correct password, it isn’t able to decrypt the symmetric key.

3.   When the client wants to access resources on a target server (such as a file server on the network), it sends the encrypted TGT to the ticket-granting server with the name of the target server.

4.   The ticket-granting server replies with an encrypted ticket (also called a session ticket) that the client uses to communicate with the target server. The ticket-granting server also provides an encrypted symmetric key that systems use to encrypt information between the client and the target server.

5.   The client presents the encrypted time-stamped session ticket to the target server for authentication.

6.   The target server decrypts the session ticket and verifies it. It then replies with a message, which includes the session ticket’s time stamp. This authenticates the server to the client (providing mutual authentication), because other servers would not be able to decrypt the session ticket.

Kerberos also provides a level of confidentiality and integrity for information. It helps prevent the unauthorized access to data by ensuring that only authenticated users can access data on target servers. This also contributes to integrity by preventing unauthorized modifications of data on target servers.

Federated Access

Many SSO systems use federated access technologies. Federated access allows users in different networks to log on only once, even if they are accessing multiple systems. The systems can be different operating systems, owned and managed by different organizations.

For example, a company can have an intranet website used by employees that also includes links to outside websites. The outside websites can be for employee financial services, such as 401K information, or insurance company websites used to provide information on an employee’s health plan.

Users log in to their work account using their regular account. When they access the intranet website, it uses typical SSO technologies such as Kerberos to grant them access. Then if they click on any links to the external sites, the federated access SSO system verifies the user’s identity and provides access without additional user interaction.

Each of the different websites has its own independence or autonomy. In other words, the owners of the financial website are not dependent on information on the intranet website or the health insurance website. However, the different websites do provide information on the identity of users and provide assurances to the other sites that the user has authenticated.

Many federated SSO systems share information via a federated database. A federated database does not include passwords of users, but it does include identity information needed by each of the sites. It provides the users with a federated identity, which each of the sites can use.

SAML

Security Assertion Markup Language (SAML) is an Extensible Markup Language (XML)–based data format used for SSO on the Internet. As an example, consider two websites hosted by two separate organizations. Normally, a user would have to log on to each site separately. However, the organizations can use SAML as a federated identity management system. Users authenticate once with the first website, and they are not required to authenticate again when they access the second website.

Many online banking sites use SAML for SSO. For example, the banking site might have one service for accessing checking and savings accounts, another service for online bill paying, and another service for handling mortgages. With SSO, the user is able to log on to the primary banking site one time, and then access all the services without logging on again.

SAML includes three roles:

•  Principal   The principal is typically the user that logs on to the system. If necessary, the user might request a principal identity from the identity provider.

•  Identity provider   The identity provider creates, maintains, and manages the identity information for principals.

•  Service provider   A service provider is the entity that provides services to principals. For example, a banking institution that hosts different banking services is the service provider.

The primary purpose of SSO is for identification and authentication of users. Users claim an identity and prove that identity with credentials, such as a password. SSO does not provide authorization. For example, if a user logs on to the banking site, SSO doesn’t control what services the user can access. However, SAML includes the ability to transfer authorization data between the bank’s systems. In other words, it’s possible to use SAML for SSO authentication and for authorization.

Other SSO Technologies

Two newer SSO technologies you should be aware of are OAuth and OpenID Connect. Many online websites are using them to allow users to log on to their sites with an account they’ve created elsewhere. Many popular websites such as Google, Facebook, PayPal, and Microsoft support these technologies.

As an example, imagine you have a Google account. You want to log on to a website to post a comment, but doing so requires you to have an account. Instead of creating another account, the site gives you the option of logging on with your Google account.

Most organizations support OAuth 2.0 but not OAuth 1.0. OAuth 2.0 provides an open source authentication framework that organizations can build on. OpenID Connect is an authentication layer that can be used with OAuth 2.0 to extend its capabilities. Combined, OAuth and OpenID Connect allow websites and online web applications to verify the identity of end users without managing the users’ credentials.

Centralized vs. Decentralized Authentication

Authentication can be decentralized or centralized. Consider Figure 2-8. The group of users on the left is in a decentralized environment. Every computer has a separate database that stores credentials. If Sally needed to log on to all four computers in this network, she would need to have four separate sets of credentials—one for each system.

Figure 2-8   Centralized vs. decentralized authentication

On the other hand, the computers on the right are using centralized authentication. Credentials for the users are stored on a central server. Any user can log on to the network once and then access any computer in the network (as long as the user has permissions). For example, if a computer is part of a Microsoft domain, the central server will be a domain controller and hold accounts for all users in the domain.

Centralized authentication is used for single sign-on networks. It’s not possible to use SSO without some type of centralized authentication.

Offline Authentication

Offline authentication allows users who have logged on to the system at one time to still log on even when they are disconnected from a network.

For example, consider a consultant named Steve with an account in a Windows domain named mcgrawhill. He uses his laptop computer to log on to the domain while he’s at work. When his company deploys him to a customer site to provide consulting services, he’s no longer connected to the mcgrawhill domain, so there’s no way that a Kerberos server in the domain can authenticate him if he is not connected to the domain.

However, he is still able to log on while he’s offline. In a Windows environment, the system uses cached credentials. In other words, when Steve logged on to his laptop, encrypted data about his credentials were stored (cached) on his system. If he’s disconnected when he logs on, these cached credentials are compared to the credentials he’s entering, and if they match, he is authenticated.

Linux and UNIX users have a similar capability when they are interacting with a Microsoft domain. As long as offline authentication is selected when the computer joins the domain, they will be able to use domain credentials even when they are disconnected.

Device Authentication

Device authentication methods focus on hardware instead of the user. The goal is to prevent unauthorized devices from accessing the network.

Windows domains require users to log on from known computers that have joined the domain. This requires the computer and the user to authenticate before the user is able to access domain resources. However, there are times when you might want to allow network access without joining the device to the domain.

One method used for device authentication allows or blocks devices with media access control (MAC) address filtering, described in Chapter 3. However, this is very tedious and users can easily bypass MAC address filtering if they know how to change their MAC address.

Another method is device fingerprinting that identifies devices based on several characteristics. Many of the following characteristics are easy to capture when a user attempts to connect to a network with a web page: operating system and version, IP addresses, browser, browser fonts, browser plug-ins, time zone, data storage, screen resolution, cookie settings, and HTTP headers.

As an example, SecureAuth created SecureAuth Identity Provider (IdP), which provides mobile device management (MDM), including device authentication. Authorized devices are registered with the system. Later, when a user attempts to access the network, SecureAuth IdP verifies the device is recognized. If not, it blocks access. Chapter 9 discusses MDM in more depth.

Implementing Access Controls

An access control provides a mechanism to restrict or control access to resources. These resources can be logical, such as files and folders hosted within a network, or physical, such as servers within a locked server room. Access control starts with identification and authentication. Once individuals have been reliability authenticated, you can control their access.

Comparing Subjects and Objects

Two primary terms related to access controls are subjects and objects. In short, a subject accesses a resource, and an object is the resource being accessed. As a simple example, if a user accesses a project file stored on a server, the user is the subject and the project file is the object.

With this in mind, you would first ensure that subjects are authenticated to validate their identity and then use access controls (such as permissions) on the objects to control the access. The access controls ensure that only certain subjects have access to the objects.

In some examples, an entity can be both a subject and an object. Consider Figure 2-9. A user requesting a web page from a server is clearly a subject. Similarly, the web pages served by the web server are the objects. However, this web server is retrieving data from a back-end database (protected behind a firewall) to build the web page. When the web server retrieves the data, it is a subject and the database is the object.

Figure 2-9   Comparing subjects and objects

While there aren’t any formal access control models called subject-based access control or object-based access control, it is possible to control access based on subjects or objects. The following sections dig into subjects and objects a little deeper, including how they can be used for access control. The upcoming “Comparing Access Control Models” section describes how different formally named models control access based on subjects or objects.

Subjects and Subject-based Access Control

Access control systems can treat any of the following as subjects:

•  Users

•  Computers

•  Applications

•  Networks

You can create accounts to represent most of the subjects. For example, in most networks, each user has at least one user account and each computer has a computer account. Similarly, many applications use service accounts to access resources. You can then assign specific permissions to these accounts for any object they need to access.

Additionally, an access control system can often apply different attributes to the subject to control access further. The following are some subject attributes:

•  Time (temporal)   For example, it’s possible to prevent a user from logging on to a system outside of normal working hours.

•  Remote access attribute   Figure 2-10 shows how the Network Access Permission is set to Allow Access for a user in a Microsoft Active Directory domain. This setting allows a user to access a remote access server, such as a virtual private network (VPN) server, from any location that has Internet access.

Figure 2-10   Viewing the Network Access Privilege for a user

•  Location   Within a network, it’s possible to restrict users to only log on to specific computers, based on the computer name or MAC address. Many Internet-based systems analyze the IP address of the user’s device to determine the user’s location. A global positioning system (GPS) can identify a user’s physical location and restrict access based on the GPS coordinates. A geofence can create a virtual boundary (such as within an organization’s building) and block access to users outside of the geofence.

•  Role or group membership   Subjects (such as users) are often assigned roles or placed into groups to grant them access to objects. The “Role-based Access Control” section a bit later discusses this model in more detail.

Many organizations assign administrators two accounts. Administrators log on with a regular user account for day-to-day work, and this account gives them limited access. When they need administrative privileges, they use their administrator account. As an example, Figure 2-11 shows Active Directory Users and Computers (ADUC) in a Microsoft domain. It shows four accounts in the IT Department Organizational Unit. Each of the users has a regular account for day-to-day work and an administrator account used to perform work requiring elevated privilege.

Figure 2-11   Viewing accounts in a domain

Objects and Object-based Access Control

Access control systems can treat any of the following as objects:

•  Data (stored in files, folders, and shares)

•  Hardware (such as desktop computers, servers, and printers)

•  Applications (such as a web server application)

•  Networks (such as an Internet connection or an internal connection)

•  Facilities (controlled with physical security)

Most objects allow various levels of access. For example, a user might be able to view a web page but not have permission to modify it. Similarly, regular employees can get into the company building but they don’t have access to secure server rooms.

It’s common to store groups of objects with the same access requirements together. For example, if salespeople need identical access to 100 files, you can store all 100 files in a folder and then assign the permissions to the folder. This simplifies administration. Permissions are the most common type of access control applied to objects.

Logical Access Controls

Logical access controls (also called technical access controls) are implemented with technologies. Many logical access controls use access control lists (ACLs). For example, a router has an ACL with multiple rules that identify the traffic allowed in or out of a network. Similarly, files and folders often use ACLs to identify who can access the resource and what level of access each user has.

Comparing Access Control Models

There are several formally defined access control models available. At this stage of your IT career, you aren’t expected to design access based on any of the models. However, you should be aware of the models that exist and have a basic understanding of how they work. The following sections summarize some basic characteristics of these models.

Discretionary Access Control

The Discretionary Access Control (DAC) model provides the most granular level of access control. It is an identity-based (or subject-based) model and allows data owners to assign permissions to subjects at the most basic level. For example, you can assign read permission to a single user. File systems such as New Technology File System (NTFS, used by Microsoft) and Network File System (NFS, used on UNIX-based systems such as Solaris and Linux) use the DAC model.

DAC uses ACLs, or, more specifically, discretionary access control lists (DACLs). As an example, consider Figure 2-12. It shows the permissions assigned to different subjects for the Sales Data object (a folder on a server).

Figure 2-12   Viewing permissions as a DACL

A DACL is composed of several access control entries (ACEs), and Table 2-1 shows the underlying ACEs for Figure 2-12. A distinguishing feature of the DAC model is that users have full control over any objects they create. The CREATOR OWNER group is a special group that ensures that users are automatically assigned full control permission to any file or folder they create. Maria Gomez (the sales manager) has full control permission on the folder. The Sales group would include all personnel in the Sales department, and it has read & execute, list folder contents, and read permissions. The Administrators group has full control permission.

Table 2-1 Individual ACEs Creating a DACL

Non-Discretionary Access Control

In non-Discretionary Access Control (non-DAC) models, security administrators control the access granted to users. In contrast, in a DAC model, users have ownership of their resources and users have full control of the resources they own. In general, any model that is not a DAC model is a non-DAC model.

Some operating systems implement non-DAC models for system file access. This prevents malware from taking ownership of any critical or sensitive system files or modifying permissions on any of these files. Users still own and manage their own files using DAC, but the non-DAC model methods protect system files. In other cases, the operating system uses a non-DAC model exclusively, such as Mandatory Access Control (described later in this chapter). Other non-DAC models include role-based, rule-based, and attribute-based models.

Role-based Access Control

The Role-based Access Control (Role-BAC or RBAC) model uses roles or groups to determine access. Subjects are placed into specific roles and object permissions are granted to the roles. Although the Role-BAC model doesn’t provide the granularity offered by DAC, it is easier to implement for large groups of people.

Consider Figure 2-13. An organization has a group of salespeople in the Sales department. The organization wants each of these users to have access to a printer, a file server, and several folders and files. An administrator adds the accounts for each salesperson to the Sales Role and then assigns appropriate permissions to the Sales Role. These permissions apply to all users in the Sales Role without having to assign the permissions individually.

Figure 2-13   The Role-BAC model

If the organization hires another salesperson, administrators place the new salesperson’s user account into the Sales Role. This gives the new employee all the appropriate access in a single step. If a salesperson transfers to a different department, an administrator would remove the account from the Sales Role. When you remove a user from a group or role, it revokes all the permissions they had as a member of the old group or role. An administrator would add the user account to appropriate roles in the new department. This reduces the administrative workload and improves security.

In contrast, if the organization doesn’t use roles, but instead forces administrators to assign permissions individually, it becomes very difficult to manage. Looking at Figure 2-13, administrators would have to assign permissions individually for each salesperson at each resource. When a new salesperson is hired, administrators would have to remember all the resources that salespeople need to access and assign permissions individually. When employees transfer, administrators should remove their permissions to resources associated with their previous job. However, without roles or groups, this step is very difficult and often skipped. This results in permission creep, where employees just collect more and more permissions. All of this can be challenging with just a few people, but it is unmanageable if your organization has hundreds of users.

Rule-based Access Control

The Rule-based Access Control model is another non-DAC model. Administrators create rules that determine access to resources. As an example, routers have rules within an ACL. These rules identify what traffic the router will pass based on IP addresses, ports, and protocols.

Attribute-based Access Control

Attribute-based Access Control (ABAC) is a more sophisticated type of Rule-based Access Control. It evaluates subject and object attributes, and grants access based on the value of these attributes. Attributes can be almost any characteristic of a user, the environment, or the resource.

Some systems implement ABAC with plain-language statements to build policies. These policies work as rules, but provide you with a lot more granularity than you can achieve with traditional Rule-based Access Control models. Software-defined networking is becoming very popular and often uses these types of policies. For example, you could create a policy rule that states, “Allow logged-on users to access YouTube videos using smartphones or tablets via the guest network.”

Policy statements typically include four elements:

•  Subject   The user accessing a resource. You can use any user property as an attribute. This includes roles, group memberships, management level, and assigned department. The preceding example uses the status of the user—logged on.

•  Object   The resource that the user is trying to access. It can be a file, a database, or an application. The example uses the YouTube application. Notice that this allows the rule to cover much more than just Internet access.

•  Action   What the user is attempting to do. It could be reading or manipulating a file, accessing specific websites, or accessing website applications. The example allows access to the YouTube website via the guest network. This could prevent video streaming from overloading the primary network, while allowing it on the guest network.

•  Environment   Includes everything outside of the subject and object attributes. This is often referred to as the context of the access request. It can include the time, location, protocols, encryption, devices, and communication method. In the example, it specifies smartphones, tablets, and the guest network as environmental attributes.

While the policy statement is stated in plain language, it would typically be stored in a database using an XML format. The eXtensible Access Control Markup Language (XACML) is a specialized XML format used specifically for ABAC.

Mandatory Access Control

The Mandatory Access Control (MAC) model is a non-DAC model that uses labels to identify both subjects and objects. It provides the highest level of security among the models (MAC, DAC, Role-BAC, Rule-BAC, and ABAC) and is commonly used by the U.S. military to ensure that data is protected in mission-critical systems.

The U.S. government uses the following classifications for data, from highest to lowest:

•  Top Secret

•  Secret

•  Confidential

•  Unclassified

Just because someone has a Top Secret classification, they don’t automatically have access to all Top Secret data. Instead, data owners authorize access based first on their Top Secret security clearance, and second based on their need to know the information for their job. Additionally, it’s possible to create subclassifications or compartments within each classification level.

As an example, Figure 2-14 shows the three classification levels of Top Secret, Secret, and Confidential. Within each level, there are additional labels identifying compartments within the classification level. The Top Secret level includes compartments labeled Diplomat, Lucid, and Foil (names from World War II military operations). The Secret level includes compartments labeled Teardrop, Alacrity, and Marmalade, and the Confidential level includes compartments labeled Stonewall, Cockpit, and Jaywick.

Figure 2-14   Using labels with the MAC model

Lisa has both the Top Secret label and the Lucid label. She can be granted access to any data labeled Top Secret and below as long as it doesn’t have an additional label. Additionally, she can be granted access to compartmentalized data with the Lucid label. Maggie has the Secret and Marmalade labels. She can be granted access to any data labeled Secret and below as long as it doesn’t have an additional label. Additionally, she can be granted access to compartmentalized data with the Marmalade label. Bart has only the Confidential label so he can only be granted access to Confidential data that doesn’t have an additional label.

Some of the MAC-based architecture models are Biba, Bell-LaPadula, Clark-Wilson, and Brewer-Nash. Table 2-2 provides an overview of these models, including their primary goals and some of the rules they use. The following sections explain them in a little more depth.

Table 2-2 Goals and Rules of Some Access Control Models

Bell-LaPadula David Elliott Bell and Leonard J. LaPadula designed the Bell-LaPadula model with a primary goal of ensuring confidentiality. It enforces security through two primary rules commonly called no read up and no write down. Each of these rules compares the subject’s clearance with the object’s classification.

•  Simple security property rule—no read up   Subjects granted access to any security level may not read an object at a higher security level. For example, if Joe is granted Secret access, he cannot read materials classified as Top Secret.

•  The * property (read as “star-property”) rule—no write down   Subjects granted access to any security level may not write to any object at a lower security level. For example, if Sally is granted Top Secret access, she cannot create or modify documents classified as Secret.

Biba The Biba model, another MAC-based model, enforces integrity (unlike the Bell-LaPadula model, which enforces confidentiality). Biba includes two rules that are reversed from the Bell-LaPadula model:

•  Simple Integrity Axiom—no read down   Subjects granted access to any security level may not read an object at a lower security level, at least not as the authoritative source. For example, a captain of a ship can read orders from an admiral and consider them authoritative and actionable. However, if a seaman recruit tries to issue orders to the captain, the captain will not read them as authoritative.

•  The * Integrity Axiom (read as “star Integrity Axiom”)—no write up Subjects granted access to any security level may not write to any object at a higher security level. For example, a seaman recruit cannot write orders for the captain of the ship. Similarly, the captain cannot write orders for the admiral.

Clark-Wilson David Clark and David Wilson created the Clark-Wilson model, and its primary goal is information integrity, although it is more stringent than the Biba model. It also helps enforce the separation of duties principle. Chapter 1 described separation of duties. As a reminder, separation of duties is a security principle that ensures that no single person has complete control over a process.

The Clark-Wilson model uses certification rules (identified as C1 through C5) and enforcement rules (identified as E1 through E4) to enforce separation of duties. The certification rules are integrity-monitoring rules, and the enforcement rules are integrity-preserving rules.

These rules are complex, but they work together to ensure there is adequate separation of the elements of any transaction. For example, consider a company that purchases products. The transaction includes someone placing an order, someone receiving the products (and verifying that they were received), and someone paying for the products (after verification that the products were received).

Imagine that Fred has sole responsibility for doing all three tasks in the transaction. This increases the potential for fraud, because he could place an order through a fictitious company, acknowledge receipt (even if no products were received), and deposit the funds into his own bank account. The Clark-Wilson model ensures that different people perform the separate tasks independently of each other.

Brewer-Nash The Brewer-Nash model (sometimes called the Chinese Wall model) is documented by Dr. David F. C. Brewer and Dr. Michael J. Nash. Financial services organizations often implement this model to help prevent a conflict of interest, and it helps enforce the separation of duties principle.

Data is classified in the ethical screen model using different conflict-of-interest classes. If a subject has access to data in one class, he or she cannot access data in a conflicting class.

As an example, consider traders in an investment bank who are selling financial securities to investors. These traders should all have access to the same information. In another part of the investment bank, advisors are helping a separate organization with a major merger. If the merger is finalized, it will affect investments sold by the traders. If the traders have access to this information, they could use it to increase investment returns for themselves or their clients. This type of insider trading is illegal, but that isn’t enough to stop some people.

A Brewer-Nash model provides a barrier between these two groups of employees by classifying data. It can be as simple as classifying data as Trader Data and Advisor Data and indicating the two classes have a conflict of interest. Traders have access to Trader Data, and the Brewer-Nash model blocks their access to the Advisor Data.

Access Control Matrix vs. Capability Table

Administrators use various tools when implementing access control models. Two common tools are access control matrixes and capability tables. A key difference between the two is that access control matrixes are object based and capability tables are subject based.

An access control matrix is a list of objects along with the permissions granted for each object. You can think of an access control matrix as a group of ACLs. Each ACL represents a single object and lists all the permissions for that object.

A capability table is a list of subjects, along with the capabilities granted to the subjects. These capabilities include rights and permissions. For example, a capability table can list several groups such as Project Managers, Project Team Leads, and Project Members. It then lists the rights and permissions granted to each of these groups.

Participating in the Identity and Access Management Lifecycle

Identity management lifecycle refers to managing accounts through their lifetime. Identity and access management (IAM) refers to granting accounts access to resources. Accounts need to be configured properly when they are first created, managed while in use, and disabled or deleted when they are no longer needed.

Privileges include both rights and permissions. Rights are actions that an account can take on a system, such as backing up files, changing the time, or rebooting the computer. Permissions identify what a user can do with resources, such as reading and writing to a file or printing to a printer.

The principle of least privilege dictates that users should have only the rights and permissions they need to perform their jobs and no more. However, enforcing the principle of least privilege isn’t a one-time event. Instead, administrators take steps to enforce this principle throughout the lifecycle of any identity.

Identity Proofing

It’s important to verify a person’s identity before creating a user account. Within an organization, Human Resources (HR) departments typically have processes they use for identity verification. Many HR departments require documents such as a driver’s license.

Online banks and retailers often use identity-proofing methods to prevent fraud. One common method to prevent credit card fraud is the use of a credit card verification value (CVV). While criminals might steal databases with credit card numbers, these databases rarely include the CVVs too.

Cognitive passwords (described earlier in this chapter) provide identity proofing after an account has been created. For example, if a user claims to have forgotten a password, the system will challenge the user with cognitive password questions to verify the person’s identity.

Provisioning and Authorization

Provisioning refers to creating accounts for users and granting them access to appropriate resources. Authorization refers to granting appropriate privileges for the accounts. Many organizations use groups, as described in the “Role-based Access Control” section of this chapter, to streamline the process of granting privileges. For example, administrators can create a group named Sales to represent the Sales department. They add the user accounts for people in the Sales department to the Sales group, and they assign appropriate privileges to the Sales group.

It’s common to use template user accounts for different departments. For example, administrators can create an account named SalesTemplate and configure this account with appropriate group membership in the Sales department. When creating an account for a new employee, they make a copy of the template, and it is automatically provisioned with the appropriate group membership.

Some organizations automate account creation. For example, when HR personnel process a new hire, they can enter information about the new employee into an application. This includes basics such as name, address, and the department in which the employee will be working. After the HR person enters the information, the application automatically creates the account and adds the user to the appropriate groups or roles based on the employee’s job.

This type of application helps ensure that account-naming conventions are always followed. For example, if the organization wants to create accounts based on a <first name><dot><last name> format (such as darril.gibson), the application will always create it using this convention.

It’s important to consider accounts that have elevated permissions, such as administrator accounts. Many organizations require administrators to maintain two accounts. They use one account for day-to-day tasks that have limited privileges, similar to any regular user. They have a second administrator account that they use only when performing administrative work. This helps limit the risks to the administrator account.

For example, if malware infects a system while a user is logged on, the malware can assume the privileges of the logged-on user. If the user is logged on with administrative privileges, the malware assumes the same level of privileges and can then take actions as an administrator.

In contrast, if malware infects a system while a regular user is logged on, the malware must use more technical methods to escalate its privileges. If an administrator is logged on as a regular user 90 percent of the time and uses the administrator account only 10 percent of the time, it reduces this risk.

Maintenance and Entitlement

Many organizations have account management policies that dictate how accounts are created and managed through their lifetime. These policies address password management, account lockouts, and procedures to add and remove privileges.

The “Something You Know” section earlier in this chapter discussed password policies. They ensure that users create strong passwords, change them regularly, and don’t reuse the same passwords. It’s common to enforce password policies with a technical policy such as with Microsoft’s Group Policy. In other words, the password policy starts as a written policy and a technical policy enforces it.

Account Lockout Policies

An account lockout policy locks out an account after too many failed logon attempts. The goal is to prevent attackers from guessing passwords in an online brute-force attack. For example, a policy may dictate that an account is locked out for 30 minutes if someone enters an incorrect password five times in a row.

There are two common settings for account lockout policies:

•  Threshold   This identifies how many incorrect passwords are allowed. For example, if it is set to five, an account is locked out after someone enters the wrong password five times in a row.

•  Duration   This identifies how long the account remains locked out. For example, if the duration is set to 30 minutes, the account will remain locked out for 30 minutes. After 30 minutes, the user will be able to log on with the correct password. In some cases, the duration is configured so that it never expires. The account remains locked out until an administrator unlocks it.

Entitlement and the Principle of Least Privilege

Entitlement refers to the privileges granted to users, and following the principle of least privilege, it is an important part of entitlement. As mentioned in the “Role-based Access Control” section, using roles (or groups) makes it easier to manage privileges.

Roles and groups provide significant security benefits related to entitlement. For example, suppose that Maria is working in the Sales department. She has appropriate privileges to perform her job there. After earning her SSCP certification, she transfers to the IT department and starts working in IT security. Administrators add her account to IT groups related to her new IT security job and remove her account from groups related to her job in sales.

Removing a user from a group immediately removes all the privileges assigned to the user as a member of that group. In other words, removing Maria from the Sales group removes the privileges that she had while working in the Sales department. The key here is that it’s important to remove users from groups when they transfer. If processes aren’t in place to monitor entitlement, users end up having more privileges than they need to perform their jobs.

De-provisioning

Account de-provisioning refers to disabling and deleting inactive accounts. At a minimum, inactive accounts need to be disabled. When it’s determined that the account is no longer needed, it should be deleted.

As an example, if Sally leaves the company to take an executive position in another company, her account needs to be disabled. If it is not, she may be able to access it. If she was able to work from home using a VPN connection, she could still use this VPN connection after she leaves the company. If the account is not disabled and another employee discovers the password, the other employee can log in to the account. Auditing will record any malicious action taken by the other employee as if Sally did it.

Most organizations require that someone disables user accounts as soon as possible after employees leave the company. This includes employees who are terminated and employees who resign. After a specified time, such as 90 days, administrators delete the account. This allows managers to verify the account is not needed prior to deleting it.

In addition to disabling accounts for employees who leave the company, many organizations disable accounts when employees leave for an extended period. For example, if an employee must take an extended leave of absence, the organization disables the account.

Participating in Physical Security Operations

While the majority of this chapter focused on logical controls, organizations also use physical access controls to protect assets. Physical access controls include items that you can physically touch. The following list identifies many physical access controls:

•  Guards

•  Mantraps

•  Locked doors

•  Alarm systems

•  Cameras and closed circuit TVs (CCTVs)

•  Facilities (controlled with physical security)

Personnel in the organization need to understand and follow appropriate policies related to physical security. As an example, personnel should help prevent tailgating. Tailgating occurs when someone follows someone through a controlled entry point without providing credentials. Imagine that Bob enters the numbers into a cipher lock to open a door. Suzie follows right behind him without entering the numbers into the cipher lock. In this example, Suzie is tailgating. A mantrap would prevent this activity.

Chapter 9 covers security controls in more depth including physical security controls. In the context of physical security operations, it’s worth discussing badging and data center assessments.

Badging

Organizations often issue badges to employees to help identify them. These badges typically include information about the employee, such as the employee’s name, along with a picture of the employee.

Many times these badges include additional capabilities. For example, the badge can also be a proximity card used to open doors. Similarly, the badge can also be a smart card used for authentication with computers. As mentioned previously, PIV cards and CACs are specialized types of smart cards that include a photo and can be used for identification as well as authentication.

Data Center Assessment

A data center assessment can evaluate the effectiveness of physical security for a data center. Data centers can house hundreds of physical and/or virtual servers, and these servers often hold valuable data that needs to be protected.

Security professionals and/or security consultants look at various elements of physical security. As an example, a security consultant can test physical security by attempting to gain access to secure areas by tailgating or via other methods. If a security consultant is successful, an attacker could also be successful.

Similarly, an assessment can evaluate cameras and CCTV systems. A primary concern is ensuring that the systems meet the needs of written security policies. For example, a security policy may state that both entrances and exits need to be monitored, which requires at least two cameras. Chapter 8 covers different types of security assessments.

Chapter Review

Access control systems use identification and authentication. Identification occurs when a subject professes an identity, and authentication occurs when the user proves the identity. Administrators authorize authenticated users access to resources by granting permissions to the resource.

The three factors of authentication are something you know (such as passwords), something you have (such as smart cards), and something you are (using biometrics). Most organizations use written password policies to define requirements. Technical controls implement and enforce password policies, and auditing tools verify compliance with the policies.

Passwords are the weakest authentication mechanism. Static passwords stay the same over a period of time. Dynamic one-time passwords use a different password for each user session and provide much more security than static passwords. Cognitive passwords are based on information that a user knows but an attacker is unlikely to know.

Smart cards, hardware tokens, and proximity cards are examples of something you have. It’s common to combine these methods with an additional factor of authentication, providing multifactor authentication. For example, users often enter a PIN along with using a smart card.

Hardware tokens use one-time passwords. A synchronous one-time password is time-based and requires the token and a server to be synchronized. An asynchronous one-time password doesn’t require time synchronization but instead uses another method to create the password. Software tokens use protocols such as Time-based One-Time Password (TOTP) and HMAC-based One-Time Password (HOTP). TOTP creates synchronous time-based one-time passwords. HOTP, One-time Password In Everything (OPIE), and S/KEY create asynchronous one-time passwords.

Many organizations implement two-step authentication using HOTP and/or TOTP. After a user attempts to log on, the authenticating system sends a numeric code to the user and requires the user to enter this code to complete the log on process.

Biometrics methods measure physical characteristics of individuals, such as their fingerprints, palms, retinas, and irises. These characteristics are in the something you are factor of authentication. When evaluating the effectiveness of biometrics, you should consider the type 1 and type 2 errors. The False Rejection Rate (FRR, or type 1 error) refers to the percentage of times a system falsely rejects a known user. The False Acceptance Rate (FAR, or type 2 error) refers to the percentage of times a biometric system falsely identifies an unknown user as a known user. The Crossover Error Rate (CER) indicates the point where the FAR and FRR are equal. Lower CERs indicate a better biometric system.

Single sign-on (SSO) allows a user to authenticate once for a system. The user can then access any resources in the system (as long as the user has access) without authenticating again. Kerberos is a popular SSO protocol used within networks. A Kerberos server issues symmetric encryption keys as a Key Distribution Center (KDC) and issues tickets as a ticket-granting server. Kerberos provides authentication on a network and contributes to the confidentiality and integrity of information. Many SSO systems use federated access, providing centralized authentication for different systems. Security Assertion Markup Language (SAML) uses an XML-based data format to share SSO information between servers within a federated identity management system. While SAML is primarily used for authentication, it can also exchange authorization information between different entities.

Two newer SSO technologies are OAuth 2.0 and OpenID Connect. OAuth 2.0 is an authentication framework. OpenID Connect is an authentication layer that is commonly used to extend the capabilities of OAuth. Combined, the two allow websites and online web applications to verify the identity of end users without managing the users’ credentials.

Access controls enforce security. For example, a security kernel (a central part of an operating system) enforces security for the operating system by monitoring subjects and objects. Examples of subjects are users, computers, and applications. Examples of objects include data, hardware, and facilities. Access controls can be logical (implemented with technology such as a security kernel) or physical (such as locked doors).

Several access control models are in use, including discretionary (DAC), non-discretionary (non-DAC), mandatory (MAC), role-based (Role-BAC or RBAC), rule-based, and attribute-based (ABAC) models. The DAC model provides the most granular control and is a subject-based or identity-based model. Individual users own the objects (such as files), and as the data owners, they can assign permissions to subjects (such as other users) as desired. DAC is used with file systems such as NTFS with Microsoft systems and NFS with Linux systems.

The RBAC model uses roles. Subjects (such as users) are placed into roles, and permissions to objects are assigned directly to the role. In non-DAC models, security administrators control access. An ABAC model is a sophisticated type of Rule-based Access Control model. Policies identify attributes of subjects, objects, and the environment to control access.

The MAC model provides the highest level of security when compared to DAC and RBAC models. Both subjects and objects are assigned labels, and when the labels match, access is granted. Several architectures are based on the MAC model. The Bell-LaPadula model has a primary goal of ensuring confidentiality and uses rules of no read up and no write down. The Biba model has a primary goal of ensuring integrity and uses rules of no read down and no write up. The Clark-Wilson model provides integrity by using certification and enforcement rules to enforce integrity and separation of duties. The Brewer-Nash model helps prevent conflicts of interest by preventing access to data organized in conflict-of-interest classes.

Many access control models use an access control matrix and/or a capability table. An access control matrix is object based, with a list of objects along with the permissions granted for each object. A capability table is subject based, with a list of subjects along with the capabilities granted to the subjects.

Identity and access management includes provisioning, maintenance, entitlement, and de-provisioning. Provisioning includes creating accounts and providing appropriate access. Many organizations use roles or groups to manage access to resources. Account management ensures that accounts use appropriate password policies and account lockout policies to help thwart online brute-force password attacks. Entitlement refers to privileges granted to users and helps ensure that the principle of least privilege is followed. Proper de-provisioning practices ensure that accounts are disabled when the employee is no longer working for the company.

Physical security controls include any controls that you can physically touch. Badges are one type of physical security control and typically include a picture of the employee. Badges can also include other capabilities such as a proximity card and/or a smart card. Data center assessments evaluate the physical security methods used to protect data centers.

Questions

1.   A user professes an identity by entering a user logon name and then enters a password. What is the purpose of the logon name?

A.  Authentication

B.  Accountability

C.  Identification

D.  Accounting

2.   Access controls protect assets such as files by preventing unauthorized access. What must occur before a system can implement access controls to restrict access to these types of assets?

A.  Identification and authentication

B.  Identification and accountability

C.  Authentication and accounting

D.  Accountability and availability

3.   Users are required to enter a different password each time they log on. What type of password is this?

A.  Static password

B.  Cognitive password

C.  Passphrase

D.  Dynamic password

4.   Authentication includes three types, or factors. Which of the following best describes these authentication methods?

A.  Something you say, something you think, and something you are

B.  Something you know, something you have, and something you type

C.  Something you know, something you say, and something you are

D.  Something you know, something you have, and something you are

5.   Which of the following choices does NOT ensure that a password is strong?

A.  Ensuring that the password is of a sufficient length

B.  Ensuring that the password is changed frequently

C.  Ensuring that the password has a mixture of different character types

D.  Ensuring that the password does not include any part of the user’s name

6.   What can be used to prevent a user from reusing the same password?

A.  Minimum password age

B.  Maximum password age

C.  Password length

D.  Password history

7.   A user tries to log on to his bank account via the Internet with his username and password. The webpage then displays a message indicating a code was sent to his smartphone and prompts him to enter a six-digit code. What type of authentication is this?

A.  One-factor authentication

B.  Two-step authentication

C.  Three-factor authentication

D.  TOTP-based authentication

8.   What form(s) of authentication are individuals using when they authenticate with a hardware token and a password?

A.  Something they have only

B.  Something they know only

C.  Something they have and something they know

D.  Something they have and something they are

9.   An organization uses a biometric system with a one-to-many search method. What does this system provide for the organization?

A.  Authentication

B.  Accountability

C.  Authorization

D.  Identification

10.   An organization has been using an iris scanner for authentication but has noticed a significant number of errors. Assuming the iris scanner is a high-quality scanner, which of the following is MOST LIKELY affecting its accuracy?

A.  False Acceptance Rate (FAR)

B.  False Rejection Rate (FRR)

C.  Sunlight shining into the scanner

D.  Faulty laser beam

11.   Which of the following metrics identifies the number of valid users that a biometric authentication system falsely rejects?

A.  FAR

B.  FRR

C.  CER

D.  AAA

12.   What is SSO?

A.  A system that requires user credentials once and uses the same credentials for the entire session

B.  An authentication system that requires users to use different credentials for each resource they access

C.  A secure system used for operations

D.  Any network that employs secure access controls

13.   What type of service does Kerberos provide?

A.  Authentication

B.  Accounting

C.  Availability

D.  Accountability

14.   Of the following choices, what most accurately identifies the major drawback of SSO systems?

A.  It allows users to access multiple systems after logging on once.

B.  It increases the difficulty for users to log on.

C.  It increases the administrative workload.

D.  It risks maximum unauthorized access with compromised accounts.

15.   What type of access control is subject based?

A.  Discretionary

B.  Non-discretionary

C.  ABAC

D.  Biba

16.   What is the primary goal of the Bell-LaPadula model?

A.  Enforce separation of duties

B.  Enforce two-factor authentication

C.  Enforce confidentiality

D.  Enforce integrity

17.   Which of the following models helps enforce the principle of separation of duties?

A.  Brewer-Nash and Clark-Wilson

B.  Brewer-Nash and Biba

C.  Clark-Wilson and Bell-LaPadula

D.  Biba and Bell-LaPadula

18.   Which of the following statements is true?

A.  An access control matrix is object based and a capability table is object based.

B.  An access control matrix is subject based and a capability table is object based.

C.  An access control matrix is object based and a capability table is subject based.

D.  An access control matrix is subject based and a capability table is subject based.

19.   Which of the following will disable an account if an attacker tries to guess the password multiple times?

A.  A password policy

B.  An account lockout policy

C.  A password history

D.  De-provisioning accounts

20.   Which of the following actions is most appropriate if an employee leaves the company?

A.  Delete the user’s account as soon as possible.

B.  Disable the user’s account as soon as possible.

C.  Change the user’s password as soon as possible.

D.  Change the user’s permissions as soon as possible.

Answers

1.  C. The logon name provides identification for the user. When combined with the username, the password provides authentication. Accountability is possible if a system can identify users and track their activities. Accounting is provided by logging after proper identification and authentication.

2.  A. Identification and authentication must occur before a system can implement access controls. Identification is the act of a user professing an identity, and authentication occurs when an authentication system verifies the user’s credentials (such as a username and password). Without proper identification and authentication, it isn’t possible to restrict access to specific subjects. Accountability is not possible if an authentication system does not identify and authenticate users. Similarly, you can’t provide accurate accounting if users haven’t been identified and authenticated.

3.  D. A dynamic password is a one-time password that changes for each session. A static password stays the same over a period of time, such as 30 days. A cognitive password includes information that a user would know but isn’t necessarily public knowledge. A passphrase is a static password using a long string of characters that has meaning to the user.

4.  D. The three factors of authentication are something you know, something you have, and something you are. Something you think, something you type, and something you say are not authentication factors.

5.  B. A password should be changed regularly, but doing so doesn’t ensure the password is strong. For example, if a user changes a password from “1234” to “4321,” it is not strong. The other options all contribute to the strength of a password. Note that this an example of a question that can be switched to a multiple-correct-answer question. For example, it could be “Which of the following choices ensures that a password is strong? (Choose THREE).”

6.   D. Password history remembers users’ previous passwords and prevents them from reusing passwords. The minimum password age is used with the password history to prevent users from changing their password repeatedly to get back to the original password. It is often set to one day. The maximum password age identifies when users must change their passwords. The password length identifies the minimum number of characters in the password.

7.  B. This is two-step authentication. It is not one-factor authentication because it requires the user to know something (the username and password) and have something (the smartphone) to retrieve the code. It is not three-factor authentication because it not using biometric authentication (something you are). While two-step authentication might use the Time-based One-Time Password (TOTP) protocol, all two-step authentication methods do not use TOTP. Some use the HMAC-based One-Time Password (HOTP) protocol.

8.  C. The two factors of authentication are something they have (the hardware token) and something they know (the password). The third factor of authentication is something you are (using biometrics), but neither a hardware token nor a PIN uses biometrics.

9.  D. Biometric systems used for identification use a one-to-many search method. They use the one biometric value (such as a fingerprint) provided by the user and search a database of many similar values (fingerprints) to find a match. Biometric systems used for authentication use a one-to-one search method. They use the biometric value provided by the user, along with the user’s claimed identity, and check to see if the value matches the value stored with the user’s account. Once a system identifies and authenticates a user, biometric systems are not used for accountability or authorization.

10.  C. Lighting affects the accuracy of an iris scanner, so sunlight shining into the scanner’s aperture will affect the accuracy. The FAR and FRR indicate specific types of errors. An iris scanner does not use a laser beam.

11.   B. The False Rejection Rate (FRR, also called a type 1 error) refers to the percentage of times a biometric system falsely rejects a known user. The False Acceptance Rate (FAR, also called a type 2 error) refers to the percentage of times a biometric system falsely identifies an unknown user. The Crossover Error Rate (CER) identifies where the FAR matches the FRR. AAA refers to the three As of security—authentication, authorization, and accounting.

12.  A. Single sign-on (SSO) requires users to log on once, and it uses the same credentials for any other resources accessed during the session. Users are not required to use different credentials for each resource with SSO. SSO is not a network.

13.   A. Kerberos provides authentication. Accounting and accountability are possible if a system can identify users and track their activities, but Kerberos doesn’t provide logging of user activities. Availability ensures systems are operational when needed. While not listed as one of the answers, Kerberos also contributes to confidentiality and integrity.

14.   D. A major concern with SSO systems is that if any single account is compromised, it maximizes the potential unauthorized access. A primary benefit is that SSO allows users to access multiple systems after logging on once. It decreases the difficulty for users to log on and decreases the administrative workload.

15.  A. A Discretionary Access Control (DAC) model assigns permissions to identities (subjects), making it a subject-based model. Not all non-discretionary models assign permissions to identities, so B is not the best answer. Attribute-based Access Control (ABAC) focuses on attributes of subjects, objects, and/or the environment. Biba is a MAC-based model that uses labels assigned to both subjects and objects to enforce integrity.

16.   C. The Bell-LaPadula model has a primary goal of ensuring confidentiality. The Clark-Wilson and Brewer-Nash access control models help enforce the principle of separation of duties. The Biba model enforces integrity. Access control models do not enforce authentication factors.

17.   A. Both the Clark-Wilson model and the Brewer-Nash model enforce the principle of separation of duties. The Clark-Wilson model also enforces integrity, and the Brewer-Nash model also helps prevent conflicts of interest. Biba enforces integrity. Bell-LaPadula enforces confidentiality.

18.  C. An access control matrix is object based and a capability table is subject based. An access control matrix is a list of objects along with the permissions granted for each object. A capability table is a list of subjects along with the capabilities granted to the subjects.

19.   B. An account lockout policy can disable an account if an attacker (or a user) enters the wrong password too many times. The threshold is often set to three or five, causing an account to be locked out after a user enters the wrong password three or five times, respectively. A password policy ensures that users create strong passwords and regularly change their password. Password history prevents users from reusing the same password. De-provisioning refers to disabling and deleting inactive accounts.

20.   B. User accounts should be disabled as soon as possible after the user leaves the company under any circumstances. The account should not be deleted until it’s determined to be no longer needed. Changing the password without disabling the account stills allow the account to be used. Disabling the account removes the access and is more direct than changing permissions.