Security Patterns in Practice E-Book

Eduardo Fernandez-Buglioni

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Serie: Wiley Series in Software Design Patterns
• Sprache: Englisch

Seitenzahl: 729

Veröffentlichungsjahr: 2013

Beschreibung

Learn to combine security theory and code to produce secure systems

Security is clearly a crucial issue to consider during the design and implementation of any distributed software architecture. Security patterns are increasingly being used by developers who take security into serious consideration from the creation of their work. Written by the authority on security patterns, this unique book examines the structure and purpose of security patterns, illustrating their use with the help of detailed implementation advice, numerous code samples, and descriptions in UML.

• Provides an extensive, up-to-date catalog of security patterns
• Shares real-world case studies so you can see when and how to use security patterns in practice
• Details how to incorporate security from the conceptual stage
• Highlights tips on authentication, authorization, role-based access control, firewalls, wireless networks, middleware, VoIP, web services security, and more
• Author is well known and highly respected in the field of security and an expert on security patterns

Security Patterns in Practice shows you how to confidently develop a secure system step by step.

Leseprobe

Contents

Cover

Half Title page

Title page

Copyright page

Dedication

About the Author

About the Foreword Author

Foreword

Preface

Part I: Introduction

Chapter 1: Motivation and Objectives

1.1 Why Do We Need Security Patterns?

1.2 Some Basic Definitions

1.3 The History of Security Patterns

1.4 Industrial Use of Security Patterns

1.5 Other Approaches to Building Secure Systems

Chapter 2: Patterns and Security Patterns

2.1 What is a Security Pattern?

2.2 The Nature of Security Patterns

2.3 Pattern Descriptions and Catalogs

2.4 The Anatomy of a Security Pattern

2.5 Pattern Diagrams

2.6 How Can We Classify Security Patterns?

2.7 Pattern Mining

2.8 Uses for Security Patterns

2.9 How to Evaluate Security Patterns and their Effect on Security

2.10 Threat Modeling and Misuse Patterns

2.11 Fault Tolerance Patterns

Chapter 3: A Secure Systems Development Methodology

3.1 Adding Information to Patterns

3.2 A Lifecyle-Based Methodology

3.3 Using Model-Driven Engineering

Part II: Patterns

Chapter 4: Patterns for Identity Management

4.1 Introduction

4.2 Circle of Trust

4.3 Identity Provider

4.4 Identity Federation

4.5 Liberty Alliance Identity Federation

Chapter 5: Patterns for Authentication

5.1 Introduction

5.2 Authenticator

5.3 Remote Authenticator/Authorizer

5.4 Credential

Chapter 6: Patterns for Access Control

6.1 Introduction

6.2 Authorization

6.3 Role-Based Access Control

6.4 Multilevel Security

6.5 Policy-Based Access Control

6.6 Access Control List

6.7 Capability

6.8 Reified Reference Monitor

6.9 Controlled Access Session

6.10 Session-Based Role-Based Access Control

6.11 Security Logger and Auditor

Chapter 7: Patterns for Secure Process Management

7.1 Introduction

7.2 Secure Process/Thread

7.3 Controlled-Process Creator

7.4 Controlled-Object Factory

7.5 Controlled-Object Monitor

7.6 Protected Entry Points

7.7 Protection Rings

Chapter 8: Patterns for Secure Execution and File Management

8.1 Introduction

8.2 Virtual Address Space Access Control

8.3 Execution Domain

8.4 Controlled Execution Domain

8.5 Virtual Address Space Structure Selection

Chapter 9: Patterns for Secure OS Architecture and Administration

9.1 Introduction

9.2 Modular Operating System Architecture

9.3 Layered Operating System Architecture

9.4 Microkernel Operating System Architecture

9.5 Virtual Machine Operating System Architecture

9.6 Administrator Hierarchy

9.7 File Access Control

Chapter 10: Security Patterns for Networks

10.1 Introduction

10.2 Abstract Virtual Private Network

10.3 IPSec VPN

10.4 TLS Virtual Private Network

10.5 Transport Layer Security

10.6 Abstract IDS

10.7 Signature-Based IDS

10.8 Behavior-Based IDS

Chapter 11: Patterns for Web Services Security

11.1 Introduction

11.2 Application Firewall

11.3 XML Firewall

11.4 XACML Authorization

11.5 XACML Access Control Evaluation

