Security Blanket or Security Theater?

This chapter is from the book

Analyzing Computer Security: A Threat / Vulnerability / Countermeasure Approach

Learn More Buy

This chapter is from the book

This chapter is from the book 

Analyzing Computer Security: A Threat / Vulnerability / Countermeasure Approach

Learn More Buy

Imagine a series of events unfolding on a single day. First, 20 million U.S. smart phones stop working. Next follow outages in wireline telephone service, problems with air traffic control, disruptions to the New York Stock Exchange, and eventually severe loss of power on America's East Coast. What could cause such crippling outcomes?

You might think first they are isolated events, just coincidentally occurring on the same day. But with several things happening at once, you next start to look for common causes. Perhaps the various organizations providing these services bought some of their software from the same vendor, and the software is failing because of a shared flaw. Possibly this situation is like the Y2K problem, when people were concerned that on January 1, 2000 computer systems would crash because they used only two digits for the date (98, 99) and would fail when computer clocks rolled over the year boundary. Or maybe dependencies in one sector trigger actions that cause the initial failure to cascade into other sectors, for example:

1. A software defect causes disruption in mobile phone service.
2. Consequently, those who need to use phones revert to their wireline service, thereby overloading circuits.
3. Air traffic controllers in some parts of the country depend on wireline communication, so overloaded circuits lead to air traffic control problems.
4. Similarly, the New York Stock Exchange is severely debilitated by its brokers' inability to place and verify trades.
5. At the same time, the power grid experiences problems because its controllers, no longer able to exchange information by using mobile phones, shut down because of a flawed protocol.

There is yet another scenario, used by the Bipartisan Policy Center in its February 2010 Cyber ShockWave exercise: malicious computer software or malware, "planted in phones months earlier through a popular 'March Madness' basketball bracket application, disrupts mobile service for millions" [BPC10].

It is difficult—sometimes impossible—to distinguish between an accident and an attack. Consider, for example, an online gambling site that received a flood of blank incoming email messages that overwhelmed servers and slowed customer traffic to a crawl. Blank messages could easily come from a software or hardware problem: a mail handler caught in a loop with one malformed message that it dispatches over and over. Shortly thereafter, the company received email written in broken English. It told the company to wire $40,000 to ten different accounts in Eastern Europe if it wanted its computers to stay online [MCA05]. So much for the "just an accident" theory.

Are these scenarios realistic or implausible? And are cyber security exercises such as these and the ones described in Sidebar 1-1 designed to confirm our readiness (a security blanket) or exacerbate our worries (security theater)? What is the likelihood we will be able to determine the causes of these kinds of failures and then prevent or mitigate their effects?

No matter what your work or family responsibilities, it is important for you to understand the nature of these scenarios, make reasoned judgments about their likelihood, and take prudent actions to protect yourselves and the people, data, and things you value.

One way to develop an understanding is to imagine how you might interpret a situation and then react to it. For example, in the unfolding events from mobile phone outage to East Coast power failure, consider these roles:

• You are using your mobile phone to talk with your friend, and the connection drops. You redial repeatedly but never connect. You then try to call your friend on your land line, but again there is no connection. How long does it take you to realize that the problem affects far more people than just you and your friend? Do you contact the telephone company? (And how? You cannot phone, and your Internet connection may very well depend on your telephone carrier!) By the time the power goes out, how do you know the power failure is related to your phone problems? When do you take any action? And what do you do?
• You are using your mobile phone to call your stockbroker because your company's initial public offering (IPO) is scheduled for today—so your company's viability depends on the resulting stock price and the volume of sales. As you begin your conversation with the stockbroker, the connection drops. You redial repeatedly, but never connect. You then try to call your broker on the land line, but again there is no connection. How long does it take you realize that the problem affects your company? Your broker? Others? Whom do you call to report a problem? And when the power goes out, what action do you take?
• You are a government official involved with air traffic control. All morning, you have heard rumors of telephone problems around the country. On your secure government line, you get a call confirming those problems and reporting widening problems with the air traffic control system. How do you determine what is wrong? To whom do you report problems? When you realize that problems with air traffic control may be dangerous to aircraft and their passengers, how do you react? Can you ground all aircraft until the sources of the problems are located and corrected?
• You are a government official involved with regulating the power grid. All morning, you have heard rumors of telephone problems around the country. Your web-based reporting system begins to report sporadic power outages on the East Coast. On your secure government line, you get a call confirming those problems and reporting widening problems with the air traffic control system. How do you determine what is wrong? To whom do you report problems? When you realize that problems with the power grid may threaten the viability of the entire nation's power system, how do you react? The power grid is owned by the private sector. Does the government have authority to shut down the grid until the sources of the problems are located and corrected?

