0% found this document useful (0 votes)
6 views

12

This document provides an overview of access control in enterprise environments. It discusses access control lists (ACLs) and access control entries (ACEs) which define permissions for subjects to access objects. It also describes common access control models used in enterprises, including discretionary access control (DAC), mandatory access control (MAC), role-based access control (RBAC), and attribute-based access control (ABAC). The document emphasizes that enterprises must select access control models based on their structure, policies, and risk levels to balance security needs with usability.

Uploaded by

vatsb22
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views

12

This document provides an overview of access control in enterprise environments. It discusses access control lists (ACLs) and access control entries (ACEs) which define permissions for subjects to access objects. It also describes common access control models used in enterprises, including discretionary access control (DAC), mandatory access control (MAC), role-based access control (RBAC), and attribute-based access control (ABAC). The document emphasizes that enterprises must select access control models based on their structure, policies, and risk levels to balance security needs with usability.

Uploaded by

vatsb22
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 43

CHAPTER

10 Access Control in the Enterprise

ACCESS CONTROL AND AUTHENTICATION within an enterprise is a large-scale


problem with multiple solutions. Each enterprise has its own way of handling it,
depending on the risk that is associated with the information and activities on the
network. The higher the risk of an attacker entering an organization and seeing
or removing information, the more constraints the enterprise will put on users.
An organization that maintains a large amount of credit card information or per-
sonally identifiable information (PII) on its customers will incur a higher impact
if that information is removed or accessed illicitly. Corporations are now required
to let a third party know when certain information has been compromised within
their systems. The reaction to this breach in information may stop people or other
enterprises from doing business with them.

Chapter 10 Topics

This chapter covers the following topics and concepts:

What access control lists (ACLs) and access control entries (ACEs) are

Which access control models are common in enterprise environments

What authentication factors are, and the risks associated with them

What Kerberos is and how it works

How Layer 2 and Layer 3 access controls protect the network

Which access controls are associated with wireless local area networks
(WLANs)

What single sign-on is and how to use it


What best practices help you implement access controls in an enterprise
environment

What some case studies and examples are

Chapter 10 Goals

When you complete this chapter, you will be able to:

Understand how ACLs and ACEs are related, and how to use them

Identify mandatory access control (MAC), discretionary access control (DAC),


role-based access control (RBAC), and attribute-based access control (ABAC)
models

Understand authentication factors, and the strengths and weaknesses of some-


thing you know, something you have, and something you are

Understand Kerberos, the Kerberos-trusted Key Distribution Center (KDC), the


Kerberos Ticket-Granting Service (TGS), and the Kerberos Authentication Service

Identify Layer 2 and Layer 3 techniques for controlling network access

Implement security for a WLAN infrastructure

Plan for single sign-on access control

Apply best practices to access control implementation in an enterprise


environment

Apply lessons learned from case studies to real-world situations

Access Control Lists (ACLs) and Access Control Entries (ACEs)

In this section, you’ll review the definitions of access control lists and access con-
trol entries, then take a closer look at these important security features.

An access control list (ACL) is made up of access control entries (ACEs). An


ACE contains at least two items, a security identifier (SID) and one or more au-
thorization levels for each SID. A SID is created for a user, group, or computer ac-
count when a new account is first created on a network. The authorization levels
established against a user, group, or system are allowed, denied, or audited.

NOTE

Most ACLs contain access control entries. However, an ACL can contain no en-
tries. This permits either full access or no access to an object, depending upon the
operating system.

Table 10-1 provides an example of ACL permissions and what they mean. These
permissions define the capabilities that are given or denied to the access control
subject.

TABLE 10-1 ACL permissions.


PERMISSIONS DEFINITIONS

Delete Allows the ability to delete the object


Read Allows the ability to read the object
Write Allows the ability to write to the object
Modify Allows the ability to read, write, execute,
and delete (may not include file
permissions)
Execute Allows the ability to execute a program
Full Control Allows all abilities including permissions
No Access Denies access to the object

An ACL is bound to any object that has security permissions, such as a file, direc-
tory, port, process, or event. An ACL can be used in applications, operating sys-
tems, and configuration of network devices such as routers. There are two types
of access control lists:

Discretionary Access Control List (DACL)—Contains ACEs that allow or deny


subjects permission to interact with objects

System Access Control List (SACL)—Contains ACEs that allow system adminis-
trators to require auditing of the success and failure of attempted interactions
with objects
An SACL is usually established by a systems administrator. A DACL is set up by the
owner of an object. An object ACL may have multiple ACEs associated with it.
Some ACEs create permissions conflicts. In this case, permission resolution takes
place based on the operating system such as Windows or UNIX. Most systems use
a least-privilege security principle. This principle states that if a user is in multiple
groups with multiple permissions, the least permissive permission will be
granted. For example, let’s say Kevin is an employee who has been granted access
rights. He has full control permissions (most permissive) and no access permis-
sions (least permissive) applied to him, which causes a conflict. To resolve the
conflict, Kevin will be provided no access.

NOTE

When people discuss an ACL, they’re usually referring to the DACL. If no criteria
have been established against an object, the system grants an implicit “deny” to
prevent access.

Access Control Models

Access control models are the core that identifies how a user accesses an object.
An enterprise determines the best model based on the organization’s structure,
the policies within the organization, and the benefits and risk associated with im-
plementation. You’ll read about several models in the next section.

Confidentiality, Integrity, and Availability

Confidentiality, integrity, and availability (C-I-A) are large components of access


control. In order to define risk associated with a subject accessing an object, you
must understand the object and the system being accessed. The following are
brief descriptions of the components of C-I-A:

Confidentiality—Ensuring the right information is seen only by subjects that


are authorized to see it

Integrity—Ensuring a system is not changed by a subject that is not autho-


rized to do so

Availability—Ensuring a system is accessible when needed


Some systems security professionals refer to the C-I-A triad as the “A-I-C” triad
(availability, integrity, and confidentiality) to avoid confusion with the U.S.
Central Intelligence Agency, which is commonly referred to as the CIA. Either ab-
breviation is acceptable. However, if you use C-I-A, make sure people understand
you’re referring to confidentiality, integrity, and availability.

Discretionary access control (DAC)—Policy defined by the object owner

Mandatory access control (MAC)—Policy defined by the system

Role-based access control (RBAC)—Policy defined by the functions the user


performs within the organization—for instance, roles can be Human Resources or
Finance

Attribute-based access control (ABAC)—Policy a function of a subject’s


characteristics

The following sections describe access control models in more detail.

Discretionary Access Control (DAC)

The DAC model is the most widely used access control method. It is defined by the
Trusted Computer System Evaluation Criteria (TCSEC) as “a means of restricting
access to objects based on the identity of subjects and/or groups to which they be-
long. The controls are discretionary in the sense that a subject with certain access
permission is capable of passing that permission (perhaps indirectly) on to any
other subject (unless restricted by mandatory access control).”

DAC allows the owner of a resource to manage who can or cannot access the item.
Owners maintain this access through ACLs, and they can delegate the ability to
modify permissions to others. This removes the need for systems administrators
to determine the importance of a document and who should have the necessary
control. It puts the responsibility in the hands of the owner of the resource. Other
than some highly specialized cases in the defense industry, every modern operat-
ing system supports DAC.

FYI
The Trusted Computer System Evaluation Criteria (TCSEC) are a set of require-
ments used to rate the security of a computer system. The U.S. Department of
Defense (DoD) National Computer Security Center established the TCSEC. An en-
tity in the “Rainbow Series,” it is often referred to as the Orange Book because of
the color of its cover, but its official listing is DoD 5200.28-STD. The original ver-
sion was created in 1983 and was updated in 1985. TCSEC was replaced by the
Common Criteria for Information Technology Security Evaluation (ISO
15408) in 2005.

