case study

Chapter 6. Mapping Business Challenges to Access Control Types IN THIS CHAPTER, YOU WILL TAKE what you have already learned about access control and use it to design a

comprehensive access control system. All access control systems are about solving problems and meeting business

needs.

First, we will review access control types. Next, we will examine each step you should follow in designing an access

control system. Finally, we will discuss how access control systems are used in the real world.

Chapter 6 Topics

This chapter covers the following topics and concepts:

How access control types apply to business challenges

How access controls can be used to solve business challenges

What some case studies and examples are

Chapter 6 Goals

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

Explain various access control types and map them to business challenges

Create a comprehensive access control strategy to solve business challenges

Mapping Business Challenges to Types of Control The goal of any access control system is not simply to keep people out, or to organize who has access to a particular

resource, but to meet a business need. In this chapter, you will discover how to apply various access control methods

to solve a range of business challenges.

Business Continuity

PREV TWO. Mitigating Risk with Access Control Systems, Authenticati…⏮

NEXT 7. Human Nature and Organizational Behavior ⏭🔎

 Access Control, Authentication, and Public Key Infrastructure

Find answers on the fly, or master something new. Subscribe today. See pricing options.

Business continuity deals with worst-case scenarios. It addresses how essential functions continue in the midst and

aftermath of a disaster. There are two sides to business continuity: prevention and recovery. Access controls are used

primarily on the prevention side, but do have a role to play in recovery as well.

NOTENOTE A disaster is any major event that negatively impacts an organization's ability to carry on business as usual, including natural disasters such as earthquakes or tornados. It can also include criminal activities such as arson, robbery, and sabotage, or accidents such as a water main break that floods key facilities.

DISASTER PREVENTION

When creating a business continuity plan, you should start by brainstorming a list of "what-if" scenarios. Some

disasters cannot be prevented—an earthquake will happen, regardless of whether you prepare for it or not. Others,

especially criminal activities and accidents, can be prevented or minimized through careful planning and strong access

controls.

Consider this scenario involving criminal activity: Acme Collections buys delinquent accounts from small and mid-

range businesses, then attempts to collect on those debts. It has a reputation for being very effective at collecting bad

debts, and its top collection agents earn significant bonuses for closing tough accounts, often through hard sell and

intimidation tactics.

One Wednesday afternoon, the power suddenly goes out. A few minutes later, an individual with a gun enters the

office and demands to see the collection agent who has been hounding him for the past several weeks. When he is told

the agent is out of the office, the individual holds 250 employees of Acme collections hostage for several hours and

eventually destroys the servers that store account records.

This traumatic event could have been prevented with strong physical access controls. The criminal in this scenario

first cuts the power to the building, preventing the alarm system from being triggered. This is an access control failure

that is often overlooked. Many facilities require ID badges and even biometric scans to enter, but do not adequately

monitor and secure the power lines running to the building. An individual wishing to create confusion and disable an

alarm system only needs to cut the power lines. This is a dangerous activity, and can be deadly if not done properly,

but this will not stop someone who is determined to cause harm.

A more elaborate alarm system would also have been useful in this scenario. Modern, monitored alarm systems

trigger automatically if the power goes out or the connection to the alarm company is severed.

In addition to securing the power lines to the building and using a monitored alarm system, Acme could have installed

doors that locked automatically. Because Acme does not have a customer-facing front office and does not expect to

have members of the general public visit its offices, there is no reason to leave the doors unlocked. Only the employees

who work in the offices have any reason to be there, and those employees can be issued smart card ID badges to

unlock the doors.

Administrative policies and employee buy-in are important parts of disaster prevention. Policies that prevent

piggybacking at facility doors are crucial, as well as policies to handle lost or forgotten ID badges. Acme's employees

are only human; occasionally they will lose their ID badges. Those badges must be deactivated as quickly as possible

to prevent someone from finding a badge and using it to gain unauthorized access to Acme's offices.

When physical and administrative controls fail.

Physical security is not the only area where strong access controls can prevent disaster. Consider another scenario—

this one much more common.

Find answers on the fly, or master something new. Subscribe today. See pricing options.

A senior account manager at Acme Public Relations is called to a closed-door meeting with her department head and a

representative from human resources. The account manager believes she has been passed over for promotions and

bonuses unfairly, and to compensate has been embezzling funds from the company for the past year. The department

head became aware of her activities and has been monitoring her for the past three months, gathering evidence. In

this meeting, the account manager is given a choice: if she leaves quietly, the company will not pursue a legal case

against her.

She agrees, and requests an hour to clean out her office. Her department head agrees, and the account executive goes

back to her office and closes the door. She spends the next hour deleting important files and data, downloading

viruses and spam bots from the Internet, and sending her clients' contact information to her personal e-mail account.

Once she is gone, she contacts her former clients and informs them that she has decided to open her own firm and will

offer them a significantly reduced rate if they will leave Acme Public Relations. Many of her clients agree to send their

business to her new firm. The viruses she downloaded before she left infected a large portion of the Acme network

before being detected and eliminated. The spam bots she downloaded caused the company to be listed on several

spam blacklists, causing their legitimate e-mails to be classified as spam.

This scenario illustrates a failure in both physical and administrative access controls. While the account manager was

meeting with her department head and the representative from human resources, someone in IT should have been

disabling her workstation and network accounts. This would have prevented her from deleting data, infecting the

network with viruses and spam bots, and sending her clients' contact information to her personal e-mail account.

Without that contact information, she would not have been able to poach some of Acme's best clients, causing further

damage to Acme. Finally, she should not have been allowed to return to her office unescorted. Once she was

terminated, she should not have been considered "authorized personnel" and should have been treated as any other

visitor.

DISASTER RECOVERY

Access controls are not only important in preventing disasters; they are also crucial in the aftermath. In a natural

