A SECURITY DESIGN PATTERN TAXONOMY

BASED ON ATTACK PATTERNS

Findings of a Systematic Literature Review

Andreas Wiesauer and Johannes Sametinger

Department of Business Informatics - Software Engineering, Johannes Kepler University of Linz

Altenbergerstrasse 69, Linz, Austria

Keywords:

Security design pattern taxonomy, Security design patterns, Attack patterns, Literature review.

Abstract:

Security design patterns are proven solutions to security problems in a given context with constructive mea-

sures of how to design certain parts of a software system. The literature contains numerous deﬁnitions, ex-

amples, and taxonomies of such patterns. There are also a few quality criteria for them. We suggest a new

taxonomy based on attack patterns in order to enhance applicability of security design patterns especially for

non-experts in software security. We further suggest a combined consideration of attack patterns, security

design patterns and test cases for the validation and evaluation of security design patterns.

1 INTRODUCTION

Patterns provide a convenient way for encapsulating

and reusing knowledge. Their purpose is to com-

municate proven solutions in a certain domain. The

use of patterns has emerged from architecture and has

been applied to software engineering by Gamma et

al. (Gamma et al., 1995). Starting with Yoder and

Barcalow, the pattern concept has been transformed

to the ﬁeld of software security (Yoder and Barcalow,

1997). The idea of providing security knowledge as

patterns seems obvious. Numerous security design

patterns have been published over the last years.

The term ”security pattern” is used in various con-

texts. Security patterns may be reﬂected directly in

software. This is also true for patterns known from the

seminal work of (Gamma et al., 1995). In this case,

patterns typically have an impact on the architecture

and the design of software. Other security patterns

deal with administrative means for securing software,

e.g., with ﬁre-walls or with demilitarized zones. The

term security pattern is also used for patterns that in-

ﬂuence activities of software life-cycle phases other

than the design, e.g., blueprints for security require-

ment speciﬁcations or test case deﬁnitions. In this pa-

per we focus on patterns that are reﬂected in software

architecture and design. We use the term ”security

design pattern” for that purpose.

In this paper, we present the results of a systematic

literature review aimed at identifying security design

patterns and classiﬁcation schemes. Further, we sup-

pose a classiﬁcation scheme of security design pat-

terns that is based on attack patterns. The paper is

structured as follows: In Section 2 we introduce de-

sign patterns. Objectives and the methodology of

our approach, a systematic literature review, is pre-

sented in Section 3. Results of the literature review

are discussed in Sections 4, 5 and 6, i.e., security pat-

tern deﬁnitions, quality criteria, and taxonomies, re-

spectively. A new taxonomy that is based on attack

patterns is introduced in Section 7. Conclusions are

drawn in Section 8.

2 DESIGN PATTERNS

Design patterns can be described as a prob-

lem/context/solution triple (Buschmann et al., 2007;

Gamma et al., 1995). ”A design pattern systemati-

cally names, motivates, and explains a general design

that addresses a recurring design problem in object-

oriented systems” (Gamma et al., 1995). Design pat-

terns are abstract ideas that can be illustrated in differ-

ent ways and that can be instantiated in many ways.

They can be illustrated, for example, using class dia-

grams or using role models. Design patterns provide

a common design vocabulary, a documentation and

387

Wiesauer A. and Sametinger J. (2009).

A SECURITY DESIGN PATTERN TAXONOMY BASED ON ATTACK PATTERNS - Findings of a Systematic Literature Review.

In Proceedings of the International Conference on Security and Cryptography, pages 387-394

DOI: 10.5220/0002232503870394

 SciTePress

learning aid, an adjunct to existing methods, and a

target for refactoring.

Gamma et al. ﬁrst proposed a uniform descrip-

tion template which includes the name of the pattern,

its intent and motivation, applicability structure and

other patterns that are related to it (Gamma et al.,

1995). Buschmann et al. have developed an extension

to this template (Buschmann et al., 2007). It includes:

• Name:

a name and a short summary of the pattern

• Also Known As:

other names of the pattern

• Example:

a real world example that demonstrates the pur-

pose and the beneﬁt of the pattern

• Context:

situations in which the pattern may apply

• Problem:

a description of the problem the pattern addresses

including its associated forces

• Solution:

a description of how the problem can be solved

• Variants:

a reference to other patterns that are variants or

specialization of this pattern

• Consequences:

an outline of the beneﬁts and potential tradeoffs

of the pattern

Starting in 1997, design patterns had been used

for security-speciﬁc issues, see (Yoder and Barcalow,

1997). They used a similar description scheme with

a similar understanding of what a design pattern is.

Subsequently, most authors have relied on the tradi-

tional deﬁnition of design patterns as a foundation.

Examples of security design patterns are:

• Secure Pipe Pattern

Prevent eavesdropping and tampering of client

transactions caused by man-in-the-middle attacks

(Steel et al., 2005).

• Secure Logger Pattern

Application events and related data must be se-

curely logged. Log data should be secured from

unauthorized access (Steel et al., 2005).

• Single Access Point Pattern

Systems with external access should have a single

point of access that grants or denies access after

checking a client (Schumacher et al., 2006).

• Checkpointed System Pattern

Design a system in a way that its state can be re-

covered and restored to a known valid state in case

a component fails (Halkidis et al., 2004).

• Limited View Pattern

Users should only see those parts of a system that

they have access to (Yoder and Barcalow, 1997).

Additional patterns can, for example, be found at

www.securitypatterns.org/patterns.html.

3 OBJECTIVES AND

METHODOLOGY

According to Barnum and Sethi, only a minority of

software architects and developers is well educated in

security issues (Barnum and Sethi, 2006). It is doubt-

ful that people with minor security knowledge will be

able to apply security design patterns in a correct, an

effective and an efﬁcient manner. We need pattern

selection criteria that are based on security require-

ments and that are applicable in practical contexts.

This leads us to the following questions:

• How are security design patterns deﬁned?

• Which different kinds of security design patterns

have been proposed and how are they best de-

scribed and documented?

• Which classiﬁcation schemes for security design

patterns exist?

• Have any quality criteria been suggested for eval-

uating security design patterns?

The application of systematic approaches for the

assessment and the aggregation of research outcomes

is needed in order to gain a balanced and objec-

tive summary for a particular research topic (Brere-

ton et al., 2007). Conducting a systematic literature

review is such an approach. According to Kitchen-

ham (Kitchenham, 2004), systematic literature re-

views aim at ”identifying, evaluating and interpreting

all available research relevant to a particular research

question, or topic area or phenomenon of interest”.

When conducting such a review, research studies that

are analyzed are called primary studies, the analysis

itself is called secondary study. Fig. 1 shows the steps

that make up a systematic literature review. The activ-

ities are grouped in three main phases: planning, con-

ducting the review and reporting. For further details

see (Brereton et al., 2007) and (Kitchenham, 2004).

We have followed these steps and have started

by deﬁning search queries and using various scien-

tiﬁc search engines, e.g., computer.org, acm.org and

springerlink.com. The search has led us to an ample

number of papers as well as books, conference tracks

and web sites. We have identiﬁed many deﬁnitions,

quality criteria and taxonomies. These will be dis-

cussed in Sections 4, 5 and 6, respectively.

SECRYPT 2009 - International Conference on Security and Cryptography

388

Figure 1: Literature review (Brereton et al., 2007).

4 DEFINITIONS

Yoder and Barcalow have been the ﬁrst to apply de-

sign patterns to security issues (Yoder and Barcalow,

1997). They have used a similar description scheme

to Gamma et al. with a similar understanding of de-

sign pattern deﬁnition. Schumacher has deﬁned a se-

curity design pattern as a way of documenting proven

solution to recurring problems in a well-structured

manner (Schumacher, 2002). As patterns are written

by experts, Schumacher emphasizes that they provide

an effective way to learn from experts. This is es-

pecially important in the area of security, since there

are only few software architects and designers that

have experienced knowledge concerning security is-

sues. The deﬁnition of security patterns has been fur-

ther concretized: ”A pattern describes a particular re-

curring security problem that arises in speciﬁc con-

texts, and presents a well-proven generic solution for

it” (Markus Schumacher, 2005). The solution part of

a pattern consists of a set of interacting roles that can

be arranged into multiple concrete design structures.

Additionally, the process to create the mentioned

design structure is considered to be an important part

of the solution. The motivation of using security pat-

terns originates from the facts that patterns codify

knowledge in an understandable way, that the rep-

resentation of patterns is familiar to software devel-

opers and system engineers, and that patterns help

to expand the security focus from low-level imple-