Mandatory Access Control (MAC)

MAC allows a systems administrator to maintain the security aspect of an object.


It was established by TCSEC and is defined as “a means of restricting access to ob-
jects based on the sensitivity (as represented by a label) of the information con-
tained in the objects and the formal authorizations (i.e., clearance) of subjects to
access information of such sensitivity.” MAC systems are sometimes used by gov-
ernment agencies to implement the national security classification system. The
use of MAC in these cases ensures that one user cannot grant a second user access
to information that would exceed the second user’s security clearance. For exam-
ple, a user with access to a Top Secret document could not delegate that access to
a user who possesses only a Confidential security clearance.

The access for an object is based on the sensitivity of the object versus the subject
matter. The object’s access is related to the user who is attempting to access it. For
example, if an object has a classification of Secret, the subject attempting to access
the object must have a clearance of Secret or Top Secret. No ACLs are associated
with the object, and neither the object nor the system user can change the sensi-
tivity level. Similarly, a subject with a Top Secret clearance has access to an object
that is at or below the clearance level.

MAC is considered one of the most secure access methods because it requires both
the object and the subject to have security labels assigned to them. It is often used
in a multilevel security (MLS) system. An MLS system allows the computer system
to simultaneously process information of different classification levels and en-
sures a subject with the correct clearance can access only the information at his
or her authorization level. In contrast, a multiple single level (MSL) environment
does not allow different classification levels to commingle. A separate system
would be used for each classification level.
Role-Based Access Control (RBAC)

Role-based access control (RBAC) is also known as non-discretionary access


control.

It grants access to an object based on the subject’s role within the system. Three
aspects are taken under consideration within an RBAC system:

Role assignment—A subject can execute a transaction only if the subject has
selected or been assigned a role. All active users are required to have an active
role. For example, if the user Kevin is assigned to the Human Resources role, he is
allowed to perform only the actions that this role allows.

Bell-LaPadula Model

Confidentiality rules within the U.S. government were established through the
Bell-LaPadula Model and are described in the Orange Book. An MLS system is a
Bell-LaPadula system. Three security principles are used in this model:

Simple security rule—A subject cannot read an object that maintains a higher
security level. It is also known as the “no read up” rule. A user with a Secret secu-
rity clearance cannot read a document with a higher classification such as Top
Secret.

*- property rule—A subject cannot write to an object that maintains a lower


security level. It is also known as the “no write down” rule, or the “star property”
rule. A user with a Top Secret clearance cannot write to a document that has a
lower classification such as Secret.

Strong *- property rule—A subject can read and write to an object only if the
object classification and the subject’s clearance match exactly.

Role authorization—A subject’s active role must be authorized for the subject.
This ensures that users can only take on roles that they are authorized for.

Transaction authorization—A subject can execute a transaction only if the


transaction is authorized for the subject’s active role.

Administering access within an RBAC system is considered easier for the adminis-
trator because the access is based on roles within the organization and what each
role is allowed to do. For example, an administrator may define a Human
Resources role for the entire HR organization. If Kevin moves from the HR depart-
ment to the finance department, he is simply removed from the Human
Resources role and placed into the Finance role.

Separation of duties expands the RBAC controls. For example, although Kevin’s
role may be Finance, this does not mean that he needs full access to all financial
data. Separating each role into the activities users are responsible for provides
more granular access control. This ensures that no one user has enough control to
compromise the system. This mechanism helps to deter fraud, ensuring that at
least two people are required to perform a critical task. Separation of duties is
also related to the least-privilege security principle. This principle states that a
user should not have any more access than is necessary for the user to do his or
her job.

Attribute-Based Access Control (ABAC)

Attribute-based access control systems grant access for the subject based on addi-
tional attributes that they must verify. For example, when accessing a system that
is available only to residents of a particular town, the subject may have to enter
an address within that town. This allows the administrator to have a more granu-
lar access control capability to the particular objects.

FYI

A MAC or DAC system employs ACLs for managing the access of information
within a system. The RBAC method defines the access specifically on the role that
the user has within the organization, and the operations that the role can partici-
pate in. A MAC or DAC focuses more on the information, whereas an RBAC sys-
tem focuses more on the people and the actions they can or cannot do.

Authentication Factors

Authentication, with regard to a subject, is validating the subject’s claim of iden-


tity. There are multiple ways subjects can prove themselves.

Types of Factors
Ensuring the authenticity of the subject can be determined by three factors. The
more factors a subject can provide, the more trust one can put in that subject:

Something you know—An item that the subject is aware of or has knowledge
of

Something you have—An item that the subject has possession of

Something you are—A characteristic of the subject

Something You Know

Having specific knowledge that is unique to a subject is one method of


authentication.

Examples of this factor include a password, a personal identification number


(PIN), or a passphrase.

A password is generally combined with a unique identifier such as a username


(or user ID), and it provides the additional authentication that the subject is legiti-
mate. A password can have multiple limitations based on length, special charac-
ters, complexity, and reuse factor, or it may have no limitations. The more specific
or unique a password is, the stronger it is, and therefore it has a lower chance of
being guessed or cracked.

Systems administrators specify the characteristics of passwords, but subjects have


to remember passwords. This tends to be a challenge because passwords should
never be written down. Some best practices for passwords are:

A password should have a minimum of eight characters.

Change passwords on a regular basis, such as every 45 to 90 days.

Include special characters and numbers, and vary the case of letters
(P@ssW0rd).

Do not reuse passwords.

Use different passwords for different accounts.


With so many applications and tools that you log on to these days, using best prac-
tices and keeping passwords safe is becoming more difficult. Tools such as pass-
word managers or password vaults are available for storing your passwords, but
these also require a form of authentication to retrieve the information. Tools that
allow you to answer questions about yourself are a method that tends to remove
passwords altogether or, in some instances, may be used to retrieve your pass-
word from an application. For example, Kevin may have forgotten the password
for his mobile service online account. After Kevin selects “Forgot password,” the
application asks him security questions that were configured previously in his
profile. Such questions may be:

What is the name of your high school?

In what city were you born?

What is the name of your favorite childhood pet?

What is the title of your favorite book?

Additional tactics could be a passphrase related to the application or the subject.


For example, Kevin may be trying to log on to his 401(k) account but cannot re-
member the password. By creating a passphrase based on the tool he is accessing,
Kevin may be able to add complexity and provide something he can easily recall:

Saving money for my future keeps me a happy Kevin = S$4mfkma:)K

Almost everyone is aware of the purpose of passwords, and many people use
passwords daily. The problem is that passwords have turned into a risk. Years
ago, when passwords were first implemented, they were relatively simple.
Knowing how simple they were made it easier for attackers to steal them. Some
of the ways that attackers steal passwords are:

Dictionary attacks—Matching common words found in a dictionary to a user’s


password until a match occurs

Brute-force attacks—Using software code to run through various password


schemes with numbers, symbols, capital letters, and characters until a match
occurs

Eavesdropping—Listening in on a network to learn usernames and passwords


Social engineering—Convincing users that they are connecting to a secure and
well-known Web site, which is actually a site created by the attacker to obtain
usernames and passwords

Weaknesses of knowledge-based methodologies. One of the biggest challenges