11.6 Web Services Policy Language

11.7 WS-Policy

11.8 WS-Trust

11.9 SAML Assertion

Chapter 12: Patterns for Web Services Cryptography

12.1 Introduction

12.2 Symmetric Encryption

12.3 Asymmetric Encryption

12.4 Digital Signature with Hashing

12.5 XML Encryption

12.6 XML Signature

12.7 WS-Security

Chapter 13: Patterns for Secure Middleware

13.1 Introduction

13.2 Secure Broker

13.3 Secure Pipes and Filters

13.4 Secure Blackboard

13.5 Secure Adapter

13.6 Secure Three-Tier Architecture

13.7 Secure Enterprise Service Bus

13.8 Secure Distributed Publish/Subscribe

13.9 Secure Model-View-Controller

Chapter 14: Misuse Patterns

14.1 Introduction

14.2 Worm

14.3 Denial-of-Service in VoIP

14.4 Spoofing Web Services

Chapter 15: Patterns for Cloud Computing Architecture

15.1 Introduction

15.2 Infrastructure-as-a-Service

15.3 Platform-as-a-Service

15.4 Software-as-a-Service

Part III: Use of the Patterns

Chapter 16: Building Secure Architectures

16.1 Enumerating Threats

16.2 The Analysis Stage

16.3 The Design Stage

16.4 Secure Handling of Legal Cases

16.5 SCADA Systems

16.6 Medical Applications

16.7 Conclusions

Chapter 17: Summary and the Future of Security Patterns

17.1 Summary of Patterns

17.2 Future Research Directions for Security Patterns

17.3 Security Principles

17.4 The Future

Appendix A: Pseudocode for XACML Access Control Evaluation

A.1 Pseudocode for retrieveApplicablePolicy()

A.2 Pseudocode for evaluateApplicablePolicy()

Glossary

References

Index of Patterns

Index

Wiley Series in Software Design Patterns

The WILEY SERIES IN SOFTWARE DESIGN PATTERNS is designed to meet the needs of today’s software architects, developers, programmers and managers interested in design patterns. Frank Buschmann (Series Editor), as well as authors, shepherds and reviewers work collaboratively within the patterns community to strive for high-quality, highly researched, thoroughly validated, classic works, which document accepted and acknowledged design experience. Priority is given to those titles that catalog software patterns and pattern languages with a practical, applied approach in domains such as:

Distributed systems

Real time systems

Databases

Business information systems

Telecommunications

Organizations

Concurrency

Networking

Books in the series will also cover conceptual areas of how to apply patterns, pattern language developments and architectural/component-based approaches to pattern-led software development.

TITLES PUBLISHED

•PATTERN-ORIENTED SOFTWARE ARCHITECTURE, Volume 1

Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad and Michael Stal

•PATTERN-ORENTED SOFTWARE ARCHITECTURE, Volume 2

Douglas Schmidt, Michael Stal, Hans Rohnert and Frank Buschmann

•A PATTERN APPROACH TO INTERACTION DESIGN

Jan Borchers

•SERVER COMPONENT PATTERNS

Markus Völter, Alexander Schmid, Eberhard Wolff

•ARCHITECTING ENTERPRISE SOLUTIONS

Paul Dyson, Andy Longshaw

•PATTERN-ORIENTED SOFTWARE ARCHITECTURE, Volume 3

Michael Kircher, Prashant Jain

•SECURITY PATTERNS

Markus Schumacher, Eduardo B. Fernandez, Duane Hybertson, Frank Buschmann, Peter Sommerlad

•PATTERN-ORIENTED SOFTWARE ARCHITECTURE, Volume 4

Frank Buschmann, Kevlin Henney, Douglas C. Schmidt

•PATTERN-ORIENTED SOFTWARE ARCHITECTURE, Volume 5

Frank Buschmann, Kevlin Henney, Douglas C. Schmidt

•PATTERNS FOR COMPUTER-MEDIATED INTERACTION

Till Schümmer, Stephan Lukosch

•PATTERNS FOR FAULT TOLERANT SOFTWARE

Robert Hanmer

•WHERE CODE AND CONTENT MEET

Andreas Rüping

•PATTERNS FOR PARALLEL SOFTWARE DESIGN

Jorge Luis Ortega-Arjona

•SECURITY PATTERNS IN PRACTICE

