business and computer science

Imagine with us that you are the engineering director of a large company and you are interviewing candidates for a position as your software security architect. You ask the three main candidates, "Just how secure will you be able to make my software?"

If one of the candidates answers, "I can make your software secure against any attack," we hope you'll show him the door. If another candidate answers, "I will make your software as secure as it can possibly be," we hope you'll give her a failing grade as well.

In our opinion, the winning response is, "How secure do you want it to be?" That's because designing in too much security drains away resources, frustrates people, and can complicate matters so much that intelligent software maintenance is impeded.[2] Superfluous security controls can actually diminish the overall safety of an enterprise.

[2] By the way, we'd give extra credit to any candidate who asked his own question: "What do you mean by `secure'?"

The process of selecting design elements and principles to match a defined security need is what we mean by security architecture. In this chapter, we'll examine the role of architecture and how it applies throughout the development process, and we'll introduce the security engineering principles we believe are key to the development of secure software. Finally, at the end of the chapter, we'll discuss how some of these ideas were not followed in the design of the TCP stack with regard to our SYN flood example.


(Many of our points, as you will see, apply to any complex human enterprise.)

Returning to our interview example for a moment, what would your answer be to the question, "How secure do you want it to be?" Our suggested answer is, "Just secure enough." Throughout this book, we'll help you figure out what that would mean for your company. We also aim to teach you how to select, from many possible technical solutions, a set of complementary tools and procedures to ensure that your software is just that secure. Selengkapnya.....

In late 1996 there were approximately 14,000,000 computers connected to the Internet. Nearly all of them relied on the Transmission Control Protocol (TCP), one of the fundamental rule sets underlying communication between computers, and the one used for most common services on the Internet. And although it was known to have security weaknesses, the protocol had been doing its work quietly for nearly two decades without a major attack against it.

But on September 1 of that year, the online magazine Phrack published the source code for a network attack tool that exploited the trusting way the protocol handled connection requests (see the sidebar A Fractured Dialogue). Suddenly, the majority of those 14,000,000 computers were now vulnerable to being taken offline—in some cases, crashed—at the whim of any malcontent capable of compiling the attack program.
A Fractured Dialogue
What happens when you call someone on the phone and they hang up before you do—and you decide not to hang up yourself? Until a few years ago (in the U.S., at least), it was possible to tie up the other person's telephone line for a long time this way.

Today we might call this trick a denial of service attack. It's an example of what can happen when one party to a conversation decides not to play by the rules. In the network world, a set of such rules is called a protocol. And the network attack known as a TCP SYN flood is an example of what can happen when an attacker controlling one side of a computer dialogue deliberately violates the protocol.


The Transmission Control Protocol (TCP) is used many billions of times a day on the Internet. When email is exchanged, for example, or when someone visits a web site, the dialogue between the sending and receiving computers is conducted according to these rules. Suppose that computer A wants to initiate a connection with computer B. Computer A offers to "synchronize" with computer B by sending a set of ones and zeros that fit a special pattern. One feature of this pattern is that a particular bit (the SYN flag) is set. Computer B agrees to the exchange by replying in an equally specific bit pattern, setting both the SYN flag and the ACK ("acknowledge") flag. When computer A confirms the connection by replying with its own ACK, the TCP session is open, and the email or other information begins to flow. (Figure 1-1 shows this exchange.)

As early as the mid-1980s, researchers realized that if the initiating computer never completed the connection by sending that final acknowledgment, the second computer would be in a situation similar to that of the hapless telephone user whose caller never hung up. To be sure, in each case the computer programs implementing the dialogue can break the connection after a suitable period of time, freeing up the telephone line or network connection. But suppose that an attacker writes software capable of sending dozens or hundreds of false connections requests per second. Wouldn't the receiving computer be overwhelmed, keeping track of all those half-open connections? That turns out to be the foundation for a TCP SYN flood attack; and in 1996, it was deadly.[1]
It was a time when new vulnerabilities were being disclosed daily, and the article at first went unnoticed by most security professionals. It was, however, read carefully in some quarters. Within days, an ISP in New York City named Panix was repeatedly savaged using the technique. Day after day, bombarded by tens of thousands of false connection requests—known as a SYN flood , after the protocol element that was misapplied—Panix was helpless to service its paying customers. The security community took notice and began to mobilize; but before experts could come up with an effective defense, the attacks spread. The Internet Chess Club was clobbered several times in September. Scattered attacks troubled several more sites, mostly media outlets, in October. In November, on election night, the New York Times web site was disabled, and the resulting publicity opened the floodgates. By the time an effective defense had been devised and widely deployed some weeks later, hundreds of sites around the world had been victimized. Tens of thousands more were affected, as experts and laypersons alike struggled to cope with the practical impact of this first widespread denial of service attack.
Selengkapnya.....