disaster, key personnel may not be immediately available. Rather than leaving mission-critical systems unavailable

until a system administrator can return to the office, procedures should be in place to allow anyone to perform the

basic tasks necessary to bring servers back online and restore essential business functions.

Let's look at a disaster recovery scenario: On Monday at 2 a.m., an electrical fire breaks out in the basement of the

Acme Financial Services' office building. Acme is a midsized investment and portfolio management company. As soon

as the fire is out, Acme's chief executive officer (CEO) and chief operations officer (COO) make their way downtown to

survey the damage. Much of the building had been damaged in the fire, and emergency personnel remain in the area,

preventing anyone from entering the building until it can be inspected and are deemed structurally sound.

Because the entire building is without power, the COO knows that the company's customer-facing Web site, which is

hosted on servers located onsite, must be down. Employees will not be allowed to enter when they come in to work

later that morning. The COO's primary goals in this situation are to reassure customers that Acme is handling the

situation and will be available to meet their needs as quickly as possible, and to arrange for alternative facilities so that

employees can do their jobs in the days or weeks ahead as the damage is repaired.

First, the COO must get the Web site running on an alternate Web server offsite. To do this, he needs the account

information for the company's hosted offsite backup account. Because he normally does not deal with backups as part

of his job, he does not have access to this account. Instead, he must call the systems administrator to obtain access to

the backup account and have those files restored to an offsite Web server. He posts a message on the Web site

informing customers of the situation and assuring them that business will resume as quickly as possible.

Next, he must inform employees of the situation and give instructions on where to report to work later that morning.

Unfortunately, the company directory is located on the intranet, which is also hosted onsite and is currently down. He

eventually resorts to publishing a brief notice to TV and radio news outlets, informing employees of the disaster and

advising them to wait to hear from their department head for further instructions.

Find answers on the fly, or master something new. Subscribe today. See pricing options.

In this scenario, a difficult situation was made more chaotic because crucial information was not available when and

where it was needed. First, the COO did not have access to the offsite backup account. Normally, this makes sense

under the need-to-know principle. Because managing backups is not one of the COO's job functions, he doesn't need

to know the account number, username, or password to that account. However, in a disaster situation, an organization

needs to have a way to quickly authorize first responders to access crucial information. In the scenario described here,

all it took was a quick phone call to a systems administrator who recognized the COO's voice. In a larger organization,

this would not have been a practical solution.

On the other hand, this scenario could have been nothing more than a social engineering ploy designed to con the

systems administrator into giving up sensitive account information. To counteract this possibility, key personnel, such

as systems administrators and department heads, should be trained in disaster recovery procedures, so they know

what to expect and can quickly spot any anomaly in the procedure that might signal a social engineering ploy.

To compound the problem, the COO did not have the company directory at hand to pass along information and

instructions to various department heads in a timely manner. Hard copies of a company directory, especially if that

directory includes employees' home or cell phone numbers, should not be widely distributed, but that information

must be available to first responders in an emergency situation.

A good solution and access control method for this issue would be to program the contact numbers of key personnel,

such as the systems administrator, in a company cell phone, which would be kept by a member of senior management

like the COO or an official emergency coordinator. This way, only the cell phone number is made public, and sensitive

information—the home phone numbers of key personnel—is kept private.

The existence of an emergency cell phone also helps prevent social engineering attacks. If someone calls a systems

administrator's home phone number claiming to be the COO or the official emergency coordinator, he or she can

check the caller ID to ensure the call originated from the company's emergency cell phone.

CUSTOMER ACCESS TO DATA

The advent of the Internet has made it easy for customers to order merchandise online, view their order history, track

packages, and update their own customer records. Unfortunately, this freedom brings a host of access control

challenges. Customers should be able to view their own information but not that of other customers, for example. To

meet this need, an access control system must be able to accommodate three key specifications:

Allow customers to create and update their own account information

Allow customers to create orders

Deny access to any information not directly associated with that customer

The key access control method here is a typical username and password combination. A Web site visitor who has not

logged in should not be allowed to view anything but the public-facing portions of a company's Web site. If the visitor

wants to place an order, they will need to create an account. This process generates a row in the customer database

keyed to the customer's username or customer ID. This unique key will also be used to identify rows in the order

database that are affiliated with that customer. Keying rows in the order database on customer ID or username will

prevent the system from inadvertently displaying customer B's order history to customer A. This system is only as

secure as the passwords customers create.

Consider this scenario: Acme Library Supply, a major supplier of books to school libraries, created a secure ordering

Web site for its customers. Acme does not sell to the general public because it carries books at a steep discount for

library use, and is not set up to collect sales tax because libraries are exempt. Most of Acme's customers are located in

North America, although Acme did supply books to a few South American and European schools.

An operations manager at Acme noticed that her department had been fulfilling a large number of orders for a specific

South American customer. She contacted a member of the systems team, concerned that the orders were being faked.

A check of the log files showed that the orders were coming from a large number of Internet Protocol (IP) addressesFind answers on the fly, or master something new. Subscribe today. See pricing options.

across Brazil, Venezuela, and Peru. The systems administrator did a Google search for the affected customer's

username and found he had posted his username and password on a Web forum, inviting people to use his account to

order books. When the books arrived, the customer would forward them to the appropriate parties.

There was nothing wrong with Acme's access control system. It worked perfectly. The access control weakness was the

customer who publicly shared his authentication information.

The scenario emphasizes the point that it's not enough to create a strong logical or physical access control system and

forget about it. Employees must be trained to recognize and report anomalies that may suggest an access control

failure.

MAINTAIN COMPETITIVE ADVANTAGE

In a competitive marketplace, information can be a key advantage point. Trade secrets, product specifications, and

business methods are all resources to be leveraged. However, if the competition also has access to the same

information, the value of the information is considerably lower. Keeping secret information out of the hands of the