mentation to higher-levelarchitectures (Markus Schu-

macher, 2005). The latter is especially important

since around 50% of all security vulnerabilities arise

from design ﬂaws (McGraw, 2006).

Similarly, Fernandez and Yuan deﬁne security pat-

terns as an aid for designers with little security knowl-

edge (Fernandez and Yuan, 2007). Also, Haﬁz and

Johnson point out the reusability aspect of patterns

(Haﬁz and Johnson, 2006). They use the general

term security pattern rather than security design pat-

tern. However, they state that security patterns inﬂu-

ence software design decisions, suggesting that they

do understand them as security design patterns in our

sense. They also mention the problem of managing

security patterns and diagnose a need for a classiﬁ-

cation or taxonomy. Heyman et al. differ slightly as

they ﬁrst view a pattern as a ”well-known technique

to package domain-independent knowledge and ex-

pertise in a reusable way” (Heyman et al., 2007). In

contrast to other deﬁnitions, they explicitlyaccentuate

domain-independence as a major characteristic of a

security design pattern. The deﬁnition is substantiated

by elements that a pattern should comprise: a descrip-

tion of a scoped problem and a constructive solution.

They further outline that patterns cover different ab-

straction levels and that some patterns are too abstract

to be considered as real patterns, e.g., roles patterns

which suggest to use actors of use cases as a starting

point when deﬁning roles within a role-based access

control system. They also propose a negative deﬁ-

nition of security design patterns: Mere guidelines,

high-level process activities or statements of security

principles cannot be considered as patterns (Heyman

et al., 2007). A pattern deﬁnition should further con-

tain a ”known uses” element, which gives an indica-

tion of whether a pattern is real or not. By applying

their positive and negative deﬁnition they analyzed

220 pattern. Only 55% of these were considered to be

patterns, whereas 35% had been classiﬁed as guide-

lines and 15% as process activities.

Romanosky presents a catalogue of eight secu-

rity design patterns and followsthe deﬁnitions already

discussed (Romanosky, 2001). He views security de-

sign patterns as a means for identifying and formu-

lating all security practices needed in a given envi-

ronment. High-level security requirements should be

transformed into security policies and further into se-

curity procedures. Patterns assist in implementing se-

curity procedures into the software product. Slightly

different, Steel et al. treat security design patterns as

”an abstraction of business problems that address a

variety of security requirements and provide a solu-

tion to the problem” (Steel et al., 2005). This def-

initions express that security design patterns should

be aligned with security requirements. Such patterns

can appear as architectural patterns or as defensive

design strategies that depict how secure code should

be written according to a given design. Kienzle et

al. have presented a security pattern repository and

distinguish between structural patterns and procedu-

ral patterns (Kienzle et al., 2002). Structural patterns

can be implemented in an application in the sense of

security design patterns, but they can be applied at the

architectural as well as at the implementation level.

Procedural patterns aim at improving the process of

developing security-critical software.

Yoshioka et al. have a broader understanding

of security patterns (Yoshioka et al., 2008). They

have carried out a survey on security patterns and

A SECURITY DESIGN PATTERN TAXONOMY BASED ON ATTACK PATTERNS - Findings of a Systematic

Literature Review

389

have classiﬁed their results by the software life-cycle

phases. They present patterns for the requirements

phase, the design and implementation phase, the test-

ing phase, etc. For example, a security needs pattern

in the requirements phase helps to identify assets of

a system and information in a system that has to be

considered as an asset. Yoshioka et al. do not only

classify procedural aspects as patterns, e.g., guide-

lines for carrying out a certain activity, but also secure

programming guidelines or refactoring measures, i.e.,

patterns in the implementation phase.

Horvathand D¨orges criticize the usefulness of pat-

terns in the security area (Horvath and D¨orges, 2008).

They outline that the concept of patterns has two ma-

jor shortcoming in the area of security. On the one

hand, patterns are only informal descriptions of what

to do. On the other hand, patterns are often not suit-

able to describe complex architectures. This is impor-

tant, because security has to be applied to the whole

system. In their opinion, patterns cannot fulﬁll their

expectations. They therefore suggest the application

of more formal approaches like Petri nets.

We can summarize that there are differing deﬁ-

nitions of the term security patterns. The focus of

such patterns is set quite differently, i.e., procedural

vs. structural and depending on the software life-

cycle phase. The term security design pattern gives

the most unanimous view of how a pattern is deﬁned.

