One consideration of access control is that of advantage. Does a company gain an advantage from securing its information? Could its competitors gain a similar advantage if they had access to the information? Is the information already secret?

Consider a proprietary recipe developed by a food manufacturer. In testing, the company realizes its new recipe is popular with customers. In fact, since releasing the new product, its sales have tripled. If sales levels hold steady, the new item will become the best-selling product of its kind within a year. Holding the recipe for such a popular product clearly gives the company an advantage over its competition.

Would a competitor gain a similar advantage if it had access to the same recipe? The competitor would probably release a similar product at a lower price point because it did not have to invest in research and development. Once customers realize that the less-expensive product is very similar to the original, sales of the more expensive original product could decrease.

Another consideration of access control is risk. As you read earlier in this chapter, there can be significant penalties for allowing sensitive information to be disclosed, even if the disclosure is purely accidental. In the preceding example concerning a secret recipe, the company might not risk fines or jail time by sharing its recipe, but it does risk being undercut by the competition.

This is where the asset valuation portion of a risk assessment (covered next) becomes important. Every organization should know what information it possesses and how important that information is in terms of access control. Organizations should also be aware of negative consequences that could arise if that information is not adequately secured.

In terms of business facilitation, there are essentially three levels of information access: no access, read access, and read-write access.

Understanding access levels: A newsletter example. To understand access levels, let’s use a corporate newsletter as an example. A corporate newsletter is a tool used to distribute important information to employees, such as the dates for open benefits enrollment. All employees have permission to read it, but only a few are entitled to write and publish information in the newsletter. This one-to-many scenario—or few-to-many, depending on how many people are involved in writing the newsletter—is used to carefully control the flow of information to the average employee. If the enrollment dates are published in the newsletter, every employee receives the same information and is expected to abide by the published deadlines.

The newsletter is also a tool for creating corporate culture and supporting employee morale. You will rarely find a negative article in a corporate newsletter, because that would be damaging to morale. Likewise, the tone of the newsletter is indicative of corporate culture.

In a traditional financial firm, the employee newsletter is likely to be straightforward and data-heavy. In a technology firm, the newsletter is more likely to be written in a fun, slightly irreverent tone. It might include trivia, news oddities, and other “fluff” that would not be included in a financial firm’s newsletter.

Both newsletters support and reinforce the firms’ corporate cultures. This does not happen by accident, but is carefully constructed to meet a goal. This goal is met by carefully restricting who can publish information in the company newsletter. By restricting write access, the organization maintains a unified voice.

Understanding access levels: An order process example. What about other information sources within a company? Consider a single order for an herb garden kit from a mail-order nursery. A wide variety of people have access to that information throughout the life cycle of the order, as shown in FIGURE 2-1.

Mike, the customer, is the first person to have access to order information. When he places his order via the company’s website, Mike has read-write access to the order data. Once he submits the order; however, he is restricted to read-only access. He can track the status of his order but can no longer change the data.

When the order is placed, the data are stored in a database, and notifications are sent to Mike (confirming the order) and to an employee in order processing. This person collects the pots, seeds, and peat pellets necessary to assemble the herb garden kit, and passes the kit to the shipping department. At this point, order processing updates the database to reflect the new status of the order. The order processor may also update the inventory database to reflect the fact that items were removed from inventory to assemble the order. The person in order processing has read-write access to the order information, at the point at which he or she needs it. The order processor has no access to the information during order creation, has read-write access while fulfilling the order, and has no access once the product is sent to shipping.

The shipping department schedules a pickup with Mike’s preferred carrier and receives a tracking number from the carrier. This tracking number is amended to the order information and sent to Mike. When the shipping carrier picks up the package, the order is closed. The shipping department may have read access to the order information while the order is in processing, and has read-write access during the time the order resides within the shipping department—after it leaves processing—but before it is picked up by the shipping carrier.

Customer service has read access to the order data throughout the entire workflow, so that representatives can give Mike an up-to-date order status. Customer service representatives may even have read-write access, if the business allows customers to modify orders or make special requests during the life cycle of an order. For example, the business may allow customers to call in and request an upgrade to priority shipping, as long as the order has not yet been sent to the shipping department. To facilitate this business need, customer service representatives must have read-write access to the order data throughout the order life cycle.

Customers themselves have read-write access only at the point of order creation. Once they submit their order, they are restricted to read-only access for the remainder of the order life cycle. This is done to avoid crisis. If a customer had read-write access—that is, the ability to modify his order at any point in the order life cycle—the order processing department could assemble the order, only to find that the customer has changed his mind and now wants a different product. The time and effort expended in assembling the first version of the order would have been nonproductive.

Controlling who can modify order data at any given point in the process is the only way to ensure productivity. Without this type of access control, order processing could go into an indefinite loop trying to assemble one customer’s order.

As shown in the previous examples, restricting access to information can be a way to ensure productivity in business processes. Access restrictions to information can also be a way to ensure that a consistent message is conveyed throughout the organization. When information has one author—one individual with read-write access—you can easily verify that the information is accurate and has not been changed.

Consider the open enrollment dates discussed earlier in this section. If those dates are published in the corporate newsletter (an information vehicle with restricted read-write access), employees can be confident that those dates are correct. What if open enrollment dates were distributed by word of mouth (essentially, without any access restrictions at all)? If you ever played the game “telephone” in kindergarten, you can imagine the chaos that would ensue. No one would really know which dates were correct and which were not.