competition is clearly an access control problem that requires several layers of defense:

Need to know and least privilege—Only those employees with a legitimate need should have access to

sensitive information such as trade secrets and product formulations. The more people who know and have access

to this information, the higher the likelihood that it will be intentionally or accidentally divulged.

Technological access controls—Strong password policies should be enforced using scripts that reject weak

passwords. Intrusion detection systems and firewalls should be in place to protect information stored on network

resources.

Physical security—Key facilities such as server rooms and data warehouses should be locked at all times.

Visitors should be escorted to and from their destinations.

Administrative policies—Policies should be in place to handle lost or stolen ID badges, acceptable use of

computers and other resources, and other potential security risks.

Employee training—Employees should be trained to recognize social engineering tactics and know how to

handle those situations. They should also be periodically re-trained in security policies and best practices.

Taking these steps will minimize the risk of corporate espionage or accidental sharing of secret information that could

lead to a loss of competitive advantage.

Risk and Risk Mitigation As you recall from Chapter 2, there are four ways to handle risk:

Risk avoidance

Risk acceptance

Risk transference

Risk mitigation

Each of these methods has its benefits as well as some drawbacks. Choosing the correct method depends upon the

specific situation and goals of the organization.

RISK AVOIDANCE

Find answers on the fly, or master something new. Subscribe today. See pricing options.

Risk avoidance is choosing to avoid an activity that carries some element of risk. For example, you may choose not to

take your vacation in an active war zone, regardless of how much natural beauty may be found in that part of the

world. Risk avoidance always carries with it some aspect of loss. In the vacation example, you lose the chance to

experience the natural beauty that exists in that area, but you avoid the risk of being harmed. In this case, the risk to

be avoided—possible injury or worse—is more pressing than the missed opportunity—seeing the natural beauty in a

certain part of the world.

Risk avoidance is not always the best answer to a problem. Doing business in the healthcare industry carries a certain

level of legal risk due to federal regulation. If your business does not comply with regulations, you could face fines or

even prison time. However, if you choose not to do business in that industry, you lose out on the potential profits of a

multi-billion dollar industry. In this case, avoidance is not the answer.

RISK ACCEPTANCE

Risk acceptance is simply accepting the risks and doing what you need to do anyway. Firefighters, police officers,

military personnel, and other individuals in high-risk occupations do this every day. A fire fighter knows that she risks

her life every time she responds to an emergency call. She could choose to stay behind at the fire house, but she knows

that her skills are needed and that her efforts may save lives. She accepts the risk to her personal safety in order to

fulfill a greater good.

NOTENOTE Businesses must accept any risk they cannot avoid, transfer, or mitigate.

RISK TRANSFERENCE

Risk transference is shifting responsibility for a risk to a third party. This is a tricky subject because sometimes risk

transference makes sense and other times it is simply a way of institutionalizing the scapegoat.

Purchasing health insurance is one way of transferring risk. Consider the following scenario: A woman slips on the ice

on her driveway and loses consciousness. She is rushed to the emergency room where the doctors perform an MRI

exam and diagnose her with a serious concussion. She goes home several hours later with a prescription for painkillers

and instructions to rest.

Without health insurance—a method of risk transference—this event would have cost the woman several thousand

dollars in hospital and physician fees. These fees would have caused her serious financial hardship. However, because

she had health insurance, she paid only a small co-pay fee. The risk of a major medical expense was transferred to the

insurance company. In this situation, risk transference makes sense.

Not all risk transference situations are as effective. Consider the case of a small medical practice. Because it operates

in the healthcare industry, it is subject to HIPAA regulation, as discussed in Chapter 4. A small business, the medical

practice is without the resources to manage compliance itself, so it hires a third-party compliance firm. Unfortunately,

the compliance firm cuts corners and the medical practice discovers the problem during an official audit.

The compliance firm is contractually responsible for the medical practice's non-compliance, but the officers of the

medical practice are still held personally responsible for bringing the practice back into compliance and paying any

fines associated with their non-compliance. The medical practice could sue the compliance firm for financial losses,

but the suit would likely drain the practice of funds necessary to continue doing business.

In this case, while the risk of non-compliance was contractually transferred from the medical practice to the

compliance firm, in the end the medical practice was still penalized and held responsible for the actions of its

contracted compliance firm.

Find answers on the fly, or master something new. Subscribe today. See pricing options.

RISK MITIGATION

Risk mitigation is a strategy that combines attempts to minimize the probability and consequences of a risk situation.

Access control is an example of risk mitigation. It attempts to minimize the probability of a risk situation by denying

unauthorized users access to resources. It also minimizes the consequences of a breach by isolating one user's data

from data owned by other users.

For example, the CEO of Acme Devices receives phone calls from several board members who are concerned about an

article that was published in the Wall Street Journal, giving detailed specifications for the company's newest high-

tech product. He believes the information must have come from an internal source, and upon investigation finds out

that the Research and Development folder on the network is accessible to all employees. Any one of them could have

been the source for the Wall Street Journal article.

Had this proprietary information been properly secured with strong access controls, only the engineers within the

research and development (R&D) department—those who had a legitimate need for the information—would have had

access to the product specification documents. Restricting access to employees within the R&D department would not,

by itself, prevent the information leak, but it would minimize the opportunity. The reporter from the Wall Street

Journal would have had to contact a member of a specific department, reducing the number of leak opportunities

from several thousand—the total number of employees of Acme Devices—down to a few dozen—the number of

employees in the R&D department.

Access controls are not the only answer to risk and risk mitigation, but they are an important part of the solution.

Differences To Keep in MindDifferences To Keep in Mind

As you recall from Chapter 2, there are significant differences between threats, risks, and vulnerabilities:

A "vulnerability" is any weakness in a system that can be exploited.

A "threat" is a potential attack upon a system.

