Introduction

"Security" is generally perceived to be a complex, mind-numbing discipline.  A "pattern" is a term that most people believe they have an intuitive understanding of, because it is a natural part of human education to recognize and generalize about perceived patterns.  For the purposes of this exercise we will take the following as working definitions:

Security is "The condition of a system that results from the establishment and maintenance of measures to protect the system."  [1]

"A pattern is the abstraction from a concrete form which keeps recurring in specific non-arbitrary contexts." [2]

So, to attempt to couple the two terms, "security" and "patterns" can introduce some tension.  There have been various attempts to produce security patterns (see appendix A).   This paper has attempted to collect and codify the material that has been gathered over several years by various security practioners from various customer engagements producing a strawman for IBM security patterns. The working definition for "security patterns" in the context of this paper is:

An abstraction of the conditions that result from the establishment and maintenance of recurring measures used to protect the system.

Within the software development community there is currently an effort to establish [3] a methodology for pattern development.

Fundamental to any science or engineering discipline is a common vocabulary for expressing its concepts, and a language for relating them together. The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered throughout all of software development. Patterns help create a shared language for communicating insight and experience about these problems and their solutions. Formally codifying these solutions and their relationships lets us successfully capture the body of knowledge which defines our understanding of good architectures that meet the needs of their users. Forming a common pattern language for conveying the structures and mechanisms of our architectures allows us to intelligibly reason about them. The primary focus is not so much on technology as it is on creating a culture to document and support sound engineering architecture and design. [4]

The fundamental point of confusion, is that patterns, like beauty, seem to be in the eye of the beholder. So, if you get any 5 security people together, they will define patterns specific to their area of interest.

It is for this reason, that I digress into a discussion of "roles" to help group patterns by the community of interest. 

Who's on First?

Within the world of software, there are people who design things, people who draw pictures and write documents, people who write code, and people who pull all the pieces together and provide computer based systems.

Each organization probably has its own way of defining the tasks, but there are archetypal roles.

An archetype is an idealized model of a person, object or concept from which similar instances are derived, copied, patterned or emulated. In psychology, an archetype is a model of a person, personality or behaviour. [5]

In any medium to large organization, tasks are assigned to different people based on their organizational responsibilities.  In general, business analysts and business applications need to protect the informational assets of the business. They drive the creation of the business application requirements for security.

Archetype 1 - Business Analyst

In organizations that have to comply with legislative or regulatory requirements there is sometimes a specific set of tasks at the "C" level to monitor and enforce these regulations.  The CSO and CPO generally work with business analysts to compile a set of corporate guidelines and requirements - the fundamentals of good business practice.

Archetype 2 - Chief Security (Privacy) Officer

Most organizations of any size today have a firewall. Even individual users in their homes establish firewalls for their home networks. Someone has to setup and maintain these devices. Some are simple, some are complex.

Archetype 3 - Network Security Officer

When it  comes to actually understanding and selecting some kind of security mechanisms to meet the requirements specified by the business, there are many people that work together to implement security.  

Archteype 4 -  Security Architect

TBD: Security Developer, Security Deployer, Security Policy Author, Security Policy Administrator, Security System Adminstrator

Looking at patterns by Role

It is the intent of this paper and the accompanying slide deck, to provide a strawman for identifying and illustrating existing common security patterns within the IBM customer- business analyst community.  The task of the e-business patterns effort is  the reconciliation of the volume of information into an abstraction that is general enough to be grasped by the non-security practitioner and yet maintains enough context to provide a concrete underpinning to the security community.

IBM is a microcosm of the larger software industry in that it represents both product development and business application service development, as well as middleware products for management and deployment of applications. 

There are several methodologies for designing and developing secure applications (i.e MASS, Open Group, JAAS) but several of these are targetted to the trained security professional with a detailed understanding of technology. So, one group of patterns will be "security architectural patterns". Detailed architectures for security are needed for developing the technology to provide security solutions and these are referenced by the patterns where appropriate but it is not the intent of this paper to document all the security architectural patterns.

What is security?

The IETF is an organization that has been fundamental to the development of the internet as we know it today. The IETF established a security glossary in 2000, and this captures most if the fundamental concepts of computer security. Improvements are made, new technologies and mechanisms come in and out of use, but the basic definitions remain.

The most common components that are in practice today for security include the following:  identification and authentication, authorization, assurance, audit, message protection, confidentiality, integrity.  Rather than only providing patterns for each individual security mechanism, this strawman has looked across the individual security mechanisms to identify the common characteristics.  This white paper focuses on the identification of a "security solution pattern".  These common elements were derived from looking at a detailed set of individual pattern elements for each security mechanism (i.e, authentication---- username, password, Kerberos, PKI) and then abstracting those things that were in common across authentication, authorization, assurance, etc.

Looking for common elements in all security patterns  resulted in the identification of the 3 sub-pattern elements that are present in some form in any type of security solution:

1. there has to be a point within the software where the security mechanism is called (i.e. a "control point")
2. there is typically some type of meta-information that is important to the execution of #1 and  this is called "system trust and access properties"
3. there is some task which relates to the initialization and ongoing maintenance of the security mechanism and these are called "security management/workflow tasks".

To demonstrate how each individual security mechanism can be mapped to these 3 sub-elements we give an example of "identification".  Again, from the IETF glossary:

identification  -  (I) An act or process that presents an identifier to a system so that the system can recognize a system entity and distinguish it from other entities. (See: authentication.) 

Distinguishing one person from another when invoking an application is a pattern that every business confronts. The strategies for addressing the business problem vary based on the number and diversity of the elements involved in the application and its deployment environment.  Some businesses leave the decision about "naming" to the individual applications or maybe to a group of applications in a line of business.  Some businesses are constrained by the software in their data centers. Some have tightly coupled the application deployment environment to a strict set of mechanisms.  

Nonetheless, there is a point at which an "identifier" is presented to an application, and this is considered to be a "security control point" pattern, for identification.   The quanitity and type of information required also varies significantly.   An identifier can be a real person's name, (i.e.  Maryann Hondo) or a  pseudonym (e.g. mhondo).  The identifier can be globally unique (a UUID) or it can be unique within a qualified namespace ( i.e. mhondo@us.ibm.com) .

Characteristics of a Security Pattern

• Definition of one or more control points (Identity, authentication, authorization, policy enforcement, audit, compliance, message protection)
• Definition of system protection properties (Configuration constraints; trust and access rules)
• Definition of management tasks (Provisioning, registry/repository synchronization, governance, monitoring)

References

1. RFC 2828 Internet Security Glossary May 2000
2. Understanding and Using Patterns in Software Development, Dirk Riehle and Heinz Zullighoven.
3. Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
4. Patterns and Software: Essential Concepts and Terminology, Brad Appleton: http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html#Origins
5. Wikipedia: http://en.wikipedia.org/wiki/Archetype