Security Architecture Principles

I would like to recommend to you some principles for security architecture, how to design security into our enterprises, networks, systems, and applications. First I have to say a little about architecture in general and security architecture in particular.

Architecture is part of design. It is that part of design that deals with:

* appearance, how things look,
* function, what they do,
* location, where things sit relative to other things, and
* materials, what they are built with.
I like to use the analogy of residential architecture because that is what most of us think about when we think architecture. The design describes what the house will look like, what kinds of rooms it will have, where they will sit relative to one another and what materials the house will be built with.

Note that the design of the house includes multiple views and documents, including a model, elevation, or perspective, a floor plan, and a list of materials and their specifications. Note that most of the materials can be specified by reference to existing standards but novel materials have to be described in detail.

Security architecture deals with how security looks to the user, security functions, such as user identification and authentication, and access control, where the functions are located and how they interact, and what components, both off-the-shelf and purpose built, they are built with.

My mentor, Harry DeMaio, likes to say that "security architecture is derivative of and dependent upon IT architecture" but then goes on to point out that if that architecture is not rigorous and well documented then that must be done before the security design can proceed. My own experience is that when I ask management about their IT architecture, they give me a list of components but cannot tell me how they are used or how they fit together, let alone show me where these things are documented. Of course the implication is that much of the design is ad hoc, not to say that it "grew like Topsy." Thus our work often starts with documenting "what is" so that we can refer to it.

We speak of "expressing" the design. Like the design of the house, our design involves multiple views and levels of detail, multiple documents and models. We can think of it as top down, one page at a time, carefully indexed and cross referenced. As the designer of a building or house uses blue-prints (still called that though they are no longer blue) we use network diagrams, stack diagrams, and access path schematics. As the building designer uses pictures, we may use screen shots, as he uses models, we may use working prototypes.

Design is an iterative process that begins with identification and documentation of requirements. Think about the residential architect. He needs to know neighborhood, family size, life style, taste, budget, etc. We need to know industry, business strategy, environment, including natural and man-made hazards, scale, required behavior, forbidden behavior, permissible and impermissble failure modes, applications, risk tolerance, cost to over come resistance, i.e. strength, organization, users, etc. Identifying and expressing security requirements is a topic for another day.


To identify all of these requirements, like the residential architect, we may use our experience, structured interviews, questionnaires, document reviews, and "strawman" documents, sample deliverables that illustrate design options and choices.

For security design these choices may include economy of logon, single point of administration, end-to-end user-to-application encryption, layered networks, limited reliance on operating systems, granular access close to the data, certificate based credentials, failure to logon (rather than to the operating system prompt).

So much for context. Let's get to the principles. First practices, then appearance, function, materials, and, finally one or two ideas on sources.

The most important practice, perhaps the most important design principle is "do it right." Do it right the first time; build for the ages as contrasted to iteratively assess and fix. Design top down by functional decomposition and iterative refinement. Plan to implement by composition from the bottom up. Prefer broad solutions, for example backup, that work across the enterprise, across multiple applications, and that address multiple risks. Prefer end-to-end encryption-based solutions that are independent of the underlying network.

Appearance. Provide a consistent presentation and interface that is predictable, intuitive, and obvious as to intent and effect. Design for ease of safe use, such that doing the right thing is easier than doing the wrong thing. Hide and encapsulate necessary special knowledge such as encryption keys. Using the system safely should require as little user effort and special knowledge as possible. Prefer simplicity, hide complexity. Design around roles and responsibilities so that users see only that which is relevant to what they are supposed to be doing. All other things equal, security should look the same across the enterprise, i.e., across applications, systems, and platforms. Correct behavior learned in one context should not cause errors in another.

Place controls close to the resources, e.g., on the server, but place operation of the control close to the special knowledge required for its safe operation. For example the control for enrolling users should be in the hands of the user's manager while that for granting access to a resource should be in the hands of the owner or manager of the resource. Place control where the effect of its operation can be observed. The operator of a control should be able to observe the effect of its operation. Prefer localized function and data; the fewer things that must operate correctly to produce the safe result the better. Distribute functions and data only as required for reliability, availability, and performance. Separate controls from their use and user. For example, the operating system of a server should be hidden from users of the server.

Include audit trail in your design. An audit trail should enable you to know the current state of the system, how it got that way, and what it looked like in the past. It should enable one to fix accountability for all use, content, and behavior of the system to the level of a single individual

Localize security function. Prefer single services for naming of resources, users, and groups, authenticating users, and controlling access across a domain, e.g. network or organization. Similarly, prefer a single service for encrypting data and managing keys.

Structure and layer networks, for example into public, i.e., peer with the Internet and the PSTN, private, i.e., user and application, trusted, i.e.,trusted-system to trusted-system. and control, i.e., privileged operator to system controls. Isolate the layers from one another using firewalls, proxies, and encryption, e.g., vLANs and VPNs. Prefer short segments and limited to segment-to-segment traffic, i.e., a balance between the two.

Prefer robust materials from trusted sources in tamper-evident packaging. Prefer materials that have been evaluated by third parties against industry or government standards. Prefer single-use to multi-use components. Prefer hardware to software for process-to-process isolation. Prefer virtual-machine to virtual-machine isolation to operating-system-process to operating-system-process isolation. Said another way place more reliance on hyper-visors than operating systems. Prefer industry-standard, public, and mature encryption mechanisms and products, e.g., SSL, SSH, and IPSec; avoid RYI.

Finally, we come back to "do it right." Use the right material for the application. Use materials as they are intended to be used. Do not bend to fit. Do not break interfaces, that is, do not exploit knowledge that you may have about what is behind the interface.

Now, you might think that is a lot to absorb at one time. On the other hand, once enumerated, the principles are pretty straight forward. Many of them you abide by much of the time without thinking about them. For those of us who participate in the design of organizations, networks, applications, or products they can go a long way to earning us the warrant of professional and the big bucks.