"Risk" occurs when a particular threat will exploit a vulnerability. The degree of risk is measured in terms of probability and impact.

Threats and Threat Mitigation Any organization faces certain types of threats to its IT infrastructure. The goal of access control is to mitigate those

threats as much as possible.

There are three main threat categories that you need to be concerned with:

Information confidentiality—Ensuring that private or sensitive information is not disclosed to unauthorized

individuals

Information integrity—Ensuring that data has not been modified without authorization

Information availability—Ensuring that information is available to authorized users when they need it

A good access control system will guard against all three primary threat categories. It will restrict access to sensitive

information to authorized users and deny access to anyone else. It will provide an audit trail to prove that

unauthorized individuals have not altered data. Finally, it will prevent unauthorized users from destroying data or

launching denial of service (DoS) attacks, making data unavailable to authorized users.

Find answers on the fly, or master something new. Subscribe today. See pricing options.

For example, consider the Acme Aeronautics Company. It designs experimental aircraft, primarily for military use. Its

design specifications are considered highly sensitive. If those specifications were to be divulged to the wrong people,

at best Acme could lose its biggest customer to a competitor that could produce the same technology less expensively

(having not invested millions in research and development). At worst, enemy nations could use those specifications to

design weapons systems to exploit the weaknesses of those aircraft.

Any access control system designed to protect those specifications documents must account for all three threat

categories:

It must ensure that information is not disclosed, either accidentally or intentionally, to unauthorized individuals.

This is the primary purpose of the access control system, and where the majority of resources are devoted. To

accomplish this goal, a two-stage authentication system is implemented, which requires individuals to use a

challenge-response token in order to access the login screen for the file server that stores specification documents.

It must ensure the integrity of the information. If design specification documents are changed even slightly, the

planes that are built from those specifications could catastrophically fail. To meet this goal, the documents are

placed under version control that notifies the entire project team, as well as departmental management, any time

a key document is changed. This ensures that an official document cannot be changed outside of the approved

workflow.

It must ensure that the data is available to authorized users. Physical access controls on the data center are the

primary method for meeting this goal. If the data center is compromised, the data stored there could be stolen or

destroyed. Security guards, biometric scanners, and smart card ID badges work together to maintain physical

security on the data center.

Vulnerabilities and Vulnerability Management A vulnerability is a weakness in a system that can be exploited. Every system has vulnerabilities, so a good access

control system must manage those vulnerabilities to minimize the risk of exploitation. The most common

vulnerability categories you will need to manage are:

Operating system—All operating systems are vulnerable to a variety of threats including viruses and other

malware, unauthorized access, and overflow attacks. As new attack vectors are discovered, operating system

manufacturers release patches to harden their software. Keeping the operating system up to date is the most

important thing you can do to manage vulnerabilities in the operating system.

Applications—Applications can introduce vulnerability into a system either through design flaws in the

application itself or through bugs in the programming language used to code the application. Thorough testing

and patching is the only way to manage this vulnerability, as you will probably not have complete control over the

application design process. Even if all of your applications are coded in house, you will not have control over the

design of the programming languages you use.

Users—Users are primarily vulnerable to social engineering tactics and insecure password practices, as covered in

earlier chapters. Training and policy mandates are the best way to manage user vulnerabilities.

TIPTIP The best way to manage vulnerabilities using access controls is by running applications as their own, unprivileged user. This way even if an application does have a vulnerability that is exploited, the damage is limited.

Find answers on the fly, or master something new. Subscribe today. See pricing options.

Consider a shared Web hosting firm. It has dozens of clients, each running various applications on their Web sites.

The Web sites are hosted on a few shared servers. Unfortunately, one of those clients installs an unsecure message

board on one of the shared servers. Through the message board application, attackers are able to gain access to the

client's Web hosting account, and then the administrative tools of the shared server. The attackers deface every Web

site hosted by the shared Web server. They also install a backdoor and dozens of spam bots on the shared Web server.

The server administrator learns of this problem when his customers call him asking why their Web sites have been

taken down and replaced with a defacement page. It takes the administrator several days to completely remove the

artifacts left by the attacker, and to have his clients' Web sites removed from the spam blacklists.

If this shared Web server had better access controls, the attack still might have happened, but the effects would have

been limited to a single client instead of the entire server. The message board application should have been run as an

unprivileged user instead of under the client's user account, and each client should have been strictly segregated from

the others.

Solving Business Challenges with Access Control Strategies The key to applying access controls to solving business challenges is in taking a systematic approach to designing a

comprehensive strategy. As you consider each element of access control, you will begin to see how various strategies

interrelate to form a multilayered security system.

The first step in creating a comprehensive access control strategy is to define your subjects and objects.

NOTENOTE Remember, a "subject" is anything that acts upon another entity. An "object" is anything that is passively acted upon by a subject.

The most common subjects are:

Users—They are generally the individuals who need access to resources. In some cases, applications can also have

user accounts. The most common example of this scenario is a Web server application that is typically run under

the "nobody" user account.

Applications—Applications often access the file system directly by reading or writing files, make database

connections, and utilize the mail system on a server. These are all access control requests to be managed securely.

Network devices—A proxy on one network will often request access to resources on another network, on behalf

of a user or application on its own network. The proxy is, in effect, making an access control request, and is

therefore acting as a subject.

Your infrastructure may have other subjects. These are simply the most common types of subjects. Once you have

defined all the subjects in your infrastructure, you can begin to categorize them into groups and roles.

Groups are useful because they allow you to generalize the access privileges needed by several subjects. They also

allow you to create specialized combinations of privileges by adding a subject to two or more groups. To remove

certain access privileges, you would simply remove the subject from one or more groups.

Roles also allow you to generalize, and separate a subject's function from its identity. For example, Bob Smith may

hold the role of user on his workstation most of the time, and the role of administrator only when he needs to install a