Eduardo B. Fernandez

Security Patterns in Practice

This edition first published 2013

© 2013 John Wiley & Sons, Ltd.

Registered office

John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom

For details of our global editorial offices, for customer services and for information about how to apply for permission to reuse the copyright material in this book please see our website at www.wiley.com.

The right of the author to be identified as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act 1988.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners. The publisher is not associated with any product or vendor mentioned in this book. This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold on the understanding that the publisher is not engaged in rendering professional services. If professional advice or other expert assistance is required, the services of a competent professional should be sought.

Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley and Sons, Inc. and/ or its affiliates in the United States and/or other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Ltd. is not associated with any product or vendor mentioned in the book.

Images on pages page 289, 293, 309 and 316, clockwise from top-left, Teneresa/Shutterstock, gitan100/Shutterstock, dedMazay/Shutterstock

A catalogue record for this book is available from the British Library.

ISBN 978-1-119-99894-5 (hardback)978-1-119-97049-1 (ebook)978-1-119-97048-4 (ebook)978-1-119-97057-6 (ebook)

To Minjie, Lian and Anna

Publisher’s Acknowledgements

Some of the people who helped bring this book to market include the following:

Editorial and Production

VP Consumer and Technology Publishing Director: Michelle Leete

Associate Director – Book Content Management: Martin Tribe

Associate Publisher: Chris Webb

Executive Commissioning Editor: Birgit Gruber

Associate Commissioning Editor: Ellie Scott

Project Editor: Steve Rickaby

Shepherd: Markus Schumacher

Editorial Manager: Jodi Jensen

Senior Project Editor: Sara Shlaer

Editorial Assistant: Annie Sullivan

Marketing

Associate Marketing Director: Louise Breinholt

Marketing Manager: Lorna Mein

Senior Marketing Executive: Kate Parrett

Marketing Assistant: Tash Lee

Composition Services, Printed Edition

Steve Rickaby, WordMongers Ltd

About the Author

Eduardo B. Fernandez (aka Eduardo Fernandez-Buglioni) is a professor in the Department of Computer Science and Engineering at the Florida Atlantic University in Boca Raton, Florida. He is now a visiting professor at Universidad Tecnica Federico Santa Maria, Chile, on leave from FAU. Ed has published numerous papers and four books on authorization models, object-oriented analysis and design and security patterns. He has lectured all over the world at both academic and industrial meetings. His current interests include security patterns, web services, cloud computing security and fault tolerance. He holds an MS degree in Electrical Engineering from Purdue University and a PhD in Computer Science from UCLA. Ed is an active consultant for industry, including assignments with IBM, Allied Signal, Motorola, Lucent, and others. His web page is www.cse.fau.edu/~ed.

About the Foreword Author

Markus Schumacher has served as CEO and Co-Founder of Virtual Forge GmbH since 2006. The company specializes in the security of SAP applications. He was previously a representative of the Fraunhofer Institute for Secure Information Technology (SIT) and worked at SAP as Security Product Manager. Focus topics were secure development, security testing, security response, product certification (Common Criteria) as well as awareness events for the development crew. Markus earned his Doctorate in the field of computer science. He has published numerous articles and coauthored a handful of books, including Secure ABAP Programming and Security Patterns – Volume 1, and speaks regularly at international conferences.

Foreword

Security is simple. We use a little bit of cryptography, add some firewalls and passwords – done! In theory…

When I started work in the field of security in the mid 1990s, I met many people who thought they could easily secure their applications. They used certain ingredients of security measures and applied them to whatever problem they had. Even worse: sometimes they didn’t use existing ingredients, but build their own – making the same errors made in hundreds of previous projects. And practice proved them wrong: security was never simple – there’s always at least one loophole. There’s always an unexpected side-effect. There’s always something that you miss if you are not an expert. Front page news regularly proves that we obviously never learn.

Key reasons for insecure applications are:

Lack of time, due to aggressive deadlines and tight budgets

Lack of knowledge – IT experts are usually not security experts

Lack of priorities – functionality and performance usually come top

That’s why we are literally doomed to failure. Hackers have an easy job entering a system, stealing or changing data and leaving without a trace. Sometimes the victim doesn’t even know that something really bad happened until his new designs are somehow copied by a competitor, or supposedly protected customer data is published on public web sites. Or a journalist gets a hint of a fantastic new story. Even worse, modern applications are becoming more and more complex – think of recent trends like mobility and cloud computing. Borders disappear and the means of protecting known areas is difficult.