The main beneﬁt of a security design pattern is also

seen uniformly as a mean for documenting knowledge

and transforming experience to people with little se-

curity knowledge. This beneﬁt is scrutinized by some

authors because they see a lack on useful classiﬁca-

tions and taxonomiesas well as formalisms of the pat-

terns. Also there is a difﬁculty of pattern application

when being confronted with complex architectures.

We use the term security design pattern for proven

solutions to security problems in a given context.

These solutions have to contain constructivemeasures

of how to design certain parts of a software system,

i.e., security design patterns have to be directly re-

ﬂected in the software design.

In contrast to the deﬁnitions, the scientiﬁc com-

munity mainly has a uniform opinion on how secu-

rity patterns should be described and documented.

Most authors stuck to the template proposed by

(Buschmann et al., 2007) with only minor modiﬁca-

tions, see (Fernandez and Pan, 2001; Fernandez et al.,

2008; Kienzle and Elder, 2001; Romanosky, 2001;

Schumacher et al., 2006; Yoder and Barcalow, 1997;

Yoshioka et al., 2008). Some authors complement this

template by graphical notations, e.g., UML class or

sequence diagrams, see (Fernandez and Pan, 2001;

Steel et al., 2005). A strategy item has additionally

been added to the description template by (Steel et al.,

2005). The strategy outlines different possibilities to

implement and deploy a security pattern.

5 QUALITY CRITERIA

A pattern is a means to encapsulate knowledge about

proven solutions and transfer (externalize) the exper-

tise to others with less knowledge. Security design

patterns should help to mitigate security risks by ap-

plying them to software designs. Therefore, a top-

level quality aspect is whether a security design pat-

tern actually helps to mitigate the risks, i.e., whether

it effectively does what it pretends to do. A sec-

ond quality aspect is whether a pattern indeed accom-

plishes the transfer of knowledge, i.e., whether it is

documented precisely enough to be used in a practi-

cal context. Heyman et al. have carried out a study on

the quality of security design patterns (Heyman et al.,

2007). They concludethat patterns at ﬁrst need a clear

and appropriate description.

They have deﬁned quality scores for each descrip-

tion element like problem description, solution, or

consequences: 0 for ”not provided”, 1 for ”minimal”

and 2 for ”satisfactory”. Each description element ad-

ditionally has a certain weighting, e.g., problem de-

scription 19%, consequences 14.5%. For more de-

tails on the weighting see (Heyman et al., 2007). An

overall quality indicator for security design patterns is

obtained by using the quality score and its weighting.

Using this quality indicator, it turned out that between

2001 and 2003 the number of patterns published was

high but the quality was only mediocre. The qual-

ity level has increased in the following years together

with a decline of the number of published patterns.

Halkidis et al. have performed a qualitative eval-

uation on security design patterns by a set of criteria

(Halkidis et al., 2004):

• How well do they conform to the guiding princi-

ples of (Viega and McGraw, 2001)?

• How well do they help to deter a programmer

from building a system that suffers from security

holes like buffer overﬂows?

• How well does a speciﬁc security pattern re-

spond to attacks described in the STRIDE model

(Howard and Lipner, 2006)?

Viega and McGraw have introduced ten guiding

principles for building secure software (Viega and

McGraw, 2001). Examples are principle of least priv-

ilege and the principle of secure fail. The principle

of least privilege states that any operation in a pro-

gram should be carried out with the least privilege

SECRYPT 2009 - International Conference on Security and Cryptography

390

necessary. The principle of secure fail means that a

system should continue to work in secure mode in

case of a failure. For three typical software develop-

ment problems, Halkidis et al. have analyzed whether

patterns help to avoid security holes (Halkidis et al.,

2004). The problems were buffer overﬂows, poor ac-

cess control mechanisms and race conditions. The

STRIDE model groups possible attacks into different

categories. STRIDE is an acronym for Spooﬁng iden-

tity, Tampering with data, Repudiation, Information

disclosure, Denial of service, and Elevation of privi-

leges. Halkidis et al. have analyzed a number of secu-

rity design patterns and used an ordinal scale for their

judgement, e.g., whether a pattern does fulﬁll one of

the guiding principle or whether it negatively affects a

principle. They have further based their judgement on

whether a pattern ”possibly” helps to avoid an attack

like a buffer overﬂow or whether it delivers protection

or ”improved protection” against one of the STRIDE