new application. Rather than assigning administrative rights to Bob's user account when he only needs those rights

occasionally, he will have access to two separate role-based accounts.Find answers on the fly, or master something new. Subscribe today. See pricing options.

Once you have defined your subjects, you will need to similarly define your objects, or the data and resources in your

infrastructure. This list of objects should contain every significant asset, as well as notes about the asset's worth and

value to the organization.

Employees with Access to Systems and Data Even non-sensitive data should be stored under some level of access control. For example, the company newsletter is

available to every employee, but should not be available to the general public. As soon as you limit access to data or

resources, you have an access control scenario. Some employees will have no need to access IT systems and data. The

custodians and groundskeepers, for example, will probably not need access to the network or the data stored there.

They may, however, need access to the automated time clock system or the maintenance schedules stored on the

company intranet. Whether certain employees require access to IT resources depends upon the individual

organization and its business processes.

WHO NEEDS ACCESS TO WHICH RESOURCES?

When creating an access control strategy, the main question to ask is "Who needs access to what?" If a user does not

have a legitimate need to access data or resources, they should not be granted access. If they do need access at some

point in the future, their access privileges can be modified then. Do not be tempted to assign high levels of access to a

user simply based upon his or her status within the organization. Chances are the executive vice president of

accounting does not actually need administrative rights to the Web server. Assigning those rights to that user would

represent a significant vulnerability in the access control system because it is unlikely that the executive vice president

of accounting has the technical knowledge and background to safely administer the Web server.

CREATING GROUPS AND ROLES

When deciding which users need access to resources, try to think in terms of roles or job functions, rather than

individuals. Individuals may leave the company at any time, and some other individual will be found to take over their

roles. As discussed above, an individual may hold several roles depending upon the task at hand.

Groups and roles also simplify the task of administering permissions. Take the scenario of an employee who transfers

from one department to another. Rather than individually auditing the employee's permissions, the systems

administrator simply needs to remove the employee from the old department's group and add them to the new

department's group.

EXTERNAL ACCESS TO SYSTEMS AND DATA

Finally, determine whether any external subjects will have access to internal systems and data. An external subject is

anyone who is outside the organization's physical and network boundaries. Why would someone outside the

organization need access to internal systems and data? The following is a list of common external subjects who have a

legitimate need to access internal resources:

Third-party vendors and application service providers (ASP)

External contractors

Employees with remote access

Each of these subjects needs some of the same rights and access to resources as an internal employee, and like

internals, they should be restricted to the lowest level of privilege needed to perform necessary tasks. Employees who

work remotely are a special case here, because they are both internal and external. They are employees, but access

resources from outside the organization's network and physical boundaries. The primary access control challenge with

remote workers is that of creating a virtual private network (VPN) and ensuring that sensitive data is not

compromised due to a lack of infrastructure security at the employee's location, which could be their home, a coffee

shop, or some other public place. Find answers on the fly, or master something new. Subscribe today. See pricing options.

Once you have determined who should have access to resources in general, you can go further and consider which

employees should have access to sensitive systems and data.

Employees with Access to Sensitive Systems and Data At this point, you already have a comprehensive list of objects. Now you should go back over that list and note which

of those objects should be considered sensitive. Consider that a variety of factors may make a given system or data set

sensitive:

Regulatory compliance

Privacy—either for customers or employees

Business continuity

Competitive advantage

Any system or data resource that, if it were lost, stolen, damaged, altered, or publicly divulged, would cause a

significant negative impact to the organization should be considered sensitive.

Administrative Strategies Once you know what subjects to account for and which objects to protect with access controls, you can devise

administrative strategies to support access controls. There are two issues to consider when defining administrative

access control strategies around new and expiring accounts:

How will new accounts be created and new access levels be granted?

How will accounts be removed and access levels be lowered?

New employees and employees who take on additional job functions may need new accounts. Employees who are

given temporary responsibilities may need higher access levels for the duration of their increased responsibility.

Normally, a manager fills out an account request form, which explains what access is needed and what business need

this access will fill. The form should also specify whether the new account or heightened access is temporary (and

when it will expire) or permanent. The manager submits the form to the security team who reviews the request and

either approves or denies it. Once the request is approved, it is forwarded to a member of the accounts team to

actually create the account or modify the user's access level.

Access levels that were granted temporarily should be lowered as soon as the need for heightened access is no longer

present, and accounts for employees who leave the company should be removed immediately.

The workflow to remove or downgrade accounts is similar to that described for creating accounts. A manager fills out

an account request form, submits it to the security team, who forwards it to the accounts team. When an employee is

terminated or leaves the company, his or her accounts should be locked immediately.

Keep in mind that the goal of these administrative strategies is to minimize the human error inherent in any access

control strategy.

Technical Strategies The technical aspect of an access control strategy may include some or all of the following techniques:

Discretionary access control (DAC)—Access control system where rights are assigned by the owner of the

resource in questionFind answers on the fly, or master something new. Subscribe today. See pricing options.

Mandatory access control (MAC)—Access control system where rights are assigned by a central authority

Role-based access control (RBAC)—Access control system rights are assigned based on a user's role (as

discussed earlier in the chapter) rather than his or her identity

Automated account review—All accounts should be reviewed periodically to ensure that they still need the

access to resources and privileges they currently hold. As job functions change and evolve, so do their access

needs. An automated system cannot replace human knowledge of business processes and the resources those

processes require, but it can determine which access rights have not been used recently. Unused rights are a

vulnerability in any system.

Automated expiration of temporary access—When accounts are created for temporary employees or access

levels are temporarily raised, those accounts should be downgraded or removed promptly. Automated expirations

are an easy way to ensure that a temporary account is not forgotten and left sitting around on the system, just

waiting to be exploited.

Every organization has unique business challenges, so there is no one-size-fits-all technical access control strategy.

