Seeing and Applying Patterns

A pattern is a common and repeating idiom of solution design and architecture. A

pattern is defined as a solution to a problem in the context of an application.19

Through patterns, unique solutions convert to common patterns that make the task of applying information security to systems much easier. There are common patterns at a gross level (trust/distrust), and there are recurring patterns with more specificity. Learning and then recognizing these patterns as they occur in systems under assessment is a large part of assessing systems for security.

Identifying patterns is a key to understanding system architectures. Understanding an architecture is a prerequisite to assessing that architecture. Remediating the security of an architecture is a practice of applying security architecture patterns to the system patterns found within an architecture. Unique problems generating unique solutions do crop up; one is constantly learning, growing, and maturing one’s security architecture practice. But after a security architect has assessed a few systems, she or he will start to apply security patterns as solutions to architectural patterns.

There are architectural patterns that may be abstracted from specific architectures: [1]

There are literally hundreds of patterns that repeat, architecture to architecture. The above list should be considered as only a small sample.

As one becomes familiar with various patterns, they begin to “pop out,” become obvious. An experienced architect builds solutions from these well-known patterns. Exactly which patterns will become usable is dependent upon available technologies and infrastructure. Typically, if a task may be accomplished through a known or even implemented pattern, it will be more cost-effective than having to build an entirely new technology. Generally, there has to be a strong business and technological motivation to ignore existing capabilities in favor of building new ones.

Like architectural patterns, security solution patterns also repeat at some level of abstraction. The repeatable security solutions are the security architecture “patterns.” For each of the architectural patterns listed above, there are a series of security controls that are often applied to build a defense-in-depth. A security architect may fairly rapidly recognize a typical architecture pattern for which the security solution is understood. To the uninitiated, this may seem mysterious. In actuality, there’s nothing mysterious about it at all. Typical architectural patterns can be generalized such that the security solution set also becomes typical.

As an example, let’s examine a couple of patterns from the list above.

• Web services for third-party integration:

о Bidirectional, mutual authentication of each party о Encryption of the authentication exchange о Encryption of message traffic

о Mutual distrust: Each party should carefully inspect data that are received for anomalous and out-of-range values (input validation) о Network restrictions disallowing all but intended parties

• Message bus as a point of integration:

о Authentication of each automated process to the message bus before allowing further message traffic

о Constraint on message destination such that messages may only flow to intended destinations (ACL)

о Encryption of message traffic over untrusted networks

о In situations where the message bus crosses the network trust boundaries, access to the message bus from less-trusted networks should require some form of access grant process

Hopefully, as may be seen, each of the foregoing patterns (listed) has a fairly well- defined security solution set.[2] When a system architecture is entirely new, of course, the

security assessor will need to understand the architecture in a fairly detailed manner (as we will explain in a later chapter). However, architectural patterns repeat over and over again. The assessment process is more efficient and can be done rapidly when repeating architectural patterns are readily recognized. As you assess systems, hopefully, you will begin to notice the patterns that keep recurring?

As you build your catalog of architectural patterns, so you will build your catalog of security solution patterns. In many organizations, the typical security solution sets become the organization’s standards.

I have seen organizations that have sufficient standards (and sufficient infrastructure to support those standards in an organized and efficient manner) to allow designs that strictly follow the standards to bypass security architecture assessment entirely Even when those standard systems were highly complex, if projects employed the standard architectural patterns to which the appropriate security patterns were applied, then the organization had fairly strong assurance that there was little residual risk inherent in the new or updated system. Hence, the ARA could be skipped. Such behavior is typically a sign of architectural and security maturity. Often (but not always), organizations begin with few or no patterns and little security infrastructure. As time and complexity increase, there is an incentive to be more efficient; every system can’t be deployed as a single, one-off case. Treating every system as unique is inefficient. As complexity increases, so does the need to recognize patterns, to apply known solutions, and to make those known solutions standards that can then be followed.

I caution organizations to avoid attempting to build too many standards before the actual system and security patterns have emerged. As has been noted above, there are classic patterns that certainly can be applied right from the start of any program. However, there is a danger of specifying capabilities that will never be in place and may not even be needed to protect the organization. Any hints of “ivory tower,” or other idealized but unrealistic pronouncements, are likely to be seen as incompetence or, at the very least, misunderstandings. Since the practice of architecture is still craft and relatively relationship based, trust and respect are integral to getting anything accomplished.

When standards reflect reality, they will be observed. But just as importantly, when the standards make architectural and security sense, participants will implicitly understand that a need for an exception to standards will need to be proved, not assumed. Hence, blindly applying industry “standards” or practices without first understanding the complexities of the situation at hand is generally a mistake and will have costly repercussions.

Even in the face of reduced capabilities or constrained resources, if one understands the normal solution to an architectural pattern, a standard solution, or an industry- recognized solution, one can creatively work from that standard. It’s much easier to start with something well understood and work towards an implementable solution, given the capabilities at hand. This is where a sensible risk practice is employed. The architect must do as much as possible and then assess any remaining residual risk.

As we shall see, residual risk must be brought to decision makers so that it can either be accepted or treated. Sometimes, a security architect has to do what he or she can within the limits and constraints given, while making plain the impact that those limits are likely to generate. Even with many standard patterns at hand, in the real world, applying patterns must work hand-in-hand with a risk practice. It has been said that information security is “all about risk.”

In order to recognize patterns—whether architectural or security—one has to have a representation of the architecture. There are many forms of architectural representation. Certainly, an architecture can be described in a specification document through descriptive paragraphs. Even with a well-drawn set of diagrams, the components and flows will typically need to be documented in prose as well as diagramed. That is, details will be described in words, as well. It is possible, with sufficient diagrams and a written explanation, that a security assessment can be performed with little or no interaction. In the author’s experience, however, this is quite rare. Inevitably, the diagram is missing something or the descriptions are misleading or incomplete. As you begin assessing systems, prepare yourself for a fair amount of communication and dialogue. For most of the architects with whom I’ve worked and who I’ve had the privilege to train and mentor, the architectural diagram becomes the representation of choice. Hence, we will spend some time looking at a series of diagrams that are more or less typical. Like Figure 3.3, let’s try to understand what the diagram tells us, as well as from a security perspective, what may be missing.

  • [1] Standard e-commerce Web tiers • Creating a portal to backend application services • Database as the point of integration between disparate functions • Message bus as the point of integration between disparate functions • Integration through proprietary protocol • Web services for third-party integration • Service-oriented architecture (SOA) • Federated authentication [usually Security Assertion Markup Language (SAML)] • Web authentication validation using a session token • Employing a kernel driver to capture or alter system traffic • Model-view-controller (MVC) • Separation of presentation from business logic • JavaBeans for reusable components • Automated process orchestration • And more
  • [2] 2 he security solutions don’t include specific technology; the implementation is undefi ned—lack of specificity is purposive at this level of abstraction. In order to be implemented, theserequirements will have to be designed with specific technologies and particular semantics.
< Prev   CONTENTS   Source   Next >