attacks.

Both approaches can serve as a useful guideline

when selecting security patterns, but they are built

upon a subjective basis. The authors do not state ob-

jective criteria for judging a description element of

a pattern as ”minimal” or ”satisfactory”, or whether

it ”possibly” helps to prevent speciﬁc attacks. Fur-

ther, the weighting of the description elements is only

based on heuristics and seems to be quite arbitrary.

We have not been able to identify studies that pro-

vide objective quality measures or even metrics for

security design patterns.

6 TAXONOMIES

A huge number of security design patterns has been

published. This makes it difﬁcult to select patterns

that are appropriate for a speciﬁc software system.

Additionally, many patterns with similar intent and

similar solution are published under different names

by different authors. Most authors see the need for a

classiﬁcation or a taxonomy of patterns, see for ex-

ample (Schumacher et al., 2006; Haﬁz et al., 2007;

Weiss and Mouratidis, 2008). A classiﬁcation helps

users to navigate through available patterns and also

allows them to recognize similar patterns.

Authors have proposed classiﬁcations based on

different criteria. Haﬁz et al. created an overview

of various approaches. Among others, they were able

to identify the following classiﬁcation criteria (Haﬁz

et al., 2007; Haﬁz and Johnson, 2006):

• Applicability

They differentiate between patterns for protected

systems and patterns for available system. Pat-

terns for protected systems deal with protect-

ing resources against unauthorized use. Patterns

for available systems deal with providing pre-

dictable and uninterrupted access to services and

resources.

• Application Context

”Core security” includes patterns for security

mechanisms within a system. ”Perimeter secu-

rity” includes patterns that deal with authentica-

tion, authorization and security ﬁltering at the sys-

tem’s entry points. ”Exterior security” includes

patterns that concern data transmission and com-

munication protocols.

• Logical tiers

Patterns are classiﬁed according to the logical tier

of a system in which they are used, e.g., in the

user interface layer or in the business logic layer.

• Security concepts

ISO-13335 deﬁnes conﬁdentiality, integrity, avail-

ability and accountability as key concepts of secu-

rity. Patterns can be classiﬁed according to the key

concept that they support.

• Viewpoints and interrogatives

Patterns are classiﬁed according to different view-

points, e.g., business architecture, integration ar-

chitecture or application architecture, and to in-

terrogatives, e.g., purpose (why?), data (what?)

or function (how?). Business architecture covers

business and management perspective of an ap-

plication. Integration architecture deals with the

integration of internal and external systems. The

application architecture includes system and soft-

ware elements.

• STRIDE

Patterns are classiﬁed according to attacks from

the STRIDE model, see Section 5.

The classiﬁcation based on viewpoints and in-

terrogatives originates from the Zachman framework

and was developed by Microsoft (Trowbridge et al.,

2004). Within one of the architectures, one can fur-

ther differentiate between different stakeholders, e.g.,

software designers or implementers. This classiﬁca-

tion does not only comprise security design patterns

in our sense, but also, for example, procedural pat-

terns.

All classiﬁcation schemes have several disadvan-

tages. The security concept based classiﬁcation, for

example, has the major drawback that many patterns

belong to more categories - the classiﬁcation is not

concrete enough (Haﬁz et al., 2007). Classiﬁcation

based on logical tier brings order into the landscape

of pattern, but it does not help in selecting appropri-

ate patterns, since one already has to know where and

A SECURITY DESIGN PATTERN TAXONOMY BASED ON ATTACK PATTERNS - Findings of a Systematic

Literature Review

391

for which purpose a pattern should be applied. The

tabular classiﬁcation based on viewpoints and inter-

rogatives delivers a good overview and allows users

to navigate through different patterns, but it is not

aligned with security requirements.

7 A NEW TAXONOMY BASED ON

ATTACK PATTERNS

An architect or developer should be able to select ap-

propriate patterns in order to fulﬁll security require-

ments given to her. Classiﬁcation based on attacks

of the STRIDE model is a ﬁrst step towards this di-

rection. The overall security requirement is to re-

sist against certain attacks. When planning a secure

system, one should elicit against which attacks the

system has to resist and therefore which security re-

quirements the system has to fulﬁll. Given this set of

possible attacks, architects and developers should be

able to select patterns. We will introduce a taxonomy

based on attack patterns that enables architects and

developers to select appropriate patterns according to