The last situation has precedents. During World War I, the U.S. government took over the railroads [WIL17] and the telephone-telegraph system by presidential proclamations:

• I, Woodrow Wilson, President of the United States, ... do hereby take possession and assume control and supervision of each and every telegraph and telephone system, and every part thereof, within the jurisdiction of the United States, including all equipment thereof and appurtenances thereto whatsoever and all materials and supplies [WIL18].

During World War II, the U.S. government encouraged the automotive industry to redirect production toward jeeps, trucks, and airplane parts. The Automotive Council for War Production was formed at the end of 1941, and automobile production was suspended entirely in 1942 so that the industry's total capacity could focus on the war effort. So possible reactions to our complex scenario could indeed range from inaction to private sector coordination to government intervention. How do you determine cause and effect, severity of impact, and over what time period? The answers are important in suggesting appropriate actions.

Analyzing Computer Security will assist you in understanding the issues and choosing appropriate responses to address these challenges.

In this chapter, we examine our dependence on computers and then explore the many ways in which we are vulnerable to computer failure. Next, we introduce the key concepts of computer security, including attacks, vulnerabilities, threats, and controls. In turn, these concepts become tools for understanding the nature of computer security and our ability to build the trustworthy systems on which our lives and livelihoods depend.

How Dependent Are We on Computers?

You drive down the road and suddenly your car brakes to a stop—or accelerates uncontrollably. You try to withdraw money from your bank and find that your account is overdrawn, even though you think it should contain plenty of money. Your doctor phones to tell you a recent test showed that your usually normal vitamin D level is a fraction of what it should be. And your favorite candidate loses an election that should have been a sure victory. Should you be worried?

There may be other explanations for these events, but any of them may be the result of a computer security problem. Computers are embedded in products ranging from dogs to spaceships; computers control activities from opening doors to administering the proper dose of radiation therapy. Over the last several decades, computer usage has expanded tremendously, and our dependence on computers has increased similarly. So when something goes awry, it is reasonable to wonder if computers are the source of the problem.

But can we—and should we—depend on computers to perform these tasks? How much can we entrust to them, and how will we determine their dependability, safety, and security? These questions continue to occupy policy makers, even as engineers, scientists, and other inventors devise new ways to use computers.

From one perspective, these failures are welcome events because we learn a lot from them. Indeed, engineers are trained to deal with and learn from past failures. So engineers are well qualified to build large structures on which many of us depend. For example, consider bridges; these days, bridges seldom fail. An engineer can study stresses and strengths of materials, and design a bridge that will withstand a certain load for a certain number of years; to ensure that the bridge will last, the engineer can add a margin of safety by using thicker or stronger materials or adding more supports. You can jump up and down on a bridge, because the extra force when you land is well within the tolerance the engineer expected and planned for. When a bridge does fail, it is usually because some bridge component has been made of defective materials, design plans were not followed, or the bridge has been subjected to more strain than was anticipated (which is why some bridges have signs warning about their maximum load).

But computer software is engineered differently, and not all engineers appreciate the differences or implement software appropriately to address a wide variety of security risks. Sidebar 1-2 illustrates some of these risks.

Like bridges, computers can fail: Some moving parts wear out, electronic hardware components stop working or, worse, work intermittently. Indeed, computers can be made to fail without even being physically touched. Failures can happen seemingly spontaneously, when unexpected situations put the system into a failing or failed state. So there are many opportunities for both benign users and malicious attackers to cause failures. Failures can be small and harmless, like a "click here" button that does nothing, or catastrophic, like a faulty program that destroys a file or even erases an entire disk. The effects of failures can be readily apparent—a screen goes blank—or stealthy and difficult to find, such as a program that covertly records every key pressed on the keyboard.

Computer security addresses all these types of failures, including the ones we cannot yet see or even anticipate. The computers we consider range from small chips to embedded devices to stand-alone computers to gangs of servers. So too do we include private networks, public networks, and the Internet. They constitute the backbone of what we do and how we do it: commerce, communication, health care, and more. So understanding failure can lead us to improvements in the way we lead our lives.

Each kind or configuration of computer has many ways of failing and being made to fail. Nevertheless, the analytic approach you will learn in this book will enable you to look at each computer system (and the applications that run on it) to determine how you can protect data, computers, networks, and ultimately yourselves.