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.

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.

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.

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:

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) addresses 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.

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:

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 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 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.

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.

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.

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.

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.

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:

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.

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.

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 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.

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.

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 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.