Use the methods and techniques that make sense for your situation.

Separation of Responsibilities The principle of separation of responsibilities is designed to ensure that if an attacker compromises one account,

he or she will be denied access to highly sensitive information because it is protected by two separate conditions. Both

conditions must be met in order to access to be granted. If one condition is met but not the other, access is denied.

Separation of responsibilities is a strategy that is used extensively in many areas:

NOTENOTE The terms "separation of duties" and "segregation of duties" are synonymous with "separation of responsibilities."

Accounting department employees usually do not have the ability to create new vendors and cut checks. This

policy exists to prevent a single employee from creating a fake vendor, then creating checks made out to the fake

vendor. It will take at least two employees working in tandem to embezzle this way. The two conditions that must

be met to pay a new vendor are executed by two separate employees: one to create a vendor and one to cut checks.

Safe deposit boxes usually have two keys that are kept physically separate. Both keys must be present to open the

box.

Missile launch procedures require two military officers of sufficient rank to give the correct command and turn

launch keys in order to arm a missile launch system. A single officer is not sufficient, as this would place too much

power in the hands of a single individual.

In access control systems, separation of responsibilities has two aspects: compartmentalization and dual conditions.

Compartmentalization is the practice of keeping sensitive functions separate from non-sensitive ones. In practice,

this is implemented by isolating programs running under one user account from other users. Dual conditions are most

often implemented through two-stage authentication methods, which require both a biometric scan and a password,

or a token device and a password to grant access.

Least Privilege Find answers on the fly, or master something new. Subscribe today. See pricing options.

The principle of least privilege is based on the idea that a subject—whether a user, application, or other entity—

should be given the minimum level of rights necessary to perform their legitimate functions. The purpose of this

principle is that if an account is compromised, an attacker will have a minimal set of privileges and will not be able to

use the compromised account to do real damage to the entire system.

In practice, the principle of least privilege is usually implemented as least user access (LUA), which requires that

users commonly log onto workstations under limited user accounts. Administrative accounts should be reserved for

administrators, and then only used when performing administrative tasks.

RISKS ASSOCIATED WITH USERS HAVING ADMINISTRATIVE RIGHTS

On a server, having an administrator logged into a privileged account can create an opportunity for an attacker to

hijack the administrative session.

NOTENOTE On Windows servers, the administrator account is called Administrator. On UNIX and Linux servers, the administrator account is called root.

If an administrator regularly logs into the server using the administrative account to perform routine tasks, the

window of opportunity is larger than if that account is only activated for specific tasks and promptly logged off.

Workstations are not usually connected directly to the Internet, as a server is, so the risk is much lower that an

attacker will attempt to hijack the administrator account. On a workstation, the major risks to allowing users to log

onto the administrator account for routine tasks are malware and misconfigurations.

Malware, such as viruses, Trojan horses, and spyware, usually require administrative privileges to install them, just

as any other application does. If a user is logged in as administrator on his or her workstation, the chances of infection

by any given piece of malware is greater.

The risk of misconfigurations is based on the fact that many users are not experts in computer maintenance and

configuration. If users without sufficient knowledge attempt to change their firewall settings because they read a blog

post or heard someone talking about the latest virus, they are likely to do more harm than good.

COMMON ROLES

There are three common roles on any system, either workstation or server: administrator, user, and guest. Many

systems have other customized roles as well, but the ones discussed here are the ones you will find on any system.

Administrator.

The administrator, or root user, has the ability to perform most tasks on a system. At a minimum, the administrator

can:

Create user accounts and assign privileges.

Install software and devices.

Perform low-level system maintenance tasks, such as registry maintenance, start and stop services, install drivers,

and manage log files.

This is by no means an exhaustive list of the tasks an administrator can perform. These are simply the primary

categories of tasks for an administrator. Find answers on the fly, or master something new. Subscribe today. See pricing options.

NOTENOTE Some user accounts are limited to a subset of the applications installed on a computer. It does not make sense to enable a user account to run the user-creation application because that is an administrative task.

User.

There will usually be more than one user account on any given system. Some user accounts are tied to individuals,

while others are used by applications. In general, a user account can:

View the status of services, drivers, processes, and so on.

Run programs.

View log files.

Make limited changes to registry entries.

Add, modify, and delete data and files owned by that user.

This is the most common type of account, and may be further defined into specific types of users with more granular

privileges.

Guest.

Some systems will have a guest or anonymous account. Others will have this account disabled or removed. The guest

account is a severely limited version of a user account that is enabled to run only specified programs and view specific

data. On a system without a clear need for a guest account, it should be disabled or removed. An attacker could

potentially use the guest account to attack the more privileged accounts on the system.

Need to Know Users should be given access to the minimum amount and sensitivity levels of data and resources necessary to

perform essential functions. If a user does not need to know the Social Security number of a client in order to do his or

her job, he or she should not be given access to that information.

WARNINGWARNING In practice, it is rare—and a bad idea—for an authentication system to query a database with a plain-text password. More likely, the system will query the database with the results of a password hash equation.

There are three basic levels of need for information:

Existence of information—At this level, the subject only needs to know whether or not a certain piece of

information exists, or if it matches a predefined pattern. Username and password authentication systems are a

good example of this level of need.

FYIFYI

Find answers on the fly, or master something new. Subscribe today. See pricing options.

When users enter their usernames in an authentication system, the system sends a request to the database: "Does a record with the supplied username exist?" If the record exists, the database returns the Boolean result TRUE. If the record does not exist, the database returns FALSE. Likewise, when users enter their passwords, the system sends another request to the database: "Does the password in the database record keyed on the supplied username match the user supplied password?" Again, the database will return a Boolean result, either TRUE or FALSE. The authentication system does not need to know what the password associated with a user record is; it simply needs to know if the user-supplied password matches what is stored in the database.