In traditional engineering we have hundreds of years of knowledge that has evolved over time. We know how to build bridges that survive rain, wind and earthquakes. We know how to build solid cars that give you a good chance of surviving a crash. We know of proven solutions to problems in specific contexts. Written down, these are called a patterns, paradigms that have also been applied to software engineering for quite some time. Towards the end of the 1990s we saw work on patterns that were dedicated to security problems. The pattern community came together and collected the work in progress, resulting in one of the first comprehensive security pattern collections, which captured security expertise for getting it done the right way.

It was obvious that the work was not completed by the publication of a few books. Besides mining additional knowledge and writing more patterns, an interesting question is how to apply them effectively. Both of these issues are answered with this new book from Eduardo Fernandez, a pioneer of computer science and security patterns. He has continued the work that we started ten years ago, and I’m honored that I could be his sparring partner while he wrote it.

The result is the most up-to-date guide for software engineers who want to understand how to build reliable applications. It provides guidance for applying the captured expertise of security pattern in your day-to-day work. Security is still not easy, but it is much easier when you understand the benefits, liabilities and dependencies of specific solutions.

Markus SchumacherHeidelberg, Germany, March 2013

Preface

El que lee mucho y anda mucho, ve mucho y sabe mucho.

(The one who reads a lot and goes around a lot, sees much and knows much.)

Miguel de Cervantes, El ingenioso hidalgo don Quijote de la Mancha

I started working on security when I joined IBM, where I worked for almost nine years doing security research. I coauthored a book on database security while there, one of the first to appear on this topic. I later realized that a large amount of security knowledge was wasted, because practitioners had not read the variety of books and papers that had started to appear; they kept repeating the same mistakes. In particular, software developers knew little about security. Later I participated in a conference about patterns and realized that expressing security knowledge as patterns could be an effective way to spread this knowledge. Around that time, Yoder and Barcalow [Yod97] published a paper about expressing security solutions as patterns that further convinced me that this was a good direction. I found later that security patterns could do more than propagate security knowledge to inexperienced developers; they could also be useful for security experts, to help them apply security in a systematic way to build new applications or products, understand complex standards, audit complex applications and reengineer legacy systems. I was coauthor of a book that published most of the security patterns known up to 2005. However, since that book was published, many more patterns have appeared.

I have written over 80 patterns, most of which are shown in this book. Other authors have presented patterns which complement ours (see Chapter 1). I have listed most of them in the See Also sections of each pattern. Note that they may use a different notation or pattern form to ours.

I did not try to be exhaustive, and I may have left out some useful patterns. I hope to include those discovered later, or that appear later, on the book’s web page at http://www.wiley.com/go/securitypatterns or in a new edition of this book. Patterns can be improved after one uses them or understands them better. Some of these patterns were written as long as 15 years ago, while others are still under development. When I looked at the older patterns, I realized that I could write them better now, which delayed the completion of this book. It is not a second volume or a continuation of our 2006 book [Sch06b], but it reflects my own views and my own work. Some of my patterns from the earlier book are included here for completeness; my intention is to eventually produce a complete catalog, although I am not there yet. Other authors have also produced some good patterns, and altogether there is a good quantity of patterns that developers and researchers can use. My audience is mostly made up from software developers who are trying to incorporate security in their work. However, there is material here for researchers and computer science students, as well as for anybody interested in systems security.

A difficult point was to unify the style of patterns produced over a long time span. All the patterns presented here have either been discussed at a pattern conference or presented at a research conference. However, I have reworked all of them for this book, some extensively. I also participated very actively in the original versions, having usually provided the initial ideas, read every line of them and improved their contents. In other words, I am really a full author of this book, not just an editor of past works or a presenter of my students’ work.

Patterns alone are not enough: the final objective is to build secure systems. For that purpose, I have been working on a methodology for building secure systems using patterns, of which several examples are shown here. The approach I use is strictly an engineering one. This does not mean avoidance of theory, but I use it only when necessary. It does not mean code either: although I give some code examples, I use mostly models. To handle the complexity of current systems, we need the abstraction power of models. An important value of patterns is that they lead to systems thinking. A system is more than the sum of its parts; looking at isolated code and hardware components is a microscopic view that cannot lead to secure systems.