in using passwords is memorizing them. As previously stated, you should avoid
reusing passwords and avoid writing them down. Accessing applications irregu-
larly only adds to the problem with passwords. For example, Kevin accesses his
mobile online account once a month to pay the bill. He often forgets the password
and the passphrase he created for the account. Today he makes multiple attempts
at logging on, but after his fifth failed password he is locked out. He now needs to
call the mobile carrier and speak with a representative, who might ask Kevin for
his Social Security number and date of birth. Answering these questions over the
phone is a security risk, and one-on-one customer service is an extra expense for
the mobile phone carrier. Due to the extra expenses and risk of resetting a pass-
word, an organization might not choose the safest mechanism because it may be
too expensive to maintain and administer.

Third-party participants and tools also create havoc when only knowledge-based
access authentication factors are used. You might have downloaded malware,
such as a keystroke logger, to your computer without knowing it. These tools are
used to steal your password, and your account can then become compromised.
This can lead to the loss of money, personal information such as account numbers
and Social Security numbers, and additional PII.

NOTE

Malware is malicious software that inadvertently gets downloaded to your com-


puter system without your knowing it. This software can be downloaded when
surfing Web pages, clicking on Web page items, opening e-mail attachments, or
executing an application that has malicious code embedded. Examples of mal-
ware are Trojan horses, keystroke logging tools, worms, and viruses.

Trojan horse malware, which is also referred to as a Trojan, is another tool often
used by attackers to pull password information from a user. When the Trojan is
installed on a computer system, the attacker has complete access to the system.
The subject may never know that it is there. Some of the malicious activities car-
ried out by Trojans include:
WARNING

Removing a Trojan can be difficult because you don’t know what damage it has
inflicted on your system. Antivirus software can assist in blocking Trojans. It’s
highly important to keep antivirus software up to date; however, there is no fail-
safe method for keeping a computer system secure.

Viewing the screen of the computer system

Keystroke logging

Stealing passwords and PII

Changing, deleting, and installing files

In addition to malware used on computer systems to gather information about


the user, additional tactics have been implemented with changes and additions to
technology:

Man-in-the-middle attacks—The entire conversation between two parties is


controlled by an attacker. The attacker can read and, at times, change the
communication.

Phishing—Used to steal credentials of subjects by sending them an e-mail ask-


ing them to log on to a site, answer questions, and provide information that com-
promises their account. This is a form of social engineering.

Spear phishing—A form of phishing that targets specific individuals. The


phishing communication may be sent to a large group of people, hoping that spe-
cific information for several of the individuals will be returned. When all the data
is consolidated, a broader understanding of the organization and various creden-
tials will allow the attacker access.

SMShing—A form of phishing that is sent directly to the subject’s phone. This is
done through a Short Message Service (SMS) message.

Distribution of Passwords and PINs

So how exactly does a subject get an initial or saved password or PIN? How does
authentication ensure that the subject is valid if the initial authentication failed?
Should you allow the subject to reset his or her own password, or should you
provide a temporary password?

Several options for password and PIN distribution are the postal mail, SMS mes-
sages, e-mail, and the phone system. For instance, when Kevin is unable to log on
to his online banking portal, the bank may choose to send him a temporary PIN.
One option is to send this PIN to the cell phone he has registered with the bank.
The bank sends Kevin an SMS message and asks him to enter the PIN into the
portal within a preset amount of time, such as 60 seconds. The bank has identi-
fied this cell phone as Kevin’s because he provided it during his initial enroll-
ment process. The SMS message is the fastest and one of the safest ways to get the
temporary PIN to Kevin. The bank may also choose to send a follow-up e-mail to
Kevin to inform him that the text was sent with a temporary PIN. If Kevin did not
receive the SMS message, he should inform the bank as a precaution.

Another tactic for gaining information is called shoulder surfing. For instance,
Kevin likes to work on his computer at his local coffee shop, but people around
him may be able to see what he is doing, including entering passwords for his ac-
counts. Although a password may be blocked out on the screen, the username is
still available, and people can watch Kevin type his password on the keyboard
and memorize the keystrokes.

The passwords used for various systems are also kept internally, on a workstation
or server. How do enterprises secure them? How are passwords stored when you
check a Remember Me checkbox on a Web site? The passwords maintained
through a third-party application or through another tool should be encrypted so
if hackers access them, the passwords cannot be read and used to gain access to
your accounts.

Something You Have

In addition to something you know, something you have can help identify you
and/or prove your claim of identity. This identifier can be an automated teller ma-
chine (ATM) card, a token, a driver’s license, or a passport—anything that sup-
ports your identity claim simply because you have it. These forms of authentica-
tion do not require you to remember a password, but they are something you
must have in your possession to authenticate. Consider an example where you
visit a bank and request the withdrawal of funds. You can’t simply walk up to the
teller and say “I’m Bob, please give me $500.” (Wouldn’t that be nice?) The teller
will certainly ask you to prove your claim of identity. You’d most likely satisfy this
request by showing her your driver’s license. The license contains your name and
picture, and the teller uses it to authenticate you before giving you cash.

A token is a physical or software device that can be used instead of a password or


in conjunction with a password or PIN. Tokens come in many forms, such as a
card with a screen and/or a keypad. There are two varieties of token devices:

Synchronous tokens—Use time or a counter as a means of authentication

Asynchronous tokens—Use a challenge and response as a means of


authentication

Smart card. A smart card is a card that is the same size as a credit card and has a
computer chip embedded in it. The computer chip holds data pertaining to the
owner of the card and is used in various transactions through a smart card
reader. Smart cards are also referred to as integrated circuit cards (ICCs). Smart
cards are considered reliable because the information stored within the card can-
not be easily accessed if the card is lost or stolen, but it can be used by other sub-
jects if additional forms of verification are not required.

There are two primary types of smart cards:

Contact smart card—This type of card must be inserted into a smart card
reader to gain authentication or access for the subject.

Contactless smart card—This type of card is often used for access into facili-
ties. Instead of having to insert the card into a reader, the subject waves the card
in front of the reader to verify his or her access credentials. The subject receives
access or is denied access to the location. Contactless cards are also known as
proximity cards or “prox” cards.

Time-variable token. A time-variable token is a synchronous token in the form


of a one-time password. It is a dynamic password in that it can be used only once.
After a single use, it is no longer valid. A time-variable token is valid for a specific
period of time, such as 60 seconds. When authentication is based on time, the to-
ken (hardware or software) time must be synchronized with an authentication
server. The time and the seed record are the main components. The seed record is
the symmetric encryption key, which is shared between the token and the au-
thentication server. This seed record encrypts the clock time; the result is a one-
time password. The same seed record is used for both the token and the authenti-
cation server. Because the authentication server knows that this token is the only
other device with that seed record, it knows that the token code entered comes
from the person holding this particular token.

FYI

A Common Access Card (CAC) was implemented under Homeland Security


Presidential Directive 12 (HSPD-12). It is used by the DoD for authentication and
access to federal facilities and computer systems. This card holds information re-
garding the user such as his or her identity, clearance level, and physical and log-
ical access capabilities. In 1987, the International Organization for
Standardization (ISO) and International Electrotechnical Commission (IEC) im-
plemented ISO/IEC 7816 for ICC with contacts, such as smart cards.

FIGURE 10-1

ACL permissions.

Challenge-response device. A challenge-response device is an asynchronous to-


ken. Authentication occurs via communication with the token device, the authen-
tication server, and the user. A request is sent to the authentication server and a
challenge (a random set of numbers) is returned. The user enters this challenge
into the token, the token encrypts it, and another value is returned. The user then
uses this end value as the password. Once the authentication server receives this
end value, it decrypts it. If the end value matches the challenge, the user is au-
thenticated. This exchange between the user, authentication server, and token de-
vice is shown in Figure 10-1.

Something You Are

Something you are authentication is based on characteristics about a specific per-


