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.
 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.