Patterns can be described from single page ideas to 30-page detailed descriptions. I have chosen an intermediate level, where I give enough detail for a user to understand the meaning of the pattern and evaluate its possibilities. I have found this level of detail the most useful in my work. I have resisted the temptation of adding background material on security: several good textbooks exist (see Chapter 1).

Because I work in a university, I have been accused a few times of not being ‘practical enough’. I did work in industry for about ten years, and I occasionally do consulting for companies, so I do have some industrial experience. Some of my students have also provided an important industrial perspective, since many of them were working in local industry when we wrote these patterns. In some respect, this is an interdisciplinary book, in that it connects security to software architecture.

I would greatly appreciate comments or corrections. These patterns encompass all areas of computer systems architecture, and I am sure I may have misunderstood some aspects. I am also particularly interested to hear of any interesting use of security patterns in industrial projects. Write to me at [email protected]. Markus Schumacher and I will publish comments on patterns at securitypatterns.org.

Book Structure

The book is divided into three parts. The first three chapters describe motivation, experience in using patterns, the objectives of the book, and present my secure development methodology. Part II is a pattern catalog, including patterns for different architectural levels of a computer system. Part III shows some examples of application of the patterns, has tables of patterns, and indicates possible research directions.

Acknowledgements

This work is the result of my work on security over many years, attending security and patterns conferences, listening and talking to many colleagues around the world, all of whom contributed to this work. More specifically, my students, in particular Nelly Delessy, Keiko Hashizume, Ola Ajaj, Juan C. Pelaez and Ajoy Kumar, wrote several versions of these patterns. My colleagues Maria M. Larrondo-Petrie and Mike Van Hilst collaborated in some of the published patterns. My international collaborators included Nobukazu Yoshioka and Hironori Washizaki (Japan), Günther Pernul (Germany), David LaRed (Argentina), Anton Uzunov (Australia), Fabricio Braz (Brazil), Jaime Muñoz Arteaga (Mexico) and Antonio Maña (Spain).

The shepherds and workshop participants in the Pattern Languages conferences (PLoP, EuroPLoP, Asian PLoP and Latin American PLoP) gave valuable comments, in particular Joe Yoder, Fabio Kon, Richard Gabriel, Rosana Braga, Ralph Johnson, Lior Schachter, and others. Craig Heath commented on the first three chapters.

The editorial staff of Wiley UK – Ellie Scott, Birgit Gruber and Sara Shlaer – and Steve Rickaby of WordMongers, were very helpful and encouraging. Markus Schumacher was an ideal shepherd, in that he caught important errors or missing aspects. My thanks to all of them.

Part I

Introduction

CHAPTER 1

Motivation and Objectives

We will bankrupt ourselves in the vain search for absolute security.

Dwight D Eisenhower

1.1 Why Do We Need Security Patterns?

Most modern applications are distributed and connected by some type of network – often the Internet, but also LANs and other specialized network types. Their platforms may support web interfaces, web services and even agents. The complexity of such systems makes them hard to understand, design and maintain. This complexity also brings vulnerabilities which, when coupled with the fact that these applications may handle valuable information, attract security attacks. The increasing use of mobile devices with improved capabilities and the growing use of sensors make this problem even more acute. Every day the press reports attacks on web sites or databases around the world, which result in millions of dollars of direct or indirect losses. Systems are constantly attacked and often breached. There is also the fear that a hostile adversary may try to disrupt the infrastructure systems of an entire country.

Why do we fail to secure such systems? One important reason is their complexity, which makes errors common and vulnerabilities hard to find. Another important reason is that security is built piecemeal: parts of a system are secured using specific products, but there is rarely a global analysis of the complete system. If done, different models may be used in different parts, for example one for the databases and another for wireless devices. Regrettably, security requires a comprehensive approach if it is to block all possible means of attack. Very secure components cannot make the whole system secure if they do not protect all parts of the system and do not work in a coordinated way. Threat analysis is done locally, but many threats only emerge when different units are interconnected. Further, methodologies for building secure systems focus mostly on new systems, but the majority of the systems in use are legacy systems, often in a state of constant maintenance. Even systems that have been built carefully can suffer from architecture erosion, in which changes made, once in production, can invalidate or weaken security defenses.