son. The characteristics can be voice, facial features, retinal patterns, handwrit-
ing, and repetitive actions. These characteristics are called biometrics. This sec-
tion provides only a brief summary of biometrics.

The technology behind biometrics involves scanning and analyzing the unique
characteristics of a user and matching them against information that was col-
lected during enrollment. The information about individuals can be used for ei-
ther identification or verification. These characteristics can be:

Physiologically-based

Behaviorally-based

NOTE

Enrollment in a biometric system brings an extra level of security to the authen-


tication system because the person must be physically present during the
process. It is also an advantage for individuals because they will not need to re-
member a password to gain access.

Each person’s biometric features are unique, and forging this identification is in-
credibly complicated. However, there are error rates associated with a biometric
system:

False rejection error—Rejecting an authorized user. The frequency with


which this type of error occurs is known as the false rejection rate (FRR).

False acceptance error—Accepting an unauthorized user. The frequency with


which this type of error occurs is known as the false acceptance rate (FAR).

Crossover error rate (CER)—Point at which the FRR and FAR are equal. The
smaller the CER, the more accurate the system is.
Physiologically-based biometrics. Physiologically-based biometric authentica-
tion uses attributes of the user that are unique. Such attributes include finger-
prints, facial features, and retinal patterns. A scanning device scans for biomet-
rics, and the subject must enroll his or her information before access is granted.
When a user accesses a scanner, multiple points of reference are scanned, ana-
lyzed, and compared with the data stored in the database. If enough points match
between the user and the database, access can be granted or denied.

Depending on the biometric system, one type of error may be preferred over an-
other. For example, a military system cannot disclose information to an unautho-
rized subject. Therefore, the military system cannot tolerate false acceptance er-
rors but may accept false rejection errors.

The number of devices that use biometrics for authentication is increasing.


Multiple universal serial bus (USB) and laptop manufacturers are incorporating
this technology into their systems. Many companies now sell portable external
fingerprint biometric scanners.

Behaviorally-based biometrics. Behaviorally-based biometric authentication


creates a characteristic about users based on their patterns. These patterns can be
generated from aspects such as their typing rhythm, which can be unique—differ-
ent people type at a different pace and rhythm. Organizations can use biometric
software to analyze users’ typing rhythms. The software records the time each
key is depressed, as well as the length of time between keystrokes. A unique pro-
file is created for each user. If an attacker tries to impersonate a user but types
the user’s password too slowly or too quickly, the attacker won’t be authenticated.

Financial institutions use pattern matching for online Web access. They may cre-
ate a profile of a user based on the times he or she logs onto the system. If a user
rarely logs onto the system at 3:00 a.m. on a Saturday, for example, the financial
institution’s Web site might prompt the user to enter additional information for
verification purposes.

An individual’s handwriting can also be used as an authentication method. This


requires additional hardware when used with computer systems. Many stores al-
ready use handwriting authentication devices when accepting credit card pur-
chases. Your signature is compared with the signature on your credit card.

Factor Usage Criteria


Now that you understand the various methods of authentication, it is important
to understand how they can work together to create a more secure environment.
Understanding what the user is trying to access and the risk associated with a loss
of the data determines what methods or combination of methods should be used.

Single-Factor Authentication

A single-factor authentication uses only one of the authentication factors (some-


thing you have, something you are, or something you know). This type of authen-
tication tends to be associated with a password, and it’s the least secure because
of the simplistic nature of passwords. Because passwords have been around for a
while, attackers have created tools and methods to get past them. Using symbols,
special characters, and additional controls when creating passwords can help
strengthen them. Some additional examples of a single-factor authentication are a
driver’s license and a house key.

Two-Factor Authentication

Two-factor authentication requires a user to provide two independent authenti-


cation mechanisms from different categories in order to authenticate. Two-factor
authentication is also referred to as strong authentication. It generally combines
something you have and something you know or something you have and some-
thing you are. For example, Kevin’s organization has implemented two-factor au-
thentication, which requires him to enter a PIN (something you know) and a to-
ken password (something you have). In order for an attacker to be able to access
the same resource, he or she would need to know Kevin’s PIN and have the token
in hand. Another example of two-factor authentication is an ATM card (something
you have) and the PIN (something you know). When Kevin wants to access the
money in his banking account through an ATM machine, he needs to provide the
debit card and the PIN in order to start the transaction.

NOTE

Is a debit or credit card a single-factor or a two-factor authentication method?


Recently, some vendors have chosen not to require a PIN or signature when us-
ing a debit or credit card if the purchase is below a certain amount. Does this
now make the credit card a single-factor authenticator? If the cashier does not
compare the signature on the credit card to the signature on the slip, is the credit
card a single-factor or two-factor authenticator?

Another form of two-factor authentication is something you are and something


you have. For example, security managers of a government facility want to imple-
ment two-factor authentication for access to a secure area, but they do not want
to use smart cards because the cards can be lost or stolen. To ensure only autho-
rized people can access the secure area, the managers may choose a two-factor
authentication that requires a retinal scan followed by a PIN.

Three-Factor Authentication

Three-factor authentication, also a form of strong authentication, includes all


authentication factors of something you know, something you are, and something
you have. For example, obtaining access to a highly classified room may require a
badge, a PIN, and a retinal scan. Because the room is restricted to only a few peo-
ple, authentication of those who enter is extremely important to ensure the classi-
fied information inside the room does not get into the wrong hands.

Kerberos

Kerberos is a network security protocol that provides authentication and autho-


rization services on a network. Communication on an unsecure network allows
attackers to listen in on the network to steal your credentials. Kerberos uses
strong cryptography in order for the client to prove its identity to the server.
Once the identity is proven, the communication is encrypted. Credentials ob-
tained are used to verify the identity of the user and ensure the integrity of mes-
sages between the client and the system it’s authenticating to. Some of the bene-
fits associated with implementing a Kerberos system are:

It prevents plaintext passwords from being sent over the network.

It centralizes username and password credentials, making them easy to main-


tain and manage within any infrastructure size.

It removes the vulnerability associated with storing passwords local to the com-
puter system.

NOTE
The name “Kerberos” comes from Greek mythology, the three-headed dog that
guarded the entrance to Hades. It is an authentication and authorization method
that is currently being used in Windows operating systems.

Kerberos is based on three systems: the Kerberos-trusted Key Distribution


Center (KDC), the Kerberos Ticket-Granting Service (TGS), and the Kerberos
Authentication Service. Kerberos provides the ability for systems to communi-
cate in a secure manner over an unsecure network. Kerberos is also an example
of a single sign-on system, providing enterprises with scalability and flexibility.
Kerberos provides:

Transparency—The user does not need to know that the Kerberos system ex-
ists. He or she simply knows that his or her credentials work across systems.

Security—An attacker should not be able to obtain users’ credentials. It pro-


vides confidentiality and authentication.

Scalability—Administrators can use Kerberos to manage authentication in


small to large-scale environments.

FYI

Kerberos was developed in the late 1980s at the Massachusetts Institute of


Technology (MIT) under the Athena program. It is based on Needham and
Schroeder’s trusted third-party authentication protocol. Kerberos is freely avail-
able through MIT but is implemented in many commercial off-the-shelf (COTS)
products. The mechanisms for Kerberos are validated in Request for Comments
(RFC) 4120. You can view RFC 4120 on the Internet Engineering Task Force Web
site at http://www.ietf.org/rfc/rfc4120.txt.

How Does Kerberos Authentication Work?

The process for Kerberos authentication involves three primary steps: client au-
thentication, client service authorization, and client service requests. It’s impor-
tant to understand the entire process because Kerberos authentication proves an
identity across an unsecure network connection.