View partial information—This is the most common level of need. Most users will need to know some

sensitive information, but not all. For example, an office manager preparing a letter to be sent to a firm's entire

client list will need to know the clients' directory information—names and addresses—but will not need those

clients' Social Security or account numbers. Another employee in the accounting department may need clients'

account numbers but not their directory information.

View full record—The need for this level of access is rare, and should only be granted to those who cannot

perform their job functions with partial access to information.

In all cases, the need to know principle dictates that users only be granted access to the information they actually

need, and no more.

Input/Output Controls Input and output controls dictate a user's ability to interact with devices and data. The guiding principle for input and

output controls is the same as everything else: users should have the least access possible to perform their job

functions.

INPUT CONTROLS

Input controls dictate how users can interact with data and devices that introduce new data into a system. For

example, input controls might dictate whether a user is entitled to write new data files or modify existing rows in a

database. Input controls are also concerned with physical security such as automatically locking server rooms and

securing unused network jacks on servers. Left unsecured, an unused network jack could be used to attach an

unauthorized device to the network via a server.

OUTPUT CONTROLS

Output controls are similar to input controls, except that they are primarily concerned with the output of data,

either to a screen, printer, or another device. A user's ability to read a data file would be the focus of an output control

rule, as would a system that requires a personal identification number (PIN) to retrieve print jobs. This type of system

is usually put in place to prevent unattended output on a shared printer.

Case Studies and Examples of Access Control Systems That Uniquely Solve Business Challenges Now that you understand the theory behind designing a comprehensive access control system, let's examine how these

systems are implemented in real-world situations.

Private Sector Case Study Acme Corporation is a large new media company that has recently launched a Software as a Service (SaaS) office

suite. This suite includes a word processor, as well as presentation, e-mail, calendar, and spreadsheet applications.

Also included are collaboration and Web authoring tools.Find answers on the fly, or master something new. Subscribe today. See pricing options.

Figure 6-1. Portability of SaaS.

SaaS is a new model of software distribution. Instead of simply selling an application, a SaaS vendor offers access to

the applications for a small subscription fee. The application and data are stored on the vendor's servers and the

customer accesses them remotely. This benefits the customer by lowering operating costs and adding security and

portability. SaaS generally costs less, both in upfront and ongoing costs than buying software in a traditional manner.

This is especially true for a small-business environment that may not have the capital necessary for the hardware

associated with large centralized applications.

SaaS also adds a new layer of document security; even if a workstation is physically stolen, the information is safe

because all of the documents are stored on the vendor's servers instead of the customer's workstation. Storing the

information remotely also gives the customer an amazing amount of portability. Any system with appropriate access

software can access the data. In Acme's case the office suite is Web-based, so any system with a Web browser can be

used to access the applications, including smartphones. The portability of SaaS can be seen in Figure 6-1.

SaaS has its challenges as well. Privacy is a major concern because multiple organizations will have access to Acme's

systems. Acme's customers do not want other groups or even Acme employees to have the ability to access their data.

These are concerns above the normal data security issues internal to an organization. There is also the issue of ease of

use. End users at the organizations using Acme's SaaS do not expect to have to log into their word processor, for

example. For Acme's SaaS offering to be widely adopted, its security features must be seamless to end users. While

these problems are daunting, they can be addressed with a well-designed access control system.

NOTENOTE Acme's office suite provides services for many organizations from a single server, just as many families might live in a single apartment building. Each organization's data is segregated from the others, but it all resides on the same server.

The first obstacle that Acme needs to address is cording off users and organizations to make sure information is not

unintentionally shared between unrelated groups. This is handled with a RBAC system. Each organization is a "role"

in Acme's design; data is restricted then by role. Only the organization that created the information has access to it

initially, but access can be explicitly granted to other roles by sharing the data. Acme's own employees are included in

this layer of control, guaranteeing that even internal Acme users can only see the data that they have rights to see.

Acme customers also have the ability to set up a mandatory access control schema. They can set up an administrator

or group of administrators for their SaaS applications. These administrators control organization-wide rights to

accessing the data. Administrators can explicitly add or deny access to users and groups of users in a similar mannerFind answers on the fly, or master something new. Subscribe today. See pricing options.

to data that is stored locally. This allows organizations to have strict access controls based on their own access control

policies.

There is also the ability to have DAC on user-created data. If an organization does not have the infrastructure for a

centralized administrator, each document owner can set the access controls for his or her documents by explicitly

allowing or denying access to other users in the organization, and even to other organizations.

Acme also wanted to allow customers the ability to verify document integrity, as required by various regulations. To

achieve this it implemented a granular, robust document logging and auditing system. Managers and end users can

see what changes were made to a document, who made them, and when they were made. Users can also revert to a

previous version of a document. This robust logging allows users to verify the integrity of the information stored in the

system.

Acme also wanted to make all of this security seamless and invisible to the end user. Users are not used to logging in

to a word processor or calendar application, and it would be difficult to convince new customers to adopt Acme's SaaS

offering if it added a layer of unfamiliarity or complexity to applications that are constantly used and needed in an

organization. To avoid this, Acme created an authentication API utilizing Security Assertion Markup Language 2.0

(SAML 2.0). SAML is an XML-like markup language that allows Web applications to pass a security token for user

identification. This allows for organizations using Acme's SaaS to utilize a single sign-on (SSO) system. The end user

logs onto his or her workstation, and that username and password acts as the login for Acme's SaaS business suite as

well. This also allows organizations to take advantage of existing password complexity and expiration rules.

Utilizing a deep and robust access control system, Acme was able to provide information privacy and integrity for its

SaaS customers.

Public Sector Case Study The U.S. military needed a way to communicate information quickly and securely in the rapidly changing

environment of a battlefield. Wired communications, while secure and robust, had significant drawbacks.

Communications lines could easily be severed and military personnel were limited to only communicating with fixed