possible attacks.

7.1 Attack Patterns

An attack is an act of carrying out an exploit of a

vulnerability (Barnum and Sethi, 2006). An attack

pattern is a blueprint for creating a kind of an attack

- a ”blueprint for disaster” (Hoglund and McGraw,

2004). The motivation behind using attack patterns

is the same as with security design patterns: If soft-

ware developers have little knowledge in determin-

ing vulnerabilities and possible attacks, attack pat-

terns should encapsulate and transfer this knowledge.

Attack patterns are a means for teaching the software

development community how to exploit software in

reality and to implement adequate ways to avoid at-

tacks (Barnum and Sethi, 2006). Barnum has devel-

oped a description and classiﬁcation schema for at-

tack pattern (Barnum, 2008). This schema includes:

• Name and unique ID of the attack pattern

• Related weaknesses and vulnerabilities

• Methods of attack and attack examples

• Describing and diagnosing information

• Related attack patterns

”Describing information” includes injection vec-

tor and activation zone. An injection vector describes

the format of an input-driven attack and its playload,

see (Hoglund and McGraw, 2004)). The activation

zone is the area within the target where the payload

Figure 2: Attack Pattern Classiﬁcation Tree (excerpt).

gets executed, see (Hoglund and McGraw, 2004) ”Di-

agnosing information” includes techniques to probe a

certain target to determine vulnerabilities and indica-

tors for attacks, i.e., conditions that indicate that an

attack is in progress or has occurred. The schema

additionally includes an element ”related design pat-

terns”, in order to specify design patterns that help to

avoid a successful attack or that may lead to a suc-

cessful attack. Barnum therefore sees a relationship

between attack patterns and design patterns (Barnum,

2008). The MITRE Corporation hosts a website at

capec.mitre.org that provides a publicly available cat-

alog of attack patterns. The website is sponsored by

the U.S. Department of Homeland Security and is

technically assisted by Cigital Inc. The attack pat-

terns in the catalog are documented according to the

scheme described above. Additionally, the website

provides a classiﬁcation tree for attack patterns. It

classiﬁes attack patterns into categories like spooﬁng,

resource depletion or exploitation of authentication.

Figure 2 shows an excerpt of this classiﬁcation tree.

The attack pattern description schema explicitly

includes related security design patterns. However,

only a few attack patterns of the catalog actually men-

tion design patterns.

7.2 Taxonomy

We have decided to align design patterns with attack

patterns of the CAPEC catalog and to suggest a tax-

onomy based on the description of attack patterns and

the purpose and intent of security design patterns.

This taxonomy can be considered as a concretion of

the design pattern classiﬁcation based on the STRIDE

model, since the attack patterns catalog together with

its classiﬁcation tree is a concretion thereof.

The advantage of such a taxonomy is the fact that

users can easily see relevant security design patterns

when identifying speciﬁc attack patterns. It further

helps to identify similar design patterns. Security

SECRYPT 2009 - International Conference on Security and Cryptography

392

design patterns in the same attack pattern category

may be similar or even redundant. Thus, our taxon-

omy will help to rationalize the security design pat-

tern landscape. We will provide a few examples to

emphasize this fact.

The CAPEC catalogue deﬁnes a man-in-the-

middle attack (attack pattern ID 94). This attack aims

at the communication channel between a server and

a client. Attackers try to eavesdrop data transmit-

ted between server and client. The intent of the se-

cure pipe pattern (Steel et al., 2005) and the secure

channel pattern (Schumacher et al., 2006) aim at se-

curing the communication channel between different

entities. Both patterns are similar and help to pre-

vent successful man-in-the-middle attacks. If design-

ers fear a planned system might be susceptible to such

attacks, the suggested taxonomy enables them to se-

lect appropriate patterns easily.

Another example is an SQL injection attack (at-

tack pattern ID 66). This attack targets at software

that creates SQL statements out of unchecked user

input. When user input is not validated carefully, it

may be possible to create user input by appending

SQL command fragments that may cause unexpected

harmfuldatabase queries like modiﬁcation, disclosure

or deletion of data. The interception validator pattern

(Steel et al., 2005) aims at checking and validating

user input and therefore helps to avoid SQL injection

attacks. The client input ﬁlter pattern (Kienzle et al.,

2002) follows the same purpose. Furthermore, attack-

ers performing a dictionary-based password attack try