We need a way to handle the complexity of new systems and make them secure in a systematic and holistic way. We need a way to reengineer legacy systems to make them more secure, by tracing back code changes so that their impact on security mechanisms can be detected and corrected. Software developers know a particular language and its environment well; however, they may not know much about security, and their systems exhibit many vulnerabilities which can be easily exploited by attackers. They are also under pressure to produce results quickly.

Secure systems need to be built in a systematic way in which security is an integral part of the software lifecycle [Fer04b][How06][McG06]: the same applies to reliability and other quality factors. If when we build applications we also consider the effect of middleware, operating systems and networks as a whole, we can build systems that can withstand a whole spectrum of attacks from external or internal users. We believe that to build secure applications, it is not effective to build a secure platform and then run some application made secure in isolation on it, but rather that the application and its platform should be designed together and the platform match the type of application. In addition, all security and reliability constraints should be defined at the application level, where their semantics are understood and propagated to lower architectural levels [Fer99b] [Fer06b] [Sum97].

Lower levels provide the assurance that the constraints are being followed; that is, they enforce an absence of ways to bypass these constraints. The only way to provide this unification in the presence of myriad implementation details of the component units is to use abstraction. In particular, we can apply abstraction through the use of patterns. Patterns are encapsulated solutions to recurrent system problems and define a way to express requirements and solutions concisely, as well as providing a communication vocabulary for designers [Bus96] [Gam94]. The description of architectures using patterns makes them easier to understand, provides guidelines for design and analysis, and can define a way of making their structure more secure. Security patterns allow application developers to use security measures without being experts on security. We can also use patterns to evaluate existing systems by examining them to see if they contain the required patterns. Further, we can reengineer legacy systems by using patterns to add missing security features. (I compare the use of patterns to other approaches to producing secure systems below.)

We need to unify the total architecture of the network along horizontal and vertical partitions to apply a holistic approach – specifically, along the system development lifecycle and along its architectural levels [Fer11a]. This book presents a complete pattern-based methodology for building secure systems, covering pure information systems as well as embedded systems. I proposed its main ideas in [Fer06b] and am still refining and extending it. A far-reaching objective is to establish the fact that patterns offer a robust way to build security and reliability into systems. Neumann calls for the need to have ‘principled’ systems, based on solid conceptual approaches [Neu04]: patterns allow the implicit application of principles. I have done a substantial amount of work in this direction, but further work is still needed to consolidate and extend this. The use of security patterns and other approaches to building secure systems is surveyed in [Uzu 12c].

To design a secure system, we first need to understand the possible threats to the system. We have proposed an approach for identifying threats by considering the activities in each use case [Bra08a] [Fer06c]. Such an approach finds threats – as goals of an attacker – that are realized through the lower levels of a system. We need to understand how the specific components of the architecture are compromised, or used by an attacker, to fulfill their objectives. We use the concept of misuse (attack) patterns to model how a misuse is performed [Fer07a].

There is a need for ways to define and enforce standards and regulations; our proposed pattern-based approach can be valuable for that purpose. In fact, some standards – for example HIPAA, FEMA and Sarbanes-Oxley – and regulations are very complex, or even ambiguous; patterns can describe them in a precise way and make them more understandable and usable. Web services and cloud computing have brought about a need for certification of services; patterns could be a good way to achieve this [Dam09].

When we talk about modeling, we do not mean yet another authorization model, but rather a model of the integration of security controls for a variety of devices and units in a computer system, fundamental when dealing with complex systems. We can get a measure of completeness by adding patterns to cover all the threats identified in each layer and approach the holistic ideal required to secure systems. We think this is also a good approach to defend against a possible cyber war. Patterns do not provide provable security, but they are a good practical approach to apply to increasingly complex systems.

1.2 Some Basic Definitions

Before we start, we need to define a few basic terms. Security is the protection against:

Unauthorized data disclosure (confidentiality or secrecy).

Unauthorized data modification (integrity). Unauthorized modification of data may result in inconsistencies or erroneous data. Data destruction may bring all kinds of losses.

Denial of service: users or other systems may prevent the legitimate users from using their system. Denial of service is an attack on the availability of the system.

Lack of accountability: Users should be responsible for their actions and should not be able to deny what they have done (non-repudiation).

The definition of security above describes security as defense against some types of attacks. The generic types of defenses (also known as countermeasures) that we can use include:

