Access Control Case study
Dbr
CHAPTER6.docxCHAPTER
6 Mapping Business Challenges to Access Control Types
IN THIS CHAPTER, YOU WILL TAKE SOME THEORETICAL concepts about the need for access control systems and apply them to solve real-world business problems.
The first section of this chapter discusses the types of business challenges that can be solved with access control systems. The second section describes the tools and techniques that can help you apply access control solutions. The chapter concludes with case studies of access controls 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
Access Controls to Meet Business Needs
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 and Disaster Recovery
Business continuity and disaster recovery both refer to keeping organizations operating efficiently and their essential functions continuing in the event of a natural or manmade disaster. Business continuity plans consist of controls designed to mitigate risks to an extent that they do not disrupt critical business functions. Disaster recovery plans kick in when business continuity plans fail and attempt to get the business up and running again as quickly as possible.
NOTE
A disaster is any major event that negatively affects an organization’s ability to carry on business as usual, including natural disasters such as earthquakes or tornadoes. It can also include criminal activities such as arson, robbery, and sabotage, or accidents such as a water main break that floods key facilities.
Business Continuity
When creating a business continuity plan, you should start by brainstorming a list of “what-if” scenarios. Some disasters cannot be prevented—earthquakes will happen, regardless of whether you prepare for them or not. Others, especially criminal activities and accidents, can be prevented or minimized through careful planning and strong access controls.
For example, consider a cruise line with corporate headquarters located in Miami, Florida. This region is highly susceptible to natural disasters, such as hurricanes and flooding. Business continuity planners must take the risk of these disasters into account and develop plans to keep the cruise line running even in the face of a major natural disaster. Planners have several potential strategies at their disposal.
First, the cruise line could decide to separate its data center from its corporate headquarters and move it to a location in the central United States, where hurricanes and flooding are less likely. While this will address the hurricane risk, planners must then consider the new risks in the chosen location. For example, tornadoes threaten large parts of the central United States.
Second, the cruise line could choose to keep the primary data center operating and open a second data center in a facility located in a distant state. This data center may run in active-active mode, mirroring all transactions processed at the primary data center in real time. In the event the primary data center fails, the backup data center would be ready to operate at a moment’s notice. This approach provides the greatest degree of confidence in the organization’s ability to survive a disaster, but at the highest cost.
Third, the cruise line might choose to leverage cloud computing options to create a virtual remote data center. Using this approach, the business could mirror critical servers and data stores in a cloud provider’s environment but activate the servers only when needed. Many cloud providers present the advantages of built-in fault tolerance across multiple data centers and very low costs. The tradeoff with this approach is that the organization no longer maintains full control over its operating infrastructure and must ensure that the cloud environment is configured to meet its security requirements.
Finally, the cruise line could keep its data center in the current location but send backup tapes to an offsite location. This would provide the benefit of having a safe copy of the data at a remote site, but would involve significant recovery time if the primary data center were destroyed. IT staff would need to purchase servers, install software, and load backup data from tape.
The primary job of business continuity planners is to weigh these risks and choose an option that is in the best interests of the organization. At the same time, they must consider access control issues surrounding their chosen strategy. For example, how will the organization limit physical and logical access to the primary and/or secondary data centers? What controls will be used to restrict access to data on backup tapes stored at a remote site?
When physical and administrative controls fail. Strong access controls are also important components of a defense-in-depth approach to personnel issues. Consider, for example, the following scenario:
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 has been damaged in the fire, and emergency personnel remain in the area, preventing anyone from entering the building until it can be inspected and 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.
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 such as 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. A visitor who wants to place an order 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, creates 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 it 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 notices that her department has been fulfilling a large number of orders for a specific South American customer. She contacts a member of the systems team, concerned that the orders are being faked. A check of the log files shows that the orders are coming from a large number of Internet Protocol (IP) addresses across Brazil, Venezuela, and Peru. The systems administrator does a Google search for the affected customer’s username and discovers he has 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 is nothing wrong with Acme’s access control system. It has worked perfectly. The access control weakness is 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. 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 retrained 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
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 health care 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 firefighter 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.
NOTE
Businesses must accept any risk they cannot avoid, transfer, or mitigate.
Risk Transference
Risk transference shifts the potential negative consequences of a risk from one organization to another. The two most common examples of risk transference are the purchase of insurance policies and the signing of contracts that contain indemnification clauses.
Purchasing health insurance is one way of transferring risk. Consider the following scenario: A woman slips on the ice on her driveway, falls, 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 cost the woman several thousand dollars in hospital and physician fees. These fees would cause her serious financial hardship. However, because she has health insurance, she pays only a small co-pay fee. The risk of a major medical expense is 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 health care industry, it is subject to regulation under the Health Insurance Portability and Accountability Act (HIPAA). 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 is contractually transferred from the medical practice to the compliance firm, in the end the medical practice is still penalized and held responsible for the actions of its contracted compliance firm.
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, suppose 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 Mind
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:
Confidentiality—Information confidentiality ensures that private or sensitive information is not disclosed to unauthorized individuals.
Integrity—Information integrity ensures that data has not been modified without authorization.
Availability—Information availability ensures 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.
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. Training and policy mandates are the best way to manage user vulnerabilities.
TIP
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.
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 to 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.
The most common subjects are:
NOTE
Remember, a subject is anything that acts upon another entity. An object is anything that is passively acted upon by a subject.
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.
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, that user should not be granted access. If the user does need access at some point in the future, that user’s 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 individuals 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 the employee 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 (ASPs)
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, each 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 the employee’s home, a coffee shop, or some other public place.
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, which 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 and 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)—Discretionary access control (DAC) is an access control system where rights are assigned by the owner of the resource in question.
Mandatory access control (MAC)—Mandatory access control (MAC) is an access control system where rights are assigned by a central authority.
Role-based access control (RBAC)—In a role-based access control (RBAC) system, rights are assigned based on a user’s role 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 for 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:
NOTE
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 or token device and a password to grant access.
Least Privilege
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 its 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 used only 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.
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 activated only for specific tasks and promptly logged off.
NOTE
On Windows servers, the administrator account is called Administrator. On UNIX and Linux servers, the administrator account is called root.
Workstations are not usually connected directly to the Internet the way 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 are 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, installation of drivers, and management of 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.
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.
NOTE
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.
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.
WARNING
In practice, it is rare—and a bad idea—for an authenti cation system to query a database with a plaintext password. More likely, the system will query the database with the results of a password hash equation.
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.
FYI
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 uses secure hashing technology to avoid sending the password across the network in cleartext. This prevents an eavesdropper from observing the password. Additionally, the authentication database contains only hashed passwords, not the corresponding plaintext passwords that would be needed to access the user’s account. A hash of the password is not the password, and it is not the password encrypted: It allows the verification of a password without possession of the password itself.
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.
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 be granted only to those who cannot perform their job functions with partial access to information.
In all cases, the need to know principle dictates that users be granted access only 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 for 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
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.
FIGURE 6-1
Portability of SaaS.
Private Sector Case Study
Cloud Collaboration 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.
SaaS is a model of software distribution that hosts software in a cloud-based environment on a subscription basis. 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 sometimes 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 Cloud Collaboration’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.
NOTE
Cloud Collaboration’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.
SaaS has its challenges as well. Privacy is a major concern because multiple organizations will have access to Cloud Collaboration’s systems. Cloud Collaboration’s customers do not want other groups or even Cloud Collaboration 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 Cloud Collaboration’s SaaS do not expect to have to log into their word processor, for example. For Cloud Collaboration’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.
The first obstacle that Cloud Collaboration 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 Cloud Collaboration’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. Cloud Collaboration’s own employees are included in this layer of control, guaranteeing that even internal Cloud Collaboration users can see only the data that they have rights to see.
Cloud Collaboration 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 manner 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.
Cloud Collaboration 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.
Cloud Collaboration 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 Cloud Collaboration’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, Cloud Collaboration 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 Cloud Collaboration’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 Cloud Collaboration’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, Cloud Collaboration 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. Communication lines could easily be severed, and military personnel were limited to communicating only at 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 degraded the farther the units were from the base station. That led the military to turn to a new type of wireless networking called wireless mesh networking.
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 need just one other node to function. An example of a mesh network can be seen in Figure 6-2.
FIGURE 6-2
Mesh network topology.
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) and 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 its wireless communications.
Critical Infrastructure Case Study
Power plants are an important part of critical infrastructure 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 the user’s 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 to the building. 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
Compartmentalization
Disaster recovery
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.
A. True
B. 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.
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.
A. True
B. 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?
A. Discretionary access control
B. Mandatory access control
C. Role-based access control
D. 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?
A. Discretionary access control
B. Mandatory access control
C. Role-based access control
D. Media access control
11. Which of the following is an access control system in which rights are assigned by a central authority?
A. Discretionary access control
B. Mandatory access control
C. Role-based access control
D. 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?
A. 1
B. 2
C. 3
D. 4
E. 5
13. Least user access implements what access control requirement?
A. The group with the least users should be granted the highest level of access.
B. Users should commonly log into workstations under limited user accounts, unless they are performing administrative functions.
C. No user should have administrative rights to a workstation.
D. 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 ________.