The following steps are performed during client authentication:


1. The user enters a user ID and password into the client.

2. The client performs a hash on the password, creating a secret key for itself and
the user.

3. The client sends a message of the user ID to the authentication server (AS) and
requests services. This message is sent as cleartext—unencrypted. The AS per-
forms a hash on the password of the user ID in its database. This creates a secret
key.

4. The AS responds with two messages if the user is successfully authenticated.


The two messages are:

A Ticket-Granting Ticket (TGT) for the server that has been encrypted using the
secret key of the Ticket Granting Service (TGS)

A client/TGS session key, which is a temporary key encrypted using the secret
key of the client/user

5. The client receives the two messages. After decrypting the client/TGS session
key, the client uses the session key when communicating with the TGS in the
future.

The following steps are performed during client service authorization:

NOTE

An authenticator is a message that consists of the client ID and the timestamp.

1. The client sends two messages to the TGS when requesting services:

The TGT and the ID of the requesting service

An authenticator encrypted by the client/TGS session key

2. When the two messages are received, the TGS decrypts the TGT with the TGS se-
cret key. This results in the client/TGS session key. The TGS decrypts the authenti-
cator and sends two messages to the client:
A client-to-server ticket, which is encrypted with the service’s secret key. The
client-to-server ticket includes the client ID, client network address, validity pe-
riod, and client/server session key.

A client/server session key, which is encrypted with the client/TGS session key.

When a client requests a service, the following steps are taken:

1. The client connects to the service server and sends the following two messages:

A client-to-server ticket encrypted using the service’s secret key

A new authenticator encrypted using the client/server session key; the new au-
thenticator has the client ID and timestamp

2. The service server decrypts the ticket with its own secret key to retrieve the
client/server session key. With the session keys, the service server decrypts the au-
thenticator and sends a message to the client to confirm its identity and willing-
ness to serve the client. The message includes the timestamp from the client’s au-
thenticator, which is encrypted using the client/server session key.

3. The client decrypts the confirmation message using the client/server session
key and checks to see if the timestamp is updated correctly. If so, the client can
trust the server and starts issuing service requests to the server.

4. The service server provides services to the client.


FIGURE 10-2

Kerberos for authentication, authorization, and service request.

The Kerberos authentication, authorization, and service request processes are


shown in Figure 10-2.

Use of Symmetric Key and Trusted Third Parties for Authentication

Kerberos performs authentication as a trusted-third party authentication service


via a shared secret key (symmetric key). When a client wants to obtain authenti-
cation credentials for a server it does not have credentials for, the exchange be-
tween the authentication server and the client is initiated by the client. The
client’s secret key is used for encryption and decryption. This exchange obtains
credentials for a TGS, which will also be used for obtaining subsequent
credentials.

One of the primary reasons for implementing Kerberos is that without it, the prin-
cipals do not trust one another. Principals can be applications, users, or network
services. The principals trust only the KDC, which is why the KDC creates tickets
for the communication among the principals. Communication between principals
is vouched for by the KDC, and the KDC ensures that it is acceptable for the princi-
pals to talk to one another.

Key Distribution Center (KDC)

The Key Distribution Center (KDC) acts as a trusted third party. The purpose of a
KDC is to provide a secure environment for distributing keys. It provides tickets
and temporary session keys for both initial tickets and ticket-granting requests,
and acts as both an authentication service and a ticket-granting service.

Because Kerberos is formed on symmetric encryption and shared secret keys, the
database for all of the secret keys for the principals on the network is maintained
by the KDC. As an authentication server, it authenticates a principal via a pre-ex-
changed secret key. After the authentication occurs, the KDC acts as a TGS. As a
TGS, it provides a ticket to a principal establishing a trusted relationship between
other principals. The principals trust the integrity of the KDC, which is an essen-
tial part of Kerberos security.
NOTE

A secret key has a long lifetime and is shared between the KDC and the client or
server. It may be used for subsequent needs such as password changes. A session
key is destroyed after the session is complete and is generated only when needed.
The session key is shared between the client and the server.

Principals are preregistered with a secret key in the KDS through a system regis-
tration process. A set of these principals is called a “realm,” and the realm is used
to administer logical group resources and users. When added to the Kerberos
realm, the principal is given a realm key used for initial trusted communications.
Once a principal becomes a member of a Kerberos realm, the principal can then
be authenticated by the authentication server.

Authentication Tickets

Tickets are generated by the KDC and provided to the principal when authentica-
tion is needed. For example, when Kevin needs to access a specific file share, a re-
quest is made to the KDC. The KDC in return provides the TGT and client/TGS ses-
sion key. Kevin will use the TGT for authorization to the file share.

Potential Weaknesses

As a whole, Kerberos is a very secure protocol. However, all protocols have weak-
nesses. It is important to note that any weaknesses with Kerberos are based on
the concepts within the protocol and not the underlying cryptography.

Like any authentication system, Kerberos can have weaknesses if improperly im-
plemented. Security administrators should be aware of these potential weak-
nesses, which include:

Brute-force attacks—The system is susceptible to brute-force attacks. Brute-


force attackers simply repeatedly guess an account’s password until they are suc-
cessful. They typically start with a list of dictionary words and move on to try
combinations and variations of dictionary words. If a user has a weak password,
especially one that consists of dictionary words, it may be easily discovered.

Key storage—All keys must be stored securely for the user and server. If this is
not done correctly and an attacker gains access to the keys, the entire system
could be compromised.

Kerberos tickets are cached on a user’s computer system—If an attacker


were to obtain access to these tickets, he or she could impersonate that user on
the network.

Clocks must be synchronized to complete authentication—There is a time


availability period, and if the times are more than five minutes apart, authentica-
tion will not occur.

Central server continuous availability requirement—Authorization on a


network is an occurrence that happens multiple times for principals. Loss of time
can be costly to enterprises. Organizations must design networks so that the
Kerberos components are always available to users and authentication is never
compromised.

Requirement for host synchronization—Ensuring that servers are available


at all times requires the servers to have the same information. Synchronizing in-
formation between multiple servers and sites will minimize any downtime that
occurs when a server or site goes offline.

Potential single point of failure—The KDC is a single point of failure in the


communication line. If the KDC were to go down, users would no longer be able to
authenticate to any systems on the network. Loss of the KDC has a critical impact
to the enterprise, and a business continuity plan needs to be designed around it.
Part of this plan should include multiple KDC systems sharing information so that
end-user access and productivity is never diminished.

Kerberos in a Business Environment

Many organizations use Kerberos daily for employee authentication and access to
resources. Consider this example of appropriate use of Kerberos in the business
environment, featuring Kevin.

Kevin logs on daily to the corporate network with his computer system. He pro-
vides a username and password. When Kevin logs on, his user ID is sent to the au-
thentication server on the KDC. A TGT is provided to Kevin, and it is encrypted
with Kevin’s password (secret key). If it is the correct password, the TGT will be
decrypted and access is granted to the computer system. The secret key will reside
temporarily on the computer system.

Later in the day, Kevin needs to print some documents for his meeting. Kevin’s
system sends the TGT to the TGS on the KDC. The TGS creates a client/server ses-
sion key and provides it to Kevin’s system, which he uses to authenticate to the
print server. This second ticket contains the session key that is encrypted by
Kevin’s secret key and another session key that is encrypted by the print server’s
secret key. This second ticket also contains a timestamp and the computer
system’s Internet Protocol (IP) address. These components added to the second
ticket are the authenticator.