Identification and authentication (I&A). Identification implies a user or system providing an identity to access a system. Authentication implies providing some proof that a user or system is who or what they claim to be. The result of authentication may be a set of credentials, which later can be used to prove identity and may describe some attributes of the authenticated entity. Patterns for identity management and patterns for authentication are described in Chapter 4 and Chapter 5 respectively.

Authorization and access control (A & A). Authorization defines permitted access to resources depending on the accessor (user, executing process), the resource being accessed and the intended use of the resource. Access control is the use of some mechanism to enforce authorization. Chapter 6 describes patterns for access control.

Logging and auditing. These functions imply keeping a record (log) of actions that may be relevant for security and analyzing it later. They can be used to collect evidence for prosecution (forensics) and to improve the system by analyzing why an attack succeeded. Logging and auditing is also described in Chapter 6.

Hiding of information. Information hiding is usually performed by the use of cryptography, but steganography is another option (see Chapter 12). The idea is to hide information to protect it.

Intrusion detection. Intrusion Detection Systems (IDS) alert the system in real time when an intruder is trying to attack it. Chapter 10 discusses patterns for networks.

My objective in this book is the construction of complex applications. These include medical systems, financial applications, legal applications, operating systems and others. Such applications are typically implemented with systems that are subject to non-functional requirements such as reliability or fault tolerance. Often they are composed of a variety of software and/or hardware units, some built ad hoc and some bought or outsourced. In such systems the security of the application software itself cannot be separated from the security of the rest of the system.

Another common aspect of such systems is that they frequently must comply with regulatory standards. Systems may include several databases, and usually have Internet access as well as distributed and wireless access. Data is typically accessed using a web application server (WAS) that integrates web and database applications and uses a global enterprise model, usually implemented using components such as J2EE or .NET, applications that are of fundamental value to enterprises and institutions of any type. A systematic approach is required towards building these applications such that they can reach the appropriate level of security. We focus on these applications because they define worst-case scenarios for the application of our patterns methodology.

Security was first studied from a systems viewpoint [Sum97], and standards appeared for evaluating security [cc] [DoD83]. The emphasis then moved to software; numerous papers indicated its importance and gave the impression that software security was the only objective we need to fulfill to produce secure systems [How03]; there is now a considerable effort to improve the security of code [De W09]. However, things are not so simple: the whole system must be secure, including its hardware and the way the whole system is configured. We need a global and holistic view if we want to produce secure systems. Typical textbooks, for example [Gol06] [Sta 12], are very good for discussions of specific topics, but they don’t provide a global view. Most research papers study specific mechanisms but rarely look at the complete system. Much work as also been done on stochastic system views of security [Nic04], but while this is an interesting direction for evaluating global aspects of systems, it does not provide constructive solutions for systems security.

In this book we take a systems view of security, for which software architecture is an important basis [Bus07] [Tay10]. Software architecture provides a global view of systems, but until now most studies have not considered the early lifecycle stages or said much about security [Fer12a]; however, the software architecture viewpoint is very important. To apply any methodology, we need a good catalog of patterns: providing that is one of the main objectives of this book.

A related aspect is that of how to apply these patterns through some systematic methodology. We have applied the patterns described here throughout a secure system development methodology based on a hierarchical architecture whose layers define the scope of each security mechanism [Fer04b] [Fer06b]. We discuss this approach in Chapter 3.

1.3 The History of Security Patterns

Yoder and Barcalow wrote the first paper on security patterns [Yod97]. They included a variety of patterns useful in different aspects of security. Before them, at least three papers [Fer93a] [Fer94a] [Ess97] had shown object-oriented models of secure systems without calling them ‘patterns’, or using one of the standard pattern templates. In 1998, two more patterns appeared: a pattern for cryptography [Bra00] and a pattern for access control [Das98]. After that, several others appeared, and we have now three books on the subject [Bla04] [Sch06b] [Ste05], one of which [Sch06b] was the first to try to categorize and unify a variety of security patterns. Many papers have also appeared, some of which are surveyed here.

Security patterns are now accepted by many companies, Microsoft [msd], Sun [jav] and IBM [IBMb] have papers and web pages on this subject. A general web page for security patterns also exists [sec]. Pattern catalogs include [Ste05][Kie02][Bla04][Dou09], [Sch06b][Ysk06][Haf11]1. Some surveys of security patterns include [Fer06a][Yos08] [Uzu 12a]. This book extends the ideas of [Sch06b] and adds many new patterns, as well as a methodology for building secure systems.

