2.1 What Is Security Architecture?
Although the concept is somewhat abstract, there are several reasonable definitions. We think of security architecture as a body of high-level design principles and decisions that allow a programmer to say "Yes" with confidence and "No" with certainty.
Let's look at an example. Suppose that you are responsible for your company's main e-commerce application. If you are asked to modify it so that it can be operated on a server outside your firewall by an "application service provider," you could agree?knowing that you won't be compromising security?if your architecture provides for sound and flexible third-party authentication and authorization. If the vice president of operations asks you if thieves could use your application to break through the corporate firewall, you can rule out that possibility if your architecture constrains tightly enough the access granted to your software as it runs.
A security architecture also serves as a framework for secure design, which embodies in microcosm the four classic stages of information security: protect, deter, detect, and react.[3]
[3] Many of the principles described in this chapter were first enunciated formally in J.H. Saltzer's "The Protection of Information in Computer Systems." For our money, that remains the best general paper on the subject. We also cite some ideas from a second attempt at a set of general rules, known as the GASSP (Generally Accepted Security System Principles) project.
There is still another way to look at it. We know many professionals who, if asked for an example of a "security architecture," would produce a set of documents. We have no problem with that definition, either, as we'll describe in the next section.
Whichever way you think of it, one thing is sure. A good security architecture can be applied many times, to many applications. There is no need to "reinvent" the entire framework every time you or someone else starts a new program. Many large well-run development shops we have seen use a sound, well-thought-out architecture as the foundation for all their development. Individual designs are based on it, derive principles and rules from it, and occasionally depart from it.
Finally, we'll point out one thing that security architecture is not. Architecture is different from policy. Your site should certainly have a set of security policies and standards, laying rules about who can have access to what kinds of data, the testing procedures necessary for an application to be certified to run on the network, and so on. Such decisions should be developed in the usual way that policy is formulated for your enterprise, and then used as a guideline for your application architecture.
2.1.1 What's in an Architectural Document?
What should an architectural document include? We can't improve on the following list, adapted from Steve McConnell's excellent Code Complete. He says that an architecture should discuss (or influence) all of the following:
Program organization
Change strategy
Buy versus build decisions
Major data structures
Key algorithms
Major objects
Generic functionality
Error processing (corrective or detective)
Active or passive robustness
Fault tolerance
2.1.2 Doing It Right from the Start
Many times in life, getting off to the right start makes all the difference.
Consider the contrasting styles of the Wright brothers and their French predecessors, the Montgolfiers (see Figure 2-1). The boys from Dayton, Ohio were bicycle mechanics by training. Born engineers. They proceeded so cautiously in their years-long campaign to design the first reliable flying machines that they are widely credited as being the fathers of aeronautical engineering. They invented, for example, the wind tunnel. They were the first to understand and calculate the "lift" yielded by a particular wing design, and they laid the groundwork for the twentieth-century miracle of transatlantic flight.
A century earlier, the Montgolfier brothers electrified crowds (among them the king of France) by sending aloft a rooster in a basket under a big balloon filled with hot air. They had their experiments, too. (And their setbacks?after one landing, farmers beat the balloon to pieces with pitchforks.) But we've heard that the method they preferred for testing new ideas was to push a new design off a cliff, then run down to the beach and inspect the wreckage.
Figure 2-1. The Wright brothers (left) invented novel, precise engineering methods; the Montgolfier brothers (right) preferred "rapid prototyping"
We think many software engineers are Montgolfiers at heart. The "rapid prototyping" approach has a lot to recommend it. But in today's world, your software is likely to have to operate in a very hostile security environment. So we respectfully suggest that it's time for us to put away our roosters and pick up our micrometers.