Kevin’s system receives the second ticket, decrypts it with his secret key, and re-
moves the session key. Kevin’s system also adds a second authenticator and sends
the ticket to the print server. The print server receives the second ticket and de-
crypts it with its secret key and removes the session key and the two authentica-
tors. If the print server is able to decrypt the session key, it knows to trust Kevin’s
system because it knows the KDC created the ticket.

Remember that only the KDC has the key to encrypt the session key. As well, if the
authenticators from the KDC and Kevin’s computer system match, it knows the re-
quest was sent for the correct principal.

The beauty of Kerberos is that Kevin does not even need to be aware that any of
this is taking place. It is the responsibility of Kerberos and the operating system to
handle all of these ticket requests. Kevin merely needs to provide the correct user-
name and password for his account

Network Access Control

Network access control (NAC), sometimes called network admission control, is


the use of policies within a network infrastructure to limit access to resources un-
til the system proves that it has complied with the policy. Policies are defined by
the network administrator and can apply to antivirus software, software versions,
software updates, and other aspects of the computer system that might affect the
security of the system and/or the network.

The components involved with NAC include computer systems, routers, switches,
servers, and network firewalls. For example, a router might not allow you net-
work access if you do not have the correct IP address associated with your com-
puter system. Additional aspects for NAC are:

Address tables on network devices such as routers or switches

Segmenting the network via virtual local area networks (VLANs)

Blocking or limiting access of certain protocols on the network VLANs

Network devices similar to intrusion detection systems (IDSs) and intrusion


prevention systems (IPSs)

FIGURE 10-3

The OSI Reference Model.

Layer 2 Techniques

Layer 2 of the Open Systems Interconnection (OSI) Reference Model is re-


ferred to as the Data Link Layer. The Data Link Layer allows communication of
systems within a wide area network (WAN) and communication of systems on the
same local area network (LAN). These networks may use Ethernet and wireless lo-
cal area network (WLAN) protocols. Devices that support these protocols and
therefore are associated with Layer 2 of the OSI model are bridges and switches.
Sublayers to the Data Link Layer are:

Logical Link Control (LLC)—Provides flow control, error notification, and


acknowledgment

Media Access Control (MAC)—Provides the determination as to who can talk


when on a network connection
Figure 10-3 shows the OSI reference model and the location of the LLC and MAC
layers.

MAC Address Database for LAN Switches

The MAC address is a unique identifier of a network device. Each MAC address is
assigned by the vendor of the device and is associated with the network interface
card (NIC). A MAC address is 48 bits in length and is identified as 12 hexadecimal
digits. The first six hexadecimal digits identify the manufacturer and are provided
by the IEEE (formerly known as the Institute of Electrical and Electronics
Engineers). The last six hexadecimal digits identify the interface, like a serial
number, and are provided by the vendor. A MAC address is burned into read-only
memory (ROM) and is therefore considered permanent to the device. MAC ad-
dresses are written in this format:

MM:MM:MM:SN:SN:SN

When a device is powered up, the MAC address is sent out on the network connec-
tion, or the wire. The switch adds the MAC address and the port number on which
it received the information to its MAC address table. The switch uses this table
when it needs to communicate with a specific device. When the switch receives a
communication request, it looks for the MAC address in its table and sends the
communication out the port identified in the table.

IEEE

IEEE is a professional not-for-profit organization designed to foster technical in-


novation. It was founded in 1884 in New York. The organization develops stan-
dards through the IEEE Standards Association (IEEE-SA) for information technol-
ogy, power, transportation, information assurance, and other technologies and
sciences. The IEEE 802 series of standards that specifically address local and met-
ropolitan area networks are:

IEEE 802.1—Bridging and Management

IEEE 802.2—Logical Link Control

IEEE 802.11—Wireless

IEEE 802.15—Wireless Personal Area Networks


IEEE 802.16—Broadband Wireless Metropolitan Area Networks

MAC spoofing is done to bypass a network access control or to identify a system as


one that has already been authorized by the access control. For example, a spe-
cific network allows only a certain set of MAC addresses. An attacker can find an
approved MAC address and change his or her system to match it. This will allow
the attacker to gain access to your network.

Defining Broadcast Domains

Broadcast domains fall within the Data Link Layer and allow network devices to
broadcast their MAC addresses to everyone on that LAN. By limiting the number
of devices on a domain, you limit the number of network devices that can talk to
one another without a switch.

IEEE 802.1q Virtual Local Area Networks (VLANs)

VLANs are defined in the IEEE 802.1q standard. VLANs can be used to segment
network traffic and limit communications between multiple networks. A VLAN is
a collection of devices in a single broadcast domain. VLANs are used within an or-
ganization to separate networks with different resources. For example, a com-
pany may create a VLAN specifically for the HR department so that members out-
side this VLAN cannot access HR resources. It becomes another mechanism for
defense in depth.

VLANs may even be used on a temporary basis for projects. If an organization has
contractors working on a specific application, an administrator may restrict the
contractors to a particular VLAN that allows access only to the specific applica-
tion. The contractors can communicate with one another and the application
within the VLAN, but they cannot generate traffic to the entire network. VLANs
also reduce broadcasts, and therefore an administrator may design the network
to limit such network traffic.

Layer 3 Techniques

Layer 3 of the OSI model is referred to as the Network Layer. It is responsible for
transmitting traffic from a source network to its destination on a separate net-
work. Some of the functions provided on the Network Layer are routing, forward-
ing, and addressing. Routers are the most common Layer 3 devices, although
other devices, such as switches and firewalls, often perform Layer 3 functions.
Routers maintain routing tables, which provide instructions on how to direct traf-
fic to reach other networks.

Access Control Lists

You can configure access control lists on a router to deny certain access to a net-
work or deny certain traffic from traveling on a network. A router examines each
packet and determines whether the packet should be forwarded or dropped
based on what is stated in the access control list. For example, an administrator
may use an access control list to block File Transfer Protocol (FTP) traffic on part
of a network but allow Simple Mail Transfer Protocol (SMTP) traffic for e-mail.

Route Maps

Route maps are a way for an administrator to direct traffic on a network. A route
map allows an administrator to define a routing policy before the routing table on
the router is referenced. Creating a route map is sometimes called “policy-based
routing.” An administrator sets a policy that states “if … then.” A route map can
use multiple policies requiring that multiple matches of packets must occur be-
fore routing changes occur.

ACLs can be used to match specific policies. Route maps are similar to ACLs in
that they are an ordered sequence of events resulting in either a permit or deny
permission. A route map and an ACL are scanned in a specific order until a match
occurs. A route map may use an ACL in order to match the specific criteria.

When a route map is applied to an interface and tested against specific criteria
and the criteria matches, an action is taken. These actions can be used to modify
the packet or modify the route. For example, a route map would be used to ensure
only traffic with an internal IP address (192.168.1.X) is allowed out of a specific in-
terface. If an IP address that does not match (192.168.5.X) is on the network, the
route map’s action would be to drop the packet. In this case, you can use a route
map to ensure that IP addresses within a certain range do not leave the network.

Disabling IP Routing for Complete IP Traffic Isolation

In certain situations, disabling an entire IP network may be a necessary step. For


instance, there may be a virus on the human resources network. Instead of allow-
ing the virus to spread to other networks such as engineering or finance, an ad-
ministrator may disable the network altogether.

CEO/CIO/CSO Emergency Disconnect Prime Directive

Executives within an organization may take it upon themselves to remove any


connection that their organization has to outside networks. For example, if an or-
ganization is being bombarded with denial of service (DoS) attacks, instead of
trying to address each attack individually, the chief security officer (CSO) may de-
cide to cut the connection so that the organization’s network can be restored in-
ternally and an assessment of the damage can be made.

NOTE

