2.4 Summary

In this chapter, we presented what we consider to be the fundamentals of secure application architecture. These are the principles that you will constantly call on with confidence in deciding what design decisions to make and how to implement your application. As you read through them, you probably noticed that many of the principles are applicable not only to secure design, but also to many aspects of software design and implementation.

By way of example, let's consider defense in depth once again. This principle is used in designing a secure network infrastructure, a bank vault, a military compound, and all kinds of other things. In this book we'll naturally be concentrating on how it applies to designing, implementing, and deploying an application. But remember that a good architectural principle should be broadly applicable.

Returning to our discussion of the SYN flood attacks, we feel that, at a minimum, the following architectural principles were violated (or at least not sufficiently followed) in the TCP stack design:

• Design with the enemy in mind

• Build in appropriate levels of fault tolerance

• Degrade gracefully

• Self-limit program consumption of resources

We'll discuss each of these in more detail in Chapter 3 when we talk about the specific design flaws of the TCP stack, but our point here is that adherence to each of these principles would have—or at least could have—resulted in a very different design (and thus implementation) of the TCP stack.

Most technologists probably consider our architectural principles to be just plain common sense. They're right and they're wrong. While these principles do represent sound security practices, they're far too often overlooked—or implemented as an afterthought—in designing software that should be secure.

Our final message here is that we feel that software security should be so ingrained in an application and its surrounding architecture that it becomes a business enabler. By starting with the architectural principles that we've presented here, businesses should be able to enable practices and processes with confidence that they would otherwise run screaming from. Imagine a commercial enterprise that enables its employees, contractors, and temporary employees to sit down at any workstation in the company and get to their files and do productive work, just as if they were logged into their own workstations—and to do it anywhere, whether at home or at a mall kiosk. Imagine the cost savings that they could gain from that.

The key enabling technology to this dream can and must be security, from the applications to the infrastructure. This will never occur without broad and consistent application of the principles presented in this chapter.

Questions If the software you design is "secure," but is compromised because of a flaw in the operating system it runs on, whose fault is it? What is the longest program you think you could write without including a security design error? How many of the working programmers you know are familiar with most of the principles outlined in this chapter? Do you believe that one of today's popular programming languages is easier to write secure programs in than another? What does that say about the role of security architecture and design?