to guess user passwords by using words in a dictio-

nary (attack pattern ID 16). The account lockout pat-

tern (Kienzle et al., 2002) helps to avoid such attacks

by limiting the number of incorrect login attempts.

Applications must log events and actions in order

to guarantee accountability and non-repudiation and

for forensic purposes. When a target system does not

properly the control the log ﬁle, an attacker might ma-

nipulate or forge it (Log injection-tampering-forging

attack, pattern ID 93). This has an impact on the ac-

countability and non-repudiation of actions and may

lead to incorrect forensic analysis. The secure logger

pattern (Steel et al., 2005) provides instructions for

properly handling logging facilities.

7.3 Validation

In a ﬁrst iteration, we have been able to assign some

40 security design patterns to attack patterns. So far,

our assignments rely on semantic analysis of the at-

tack pattern descriptions and on security design pat-

tern descriptions. We will have to validate the cor-

rectness and usefulness of the classiﬁcation, i.e., to

Security Design Patterns

Attack Patterns

Test Cases

Assignment

Assignment validation

Vulnerability determination

Figure 3: Assignment Validation Triplet.

test whether a security design pattern actually helps

to deter from a successful attack described by an at-

tack pattern. It is also necessary to check whether

non-experts actually will be able to select appropriate

patterns in speciﬁc situations.

We envision an approach for the validation of our

assignments based on test cases, see Fig. 3. For each

attack pattern one or more test cases should be de-

ﬁned. These test cases can be used to check whether

the attack described by the pattern can be executed

successfully on a particular software system. The as-

signment is valid if the application of the security de-

sign pattern prevents such an attack from being per-

formed successfully, or at least increases the resis-

tance of the system against such attacks.

Our goal is to have a list of attack patterns with

correspondingsecurity design patterns with test cases.

8 CONCLUSIONS

We have introduced design patterns and presented an

overview of security design patterns. In the literature,

there are many different security design pattern deﬁ-

nitions and speciﬁcations. Also, different taxonomies

for security design patterns are available. We ar-

gue that these taxonomies are not adequate for non-

experts in order to select patterns in speciﬁc situa-

tions. We have therefore introduced a new taxonomy

that is based on attack patterns.

In the literature, there are several approaches on

how to determine the quality of security design pat-

terns. But there is a lack on sufﬁciently impartial

quality measures. The two most important aspects

in this context are documentation and repeatability.

First, security design patterns have to be documented

precisely enough to let non-experts understand and

apply them. Second, test cases are needed to let non-

expert users ﬁnd out whether the pattern had been ap-

plied correctly, i.e., attacks will indeed be prevented.

In the future, we plan several projects for the as-

signment validation as well as for a security pattern

evaluation based on test cases. These projects addi-

tionally aim on determining whether non-experts are

able to apply security design patterns or further oper-

ationalisation of security knowledge is required.

A SECURITY DESIGN PATTERN TAXONOMY BASED ON ATTACK PATTERNS - Findings of a Systematic

Literature Review

393

REFERENCES

Barnum, S. (2008). Common Attack Pattern Enumera-

tion and Classiﬁcation (CAPEC) Schema Descrip-

tion. Cigital Inc., http://capec.mitre.org/about/ doc-

uments.html.

Barnum, S. and Sethi, A. (2006). Introduction to at-

tack patterns. Technical report, U.S. Dept. of

Homeland Security, https://buildsecurityin.us-

cert.gov/daisy/bsi/articles/knowledge/attack/585-

BSI.html.

Brereton, P., Kitchenham, B. A., Budgen, D., Turner, M.,

and Khalil, M. (2007). Lessons from applying the sys-

tematic literature review process within the software

engineering domain. Journal of Systems and Software,

80(4):571–583.

Buschmann, F., Henney, K., and Schmidt, D. C. (2007).

Pattern-Oriented Software Architecture Volume 4: A

Pattern Language for Distributed Computing. Wiley

& Sons.

Fernandez, E. B., Fonoage, M., VanHilst, M., and Marta, M.

(2008). The secure three-tier architecture pattern. In

Proc. of International Conference on Complex, Intelli-

gent and Software Intensive Systems, pages 555–560,

Los Alamitos, CA, USA. IEEE Computer Society.

Fernandez, E. B. and Pan, R. (2001). A pattern language

for security models. In Proceedings of PLoP 2001

Conference.