In practice, the CSO often delegates this emergency disconnect authority to indi-
vidual members of the information security team. Providing trusted team mem-
bers with this authority reduces the time to respond to a security incident in
progress.

Wireless IEEE 802.11 LANs

IEEE has established the standard for WLANs. This particular standard is num-
bered 802.11 and was established in 1997. Subsequent amendments have been
added to the standard to address connections at a higher radio frequency.

Establishing a standard ensures that all WLANs can operate with one another and
that the controls for the networks are similar. Enabling WLANs within an organi-
zation is an easy way to control access, especially if people are not permanently
located at the facility. In addition, an organization may have an area in the build-
ing where customers are allowed to gain network access. Instead of having multi-
ple wired network connections, a wireless access point may be added to allow
many people access to the network with little effort.

Access Control to IEEE 802.11 WLANs

A service set identifier (SSID) identifies a wireless network. It is the friendly


name displayed to network users. For example, an organization might have two
SSIDs: AcmeWidgets-Employees and AcmeWidgets-Guests, designated for their
private and guest networks. All APs within range display their SSIDs, if they aren’t
configured to hide them.

Some APs may have security enabled, such as Wi-Fi Protected Access (WPA). An
attacker can connect directly to an access point if no security or access controls
are configured on the AP. This creates an enormous risk to an organization and all
of the information maintained on the internal network.

Identification

Enabling the MAC address table on a wireless AP limits the devices that are able
to connect directly to it. For example, a building may hold a single company on
each floor, and each of these companies may have several access points. Allowing
the company on the 7th floor the ability to get on the company’s network on the
8th floor is a security risk. Security may be enabled on each of the APs, but di-
rectly limiting the devices that are able to connect to the APs provides defense in
depth. In practice, very few companies use MAC address filtering because of the
heavy burden of maintaining MAC tables each time the organization purchases a
new device.

Confidentiality

Wired Equivalent Privacy (WEP) was designed to provide encryption between an


access point and a client. The WEP algorithm uses a secret key to protect the con-
fidentiality of the information between the two devices attempting to connect.
Tools were developed shortly after the release of WEP to break its encryption. If
an attacker uses such tools and the encryption fails, the communication between
the AP and the client is in cleartext. WEP uses a fixed 40- or 104-bit encryption
scheme and a 24-bit initialization vector (IV) as the two components of its secret
key. The IV is relatively short, so when an attacker monitors a network, the key
shows repetitions and enables the attacker to obtain the base key. Using a short IV
causes these encryptions to break. Therefore, it is strongly advised not to use
WEP.

WARNING

WEP is not secure and should not be used. WPA and WPA2 provide stronger se-
curity and should always be used to protect wireless connections.
WPA and WPA2 provide much greater security than WEP. WPA was developed in
2003 by the Wi-Fi Alliance. WPA implemented the Temporal Key Integrity
Protocol (TKIP) with Message Integrity Check (MIC) in order to tackle the inher-
ent security problems with WEP. TKIP replaced the WEP encryption key with a
128-bit-per-packet key. WPA dynamically generates keys and removes the pre-
dictability that was inherent to WEP keys. WPA also includes MIC, designed to
prevent an attacker from capturing, altering, and resending data packets.

Authorization

Having access to WLANs may require you to accept certain risks or agreements
that the work being done on the network will not compromise the network or the
organization that the network belongs to. A banner message may appear before
the organization allows you access to other resources. This protects the party pro-
viding the wireless connection and ensures that whatever activities occur on the
network are not something the organization supports.

For example, Alexandra may use the WLAN at her local coffee shop to snoop on
other systems using those access points. The coffee shop does not agree with
Alexandra doing this, but the shop is not capable of monitoring her work. The cof-
fee shop, or its Internet service provider (ISP), can add a disclaimer letting others
know that there are security risks to being on the WLAN. The warning provides
transparency to customers and removes liability for the coffee shop.

Single Sign-On (SSO)

Single sign-on (SSO) is a method of access control that allows a user to log on to a
system and gain access to other resources within the network via the initial logon.
If SSO was not implemented, the user would need to log on multiple times and re-
member multiple passwords for the various systems. For example, when Kevin
needs to access the file share, the print server, the customer database, and his e-
mail, he does not want to have to remember a different password for each re-
source. Luckily for him, his organization implemented Kerberos, a single sign-on
system, and instead his initial logon credentials are used for these resources. Use
of SSO:

Eliminates the need to remember multiple passwords. By reducing the number


of passwords, you reduce the amount of time spent by administrators who must
reset user passwords.
Ensures that the same password policy is applied to all resources.

Reduces the need for an administrator to manage various accounts on individ-


ual resources. Having centrally managed access also helps when employees leave
the organization. Removing all of their access to multiple accounts at one time is
efficient and ensures employees cannot access the accounts later.

NOTE

Constantly resetting passwords can be demanding on IT resources and increases


costs. However, an SSO system might be too expensive for smaller organizations.
If the organization is small and resetting passwords is not a costly factor, an SSO
solution may be more of a drawback than a benefit.

To understand if you should implement SSO, it is also important to understand


the risks associated with allowing the same credentials to be used by multiple re-
sources. Some risks of using SSO are:

If an attacker obtains the initial password, he or she will have access to all
resources.

If an employee leaves his or her system unlocked and steps away, the employee
essentially provides full and open access to all resources.

Defining the Scope for SSO

The scope for SSO is to provide a unified sign-on interface for end users that al-
lows them to authenticate once and access multiple systems and applications. In
particular, the interface should be independent of the authentication mecha-
nisms. An SSO interface provides the capability to use credentials for other sys-
tems, but it does not specify a mandatory authentication mechanism, leaving that
decision to individual access control administrators. The administrator might, for
example, require two-factor authentication for sensitive applications while only
requiring a username and password for more routine access.

Configuring User and Role-Based User Access Control Profiles

Adding the access controls previously discussed in this chapter provides an extra
layer of security for SSO. Using credentials to limit access to resources and docu-
ments is essential for an organization attempting to limit the level of risk.
Configuring user- and role-based access control profiles in an SSO system is a task
that can be simplified with identity and access management software. This soft-
ware is available through third-party vendors, and it allows you to incorporate
SSO capabilities and control user- or role-based access control in a few steps.

These tools allow organizations to manage authentication and authorization for


large numbers of users or groups from a single source. The advantages and disad-
vantages do not change with the implementation of additional capabilities but
add to the security needed to ensure the right information gets into the right
hands at the right time.

Common Configurations

There are various ways to implement SSO within an infrastructure. Determining


which system to deploy within the network must be done by analyzing the bene-
fits and risks with the system as well as the return on investment (ROI). The fol-
lowing are three common SSO configurations implemented within an enterprise:

Kerberos—As previously stated, Kerberos is a form of SSO that employs a


trusted third-party infrastructure for authentication.

Cookies—Once a user logs on to a system, a cookie is placed on his or her ma-


chine. When the user wants to access this system again, the system checks for the
cookie. If the cookie is available and valid, the user will not need to log on again.

Smart cards or biometrics—Authenticating directly to the computer system


through either a smart card or using biometrics will subsequently allow access to
the other tools available on the system, such as e-mail or enterprise communica-
tion tools.

Enterprise SSO

Enterprise SSO allows credentials to be passed outside of the corporate domain or


network. Participation in an enterprise SSO system ensures that the logon creden-
tials will work with any resource even if its credentials do not match. For exam-
ple, suppose Kevin logs on to his computer system with the username of kevin1.
The credential for his time card is his employee ID, 13579. Being a part of an en-
terprise SSO means that his kevin1 username will work as his time card logon.
Best Practices for Handling Access Controls in an Enterprise Organization