locations. Radio and wireless communications removed the threat of cut lines, and extended the range of

communications, allowing military personnel to communicate with mobile units, but only to a fixed range. Stationary

installations were still needed as base stations, and throughput degrades the further units were from the base station.

That led the military to turn to a new type of wireless networking called wireless mesh networking.

Figure 6-2. Mesh network topology. Find answers on the fly, or master something new. Subscribe today. See pricing options.

Wireless mesh networks are based on a distributed network mesh topology. Each node in the network connects to

multiple nodes; each node also acts as a router for the nodes it connects to allowing traffic to hop along multiple paths

to a destination. This allows for a very robust and flexible network. The loss of one node will not hurt the network, and

nodes can be added at will. Range of the total network is also massive because nodes don't need to be close to a central

point. They just need one other node to function. An example of a mesh network can be seen in Figure 6-2.

While a wireless mesh network solved part of the military's requirements, security remained a major concern. To

make sure the communications were secure the military implemented both physical and logical access controls on the

network.

For the physical security of the communications, the military uses frequency hopping on the radios connected to the

network. The radios are constantly changing frequencies. This allows them to avoid jamming and eavesdropping.

For logical security the mesh network relies on MAC addressing to identify all of the devices in the network. A list of

all allowed Media Access Control (MAC) addresses is generated and each device knows whom it talks to. A MAC

address can be faked, so they also utilize a shared secret style encryption key to handle security. When devices in the

network first link together, they will authenticate each other utilizing public key infrastructure (PKI) then develop a

shared key, which will get renewed periodically to handle encryption. Now any communications between nodes can be

validated with that key. These two network access controls methods give the military the ability to secure their

wireless communications.

Critical Infrastructure Case Study Power plants are an important part of critical infrastructures and local, state, and national economies. Therefore,

power plants need deep and multilayered access controls due to concerns over physical security. There are a number

of sensitive areas that must be secured, and various employees need different levels of access to these locations. At a

plant in the upper Midwest, this access is handled with identity badges that include images of the user and an RFID

with their access rights.

The RFID handles access through multiple levels. There is a security checkpoint at the entrance to the parking lot, and

at the entrance. Both points require a badge to enter. From there the badge allows personnel to enter the facilities they

are authorized to enter. It also acts as "something you have" for multipoint authentication onto secure systems. These

are all standard functions for an RFID badge system.

The badges also have an automatic deactivation feature, which is useful for certain personnel. Maintenance personnel,

for example, do not have enhanced access and do not require access to secured areas of the site. However, the

maintenance team may need access to any area of the facility regardless of its sensitivity, in the case of a breakdown or

special project. To allow for this, the badges can be granted access rights that decay over time. This allows for

temporary access to secure areas that is then automatically revoked over a number of hours or days. This lowers

administrative time, and reduces the risk of human error in rights assignment.

CHAPTER SUMMARY All access control systems are about solving problems and meeting business needs. In order to do this effectively, you

should be familiar with a variety of access control types, and understand how to map those types to various business

challenges. Understanding how access control systems are used in the real world is a good way to integrate what

works into your own access control systems.

KEY CONCEPTS AND TERMS Business continuity

CompartmentalizationFind answers on the fly, or master something new. Subscribe today. See pricing options.

Discretionary access control (DAC)

Group

Information availability

Information confidentiality

Information integrity

Input control

Least privilege

Least user access (LUA)

Malware

Mandatory access control (MAC)

Media Access Control (MAC) address

Output control

Risk acceptance

Risk avoidance

Risk mitigation

Risk transference

Role

Role-based access control (RBAC)

Separation of responsibilities

Software as a Service (SaaS)

Wireless mesh networks

CHAPTER 6 ASSESSMENT 1. In terms of business continuity, a hostage situation could be considered a disaster.

1. True

2. False

2. ________ is choosing not to engage in an activity that carries some element of risk.

3. ________ is carrying on despite the risks involved in a given activity.

4. ________ is the process of assigning risk to someone else.

5. ________ combines attempts to minimize the probability and impact of risk. Find answers on the fly, or master something new. Subscribe today. See pricing options.

6. The three main threat categories are information confidentiality, ________, and availability.

7. Even non-sensitive data should be kept under some level of access control.

1. True

2. False

8. Any system or data resource that, if it were lost, stolen, damaged, altered, or publicly divulged, would cause a

significant negative impact to the organization should be considered ________.

9. Which of the following is an access control system in which rights are assigned by the owner of the resource?

1. Discretionary access control

2. Mandatory access control

3. Role-based access control

4. Media access control

10. Which of the following is an access control system in which rights are assigned based on a user's role rather than

his or her identity?

1. Discretionary access control

2. Mandatory access control

3. Role-based access control

4. Media access control

11. Which of the following is an access control system in which rights are assigned by a central authority?

1. Discretionary access control

2. Mandatory access control

3. Role-based access control

4. Media access control

12. The principle of separation of responsibilities requires a minimum of how many conditions to be met before

access can be granted?

1. 1

2. 2

3. 3

4. 4

5. 5

13. Least user access implements what access control requirement?Find answers on the fly, or master something new. Subscribe today. See pricing options.

Recommended / Playlists / History / Topics / Settings / Get the App / Sign Out © 2019 Safari. Terms of Service / Privacy Policy

1. The group with the least users should be granted the highest level of access.

2. Users should commonly log into workstations under limited user accounts, unless they are performing

administrative functions.

3. No user should have administrative rights to a workstation.

4. All users should have administrative rights to a workstation.

14. The three basic levels of need for information are existence of information, view partial information, and

________.

PREV TWO. Mitigating Risk with Access Control Systems, Authenticati…⏮

NEXT 7. Human Nature and Organizational Behavior ⏭

Find answers on the fly, or master something new. Subscribe today. See pricing options.