These are all simple examples of the need for access restrictions to facilitate business processes. However, there are more serious reasons that businesses need to restrict access to information. Internal business policies should not be shared with customers or competitors, for example. In addition, there are situations in which commonly known information within one part of the business cannot be shared with another.

Consider a large financial firm with two divisions. One division handles client investments while the other is involved in banking and insurance activities. On the banking side, everyone may be talking about an upcoming acquisition of an insurance carrier. Many of the details of the acquisition are common knowledge. However, employees on the investment side are not allowed to know those details because they could influence, even subconsciously, their buy and sell decisions. In this case, strict physical access limitations to data are necessary. An employee from the investment side of the firm, which has offices on the second floor of the building, would not be allowed on the third floor, where the banking and insurance division is located. Smart card ID badges and other physical security measures would generally be used to enforce this access restriction.

If a warehouse manager comes into work on Monday morning and finds the quarterly financial report on her desk instead of the inventory report, she cannot do her job. She has to track down the necessary information, costing her valuable time. The warehouse manager has no immediate need for the financial report (although if she is vested in the company, she may be interested in the information), so having access to the report does not increase her efficiency. The inventory report, on the other hand, is information she has a direct need for.

In IT, it is your job to ensure that the warehouse manager has the inventory report on Monday morning and has access to the financial report only upon request.

As shown in the earlier example of an order life cycle, if the wrong people have access to information, productivity can come to a halt. If a customer can change the details of his or her order after it has already been assembled, there can be a breakdown in processes and efficiencies.

The same thing can happen if too many people are brought into a decision-making process. Consider the CRM vendor example in the previous section. Management and select experts from the IT department should be involved in that decision process. What would happen if the entire assembly line from manufacturing were invited to comment on each CRM choice? The decision process could be slowed down or even halted because the wrong people were brought into the process.

In the CRM vendor example, sales might be the driving force behind the initiative. The company has determined that a CRM solution will increase its ability to serve customers and make sales. This determination is made within the Sales department before it is brought before senior management for approval. Senior management must approve the initiative before it is sent to IT for research and before the contracts are requested from the legal department. Much time would be wasted if someone in Sales were to send a memo directly to a manager in Legal asking for a contract to be drawn up for a new CRM vendor. That work would have to be redone later because requirements would inevitably change during the requirements gathering and research phases.

In the warehouse example, if the manger has the quarterly financial report on Monday morning instead of the inventory report, she loses efficiency because she does not have the right information at the right time.

The asset inventory contained within a risk assessment report should contain a list, along with location information, of every major resource within the IT infrastructure. However, if an attacker learns that the company’s customer database is located on Server A5 in the third rack on the northwest wall of Server Room 12, the task of stealing or disabling that server is a lot easier. Once the attacker is past physical security measures, he or she has a short amount of time to get in, do the job, and get out without being caught. Knowing exactly where to find resources helps to get in and out more quickly.

For a risk assessment to be useful, it must look at the weaknesses in the infrastructure. Every system has weaknesses. They are an unavoidable fact of life. The point of a risk assessment is to look honestly at those weaknesses and determine how to eliminate them or minimize their impact.

If an attacker were to obtain a copy of the risk assessment report with the vulnerability assessment, he would have a customized manual for attacking the resources he is most interested in. Instead of trying dozens of possible vulnerabilities until he finds one that hasn’t been patched, he knows exactly what has been done to strengthen the system and where the weak points can be found. This information makes attacking a system trivial.

A threat assessment is similar to a vulnerability assessment, with one slight difference. While the vulnerability assessment looks at weaknesses within the existing infrastructure, the threat assessment deals with the potential for those weaknesses to be exploited.

An attacker with access to a threat assessment knows what attacks the company’s security team has already considered and may have begun to mitigate. He also knows which attack methods the company has overlooked or did not realize were possible. This saves the attacker the trouble of attacking in ways that the security team has already anticipated. Depending on how recently the risk assessment was done, the attacker could assume that the threats described in the threat assessment have already been mitigated, or that they are open doors. If the risk assessment is relatively recent, the attacker has a list of attacks that are known to be effective. If the risk assessment is several months or years old, he knows which attacks he shouldn’t bother with.

A risk assessment usually has a section that details plans to mitigate the vulnerabilities and risks described in the previous two sections. If an attacker has those mitigation plans, he knows how much time he has before a given attack is no longer effective. He can also pick apart those plans, looking for new vulnerabilities that may be introduced in the course of mitigating older vulnerabilities.

A particularly sophisticated attacker who is skilled at social engineering could even pose as a vendor or consultant selling threat mitigation services. If he can convince the company that he is legitimate, the company could face a situation where the attacker is the same person hired to “fix” IT security problems.

The final section of a risk-assessment report is usually a description of the company’s policies governing how often a risk assessment should be carried out, what methods should be used, and who should be involved. It also contains a list of individuals who will receive a copy of the report.

An attacker can use this information as well. If he knows that a risk assessment is carried out every 2 years, and the report he has is 18 months old, he may decide to wait 6 months to attack that company because he knows that in 6 months, a newer risk assessment will be available. Like everyone else, an attacker is interested in the most up-to-date information available. He also knows what the risk assessment team is looking for, so he can figure out where to hide the evidence of his activities if an attack is already in progress. For example, if the risk assessment policy states that employees should be secretly tested for vulnerability to various social engineering ploys, an attacker might choose that time to attempt social engineering. He knows that if someone catches on, he or she is likely to assume he is just a member of the risk-assessment team. The attacker has a built-in story to cover his actions if someone begins to suspect something.