Security Patterns in Practice

Designing Secure Architectures Using Software Patterns

Eduardo Fernandez-Buglioni

• Publisher: Wiley
• Year: 2013
• Print ISBN: 9781119998945
• eBook ISBN: 9781119970484
• Edition: 1
• Topic: Computer Science
• Subtopic: Software Development
• Index: Computer Science

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.

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 a...

Table of contents

• Cover
• Half Title page
• Title page
• Copyright page
• Dedication
• About the Author
• About the Foreword Author
• Foreword
• Preface
• Part I: Introduction
• Part II: Patterns
• Part III: Use of the Patterns
• Appendix A: Pseudocode for XACML Access Control Evaluation
• Glossary
• References
• Index of Patterns
• Index