Security Patterns: Comparing Modeling Approaches

1. Introduction

The collective experience of engineering secure software systems indicates that potential considerations for vulnerabilities in system design are both broad and deep. Anything from a single line of program code, the level of power consumption by the computer, to lapses in human memory may invite security breaches. Security engineers, therefore, need an array of tools at their disposal in dealing with diverse security problems. An integral part of the toolkit is the ability to access transferable design knowledge. Very often it is convenient to document this transferable knowledge in a pattern. A pattern is a description of a recurring problem and its corresponding successful solution (Gamma et al., 1996). As a pattern describes the identified recurring problem and its solution in principle, it (pattern) can be described in different languages. We call the description of a pattern using a specific modelling language, such as UML, its representation. Security patterns are well-understood solutions to recurring security problems (Schumacher et al., 2005). They enable engineers to recognise, with relative ease, known vulnerabilities in their design and potential solutions. Several security patterns have been reported by practitioners and researchers, and there are lively and ongoing discussions about the discovery, documentation and application of security patterns.

Although many security patterns are documented in the public domain, they are often specifically tied to the language and the method in which they are expressed. Since security engineers do not have a common language and method to model, analyse and implement systems, it is important to know whether a particular security pattern can be expressed and applied in their own approach. This chapter aims to examine some of the languages in which security patterns may be expressed and the methods in which they are applied, with a view to articulating their relative strengths and weaknesses.

In this survey, we will focus primarily on the languages for modelling and methods for applying security patterns in early requirements analysis and designs. This choices are both principled and practical: principled because earlier patterns are less understood compared to those at the implementation level and because early prevention of security vulnerabilities is thought to be less costly than remedial actions taken later; and practical because further expanding the scope of the survey would open up issues that are too many to be discussed in this chapter.

The main contribution of this chapter is an evaluation of security pattern modelling approaches. Our evaluation builds on the survey of security patterns by Yoshioka et al. (Yoshioka et al., 2008). We compare approaches from the following three categories because these approaches are repeatedly referred as representative ones that address security in models (Mayer et al., 2007; Cabot and Zannone, 2008): object-oriented design (UML, SecureUML, UMLsec, Misuse Cases), goal-oriented (KAOS, Secure Tropos, i*), and problem-oriented (problem frames, abuse frames). In comparing and contrasting these different approaches, we adopt the widely acknowledge security pattern, Roll-Based Access Control (RBAC), and a familiar example to illustrate different aspects of each approach using a common set of evaluation criteria to judge the pros and cons of each approach. The general objective of this survey is to evaluate how security patterns can be described in selected requirements engineering approaches: in particular whether all key properties of RBAC can be expressed in those approaches. In other words, we are evaluating what each RE approach is able (and not able) to describe. Evaluation results should be useful for the following stakeholders: security pattern designers can use the results to find out what languages are appropriate for modeling their patterns; and application designers can use security patterns to develop their applications with desired quality characteristics including security. Since the evaluation results characterise the attributes of existing security patterns, they can also be used to improve the understanding of these security patterns that are modelled by any one of the approaches evaluated in the chapter. This survey aims to examine some of the languages in which security patterns may be expressed partially or entirely.