Enterprise organizations that implement access controls must understand the risk
that is associated with materials being accessed by unauthorized users. How im-
portant is it to allow customer support engineers access to financial records? If
the company is open to sharing all documents and information with all employ-
ees, access controls may not be needed. But no business runs that way.
Enterprises always limit access to data on the network. Some of the best practices
that are used across enterprises to reduce risk are:

Discovering and identifying all data on the network.

Developing policies based on the risk associated with the data. For example, if
an organization maintains credit card and Social Security numbers of its cus-
tomers, the risk is high if left in cleartext. To reduce this risk, a policy may be put
in place to ensure data such as credit card and Social Security numbers can be
stored only on an encrypted file share.

Placing appropriate access controls on data based on risk level. For example, a
software development firm may allow software engineers access to code under
development but deny access to customer service representatives.

Continuously monitoring and testing the policies and access controls to ensure
that a loophole has not opened. Continuously testing the system will help deter-
mine if changes within the controls are needed.

Case Studies and Examples

It is important to look at examples of how various enterprises use access controls


to keep their information and infrastructures safe. The following case studies of-
fer insider views of access controls that solve business challenges.

Private Sector Case Study

The KMU Organization in Connecticut is a small software development company


with under 10 employees. KMU employees were all founders in the company, and
the majority of company data was viewable by all employees. There were no ac-
cess controls placed on the network; however, some documents required pass-
words to open them. These passwords were provided on a need-to-know basis.
Once a user no longer needed the document, the password was changed by the
document owner. Network authentication required a user ID and password.
Constraints were put on network passwords to ensure they were strong and had
to be changed every 90 days.

KMU acquired the Acme Software Company in Ohio. The Acme Software Company
was much larger than KMU. Acme Software had 75 employees and more access
constraints, but the constraints were limited and not very secure. KMU realized it
needed to make changes to the IT infrastructure and data access controls now
that the two networks would be joined. KMU reviewed all of its options and de-
cided to establish roles within the company that would cover both KMU and Acme
Software. The company would still have a Founders’ role, but it would also imple-
ment roles based on job functions in the two companies.

KMU also determined that its user IDs and passwords were not secure enough for
some of its software development tools. The company’s software assets were the
cornerstone of the company, and losing them would be detrimental to the com-
pany. The organization decided to purchase a two-factor authentication solution
for access to the software tools. This method of authentication was used to ensure
competitors could not access the software being developed.

After implementing a role-based access control system, the network administra-


tors of the two companies were able to know who was responsible for which
tasks within each organization and could easily control access based on role.
Granting access to documents and systems was no longer done on an individual
basis but by a company-wide policy. Two-factor authentication also reduced the
risk of the information being accessed by unauthorized users.

Implementation of the two systems was difficult because the administrators had
to start from scratch, but they knew as the company grew, the systems would
grow with it.

Public Sector Case Study

The Town of Springfield recently experienced a security lapse in which some im-
portant, confidential documents were made available to the public. Although
most of the documents it maintains could be viewed by any resident of the town,
some documents need to remain private until they are deemed public records.
The documents that were made available to the public were bids by various con-
struction companies to build the new high school. Until the town decided which
construction company would win the bid, the documents should have been kept
private and available only to certain town employees.

To avoid this problem in the future, the town’s IT staff decided to implement a
mandatory access control system on the network. They felt this was better than a
role-based access control method because classification of the documents would
change more often than user roles. For instance, the mayor’s staff would probably
not change often, but document classifications might change from confidential to
unclassified on a monthly basis. There may also be times when the governor of
the state would need to see information, and that person would be provided “as
needed” clearance.

The Town of Springfield felt these changes would resolve its document access is-
sues and would further ensure that documents were not seen by people who did
not have the appropriate clearance.

Critical Infrastructure Case Study

A large government contractor had the schematics stolen from its network for the
aircraft used to fly the president of a large nation. These documents were critical
to national security, and the loss was detrimental to the company’s integrity. The
schematics were clearly in an unprotected area, and access to them was not se-
cure. The government contractor was also not aware the documents were re-
moved from their location until a third party identified them on a server in a sep-
arate country.

After further investigation, it was determined that software installed on one of


the contractor’s computer systems made changes to the network configuration, al-
lowing files to be shared outside of the contractor’s network domain without
prior knowledge or approval. Although the risk was great, the contractor had not
employed some of the tactics available to secure such data:

Policies were not in place to limit who could install software on the computer
systems.

Access to documents was not limited based on the importance of the document.

Controls were not put in place to limit connections made to and outside the cor-
porate network.
After the network breach was detected, the government contractor limited ad-
ministrative rights for the computer systems to the Administrator role. This en-
sured that users on the systems were not able to download software without go-
ing through the appropriate approvals. The contractor also reevaluated access
controls on its documents and tested them regularly. This helped to ensure the
documents did not get into the hands of those who were not authorized to access
them. The last measure the contractor took was to have the administrator contin-
uously monitor network access and network traffic. This action helped the admin-
istrator understand normal traffic on the network and whether changes occurred
on systems or the network without the administrator’s approval.

CHAPTER SUMMARY

In this chapter, you learned that understanding the significance of information


within an enterprise helps an administrator grant proper access to those work-
ing within the infrastructure. Limiting access reduces risk for an enterprise and
assists in ensuring data does not get into the wrong hands. Limiting access can
also be a hindrance to employees; therefore, planning is essential before imple-
menting controls.

Access to systems and data should be granted only after a user is authenticated.
Types of authentication, their benefits, and their risks are factors in the planning
process to keep employees, customers, and data safe.

KEY CONCEPTS AND TERMS

Access control entry (ACE)

Access control list (ACL)

Attacker

Authentication Service

Authenticator

Bell-LaPadula Model

Cleartext
Commercial off-the-shelf (COTS)

Common Criteria for Information Technology Security Evaluation

Compromise

Credentials

Cryptography

Denial of service (DoS) attack

Kerberos

Key Distribution Center (KDC)

Network access control (NAC)

Open Systems Interconnection (OSI) Reference Model

Orange Book

Secret key

Security identifier (SID)

Service set identifier (SSID)

Single sign-on (SSO)

Single-factor authentication

Symmetric encryption

Temporal Key Integrity Protocol (TKIP)

Three-factor authentication

Ticket-Granting Service (TGS)

Transparency
Two-factor authentication

CHAPTER 10 ASSESSMENT

1. What does ACL stand for?

A. Access control level

B. Access control limit

C. Access control logic

D. Access control list

2. List the four types of access control models.

3. Which of the following are components of a Kerberos system? (Select two.)

A. TKIP

B. AS

C. GS

D. BGP

4. A switch is a device used on which layer of the OSI model?

A. Layer 1

B. Layer 2

C. Layer 4

D. Layer 5

5. Which of the following are authentication factors? (Select three.)

A. Something you need

B. Something you have


C. Something you are

D. Something you believe

E. Something you know

6. VLANs are used to segment networks.

A. True

B. False

7. What are types of access control lists? (Select two.)

A. DACL

B. MACL

C. SACL

D. TACL

8. Passwords should have no time limit assigned to them.

A. True

B. False

9. Which of the following is the most secure encryption method for WLANs?

A. DAC

B. WEP

C. WPA

D. MAC

10. How many hexadecimal digits are provided by IEEE for vendor identification?

A. 6
B. 12

C. 18

D. 24

11. Which IEEE standard defines WLANs?

A. 802.11

B. 802.10

C. 802.5

D. 802.1q

12. Which of the following is an example of SSO?

A. Keystroke logger

B. Trojan horse

C. Kerberos

D. Broadcast domains

You might also like