This tutorial ws given by Bob Blakley (Chief Scientist, Security and Privacy, IBM
Tivoli Software). The tutorial was open ot all attendees to the Cannes meeting. Its
objective was to explain what design patterns are about and how to use them to design and
validate an information security system matched to a given set of requirements.
This tutorial was specifically valuable as preparation for attendees to the Security
Design Patterns Workshop on the Wednesday afternoon of the Cannes meeting.
The tutorial was attended by 18 people.
Bob Blakley's slide presentation refers.
Bob first explained the history behind why the Security Forum decided to develop Design
Patterns for doing security design. There is a long history of Open Group security
specifications, providing structural guidelines and defining interface definitions in C
language. This approach is no longer addressing the real needs of security system
designers, because most systems already exist, the C language is decreasingly relevant as
the useful way to express interface definitions, and in modern software design the
designers need instructional guidance that is language independent, not prescriptive
definitions written in C. Design patterns are language independent, and adaptable and
scalable to all design problems.
The audience for design patterns is a system designer or architect who has a specific
security problem in a specifc context, who would like to know how the Open Group’s
security experts would approach his (or her) problem but who doesn’t want to come to
our meetings or pay our consulting rates.
Design patterns originated in buildings architecture as created by architect Christopher
Alexander, who realized that in buildings design there are certain well-defined
componments that occur repeatedly and which can be represented in design terms in the same
way. He defined them as design patterns, and re-used them each time they recurred. This
technique maintained accuracy and consistency in design for the common components in his
buildings designs and allowed him more time to devote to the more creative one-off
components in his designs. Thjis approach was adopted by software designers, andbecame
established when the "Gang-of-Four" published their now seminal book on software
design patterns. Since no-one has yet put together a catalog of design patterns
specifically for software designers of security systems, the Open Group's Security Forum
decided to fill this gap.
A good definition for what a design pattern is has challenged many people, but the
generally accepted definition is a namednugget of instructive information that captures
the essential structure and insight of a successful family of proven solutions to a
recurring problem that arises within a certain context and system of forces.
Minimally, a pattern must include the following:
- Pattern name: A memorable and descriptive way to refer to the pattern.
- The problem: A description of the contexts and situations in which the pattern is
useful.
- The solution: A specific but flexible approach to solving the problem.
- Consequences: Implementing the solution described in the pattern will require making
specific tradeoffs among competing forces. These tradeoffs and their consequences are
described.
The process to define a design pattern involves stepwise refinement starting with a
high-level solution and refining it until you have the level of detail you require to
build the system. You build generative sequences of operations, allowing no backtracking ,
making well-identified choices at each step, and choosing which patterns to apply at each
step.
Bob then introduced our security patterns catalog:
- Protected System Catalog
Contains structural design patterns which facilitate construction of systems which protect
valuable resources against unauthorized disclosure or modification.
- Available System Catalog
Contains structural design patterns which facilitate construction of systems which provide
predictable uninterrupted access to the services and resources they offer to users.
The Available System patterns include:
- Recoverable Component
- Checkpointed System
- Cold Standby
- Comparator-Checked Fault-Tolerant System
- Journalled Component
- Hot Standby
- External Storage
- Replicated System
- Error Detection/Correction
and the Protected System patterns include:
- Protected System
- Policy Enforcement Point
- Subject Descriptor
- Secure Communication
- Security Context
- Secure Association
- Policy
- Proxy Patterns
- Trusted Proxy
- Authenticating Impersonator
- Identity-Asserting Impersonator
- Delegate
- Aiuthorizing Proxy
- Login Tunnel
Bob then explained the generative sequence for how to design a protected system (see
the presentation slides):
- identify resources and actors
- define the (one or more) protected system instances
- for each Protected System, define policy (in the example for securing email, anyone may
write but only the recipient may read)
- for each Policy, define the secure communications (between the guard and the recipient
of the email) derive target descriptor requirements from the Ploicy - so need the name of
the recipient
- derive what Security Context you want from the Policy, at each end of the Secure
Communication
- derive Secure Associations and Subject Descriptors for each Security Context
- examine each Security Context to determine whether it needs to be factored into a
Protected System with multiple Security Contexts.
He then applied this generatiuve sequence (see slides) to an example problem of how to
define a system for securing email.
The system illustrated is in fact "hushmail". Bob then explained how this poses
a problem, and what the solution to it is, and how it would appear on the example sequence
of design diagrams. The approach to the problem is to considering factoring protected
systems. You then end up with a system that is in fact like what Lotus Notes uses. This is
the traditional (Orange Book) approach to secure email design.
Mobile computing environments pose particularly interesting scenarios in the context of
the example that Bob used, and he suggested those interested might address this issue in a
separate design exercise.
The objective of this tutorial was achieved - to explain what design patterns are about
and how to use them to design and validate an information security system matched to a
given set of requirements.
In his closing summary, Bob Blakley reminded everyone that the idea behind design
patterns is to introduce a common discipline that is language independent and flexible
within its defined constraints. It is highly scalable but always needs care to ensure you
apply it correctly. The point of this approach is not to try to instantly change people
into design experts, but to help qualified designers to do their work better.
Bob Blakley invited attendees to consider the problem that the Security Forum would
address in a Design Patterns Workshop on the Wednesday afternoon of the Cannes meeting -
to apply our existing set of security design patterns to a Digital Rights Management test
scenario to verify that our existing set of patterns are sufficient to solve the problem.
More generally, Bob noted that mobile computing environments pose particularly
interesting scenarios in the context of the secuer email example that he used in this
tutorial, and he suggested those interested might address this issue in a separate design
exercise.