1.4 Industrial Use of Security Patterns

Most developers don’t use models, they just code. However, this situation is slowly changing and design patterns have been successfully applied in many industrial projects, for example [Bec96] [Sch95]. Several major companies now maintain patterns web pages and have published books about them.

Until now, security patterns have not been used as much as design patterns, but some interesting applications exist, such as qmail [Haf08] and BBVA [Mor12]. [ElK09] reports the use of security patterns to enforce security for remote healthcare in smart homes. [Ela11] describes a survey of 237 institutions in China to discover their use of security requirements for software construction. One of their most common sources of security knowledge were standards and security patterns.

One of the reasons for the lack of use of security patterns is the lack of a good catalog; we hope to help with this. Another reason could be lack of a methodology, and we expect that our methodology can be of value here.

1.5 Other Approaches to Building Secure Systems

There are several other approaches to building secure systems, of which the most prominent are those based on secure coding:

Microsoft’s Security Development Lifecycle (SDL) [How06]. [Lip05] defines activities for all the stages of a lifecycle based on coding with almost no modeling. The analysis stage is almost ignored, and threats are defined with respect to the deployment units of the software.

OWASP’s CLASP is a lightweight process to define requirements for secure software [OWAa]. It also starts from deployment units and analyzes their threats. Similarly to SDL it ignores the semantic aspects of the application.

Building Security in Maturity Model (BSIMM) is a software security framework, which includes twelve practices organized into the four domains of Governance, Intelligence, SSDL Touchpoints and Deployment [BSI].

DeWin [De W09] made a detailed comparison of SDL, CLASP and Touchpoints [McG06], looking for similarities and differences, as well as suggesting improvements. Code-based security, while valuable, cannot produce secure systems by itself, but it can be a good complement to model-based methods.

1Strictly, Haf11 and Ysk06 are not catalogs, they are pattern inventories where they organize existing patterns according to some classification, but do not provide pattern descriptions.

CHAPTER 2

Patterns and Security Patterns

Each problem that I solved became a rule which served afterwards to solve other problems.

René Descartes, Discourse on Method

2.1 What is a Security Pattern?

A security pattern describes a solution to the problem of controlling (stopping or mitigating) a set of specific threats through some security mechanism, defined in a given context [Sch06b]. This solution needs to resolve a set of forces, and can be expressed using UML class, sequence, state and activity diagrams. A set of consequences indicate how well the forces were satisfied; in particular, how well the attacks were handled. A security pattern is not directly related to a vulnerability, but is directly related to a threat. The specific threat may be the result of one or more vulnerabilities, but the pattern is not intended to repair the vulnerability, but to stop or mitigate the threat.

Figure 2.1 shows a generic diagram illustrating the effect of the use of security patterns as deployed in a specific architecture. The sequence diagrams on the left of the figure indicate possible attacks (threats) to a context defined by a deployment diagram. For example, a context may include distributed systems, distributed systems using web services, or operating systems. Typical objects in the deployment diagram (O1, O2, O3) are instantiated from classes in the application class diagram (Classes A, B and C respectively for this example). SP1 denotes the security pattern solution that is able to stop or mitigate these threats. There may be more than one SP1 that can handle the threats. Theoretical models of security patterns can be found in [Was09] and in Chapter 8 of [Sch03].

Figure 2.1: A security pattern controlling two attacks

2.2 The Nature of Security Patterns

There are several ways to look at security patterns:

As an architectural pattern. Security patterns can be considered a type of architectural pattern because they usually describe global software architecture concepts; for example, do we need authentication between two distributed units? We prefer this interpretation because security is a global property.

As a design pattern. The fact that security can be considered an aspect of a software subsystem has made some groups consider them design patterns [Bla04] [Dou09]. We think that design patterns are code-oriented and security is an architectural property, but this view can be useful to analyze the effect of code structure on security.

As an analysis pattern. Security constraints should be defined at the highest possible level, that is, at the conceptual model of the application. For example, we can define which users have which roles and what rights they need to perform their tasks. A conceptual, implementation-free definition of a security mechanism is, in effect, an analysis pattern. We use this approach in our methodology to define system-independent requirements, as described in Chapter 3.