The National Security classification scheme has three main levels as well as unclassified, which has subcategories. Each level has a corresponding level of security clearance. Each level of security clearance allows access to that level of information and those below it. By law, information may only be classified to protect national security, not to conceal embarrassing information or illegal activities. Classification levels are described as follows:

Information may change classifications at any time, as circumstances warrant. Information that may have been deemed confidential in 1992 may be considered Secret or even Top Secret today. Likewise, information that was of Top Secret importance in 1939 may no longer be sensitive enough to be classified at all.

Just like governments, corporations need to restrict access to information.

Information is generally classified if disclosure could harm the controlling organization. Corporations classify information to try to keep a competitive advantage over other companies. A soup company, for example, may want to keep its recipes as trade secrets. A company that tests the strength of materials may want to keep its testing methodology proprietary. Governments want to classify any information that would damage their security, such as troop locations and movement, facility locations, and so on.

Declassification is the process used to move a classified document into the public domain. Every country and organization that classifies documents has a method of declassification. Let's look at the U.S. model as a baseline.

There are four ways a U.S. government document can become declassified:

Sun Tzu was an ancient military general and strategist. His book, The Art of War, is one of the definitive treatises on warfare. Its six principles apply very well to a business setting:²

Carl Von Clausewitz was a Prussian major-general whose treatise On War is still considered one of the most influential documents in Western warfare. Clausewitz viewed war as commerce, as many people today view commerce as war. Clausewitz stressed having a strong organizational structure and logistics. He also introduced the concept of "fog of war." Fog of war is the ambiguity and lack of knowledge about the opposition. The term describes uncertainty about your opponent's intent, strength, and capabilities. Clausewitz stressed that your strategies and tactics must be flexible when you encounter the opponent. This concept of adapting your plans to a changing environment is Clausewitz's biggest contribution to business.

It is often said that information is the competitive advantage. Many companies use marketing data, custom business models, and custom business practices. A company may have a formula for its product or a method of servicing its customers that differentiates itself from the pack. These things are the life of a corporation, and are all information based. Securing that information is paramount to a company's success. Loss of that information can lead to a company's decrease in market share and reduced profits.

A lot of information that a corporation collects is legally protected sensitive information, for example PII, financial information, and in some industries classified government documents. Although this information might not have an intrinsic value, there are severe penalties for improper disclosure, both official and in the market. The following are some examples of what a company faces for improperly disclosing information.

Below are penalties for disclosing medical/patient information in violation of the Health Insurance Portability and Accountability Act (HIPAA):

Penalties for disclosing PII are as follows:

In all of these situations there are also unofficial penalties. The loss of consumer trust adversely affects a company's sales. No one wants to give their credit card number to a company that can't or won't secure it.

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: 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 3-1.

Mike, the customer, is the first person to have access to order information. When he places his order via the company's Web site, 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.

Figure 3-1. Access to information through the life cycle of an order.

When the order is placed, the data is 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. There are situations where 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 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 only has access to the financial report 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 was to send a memo directly to a manger 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 has 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 affective. 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 that 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 the 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 two years, and the report he has is 18 months old he may decide to wait six months to attack that company because he knows that in six 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, they are 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.

When outside contractors are hired to provide products or services to an organization, they often require information that could be considered confidential. A good example of this is an external consultant. In many cases, external consultants are either self-employed or employed by a consulting firm and work on an hourly basis for the client company. They are generally highly skilled professionals who are brought in to work on a specific project. When the project is finished, they move on to the next client company. Some client companies hire contractors indefinitely, so in day-to-day practice they are just like regular employees of the company.

This assumption, that a contractor is "just like a regular employee," can be useful when building team coherence, but it can also be dangerous. The contractor's primary alliance is to the consulting company, which provides payment. If a conflict of interest arises between the consulting company and the client company, the contractor is likely to side with the consulting company.

Contractors often supply their own laptop computers and other equipment they need to perform their jobs. This can be problematic, because those laptops may or may not have the same security safeguards in place as corporate laptops. To illustrate this risk, consider a programmer who is brought in to create a specific application for a company. One of the terms of the contract states that the contractor will supply his own laptop. The contractor agrees, and does the work on his personal system, which he also uses to play online games and download music from various sites. At some point, he downloads a file infected with a virus. Because his virus scanner is out of date, the virus goes undetected and infects his system. When he connects his laptop to the corporate network to view design requirements for the application he is developing, the virus uploads itself and infects the file server, quietly sending information from the file server to the hacker that originally created the virus.

When a company contracts with a vendor to manage confidential information, the client company is responsible for ensuring that the vendor has stringent access controls in place. This is especially true in regulated industries such as health care and finance.

A good example of this scenario is an insurance company that outsources its claims management application to a third-party vendor. The vendor runs the application on its servers, allowing the insurance agents to access it from any browser. This is convenient for the agents, who can submit a claim report directly from the site of the incident. It is also convenient for the insurance company because it no longer has to maintain and update its own servers. Unfortunately, the insurance company is still legally responsible for the information contained within those claims—including personally identifiable and sensitive customer information such as addresses, telephone numbers, and mortgage or auto loan information. If the vendor does not implement stringent access controls to protect that data, the client company is legally responsible for the disclosure as well as the vendor.

The most common way to safeguard confidential information that is processed or stored with a vendor is through contractual obligation. Before a vendor-client agreement can be reached, specific access control requirements should be laid out that describe what the vendor is required to do to safeguard any confidential information received in the course of dealing with the client company.

As business needs evolve, so do the partnerships that meet those needs. In the realm of access control, the key thing to remember is that the owner of the confidential information—the client company—is responsible for ensuring that it is handled securely. If the client company fails to do due diligence and hires a third party without investigating the third party's access control policies, the client company can be held partly responsible for the inevitable disclosure of confidential information.