Fernandez, E. B. and Yuan, X. (2007). Securing analysis

patterns. In ACM-SE 45: Proceedings of the 45th an-

nual southeast regional conference, pages 288–293,

New York, NY, USA. ACM.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J.

(1995). Design Patterns: Elements of Reusable

Object-Oriented Software. Addison-Wesley.

Haﬁz, M., Adamczyk, P., and Johnson, R. E. (2007). Orga-

nizing security patterns. IEEE Software, 24(4):52–60.

Haﬁz, M. and Johnson, R. E. (2006). Security patterns and

their classiﬁcation schemes.

Halkidis, S. T., Chatzigeorgiou, A., and Stephanides, G.

(2004). A qualitative evaluation of security patterns.

In Proceedings of the 6th International Conference on

Information and Communications Security (ICICS),

pages 132–144, Malaga, Spain. Springer.

Heyman, T., Yskout, K., Scandariato, R., and Joosen, W.

(2007). An analysis of the security patterns landscape.

In SESS ’07: Proceedings of the Third International

Workshop on Software Engineering for Secure Sys-

tems, page 3, Washington, DC, USA. IEEE Computer

Society.

Hoglund, G. and McGraw, G. (2004). Exploiting Software

- How to Break Code. Addison Wesley.

Horvath, V. and D¨orges, T. (2008). From security patterns

to implementation using petri nets. In SESS ’08: Pro-

ceedings of the fourth international workshop on Soft-

ware engineering for secure systems, pages 17–24,

New York, NY, USA. ACM.

Howard, M. and Lipner, S. (2006). The Security Develop-

ment Lifecycle. Microsoft Press.

Kienzle, D. M. and Elder, M. C. (2001). Final

technical report: Security patterns for web

application development. Technical report,

http://www.scrypt.net/˜celer/securitypatterns/ﬁnal

Kienzle, D. M., Elder, M. C., Tyree, D., and

Edwards-Hewitt, J. (2002). Security pat-

terns repository version 1.0. Technical report,

http://www.scrypt.net/˜celer/securitypatterns/ reposi-

tory.pdf.

Kitchenham, B. (2004). Procedures for undertaking sys-

tematic reviews. Technical report, Computer Science

Department, Keele University (TR/SE-0401) and Na-

tional ICT Australia Ltd (0400011T.1).

Markus Schumacher, Eduardo Fernandez-Buglioni, D. H.

F. B. P. S. (2005). Security Patterns. Integrating Se-

curity and Systems Engineering (Wiley Series in Soft-

ware Design Patterns). Wiley & Sons.

McGraw, G. (2006). Software Security: Building Security

In. Addison-Wesley.

Romanosky, S. (2001). Security design patterns. Tech-

nical report, http://www.cgisecurity.com/lib/ security-

DesignPatterns.pdf.

Schumacher, M. (2002). Security patterns. Informatik Spek-

trum, Juni 2002:220–223.

Schumacher, M., Fernandez-Buglioni, E., Hybertson, D.,

Buschmann, F., and Sommerlad, P. (2006). Security

Patterns : Integrating Security and Systems Engineer-

ing (Wiley Software Patterns Series). John Wiley &

Sons.

Steel, C., Nagappan, R., and Lai, R. (2005). Core Security

Patterns: Best Practices and Strategies for J2EE(TM),

Web Services, and Identity Management. Prentice Hall

PTR.

Trowbridge, D., Cunningham, W., Evans, M.,

Brader, L., and Slater, P. (2004). Describ-

ing the Enterprise Architectural Space. Mi-

crosoft, http://msdn.microsoft.com/enus/library/

ms978655.aspx.

Viega, J. and McGraw, G. (2001). Building Secure Soft-

ware: How to Avoid Security Problems the Right Way.

Addison-Wesley Professional.

Weiss, M. and Mouratidis, H. (2008). Selecting security

patterns that fulﬁll security requirements. In IEEE In-

ternational Conference on Requirements Engineering,

pages 169–172. IEEE Computer Society.

Yoder, J. and Barcalow, J. (1997). Architectural patterns

for enabling application security. In Proceedings of

the 4th Conference on Patterns Language of Program-

ming (PLoP’97).

Yoshioka, N., Washizaki, H., and Maruyama, K. (2008). A

survey on security patterns. Progress in Informatics,

(5):35–47.

SECRYPT 2009 - International Conference on Security and Cryptography

394