hard to get an overview about the state of the art of Security Design Patterns. ...... tion, a SSL-certificate can be implemented at the INTEGRATION REVERSE PROXY ...... Finally the Apple Development Environment forces developers since its ...
Security Design Patterns in Software Engineering Overview and Example
Bachelorarbeit im Studiengang Medieninformatik vorgelegt von Florian Röser and der Hochschule der Medien, Stuttgart am 30.08.2012 Erstprüfer: Prof. Dr. Joachim Charzinski Hochschule der Medien Zweitprüfer: Dr. Manfred Schäfer Nokia Siemens Networks Management International GmbH Korrektor: Rainer Schmitz Nokia Siemens Networks Management International GmbH c
2012, Stuttgart
1
Hiermit versichere ich, Florian Röser, an Eides Statt, dass ich die vorliegende Bachelorarbeit mit dem Titel: “Security Design Patterns in Software Engineering - Overview and Example” selbständig und ohne fremde Hilfe verfasst und keine anderen als die angegebenen Hilfsmittel benutzt habe. Die Stellen der Arbeit, die dem Wortlaut oder dem Sinn nach anderen Werken entnommen wurden, sind in jedem Fall unter Angabe der Quelle kenntlich gemacht. Die Arbeit ist noch nicht veröffentlicht oder in anderer Form als Prüfungsleistung vorgelegt worden. Ich habe die Bedeutung der eidesstattlichen Versicherung und die prüfungsrechtlichen Folgen (§26 Abs. 2 Bachelor-SPO (6 Semester), § 23 Abs. 2 Bachelor-SPO (7 Semester) bzw. § 19 Abs. 2 Master-SPO der HdM) sowie die strafrechtlichen Folgen (gem. § 156 StGB) einer unrichtigen oder unvollständigen eidesstattlichen Versicherung zur Kenntnis genommen.
___________________, Stuttgart den 30.8.2012 Florian Röser
2
1
1
ABSTRACT (GERMAN)
Abstract (German)
Sicherheit wird in der Softwareentwicklung zunehmend wichtiger, vor allem nach den Ereignissen in den letzten Jahren, als die Anzahl der Viren, sowie der zielgerichteten Attacken auf Softwaresysteme damatisch zugenommen hat. Es gibt verschiedene Herangehensweisen um mit diesen Sicherheitsproblemen fertig zu werden. Diese fangen beim Management und den firmeninternen Richtlinien an, gehen über Fortbildungen und projektleitungs Techniken bis hin zu der Benutzung von fertigen Sicherheits-“Frameworks” und -Praktiken. Einen Teil der Lösung um Software sicherer zu machen stellen die Security Design Patterns dar. Security Design Patterns sind abstrakte und allgemein gültige Lösungen für wiederholt auftretende sicherheitsrelevante Probleme in der Architektur und dem “Design” von Software. Zu den Security Design Patterns wurden bereits viele wissenschaftliche Arbeiten verfasst. Diese Arbeit befasst sich Schwerpunktmäßig mit zwei Thematiken: Zuerst wird diese Arbeit einen Überblick über die verschiedenen Security Design Patterns verschaffen und anschließend werden die Abhängigkeiten der Security Design Patterns untereinander näher aufgezeichnet und einige Beispielkompositionen dargestellt.
3
CONTENTS
2
Abstract
Security in software development and software engineering has become more and more important. there are many different problems when it comes to security and also many different approaches to resolve them, starting at management methodologies, over training to the use of frameworks and practices. One of the building blocks to solve these problems are Security Design Patterns in software engineering. Security Design Patterns are common generic solutions to reappearing security relevant problems in design and architecture of information systems. While a lot of work has been done on Security Design Patterns, this paper focuses on two points: First, there will be an overview of the Security Design Pattern landscape and a selection of the most essential patterns will be present. Second, this work outlines the dependencies between the Security Design Patterns. Keywords: Security Design Patterns, Software Engineering
Contents 1
Abstract (German)
3
2
Abstract
4
3
Introduction
6
4
A systematic literature review 4.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 7
4.2
8
5
6
7
Short description on the use of this approach . . . . . . . . . . . . . . . .
Research Question
8
5.1
8
Security Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . .
Research Methodology
9
6.1
Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
6.2 6.3
Search queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selection criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9 10
6.4
Inclusion and exclusion criteria . . . . . . . . . . . . . . . . . . . . . . .
10
6.5
Quality estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
6.6
Extraction Method and Criteria . . . . . . . . . . . . . . . . . . . . . . .
12
6.7
Shortcomings due to a single researcher . . . . . . . . . . . . . . . . . .
12
Validation Methods
13
7.1
Is the design pattern security relevant? . . . . . . . . . . . . . . . . . . .
13
7.2
Variables to consider . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
8
Evaluation of the Methodology
14
9
Security Principles
15
10 Security Design Patterns
17
10.1 ID Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
18
CONTENTS
CONTENTS
10.1.1 Password Design and Use . . . . . . . . . . . . . . . . . . . . .
18
10.1.2 Other possibilities of ID Management . . . . . . . . . . . . . . .
20
10.2 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
10.2.1 Authenticator . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
10.2.2 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
10.2.3 Check Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
10.2.4 Controlled Virtual Address Space . . . . . . . . . . . . . . . . .
26
10.2.5 File Authorization . . . . . . . . . . . . . . . . . . . . . . . . .
28
10.2.6 Full Access With Errors . . . . . . . . . . . . . . . . . . . . . .
30
10.2.7 Limited Access . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
10.2.8 Metadata-Based Access Control (MBAC) . . . . . . . . . . . . .
35
10.2.9 Multilevel Security . . . . . . . . . . . . . . . . . . . . . . . . .
36
10.2.10 Reference Monitor . . . . . . . . . . . . . . . . . . . . . . . . .
37
10.2.11 Role-Based Access Control . . . . . . . . . . . . . . . . . . . .
39
10.2.12 Security Session . . . . . . . . . . . . . . . . . . . . . . . . . .
42
10.2.13 Single Access Point
. . . . . . . . . . . . . . . . . . . . . . . .
44
10.3 Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.1 Secure Logger . . . . . . . . . . . . . . . . . . . . . . . . . . .
46 46
10.4 Operating System Level . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
10.4.1 Controlled Execution Environment
. . . . . . . . . . . . . . . .
48
10.4.2 Controlled Object Factory . . . . . . . . . . . . . . . . . . . . .
50
10.4.3 Controlled Process Creator . . . . . . . . . . . . . . . . . . . . .
52
10.4.4 Distrustful Decomposition . . . . . . . . . . . . . . . . . . . . .
54
10.4.5 Execution Domain . . . . . . . . . . . . . . . . . . . . . . . . .
55
10.4.6 Secure Chain Of Responsibility . . . . . . . . . . . . . . . . . .
57
10.4.7 Secure State Machine . . . . . . . . . . . . . . . . . . . . . . . .
59
10.4.8 Secure Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
10.4.9 Secure Visitor . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
10.5 Client-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
10.5.1 Demilitarized Zone . . . . . . . . . . . . . . . . . . . . . . . . .
64
10.5.2 Front Door . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
10.5.3 Information Encryption . . . . . . . . . . . . . . . . . . . . . . .
68
10.5.4 Integration Reverse Proxy . . . . . . . . . . . . . . . . . . . . .
70
10.5.5 Known Partners . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
10.5.6 Protection Reverse Proxy . . . . . . . . . . . . . . . . . . . . . .
73
10.5.7 Secure Channels . . . . . . . . . . . . . . . . . . . . . . . . . .
75
10.6 Securing Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
10.6.1 Input Validator . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
10.6.2 Secure Access Layer . . . . . . . . . . . . . . . . . . . . . . . .
79
10.6.3 Secure Blackboard . . . . . . . . . . . . . . . . . . . . . . . . .
81
10.6.4 Secure Chain of Responsibility . . . . . . . . . . . . . . . . . . .
83
10.7 Additional Patterns - not described in detail . . . . . . . . . . . . . . . .
83
10.7.1 Access Control Requirements . . . . . . . . . . . . . . . . . . .
83
5
3
INTRODUCTION
10.7.2 Audit Requirements . . . . . . . . . . . . . . . . . . . . . . . .
83
10.7.3 Audit Trail and Logging Requirements . . . . . . . . . . . . . .
83
10.7.4 Automated Identification and Authentication Design Alternatives
83
10.7.5 Controlled Object Monitor . . . . . . . . . . . . . . . . . . . . .
84
10.7.6 Defer to Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
10.7.7 Exception Manager . . . . . . . . . . . . . . . . . . . . . . . . .
84
10.7.8 Identification and Authentication Requirements . . . . . . . . . .
84
10.7.9 Intrusion Detection Requirements . . . . . . . . . . . . . . . . .
84
10.7.10 Non-Repudiation Requirements . . . . . . . . . . . . . . . . . .
85
10.7.11 Output Validation . . . . . . . . . . . . . . . . . . . . . . . . . .
85
10.7.12 Privilege Separation . . . . . . . . . . . . . . . . . . . . . . . .
85
10.7.13 RSBAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
10.7.14 Secure Builder Factory . . . . . . . . . . . . . . . . . . . . . . .
85
10.7.15 Security Accounting Requirements . . . . . . . . . . . . . . . .
86
10.8 Pattern Candidates . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
10.8.1 Sandbox
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
10.8.2 Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
11 Outlining Pattern Dependencies
92
11.1 Pattern Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
11.2 Pattern Compositions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
11.2.1 Single Access Point and Check Point . . . . . . . . . . . . . . .
93
11.2.2 Full Access With Errors . . . . . . . . . . . . . . . . . . . . . .
95
11.2.3 Limited Access . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
11.2.4 Protection Reverse Proxy . . . . . . . . . . . . . . . . . . . . . .
98
11.2.5 Login and Secure Logger . . . . . . . . . . . . . . . . . . . . . .
99
12 Conclusion and Future Work
101
13 Acknowledgment
102
14 Appendix
103
14.1 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 14.2 CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 15 Bibliography
3
104
Introduction
Patterns in software engineering are common generic solutions to reappearing problems in software design. A wide range of patterns have been described and its considered best practice to use them. Security Design Patterns specialized in two ways. First, they focus on the design stage of a software project and second, they provide common generic solutions for security relevant problems. Design patterns have already been described as
6
4
A SYSTEMATIC LITERATURE REVIEW
early as 1999 by Erich Gamma1 while Schumacher et al 2 already focused on security patterns. In the meantime there has been a lot of additional research on design patterns in general and especially on Security Design Patterns. This left us with some standard literature and a lot of small pieces and bits describing individual patterns. This makes it hard to get an overview about the state of the art of Security Design Patterns. Furthermore the topic of security in software development and software engineering gets to a completely new level. Security in information systems is now more important than ever before. This has different reasons. Companies rely more and more on information systems so that software and the information its managing has become extremely business critical. Damage can be done by: harming the integrity of data, e.g. if data is deleted or altered. Business information are revealed to competitors. In addition to this, hacked systems can seriously damage the image and reputation of a company. The topic of security and the state of the security design pattern landscape motivated this research. This paper is mainly targeted at system architects and system engineers, but also software developers interested in security. People reading this paper should already have a basic knowledge about security in software engineering and about the design principles3 4 . The focus of this research is to provide a quick overview about the Security Design Patterns with links for further information. In addition to this, this paper also contains an extra chapter concerning the dependencies pattern have with each other. This is due to the fact that most Security Design Patterns solve one or two security problems but leave others unanswered. Patterns typically used together in sets of Security Design Patterns. In this paper the dependencies and the relationships various patterns have with each other will be pointed out. At first Security Design Patterns will be described in short detail, providing information about further reading and dependencies on other patterns. Then the general dependency diagram will be outlined to give an overview of how Security Design Patterns depend on the others. Finally five sets of design patterns are chosen at random to provide a basic idea and description how patterns can work together as a composition. This is meant as a starting point for software engineers and architects for discussions in their companies and with their teams.
4
A systematic literature review
For this research paper we will make use of the “systematic literature review” -method which is described by Kitchenham5 . The intent of Kitchenham is to help researchers to make their literature researches more systematic. All further descriptions regarding a systematic literature review are referencing this paper by Kitchenham.
4.1
Motivation
There is an obvious need for transparency and a systematic approach in software engineering. A systematic approach for research papers is already known and practised e.g. in medicine. There are various benefits to this approach: • This structure makes it possible for other researchers to verify, validate and test the outcome of research. It also allows for the comparison between research methods 1 [Gamma
et al., 1995] 2006] 3 [Homeland Security, ] 4 [OWASP, ] 5 [Kitchenham, 2004] 2 [Schumacher,
7
4.2
Short description on the use of this approach
5
RESEARCH QUESTION
and new ideas. Such comparisons could lead to improvements for a new research, e.g. by using different libraries or varying the search queries. • One goal of this approach is to get more objective results. To make it more difficult for assumptions and biases of researchers to influence their research and deliver more objective, scientific results and conclusions. • Finally this approach gives a basic structure and guidelines, helping the researcher to focus more efficiently on the research itself and less on how to structure and which methods to use. Using this method has the drawback of producing quite an overhead of work at the beginning of the research. All in all, the benefits to the scientific research are considered greater than the overhead of work in the anyway short time.
4.2
Short description on the use of this approach
For a more detailed description please consider reading B. Kitchenham’s paper “Procedures for Performing Systematic Reviews” 6 . The Systematic Literature Review provides a detailed structured way to define the research question, describes the considered libraries and publications, searches queries and selection criteria. It also shows best-practices of how to define the inclusion and exclusion criteria and make the quality estimation. This paper uses for this purpose an adapted version of the systematic literature review.
5
Research Question
This section primarily describes the guiding research question for this research paper. The steps and expectations this research paper is trying to fulfill are also outlined here. The aim of this paper is to make a survey of the “state of the art” of so called “Security Design Patterns” in software development and software engineering. In addition an this research will focus on the relations between the various Security Design Patterns. The basic idea behind this topic is that in order to really achieve secure software one has to think of security already while designing the software. Help on how to consider security by design can be found in already described patterns in software engineering and software development which help to avoid certain reappearing problems and bugs from the very beginning. Which widely used design patterns exist, how relevant are these patterns for security and how are they related to each other? A second question has been added to help keep the focus when writing this paper: How can this paper outline the security design pattern - landscape as well as the dependencies between them and provide additional and practical information for developers.
5.1
Security Design Patterns
There are problems which appear regularly in similar situations, different software engineers and software developers describe similar core solutions to these problems. Thus we get design patterns. Security Design Patterns are core solutions to specially reappearing security problems. Security patterns are not only limited to software architecture and design, but they can 6 [Kitchenham,
2004]
8
6
RESEARCH METHODOLOGY
also target enterprise security, development practices and the maintenance of developed systems. Usually a software project is structured in a certain way.
• The requirement phase where all functional and non-functional requirements for this project are gathered and described. • The analysis stage, here different analysis patterns can be applied to build a conceptual model of the product. • Then the design stage, where the software architecture is defined. • The implementation stage, where the software is finally developed • The deployment stage when the product is released into the production environment. The focus of this paper lies on the overall design- and architectural security patterns assigned to the software engineering area. The term “Security Design Patterns” therefore describes patterns situated in the design stage which deals with security problems.
6
Research Methodology
This chapter describes the procedures used to research the necessary literature for this paper. As there are thousands of digital and physical libraries, the first step is to decide which libraries will be actually used for this research. Additionally this chapter defines the selection criteria according to which the decision will be taken whether a finding can and will be used for the research.
6.1
Libraries
Various kinds of sources will be used, primarily digital libraries but also the library of the Hochschule der Medien (HdM) and the library of the University of Stuttgart-Vaihingen will be used for this research. Using the search queries defined below, the primary libraries will be scanned and the findings will be selected. • HdM library (which provides access to physical books and digital e-papers) • Library of the University of Stuttgart-Vaihingen • Springerlink All findings will be collected in the bibliography. The selection criteria for the findings are described below. In addition this paper will take into consideration references from the findings. Some of these referenced material may not be available in the above mentioned libraries. To get hands on this material this paper makes also use of the Google scholar search engine.
6.2
Search queries
On the one hand, the search queries have to be general enough to also match those documents which are maybe not exactly in the search focus but nonetheless provide useful
9
6.3
Selection criteria
6
RESEARCH METHODOLOGY
information for the research topic. On the other hand they have to be specific enough not to show thousands of documents which have nothing to do with the topic of this paper, but only show some hundreds which can then be scanned through by the title and the abstract to verify if they are considered for the next step. The search queries for the different libraries have to be slightly adapted in their syntax, e.g. using ’ ’ for searching as a whole phrase or using connectors like AND or OR or organizing the search words in brackets. This is necessary due to the requirements of the digital libraries. In some digital libraries additional selection criteria can also be chosen, like publication year, kind of publication and maybe even the field of the publication like “computer information science”. If applicable the focus of the search will match documents published between 2005 and today (June 2012). This will make the range of findings smaller but more up to date. The following terms and phrases will be used for the search: • Security AND Design AND Pattern • Secure AND Design AND Pattern • Security AND Pattern AND Software AND Development • Security AND Pattern AND Software AND Engineering • Security AND Pattern AND Software AND Architecture
6.3
Selection criteria
The following steps will be applied to exclude / include my findings during the search of literature. 1. Enter the search queries 2. Check title and abstract for their inclusion and exclusion criteria 3. If included, download or rent the document and insert a reference in the bibliography 4. Skim-read through the paper for the inclusion and exclusion criteria 5. Make a summary of the relevant points in the paper 6. Reference the relevant outcomes of the papers
6.4
Inclusion and exclusion criteria
It is a critical point of how to include and exclude certain papers for the research in order to obtain a complete and systematic review. Therefore the inclusion and exclusion criteria are described before starting the search. Additionally the criteria will be tested on a few examples to verify that they are chosen in a way that allows to apply the criteria in a manageable time but still have an outcome which helps the research. • The title has to suggest that it has something to do with my topic • The abstract shows that there can be useful information for my research • The document is available either as hard copy in the university library or as a digital document on the digital libraries or in Google scholar • The language has to be English
10
6.5
Quality estimation
6
RESEARCH METHODOLOGY
• The publishing date is between 2005 and today. I will also include older publications unless the content proves to be of critical relevance to my research. • The quality of the text and the copy has to be in a good and readable state • The quality of the source is acceptable (see quality estimation) • The content proves to be useful for my research. Basically all of these criteria are critical, except the publishing date where exceptions can be made if primary sources are found in references of findings. The first five criteria are applied in a rush on all findings to the search queries so that there will be a range of documents where then the other criteria will be applied too.
6.5
Quality estimation
It is important to be aware of the quality of a source, e.g. if it is written by a group of independent researchers from different cultures or if it is a paper written by one person who has neither published any other papers nor has ever been referred to by other researchers. Therefore the findings will be checked and a rough quality estimation will be made on these papers. Only papers where the quality is estimated as “acceptable” will be used for my research. Every finding will be checked for quality and credibility. Quality • Readable • Well written • Credibility (see below) • Evidence of study Credibility • Source of the paper, like a scientific database like ACM, IEEE Xplore or Springerlink? • Amount, distribution and background of authors (e.g. are they from different countries and cultures, are they employed by one ore different companies, are they at a university?) • Have the authors already written other studies? On a similar or other topic? • Does this paper reference other papers, are these other papers well known and also referenced by other findings? • Is this finding cited by other papers and how? • What kind of paper is it, is it a study, a talk at a conference, a company paper, a book? • Has the paper been reviewed and by whom? By asking these questions points will be assigned from 0 to 5, so that 0 means something similar to “a not reviewed article from an unknown author” whereas 5 refers to “a well reviewed, referenced and referencing article from multiple internationally distributed and
11
6.6 0 1 2 3 4-1 4-2 5
Extraction Method and Criteria
6
RESEARCH METHODOLOGY
The paper is from an unkown source and of bad quality. The paper is from an unknown source, written by an author without a known reputation. The paper is from a scientific source (like ACM or IEEE), written by one author. The paper is from a scientific source, written by at least two authors from one background (e.g. one company) The paper is from a scientific source, written by at least two authors employed by different organizations The paper is from a scientific source, written by at least two authors employed by different organizations in different countries The paper is from a scientific source, written by at least two authors from different organizations in different countries and has been well reviewed and referenced Table 1: adapted description-table of the quality estimation criteria
well known authors who work for different companies and/or universities.” Kitchenham7 suggested a table similar to the following in order to estimate the quality of the findings. (See Appendix 14.1). This table does not suit the case of this paper since most of the resources are not direct outcomes of trials or experiments but instead are often literature reviews, books and talks about certain topics. Therefore the table had to be adapted to meet the requirements of this paper. Table 1 presents the adapted version. For this paper the outcome of the quality estimation means following. If a paper points below 1, it won’t be considered in the research. Has the resource the quality estimation of 1 then it will be considered if it adds value to the research and if additional resources can be found supporting the paper with the quality estimation of 1. If the resource has the quality estimation of 2 the content is used but to have other papers supporting this resource is recommended. Has the resource a quality estimation of 3 or better it will be used in for this research.
6.6
Extraction Method and Criteria
The goal of the extraction criteria is to have a checklist which can be applied to extract the relevant content from the findings in a similar way to allow a comparison afterwards. The danger of not doing this is, that different interesting findings will be extracted, but they may not be comparable, or to compare them, the papers need to be extracted again searching for the necessary points. Therefore the contents will be extracted as shown in table 2. This is repeated for each single pattern. The aim of this structure is to make it easier comparing the different descriptions of a single pattern and to bring all patterns in a similar structure for further processing.
6.7
Shortcomings due to a single researcher
In her paper Kitchenham outlines the importance of a systematic literature review for researchers. However, as this process provides best outcomes when done with a group of researchers, it can also be done by a single researcher, e.g. by a Ph.D. student or bachelor student. But she outlines certain problems due to the fact of a single researcher, compared with a group of researchers. 7 [Kitchenham,
2004]
12
7 name Identifier Title Date Type of article study aim validity findings: pattern 1 intent context problem solution example consequences further information dependencies on other patterns pattern candidates
VALIDATION METHODS
description a unique identifier for the study, in this case the citation key the title of the document publication date e.g. conference paper, thesis or journal article What are the goals of the study Who and where is it published, who is referenced, quality of data and references the name under which the pattern is known what is the intent of this pattern the context in which the pattern is described description of the security problem the pattern is solving the theoretical solution to this problem an example implementation (short) what are the possible and promised benefits and shortcomings links and hints where to get further information lists other patterns on which this pattern depends Are there common security problems for which common solutions exist but no pattern is described yet?
Table 2: This table presents the structure used for content extraction. One of these problems is the quality estimation as the single researcher often doesn’t have the capacity to perform a deeper evaluation of the quality estimation of the papers he or she uses for the review. This shortcoming, in addition to others, also applies for this paper which can have an impact on the quality of this work.
7
Validation Methods
This section describes the detailed validation of the findings. This regards to the extraction of findings and not, as above, for the inclusion and exclusion criteria of the search. There will be described how to validate if a security pattern is indeed relevant for security and there will be an outline of some metrics on how an implementation and the benefits of the security patterns can be tested in empirical environments.
7.1
Is the design pattern security relevant?
This paper wants to answer this question by looking at the problem the design pattern is solving. Schumachers characterization of security patterns for this is used: Does the security pattern describe a particular reappearing security problem that arises in specific contexts, and presents a well-proven generic solution for it?8 Schumachers paper continues as follows: The solution consists of a set of interacting roles that can be arranged into multiple concrete design structures, as well as a process to create one particular such structure. To define if a pattern can be categorized as a "security design pattern", which means that it is a security relevant design pattern, this paper will concentrate on the problem the pattern is trying to solve. Furthermore the problem will be considered, the context in which it 8 [Schumacher,
2006] - page 31
13
7.2
Variables to consider
8
EVALUATION OF THE METHODOLOGY
occurs and the consequences if they are security relevant. The security design pattern itself describes the well-proven and documented solution to this problems.
7.2
Variables to consider
Security design patterns are not only limited to architectural or design patterns. Therefore it is hard or even impossible to have one method to test the quality of implementation and the consequences of the security design pattern. There are many different forces which have to be taken into consideration when applying a security design pattern. “First of all there has to be determined that the same security problem occurs in a similar context. If this applies, there are other factors which can influence the consequences” according to Schumacher9 : • the amount of users • the use of the system • what kind of users you have • is the system set in a heterogeneous or homogeneous environment • the security awareness of the organization If available this paper will describe for each security design pattern a separate section describing approaches for testing and verifying the implementation and the outcome of the pattern. Applying a security design pattern can have different consequences. If decided to apply a pattern one has to not only be aware of but also observe and verify the consequences. The possible positive consequences are hopefully a risk reduction or even risk elimination of the specified security problem. But also there can and will be other consequences like increasing maintenance costs, software licenses, hardware and other costs. Also there are expenses for training, the problem of implementing it into an existing process or framework and a possible decrease of usability10 .
8
Evaluation of the Methodology
This chapter is only a small but nonetheless important chapter. In here the research methodology will be validated by going through some tests and verifying that the research queries provide useful output. Also selection criteria and validation methods will be evaluated. The goal of this is to test and prove the research methods and, if necessary, change some variables to achieve the objectives of the research. Search Method Evaluation: Before putting days of effort into a useless search because the search queries or other parameters may have been chosen faulty, this research will do a short test-run to evaluate the search parameters. After the first test-run the parameters indeed has to be changed slightly to the above described parameters. A second test-run with the new parameters was successful and these parameters will be used now for future research. Validation Evaluation: The quality estimation methods have already been tested in a comparable environment and delivered good results in a manageable time. Therefore the validation of this method has already been done. 9 [Schumacher, 10 [Schumacher,
2006] - page 36 2006] - page 36f
14
9
9
SECURITY PRINCIPLES
Security Principles
In software security we talk about “Security Principles” and “Security Patterns”. Principles are described as “presents a set of practices derived from real-world experience that can help guide software developers in building more secure software” 11 . The line between principles and pattern in the context of software engineering is not very clear. However, many of the security design patterns do help to apply some of the security principles. Security principles are not the aim of this study. Therefore they will only be mentioned in this section. For further information please refer to: • OWASP Principles https://www.owasp.org/index.php/Category:Pr inciple • US Government - Homeland Security https://buildsecurityin.us-c ert.gov/bsi/articles/knowledge/principles.html In the following parts some principles are listed, and if applicable, this paper will link to the patterns which are related to these principles. • Complete Mediation (This principle is supported by: CONTROLLED OBJECT MONITOR 10.7.5) “A software system that requires access checks to an object each time a subject requests access, especially for security-critical objects, decreases the chances of mistakenly giving elevated permissions to that subject. A system that checks the subject’s permissions to an object only once can invite attackers to exploit that system. If the access control rights of a subject are decreased after the first time the rights are granted and the system does not check the next access to that object, then a permissions violation can occur. Caching permissions can increase the performance of a system, but at the cost of allowing secured objects to be accessed.” [Homeland Security, ] • Defense in Depth “Layering security defenses in an application can reduce the chance of a successful attack. Incorporating redundant security mechanisms requires an attacker to circumvent each mechanism to gain access to a digital asset. For example, a software system with authentication checks may prevent an attacker that has subverted a firewall. Defending an application with multiple layers can prevent a single point of failure that compromises the security of the application.” [Homeland Security, ] • Failing Securely / Establish Secure Defaults “When a system fails, it should do so securely. This typically involves several things: secure defaults (default is to deny access); on failure undo changes and restore to a secure state; always check return values for failure; and in conditional code/filters make sure that there is a default case that does the right thing. The confidentiality and integrity of a system should remain even though availability has been lost. Attackers must not be permitted to gain access rights to privileged objects during a failure that are normally inaccessible. Upon failing, a system that reveals sensitive information about the failure to potential attackers could supply additional knowledge for creating an attack. Determine what may occur when a system fails and be sure it does not threaten the system.” [Homeland Security, ] • Least Privilege (This principle is supported by: ROLE-BASED ACCESS CONTROL 10.2.11, CONTROLLED EXECUTION ENVIRONMENT 10.4.1, DISTRUSTFUL DECOMPOSITION 10.4.4) 11 [Homeland
Security, ]
15
9
SECURITY PRINCIPLES
“Only the minimum necessary rights should be assigned to a subject that requests access to a resource and should be in effect for the shortest duration necessary (remember to relinquish privileges). Granting permissions to a user beyond the scope of the necessary rights of an action can allow that user to obtain or change information in unwanted ways. Therefore, careful delegation of access rights can limit attackers from damaging a system.” [Homeland Security, ] • Minimize Attack Surface Area (This principle is supported by: SINGLE ACCESS POINT 10.2.13, PROTECTION REVERSE PROXY 10.5.6, INTEGRATION REVERSE PROXY 10.5.4, FRONT DOOR 10.5.2, VIRTUALIZATION 10.8.2 and some others which help reducing the attack surface area.) “Every feature that is added to an application adds a certain amount of risk to the overall application. The aim for secure development is to reduce the overall risk by reducing the attack surface area. For example, a web application implements online help with a search function. The search function may be vulnerable to SQL injection attacks. If the help feature was limited to authorized users, the attack likelihood is reduced. If the help features search function was gated through centralized data validation routines, the ability to perform SQL injection is dramatically reduced. However, if the help feature was re-written to eliminate the search function (through better user interface, for example), this almost eliminates the attack surface area, even if the help feature was available to the Internet at large.” [OWASP, ] • Reluctant to Trust (This principle is supported by: SECURE ACCESS LAYER 10.6.2, INFORMATION OBSCURITY 10.5.3, SECURITY SESSION 10.2.12 as well as many of the patterns in the category “Operating System Level”) “Developers should assume that the environment in which their system resides is insecure. Trust, whether it is in external systems, code, people, etc., should always be closely held and never loosely given. When building an application, software engineers should anticipate malformed input from unknown users. Even if users are known, they are susceptible to social engineering attacks, making them potential threats to a system. Also, no system is one hundred percent secure, so the interface between two systems should be secured. Minimizing the trust in other systems can increase the security of your application” [Homeland Security, ] • Securing the Weakest Link “Attackers are more likely to attack a weak spot in a software system than to penetrate a heavily fortified component. For example, some cryptographic algorithms can take many years to break, so attackers are not likely to attack encrypted information communicated in a network. Instead, the endpoints of communication (e.g., servers) may be much easier to attack. Knowing when the weak spots of a software application have been fortified can indicate to a software vendor whether the application is secure enough to be released.” [Homeland Security, ] • Separation of Privilege (This principle is supported by: AUTHENTICATOR 10.2.1 and CHECK POINT 10.2.3 which recommend or enforce a separation of privilege) “A system should ensure that multiple conditions are met before granting permissions to an object. Checking access on only one condition may not be adequate for strong security. If an attacker is able to obtain one privilege but not a second, he or she may not be able to launch a successful attack. If a software system largely consists of one component, the idea of having multiple checks to access different components cannot be implemented. Compartmentalizing software into separate components that require multiple checks for access can inhibit an attack or potentially prevent an attacker from taking over an entire system.” [Homeland Security, ]
16
10
10
SECURITY DESIGN PATTERNS
Security Design Patterns
This chapter includes the main part of the research. The research itself and the findings are described as follows. • The research process is described briefly. • The presentation structure of the security design patterns is outlined. • The patterns are presented, structured in categories. • An outlook is made of patterns which are not taken into consideration but could nevertheless be relevant. • Some security design patterns which are not yet described in standard literature are described. Search: Inserting the queries into the database brought about 12.690 findings in the different databases. After applying the inclusion/exclusion criteria to the title and the abstract there were 47 papers left. These papers were downloaded and inserted into the reference list for further content extraction. Some more papers were downloaded which had descriptions and definitions useful for the research. Other papers were found by using the references of findings. At the end of the content extraction process there where 60 papers left from which only a few are referenced. Structure of the Security Design Patterns: In this chapter the report will present the security design patterns found in the research. Schumacher describes in his work 12 a standardized way of how to describe a security pattern. Every pattern is structured in a similar way with its context, the problem description and the solution. In order to provide relevant information for software developers and software architects in particular, this paper will outline some additional information for the described patterns. The following additional information has been added: • Further information, which describes links and places where to find additional information about this pattern and its implementation. • Dependencies, which describe on which other patterns this individual pattern depends on or, which other patterns are related to this one and in which way. Categorizing the Patterns: The patterns, which fall under the category of “design patterns” are being sub-categorized to provide an easier overview over the pattern landscape. I used the following sub-categories: • ID Management • Access Control • Accounting • Operating System • Client-Server • Securing Applications 12 [Schumacher
and Schumacher, 2003]
17
10.1
ID Management
10
SECURITY DESIGN PATTERNS
• Additional Patterns - e.g. specializations or not enough description in standard literature • Pattern Candidates - Solutions to common security problems which probably are patterns but not yet described as such ones in standard literature. References: The description of the security design patterns is kept close the original descriptions. The resources used to describe the patterns can be found at each pattern in the paragraph “Further Information”.
10.1
ID Management
10.1.1
Password Design and Use
Intent: The PASSWORD DESIGN AND USE pattern provides a strategy of how to manage, design, create and use passwords. It is intended for three different user groups: administrators, engineers and users. It helps engineers by providing strategies of how to implement and take care of password design and use in commercial projects. At an administrator’s level it provides a strategy of how the restrictions and guidelines for password design and use should be set in different environments, like managing and operating password mechanisms. Finally for end-users it provides a strategy of how a user can handle passwords and improve their security. Context: It can be used in all software where a password is used to authenticate a user to the system. Problem: A password is meant to authenticate a user to a system. While a weak password is easy to guess and therefore allows misuse by imposters, a strong password is hard to remember for the password owner. Forces: • Even though the password should be hard guess, it should be easy enough to remember (to prevent false negatives). In some cases a password manager program can be of help for very difficult passwords. If a password can not be remembered easily, the possibility increases that users will write down their passwords which is an additional security threat, especially if no password manager is used. • Password should be hard to guess for imposters. • Regular changing of passwords should be possible and encouraged. • Each distinct system should have their own password, therefore a password is used only once. (This stands in contrast to a Single Sign On solution as described by the FRONT DOOR pattern, see 10.5.2) The solution has to achieve an appropriate balance between the different constraints. Solution: This pattern outlines a catalogue of questions which administrators, system engineers or users can answer by themselves. The system engineers and administrators can enforce proper design and definition, use and protection of the password. Therefore these points have to be considered[Schumacher, 2006]: Designs and definitions
18
10.1
ID Management
10
SECURITY DESIGN PATTERNS
• What characters can be used and have to be used (e.g. minimum one letter, one symbol and one number)? • The minimum and maximum length of the password? • Who can create which password (entity)? The use of the password • What is the maximum lifetime of the password? • Who are the persons authorized to use the password? • How can a password be entered into the system? • How long is the maximum time-gap before the system requires re-authentication? Protection • What are the acceptable ways to transport a new password to the user and to the places it is required? E.g. requiring encryption and secure channels, or sending a new password with standard mail. • What are the acceptable mechanisms how the passwords are stored? E.g. only salted password-hashes are stored, never the password itself. On which system, database and table is the password stored and how is the database protected? • What are the acceptable mechanism on communicating a password from the entrypoint to its point of use? Example: Example for Password Design and Use for users at a Web-Service. This does not include any administrative or maintenance-passwords required in the system. Password Design: • min. 8 letters • max. 30 letters • min. 1 small letter, 1 capital letter and 1 number • at registration every user creates his/her own password. • when password reset is requested, a random string matching the design rules are generated by the system and sent to the user. There is no interface, e.g. for administrators, to manually type in the password for another user! Password Use: • Passwords have an infinite lifetime. • Only the user is authorized to use the account-password. Also users are responsible for not letting other people know their password. • The password can be entered in the login-screen with the browser. In addition smartphone-apps of this portal can make use of the Login-API to enter the password. • A Security Session, set up with correct username-password authentication has a maximum lifetime of 20min. After this period re-authentication is required.
19
10.1
ID Management
10
SECURITY DESIGN PATTERNS
Protection: • A password has to be transported via a SECURE CHANNEL. In this case the Login-Screen uses SSL encryption via HTTPS. The Smartphone API has to use SSL. • The password has to be salted and hashed with SHA256. The password itself is never stored! Only the password-hash is stored. Passwords are stored in a separate database where an extra userID field points to the user-entry. • When new users are registered, they type in their passwords via a secure channel. When the password is being reset, a one-time password is sent via e-mail to the users. With this one-time password users are able to type in a new password. Consequences: When applying this solution the following benefits should be considered: • increased protection of the password • higher accuracy of identification and authentication • the success-rate of password-guessing is expected to be reduced Disadvantages: • It can lead to forgetting to use other techniques for identification and authentication. A combination of different methods is often considered best practice. Further Information, please refer to: • Schumacher et al [Schumacher, 2006] • Helkals et al [Helkala, 2011] • Wikipedia http://en.wikipedia.org/wiki/Password_policy • Hitachi - Password manager http://hitachi-id.com/password-mana ger/docs/password-management-best-practices.html • OWASP https://www.owasp.org/index.php/Password_length_%2 6_complexity Dependencies: Password Design and Use is an abstract pattern and still needs to be enforced throughout the system. Typically the patterns SINGLE ACCESS POINT (see 10.2.13) and CHECK POINT (see 10.2.3) are used to enforce these password policies. 10.1.2
Other possibilities of ID Management
There are other possibilities of identification and authentication than passwords. A very common one is the use of the public key infrastructure (PKI), where a shared public key is used to identify a system, process or user (subject) to another subject. These other possibilities are not further mentioned here but should be considered too. For further information please refer to: • Wikipedia http://de.wikipedia.org/wiki/Public-Key-Infrastr uktur
20
10.2
Access Control
10
SECURITY DESIGN PATTERNS
• OWASP https://www.owasp.org/index.php/Guide_to_Cryptogr aphy
10.2
Access Control
10.2.1
Authenticator
Intent: This pattern describes a way to check if a subject is who or what it says it is. It performs authentication of the subject before deciding about access to objects. Context: A user is normally authenticated by the operating system when first logged in, but additional authentication may be required when accessing sensitive resources. Especially in distributed systems there may be required additional authentication processes to verify access to distributed objects in a variety of accesses . Problem: An imposter could gain access to the resources of a legitimate user which is more critical the more privileges the user has. Especially for distributed services, how can we prevent imposter from accessing these resources. Forces: • Different users can have different access-rights. Before granting access, identifying the user is required. • Different users may use different ways of authentication, therefore a generic approach is required which is independent of the different approaches. • The authentication-process must be reliable because other systems trust the authenticator and base their access decisions on it. Solution: At the SINGLE ACCESS POINT (see 10.2.13) the user-interactions can be monitored and a protocol can be applied to verify the identity of the user. E.g. in a distributed environment, when a remote object is requested, the AUTHENTICATOR can do the protocol negotiation plus authentication. If both are successful, the AUTHENTICATOR can create and deliver an object representing the requested object. Example: Figure 1 shows an abstract class diagram outlining the elements of this pattern. The authenticator verifies requests and creates a “proof of identity” for the subject. An example of a concrete implementation of this pattern is the “pluggable authentication module” (PAM) in Unix environments (see link under “further information”). Consequences: When applying this solution the following benefits should be considered: • We can gather different ways of authentication into one location which makes it easier to maintain. • The AUTHENTICATOR pattern can grant multiple concurrent access to remote objects. • This generic approach makes the solution independent of the systems on both sides, the client-side and the system of the remote object.
21
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Figure 1: Flow diagram after Schumacher et al • Any number of algorithms for ensuring authentication can be used. Hereby the trade-off between security and costs have to be taken into account. • The AUTHENTICATOR can provide a proof of identity, like a token for further use. Disadvantages: • It can become increasingly complex and costly with an increasing level of security. • Performance costs may be effected since there have to be done more checks. • In existing distributed environments the AUTHENTICATOR may overlap already provided authentication features. Further Information, please refer to: • Schumacher et al [Schumacher, 2006] • Brown et al [F. Lee Brown, 1999] • OWASP www.owasp.org/index.php/GuidetoAuthentication • Also the OWASP-ESAPI provides ready and usable authenticator-classes to use. www.owasp.org/index.php/Category:OWASPEnterpriseSecurity API • Pluggable Authentication Module (PAM) http://en.wikipedia.org/wik i/Pluggable_authentication_module Dependencies: • This pattern is typically implemented using the SINGLE ACCESS POINT (see 10.2.13) and/or CHECK POINT (see 10.2.3). • It may make use of the STRATEGY pattern to vary between different verification mechanisms.
22
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Figure 2: from Schumacher et al 10.2.2
Authorization
Intent: An information system has different resources which can be accessed by a user or process (the subject). How can we describe which subject is authorized to access which resource? Context: Every information system where we want/need to control access to resources. Problem: Not every resource in an information system should be accessible to every subject. A subject can be a user or a process. One necessity is to previously define how resources can be accessed. Otherwise a subject can easily circumvent authorization measures. Forces: • The access control mechanism needs to be independent from the type of the resource. • The administration of the authorizations must be efficient and consistent to administer. Solution: Show for each entity (Subject) which can access resources, if and how it can access a resource. This is realized by an extra rights object which defines the access rights for each protected resource. Another mechanism, e.g. the REFERENCE MONITOR pattern (10.2.5) and the SINGLE ACCESS POINT (10.2.3) are recommended to enforce AUTHORIZATION. Example: Figure 2 outlines the relationship between a subject requesting access to a protected object and the rights depending on this relationship. Consequences: When applying this solution the following benefits should be considered:
23
10.2
Access Control
10
SECURITY DESIGN PATTERNS
• This solution is independent from the type or the resource. • The Subjects can be of different types like single users, roles or processes. • Authorization rules can be added, modified or removed. This allows flexible management of the authorization rules. • Implied subjects and objects can be used to improve flexibility (which costs extra processing time) Disadvantages: • If there are many subjects and objects the number of rules can become very large and difficult to maintain • The implication of new rules might be hard to realize by an administrator • Another system or method to enforce the authorization rules is required. Further Information, please refer to:
• Priebe et al [Torsten Priebe, 2004] • Schumacher et al [Schumacher, 2006] • OWASP https://www.owasp.org/index.php/Guide_to_Authoriz ation • Apache Foundation http://httpd.apache.org/docs/2.2/howto/au th.html Dependencies: The following patterns can be used in combination with AUTHORIZATION to enforce authorization rules. • REFERENCE MONITOR 10.2.10 • MULTILEVEL SECURITY 10.2.9 • SINGLE ACCESS POINT 10.2.13 10.2.3
Check Point
or: Policy Enforcement Point; Access Verification; Validation Screen; Pluggable Authentication Intent: This pattern enforces security policy and encapsulates the necessary algorithms which can contain any amount of required security checks. Typically these checks include identification and authentication checks but can also include others like keeping track of failed security breaches to discover malicious activities. This pattern typically is located at the SINGLE ACCESS POINT to prevent repeated use. Also CHECK POINT can be requested by sub-systems to request repeated and enforced identification and authentication if required. Context: Any information system which is protected from unauthorized access and you need to authorize clients to be able to enter the system.
24
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Problem: One needs to check identification and authentication (I&A) but do not want to make the system too complicated to use. Another use is if one wants to discover breakin attempts and take appropriate actions if such an attempt occurs. Additionally one does not want the checking code to be spread out through the application which makes it very difficult to debug and maintain. During development one wants to allow testers to access functions without being interrupted by not yet implemented security checks. Where and how can these different functions be implemented without spreading the code throughout the application? Forces: • A way of authenticating users and granting authorizations is required. • Users do make mistakes during the process of authentication, these mistakes should be tolerated by simultaneously discovering break-in attempts. • Take action about break-in attempts or too many failed log-in tries. • Prevent from spreading checks throughout your system. • Make it easy to change security checks when better I&A techniques are available or your I&A requirements have changed. • Make it easy to test these security-critical code. Solution: This pattern describes how to create an object which encapsulates the algorithm for enforcing the security policy. The interface of the CHECK POINT can also provide further security-related functions like define hooks for SECURITY SESSION or attack-detection patterns. For development a null CHECK POINT can be set up which simply accepts any authentication requests. The CHECK POINT can also provide interfaces for additional checks like application specific access controls, which are not done when entering the system but are required by sub-systems. Example: Figure 3 outlines a combination of the SINGLE ACCESS POINT and the CHECK POINT. The concrete checkpoints themselves make use of different other patterns and methods, like the AUTHENTICATOR or the SECURITY SESSION. Consequences: When applying this solution the following benefits should be considered: • CHECK POINT is a concrete implementation of organizational security policies. • It is easily accessible and maintainable. • It allows easier testing and development. It allows more thoroughly testing on this one critical component than would be efficient when testing the whole system. • Reuse of code and components. Liabilities: • Some checks may not be performable at startup but need to be provided later on. • This can become a single point of failure and undermine security. Therefore thoroughly testing is required. • The checking algorithms can become very complex if one wants to detect malicious users.
25
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Figure 3: Flow diagram after Schumacher • The design of a good and future-proof interface for CHECK POINT can be very challenging. • The configurations can become very complicated, e.g. if a Chain of Responsibility is used, to understand the implications can be very complex. Further Information, please refer to:
• Schumacher et al [Schumacher, 2006] • Yoder, Barcalow [Yoder and Barcalow, 1998] • Wang et al [Wang et al., 2005] • Babar et al [Babar et al., 2005] Dependencies: • SINGLE ACCESS POINT (see 10.2.13) is used to hook this pattern into. • SECURITY SESSION (see 10.2.12) is useful in combination • ROLE-BASED ACCESS CONTROL (see 10.2.11) is useful in combination • STRATEGY [Gamma et al., 1995] can be used to vary on the checking methods 10.2.4
Controlled Virtual Address Space
Intent: System- and user-processes use virtual address space (VAS). This pattern describes how to control the access of processes to the VAS by splitting the VAS into segments which correspond to the logical units in the processes. Access rights are represented by descriptors.
26
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Figure 4: Block diagram after Schumacher Context: Operating systems with a variety of system- and user-processes, possibly with a variety of users. Processes belonging to one user and one program has to be able to share areas of memory. The access to this shared memory segments has to be controlled. Problem: If access of processes to memory is not controlled, a process could harm integrity and confidentiality by overriding or reading data in memory-segments belonging to other processes. Forces: • There are different ways to handle VAS, like some systems use single-level address space, others use sets of address space. Again others may split the address space between users and system. The solution should be independent of these specifications and valid for all of these types. • There will be a variety of different access rights and all should be addressed equally. Solution: The virtual address space is divided into segments. In addition there are descriptors describing the starting address, the limits of the segment the access rights and the type of permitted accesses (read, write, execute). The difference to the usual virtual address space is that the descriptor also describes access permissions. Example: Figure 4 shows how the descriptor manages the access to the segments on the virtual address space (VAS). Consequences: When applying this solution the following benefits should be considered: • The access to segments can be protected, also sharing of memory, based on descriptors with similar base-limit pair is possible. • This solution applies to different types of VAS-management • The type of the resource does not matter.
27
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Drawbacks: • Storage allocation becomes inefficient. • Overhead by checking the descriptors, therefore hardware-support is required. • When using multiple address spaces an extra identifier is required. Further Information, please refer to: Schumacher et al [Schumacher, 2006]. Dependencies: • AUTHORIZATION (see 10.2.2). The CONTROLLED VIRTUAL ADDRESS SPACE is a direct implementation of the AUTHORIZATION pattern. • EXECUTION DOMAIN pattern (see 10.4.5) which is a more general pattern, because it isn’t restricted to memory only. 10.2.5
File Authorization
Intent: The FILE AUTHORIZATION pattern describes a solution how access to files can be controlled in an operating system. The pattern describes the specific ways in which a file can be used, e.g. read, write, copy, ... and it describes which users (or roles) are authorized to use these files in which ways. This pattern is a specialization of the AUTHORIZATION pattern where the protection object now is a file on the system and the operating system manages the access. Context: Every operating system in which files are being accessed by different users and to access restrictions apply to these files. Due to organizational needs files need to be shared, e.g. from workstations, where one user may access his files from different workstations. Nonetheless, other users with another authorization should not be able to access the first user’s files. This pattern describes a way how to use the home-directories of users to make files only accessible to the authorized user. Problem: The content of files may contain security-sensitive, business-sensitive or usersensitive information ant therefore access to these files should be restricted to authorized users only. This is especially difficult in a shared environment, e.g. at workstations, where many users have access to a system and therefore the system needs to share the files to different workstations. Nonetheless the correct user authorization needs to be verified. Forces: • The solution should be independent of the type of the accessing subject. E.g. the subject can be a user, a role or a group. It should be able to put users into groups and map the group rights back to the user. • There are different ways of accessing files and the solution should take all of them into consideration. These access rights can be reading, writing, deleting, copying and others. • File systems are handled differently in different operating systems. The solution should be independent of the underlying system. • The solution should take care of the fact that some systems do not use some functions, like some systems may not use workstations or roles. The solution should be easy to adopt to these differences.
28
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Figure 5: Block diagram after Schumacher
Figure 6: Sequence diagram after Schumacher Solution: The common way is to make use of the AUTHORIZATION pattern to describe file-access by subjects. In addition the solution makes use of the tree-structure of files and directories. Directory-access-rights can be mapped hierarchical to the containing files. Since files may only be accessed from certain workstations, these workstations can be used as protection object again and the AUTHORIZATION pattern can be applied. This is basically a specialized variation of the AUTHORIZATION pattern where the protection object is replaced by a file component, all managed by an access control list (ACL). Example: In figure 5 we see the variation of the AUTHORIZATION pattern. A subject requests access to a file or file component. The Access-Control-List includes entries with specific authorization rights descriptions. Figure 6 presents the according sequence diagram.
29
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Consequences: When applying this solution the following benefits should be considered: • The solution is independent of the type of subject, may it be a user, role or group and allows nesting and structuring of roles and groups. • The protected objects can be single files or directories as well as tree-like structures of directories and files, where it is possible to map the access rights of a directory to all included files and sub-directories. • Not only the basic access types like read, write, delete are manageable, but also more complex access-types are possible. • Access from workstations can be controlled too. The control of workstation authorizations is handled separately from file authorizations. • This solution is independent of the underlying system. The concrete implementation is usually not system independent though. Drawbacks: • This pattern still requires a concrete implementation which might not be forced to use the access matrix model like in Unix-systems where the pseudo-access matrix is not useful for implementing this pattern. In such cases extra constraints are required to force all instances to use the correct access matrix model. • A mechanism enforcing the access restrictions typically is required as often as the access control lists (ACLs) are a part of the file and the system may represent these ACLs correctly but not pay attention to the associated file components. Further Information, please refer to: Schumacher [Schumacher, 2006]. Dependencies: • This pattern makes use of the AUTHORIZATION pattern (see 10.2.2) and in some ways is a specialized variation of it. 10.2.6
Full Access With Errors
or: Reveal all and handle exception; notified view; Full Access with Errors Intent: Designing a graphical user interface (GUI) where the different users have different access rights to system functions can be difficult. This pattern provides one solution opposed by the LIMITED VIEW pattern. Users will get the full view of the GUI. When an operation is requested, the system will check if the users are allowed to perform the operations and either send an error-message or run the operations. Context: An interface design of a system with access restrictions to parts of the interface. Usually this applies to a GUI but can also be used in other systems (like Linuxterminal).
30
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Figure 7: Block diagram after Schumacher Problem: The question appears what should the users be shown when they access the system and how to deal with them when they want to access operations they are not allowed to. Forces: • Users should not be able to run operations they are not permitted to. • Users should not be able to view data to which they have no access rights. • If options in the user interface start appearing and disappearing it may confuse users. • Users should be able to see what they can do, therefore hiding available functions is not an option. • Showing functions for which the user has no privileges could tease the users to upgrade their access rights, e.g. by upgrading their account to a premium member. • The privilege-grouping of the functions might not be known at the time when designing the user-interface. Solution: Design the user interface in a way that they can see all options. When an operation or data is requested by users, the system checks the access rights and either responds with an error message or will perform the operation and return the results. Example: One example is the Linux terminal, which shows all possible options, e.g. by providing all possible options when processing the –help order, but still restrictions apply. If a restricted operation is requested then you will see an error message saying that you are permitted to process this operation. Figure 7 shows a class diagram how such a solution could be implemented. Consequences: When applying this solution the following benefits should be considered: • There is only one user interface for all users. Therefore you do not have to care about multiple views.
31
10.2
Access Control
10
SECURITY DESIGN PATTERNS
• All available features are being demonstrated, even if the user has no permission to use them. • Changing permissions does not influence the user interface. • Documentation and Training materials can be done once and do not need to be done for every user group separately. • It fits well in situations where users are able to upgrade their privileges, e.g. with a premium account. Disadvantages: • The user interface can be blown up and may be bad for usability. • Steady error-messages can be very annoying for users and may reduce acceptance of the system. • For every single operation the access rights need to be checked, therefore validation of the operations can become more difficult. Further Information, please refer to: • Schumacher et al [Schumacher, 2006] • Yoder, Barcalow [Yoder and Barcalow, 1998] • Wang et al [Wang et al., 2005] • Babar et al [Babar et al., 2005] Dependencies: • LIMITED ACCESS (see 10.2.7) is a competitor to this pattern. A possible solution in between is to “grey out” inaccessible options. • ROLES-BASED ACCESS CONTROL (see 10.2.11) is useful in combination • Error-handling has to be done very carefully to not reveal critical information about the system. Please see CHECKS13 and OWASP https://www.owasp.org/ index.php/Error_Handling 10.2.7
Limited Access
or: Limited Access; Blinders; Child Proofing; Early Authorization; Invisible Road Blocks Intent: Designing a graphical user interface (GUI) where the where different users have different access rights to system functions can be difficult. This pattern provides one solution opposed by the FULL VIEW WITH ERRORS pattern. Users will get shown only the operations for which they have the right privileges. All operations which they are not allowed to perform are not shown in the GUI. Context: An interface design of a system with access restrictions to parts of the interface. Usually this applies to a GUI but can also be used in other system interfaces. 13 [Gamma
et al., 1995]
32
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Figure 8: Block diagram after Schumacher Problem: The question appears what should the users be shown when they access the system and how to deal with them when they want to access operations they are not allowed to. Forces: • Operations which cannot be performed by users should not be shown in the GUI. • Data which is not accessible by users should not be shown. • Avoid telling users with (error-)messages what they are allowed or not because user do not like to be told what to do. • To not provide access to some operations at all makes input validation easier because of a reduced amount of operations which have to be validated. • Options appearing and disappearing, due to changed privileges, may irritate users. Solution: Show users only what they are allowed to access. In the GUI, only the options accessible by the users are displayed at all. This requires that when creating the view the authorization and permissions have to be checked. E.g. at the CHECK POINT the user privileges are cached in the SECURITY SESSION. The implementation of the GUI then can use the session object to check which operation a user is allowed to perform and only render the allowed elements into the GUI. To render not accessible elements, the NULL OBJECT could be used, but the concrete implementation is beyond this pattern. Another option, if the different use-cases and their privileges can be reduced in two or three different classifications, then it would be possible to have these three GUI-designs and switch between them according to the user-roles. Example: Figure 8 shows a block diagram outlining the solution. In this solution the interface does already do all authorization checks and then is responsible to render only those elements for which the accessing user has appropriate access rights. The underlying system does not really need to check access rights itself but still should consider the “defense in depth” principle and do checks on its own.
33
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Consequences: When applying this solution the following benefits should be considered: • Provides a simplified interface to users because they do not have to pay attention to what they are allowed to or not. • Because users can only access allowed operations, developers do not need to care about validating each operation-access. • Security-checks can be simplified because they all can be done up-front. • Users won’t become frustrated by error messages popping up. Drawbacks: • Appearing and Disappearing options, because of changed privileges, can frustrate users. • Documentation and Training materials have to be re-written for different views. • Empty fields, because of not accessible and therefore not rendered options can look ugly and provide a bad user experience. Also rearranging the options, like menupoints can confuse users. • Retrofitting this pattern into existing systems can become very difficult. • Relying only on the front-up permission-checks, can be dangerous. Therefore the Defense in Depth principle should be applied too. Further Information, please refer to:
• Schumacher et al [Schumacher, 2006] • Yoder, Barcalow [Yoder and Barcalow, 1998] • Wang et al [Wang et al., 2005] • Babar et al [Babar et al., 2005] Dependencies: • CHECK POINT pattern (see 10.2.3) is often used in combination to hook in some other patterns like implementing the role-based access control. • ROLE-BASED ACCESS CONTROL (RBAC) pattern (see 10.2.11) is sometimes used. The combination of LIMITED ACCESS with RBAC allows that a limited number of views can be designed and made, matching the user-roles. The benefit is to have a limited, well-defined amount of views which have no blank space because of not rendered functions. • SECURITY SESSION pattern (see 10.2.12) is typically used in combination. • FULL VIEW WITH ERRORS (see 10.2.6) is the direct competitor. • The non-security patterns STATE and STRATEGY 14 , or their security hardened variations, can be used for implementing LIMITED VIEW. 14 [Gamma
et al., 1995]
34
10.2
Access Control
10
SECURITY DESIGN PATTERNS
• The non-security pattern NULL-OBJECTS15 can be used to fill the gaps which occur by not rendering inaccessible options. • The non-security pattern CHECKS16 describes handling of error-messages in a graphical user interface. 10.2.8
Metadata-Based Access Control (MBAC)
or: Attribute-Based Access Control (ABAC) Intent: This pattern describes a way to control access based on properties of subjects. This is an alternative where the ROLE-BASED ACCESS CONTROL (10.2.11) does not work well. Context: Any information system with a large number of users where some users may not be pre-registered and we need to control access to resources. Problem: We may have environments, like web portals, where we do not know the subjects in advance but need to control access to computing resources, too. Prohibiting access may not work either, because access could be dependent on certain values of the object. E.g. in a hospital, each patient should be allowed to access the own medical reports. Solution: The solution is to take requested objects and subjects in request and represent them as sets of attributes or property values. Also authorization subjects and objects need to be represented as sets of predicates or assertions. This results in descriptors of objects and subjects like groups, not explicitly but implicitly grouped by their attributes Example: Figure 9 outlines the relation between a subject and the requested object depending on their attributes. This figure is an abstract class model. For another example please refer to RSBAC 10.7.13. Consequences: When applying this solution the following benefits should be considered: • Using the MBAC pattern allows to integrate authorization entities based on their semantics. • It allows the applying security policies without predefined roles to not pre-registered subjects Disadvantages: • This approach only works when attributes or semantics are well defined. Compared to the RBAC pattern typically in the case of MBAC the use-cases can not be used to assign the roles and their privileges. 15 [Gamma 16 [Gamma
et al., 1995] et al., 1995]
35
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Figure 9: Class diagram after Priebe et al Further Information, please refer to:
• Mariemma I. Yagüe [Mariemma I. Yagüe, 2005] • Torsten Priebe et al [Torsten Priebe, 2004] Dependencies: This pattern is dependent or related to the following patterns: • ROLE BASED ACCESS CONTROL (RBAC) which is an alternative (see 10.2.11). The RBAC and MBAC can even be used together under some circumstances. • SESSION (see 10.2.12) is typically used in combination - CHECK POINT (see 10.2.3) is typically used in combination 10.2.9
Multilevel Security
Intent: We have an information system where some resources have critical value. This pattern describes how to classify sensitive information and to define security clearances to users. The access of users to data is based on policies. This works especially well with the ROLE-BASED ACCESS MODEL (see 10.2.11) if the roles are in an hierarchical order. Context: A system which contains resources which have sensitive information which should be accessed only by certain users. Problem: We have sensitive information and want to restrict the access to this information. Forces: • Based on its sensitivity, confidentiality and integrity, data need to be protected. • Based on their position, users have to be granted access to data. • The solution should provide an easy and efficient way to increase or decrease the ability of users to access sensitive data.
36
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Solution: Users are classified (clearance level) and data is classified (sensitivity level). The pattern uses the Bell-LaPadula17 model for user clearances and Biba’s model18 for integrity policies of data. The higher the user-clearance, the more data of higher sensitivity levels the user can access. Example: In a hospital, health data of patients are categorized as sensitive. Cleaning staff has no clearance, in some cases some of the patient data is less sensitive, e.g. which medicine the patient requires and can be accessed by health personnel. More sensitive information about the patient can only be accessed with the clearance of a doctor. Consequences: When applying this solution the following benefits should be considered: • The user classification, e.g. after the business unit in the organization, is relative simple and organizational policies can be used. • This solution allows to isolate processes and execution domain from each other. Disadvantages: • We need to label data according to their classification. • What processes are trusted to assign the classifications to users and data? We need a trusted process which can provide this job. If the process is malicious, it can grant access rights to the wrong persons or processes. • This pattern can only be used if it is possible to structure data and users into sensitivity levels and clearances. • security can be broken by hidden channels. Further Information, please refer to: Schumacher et al [Schumacher, 2006] Dependencies: This pattern provides an abstract solution. Therefore another solution is required to enforce the MULTILEVEL SECURITY. One solution could be the ROLEBASED ACCESS CONTROL pattern (see 10.2.11). 10.2.10
Reference Monitor
Intent If in information systems users or processes request access to restricted resources, we want to enforce access control to theses resources. This pattern describes an abstract model how to enforce access control to resources by intercepting all requests and checking them against authorization rules. This pattern is a direct implementation of the “Complete Mediation” principle. Context: This pattern can be applied in an information system where users request access to restricted resources, we have authorization rules and need to enforce them. 17 Wikipedia 18 Wikipedia
http://en.wikipedia.org/wiki/Bell%E2%80%93LaPadula_model http://en.wikipedia.org/wiki/Biba_Model
37
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Figure 10: Class diagram after Schumacher et al Problem: The problem is, that we have authorization rules but without a method to enforce them, they are useless and can be bypassed. Forces: • authorization-rules need to be enforced whenever a request to a restricted source is made. • As there are many possibilities of enforcing authorization a model is required which applies to all levels of the system. Solution: This pattern describes an abstract process. All requests will be intercepted by this process and checked if they are compliant with the defined authorization rules. This can be realized e.g. by the CONTROLLED OBJECT MONITOR. A specialized variation is the CONTROLLED OBJECT MONITOR. The CONTROLLED OBJECT MONITOR intercepts all access requests to an object coming from processes and checks their access rights to the requested object. Example: Figure 10 shows the basic setup as it is known from the AUTHENTICATOR pattern. The difference is the REFERENCE MONITOR which intercepts all requests and checks them for their authorization and therefore enforcing AUTHORIZATION. Consequences: When applying this solution the following benefits should be considered: • We can make sure that all requests are compliant with the authorization rules under the restriction that all requests are intercepted. • This pattern describes an abstract process which can be used in different implementations Liabilities: • Each type of resource requires a specific implementation. • The implementation may result in unacceptable high performance costs. This could be solved by performing some of the checks at compile-time.
38
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Further Information, please refer to:
• Schumacher et al [Schumacher, 2006] • Dougherty et al [Chad Dougherty, 2009] (See Controlled Object Monitor) Dependencies: There are two specializations of this pattern: • CONTROLLED OBJECT MONITOR (see 10.7.5). • DEFER TO KERNEL (see 10.7.6 is also a specialized variation of this pattern. This pattern also works well in combination with the AUTHORIZATION pattern (see 10.2.2). 10.2.11
Role-Based Access Control
or: Roles; Role Rights Definition Intent: This pattern is a variation or specialization of the AUTHORIZATION pattern (see 10.2.2). If used properly this pattern also supports the “least privilege” principle in systems with many users. The difficulty is that roles require a systematic way how to assign appropriate privileges to each role. This solution provides a systematic way of assigning the appropriate rights to roles. The implementation of this mapping of roles and access rights on protected objects is not defined in this pattern. Another mechanism is then required to enforce this solution, e.g. the REFERENCE MONITOR pattern (see 10.2.10). Context: Any information system with a large number of users, where user-profiles can be separated into different roles and therefore the ROLE-BASED ACCESS CONTROL pattern is used. Problem: When a large number of privileges and different use cases are available, the assigning of the required privileges to each use-case is difficult. If too many rights are assigned to a role, the “least-privilege” principle is undermined and information security may be breached. Forces: • Typically roles are chosen to match tasks in an organization. The assigned privileges have to support all necessary privileges to allow the task to be done properly. • The privileges assigned to roles should be compliant with the “least privilege” principle. • Changes to roles and their assigned privileges should be easy to maintain. • The solution should be system-independent.
39
10.2
Access Control
10
Subject
SECURITY DESIGN PATTERNS
Role MemberOf
id name
ProtectionObject
isAuthorizedFor
id name
Right accessType checkRights()
Figure 11: from Schumacher et al
Right accessType
Subject
*
hasRole
*
*
Role
1
* isAuthorizedFor
Object
* activeInSession
subroleOf
{subset}
* hasSession
* Session
Figure 12: from Priebe et al From Priebe 2004
Solution: This pattern makes use of use-cases, which have previously been defined. They outline the interaction of a user or process with the system. The different actors in the use-cases can be used as roles, e.g. the marketing person as “marketing_employee”role or the network administrator as “network_admin”-role. In the next step all roles appearing in a use case have to be assigned with privileges for all operations which are initiated by the role. This has to be done for each use-case. After that every role has the privileges assigned required to do their work. A diagram of the use cases and a sequence diagram to show the interactions should be made accordingly. Example: Figure 11 shows the simple relationships between the subject accessing and the protected object. The subject belongs to a role while the role itself has specific access rights to the protected object. In addition, figure 12 shows a more complex variation of the pattern while figure 13 presents a corresponding block diagram. For another example please refer to RSBAC 10.7.13.
40
10.2
Access Control
10
Role < as actor >
object1:
SECURITY DESIGN PATTERNS
object2:
objectN:
op1
op2
...
opN
Figure 13: Block diagram after Schumacher et al After Schumacher2006
Consequences: When applying this solution the following benefits should be considered: • Using this approach, the role-rights are defined according to their tasks. • The “least privilege” principle is directly supported. • Using the use cases ensures that all necessary privileges can be taken out of them • This approach allows system-independence. • Easier to maintain than to assign privileges to each user separately. • Roles reduce the complexity of administration access rights. Disadvantages: • If appropriate use cases are not available this may require very specialized expertise, which may not be available. • If users have individual privileges, it would require one role for each user which makes it complicated and useless. • Another mechanism is required to enforce the “separation of duty” principle, otherwise conflicts could occur like that the privilege requester also is the one granting the privileges. E.g. someone requesting a budget is also the one deciding on budgets in the company, this way he can grant himself an additional budget or a higher salary without someone else controlling. Further Information, please refer to: • Oracle http://docs.oracle.com/cd/E11882_01/network.112/e1 6543/guidelines.htm#CHDHFIFG • Schumacher et al [Schumacher, 2006] • Babar et al [Babar et al., 2005] • Priebe et al [Torsten Priebe, 2004]
41
10.2
Access Control
10
SECURITY DESIGN PATTERNS
• Wang et al [Wang et al., 2005] • Yoder, Barcalow [Yoder and Barcalow, 1998] Dependencies: This pattern typically makes use of the CHECK POINT pattern (10.2.3). 10.2.12
Security Session
or: Namespace; Threaded-based Singleton; Users Environment Intent: Instead of re-authenticating a user for each system function, this pattern provides a solution to keep track of a user’s global information and providing them to the systems functions without passing all access rights or re-authenticating a user repeatingly. It creates a session object which is linked with the user or process who want to access the system. Context: Any system used by multiple users or processes which needs to share securityrelevant data, like authentication data, to different sub-systems or functions. Additionally other security relevant data often has to be shared to different functions. Problem: Many components, acting on behalf of a user or process, require access to shared security values of this user. How can repeated authentication and requesting these values be avoided? Forces: • Providing access to global variables which are distinguished for every individual user (therefore a global variable will not work). • The shared values might change over time. • Multiple applications might use different values and might change them. • Passing all values on might slow down the performance too much. • Asking a user repeatedly for the values is annoying to the user and can decrease acceptance of the system drastically. Solution: The solution is to create a session object which holds the user-relevant data needed to be shared by many objects. This object can be passed around and used as needed. This session object is associated with every user-action, either implicitly by associating it with the actions coming over the user’s connection, like inside the operating system, or explicitly with an identifier, e.g. a session-cookie. In addition the session object can be used to provide limited storage for other system-functions which may need to store certain data, e.g. the shopping-cart of an online-shop. Example: Figure 14 outlines the SECURITY SESSION pattern in a class diagram and a context diagram. As another example figure 15 shows a context diagram which outlines the use of a SECURITY SESSION in combination with AUTHORIZATION context. E.g. can the mechanism enforcing AUTHORIZATION make use of the security session as the one point to receive the necessary security credentials of the accessing system. In some cases the security session can also be used as a cache for access rights so that verification of repeated access requests to an individual protected resource can be processed faster.
42
10.2
Access Control
10
SECURITY DESIGN PATTERNS
access
User
Check Point
sign in do operation sign off
Component
sign in/off
sign in sign off
operation
check rights
obtain session
create session
Manager
Session
create session dispose session look up session check time-outs
manages *
user info rights for user timestamp
Figure 14: Block diagram after Schumacher
subject
*
hasAuthorizationContext
*
1
AuthorizationContext * activeInSession
{subset}
* hasSession
* session
Figure 15: Context diagram of the Security Session in combination with an authorization context after Torsten Priebe
From Priebe 2004
43
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Consequences: When applying this solution the following benefits should be considered: • The session object provides a single place with a common interface to keep all security-relevant user-data. • A single object can be passed around instead of many different values. • Change of session values can be propagated simply because of a single place where all other objects will look at. • New shared variables can be stored easily by passing them into the session object. Liabilities: • When objects do not need a session object in first place, but later need one and create one, there could be different session objects which are not connected to each other. • If the session objects become too large and multiple users simultaneously use the system, system performance can be limited. Therefore it is important not to store unnecessary information in the session object. Additionally it might be useful to think about session time-out and a garbage-collection which can be done by the MANAGER. In distributed systems, session-identifiers could be hijacked and be used from imposters. • If the session-object is stored client-side, the cookie needs to be encrypted and signed to avoid compromised data. If the system allows, storing the session object server-side and store only a session-identifier in the cookie, could be a solution. Further Information, please refer to:
• OWASP https://www.owasp.org/index.php/Session_Management • Schumacher et al [Schumacher, 2006] • Yoder, Barcalow [Yoder and Barcalow, 1998] • Wang et al [Wang et al., 2005] • Babar et al [Babar et al., 2005] • Priebe, Fernandez [Torsten Priebe, 2004] Dependencies: • Typically the CHECK POINT pattern (see 10.2.3) is used to hook this one in. • The MANAGER pattern19 can be used to keep track of the session objects and their life cycles. 10.2.13
Single Access Point
or: Login Window; Validation Screen; One Way In; Guard Door 19 [Gamma
et al., 1995]
44
10.2
Access Control
10
SECURITY DESIGN PATTERNS
Intent: With this pattern we want to ensure that there is only one entry point into the system. At this single access point every visitor will be validated and entry allowance is either granted or not. Single access point is easy to implement and can then be used to easily hook in other processes like the CHECK POINT. A single entry point may collect all necessary information required for the entire application. Context: Your system needs to be accessed externally, e.g. to run an application, and you need to restrict these accesses. Problem: If we have a system which consists of several internal sub-systems, external access can become complicated to be checked. To check all interactions from an outside user to the different sub-systems can require many different checks which is complicated and can lead to performance loss. Solution: Set up a single entry point for using the system, e.g. a login screen which collects all basic information about the user. This information can be passed on for identification and authentication to a CHECK POINT. If users passed the SINGLE ACCESS POINT they can freely use the system from that point on, though, some sub-systems may require an additional authentication or authorization process. Example: A Linux system typically has a login screen which is the SINGLE ACCESS POINT. At his point user-name and password are required (other credentials may do it too) which are passed on to a CHECK POINT which authenticates the user and will set up a session for the user. Once logged in, the user is relatively free to use most of the applications, though some application may require some additional root-authorization to be used. Consequences: When applying this solution the following benefits should be considered: • A SINGLE ACCESS POINT provides a single place for entering the system and a single place for setting up the system. • This pattern provides a single place where to place the guard for the system, however, you may need to implement DEFENSE IN DEPTH. • It simplifies the inner structure since authorization does not need to be repeated by every sub-system. Liabilities: • Multiple access points could improve the application’s usability and flexibility. • You need to be able to trust your gatekeeper and your boundary protection. • The checks at the SINGLE ACCESS POINT may need to be more thoroughly than some uses may require, because some other sub-systems, which may not be used by the user, do require it. This could lead to less acceptance by users and slow down the entrance process. • The gatekeeper could become your single point of failure, allowing access to many of the sub-systems, or, if the SINGLE ACCESS POINT is down, e.g. in a DDOSattack, there is no other way for users to access the system.
45
10.3
Accounting
10
SECURITY DESIGN PATTERNS
Further Information, please refer to:
• Schumacher et al [Schumacher, 2006] • Wang et al. [Wang et al., 2005] • Babar et al [Babar et al., 2005] • Yoder, Barcalow [Yoder and Barcalow, 1998] Dependencies: • this pattern typically provides the location where the CHECK POINT pattern is set (see 10.2.3) • together with the CHECK POINT, others can be hooked into, like AUTHENTICATOR (see 10.2.1), SECURITY SESSION (see 10.2.12) and others.
10.3
Accounting
10.3.1
Secure Logger
Intent: Some attacks use system logs to reveal potentially useful information about the system. This pattern prevents attackers from gathering such information or to hide their actions by editing the logs. Context: Everywhere system logs or another form of logging is used, e.g. for accounting. The information in the system logs could be dangerous if an attacker gets access to it. Also SECURE LOGGER is useful where logs are used to detect and diagnose attacks to the system. Problem: To detect attacks and diagnose system failures many detailed information is logged. This information can be useful for attackers, or an attacker may want to delete some of this information to hide an attack. Still system logs are required to detect and investigate on attacks and for debugging if a system failure occurs. Forces: • The more detailed the logs are, the more useful they are for debugging and investigating on intrusions, but also the more they are valuable for a potential attacker. • More detailed logs have effects on the performance. Solution: The SECURE LOGGER describes a solution where the application and the logging is separated and isolated from each other. The application still has to generate the data which has to be logged. This data is passed on to the SECURE LOGGER. The SECURE LOGGER system takes care of the logging information in a way that it is difficult, if not impossible for an intruder to get access to the logging information. Additionally we have a “Log-Reader”. This is necessary because logging data is stored in a protected manner and reading is only allowed for a specific reading mechanism. This log reader can also be a part of the SECURE LOGGER.
46
10.3
Accounting
LoggerClient
10
LoggerBean
SECURITY DESIGN PATTERNS
LogTopic
SecureLogListener
logMessage
loadMessage
onSecurityEvent
Client
EJB Logger Client
J2EE Application Server
Logger
Logging Host
MDB Secure Log Listener
JMS Log Topic
TimeServer TimeService
From Black Hat Briefings
Figure 16: Sequence diagram after Black Hat Briefings Example: In figure 16 a sequence diagram and a class diagram on a J2EE implementation is outlined. This can be implemented accordingly on other systems. A possible combination of this pattern with other patterns is described in the section “Pattern Dependencies”. Consequences: When applying this solution the following benefits should be considered: • The logging system, the SECURE LOGGER can be placed on a remote host, which prevents performance loss at the application system and makes it harder for an attacker to get access to the logging system. • The isolation of the logging system allows an extra step of defense, following the principle of “Defense in Depth”. • An intruder getting access to the log data has only a limited visibility of the datacontent. • Modification of the log data can be discovered by an authorized user. Further Information, please refer to:
• Black Hat Briefings [Briefings, ] • Dougherty et al [Chad Dougherty, 2009]
47
10.4
Operating System Level
10
SECURITY DESIGN PATTERNS
Dependencies: This pattern relies on two other design patterns: • VALIDATOR pattern (see 10.6.1) • EXCEPTION MANAGER pattern (see 10.7.7)
10.4
Operating System Level
10.4.1
Controlled Execution Environment
Intent: This pattern intents a solution which combines three other security patterns, namely AUTHORIZATION, REFERENCE MONITOR and EXECUTION DOMAIN to provide a secured environment for running processes. If processes run in an insecure environment they could potentially access restricted files on the drive or unauthorized search memory and other things. In the worst case, processes could take control over the operating system. Context: Every system where a subject requests processes which are then run with the subject’s rights, e.g. a user-role. The EXECUTION DOMAIN is used to define sets of rights an manage these. Problem: To only have an EXECUTION DOMAIN is not enough. The execution of processes needs to be restricted in order to prevent that these processes access information uncontrolled. Forces: • Processes need to be controlled. • The subject on behalf of which the process can vary, e.g. a user or a role. • The solution should be independent of the type of resource. This includes files, disk-space or I/O-devices. • The solution needs to be flexible enough to provide multiple processes for each subject, with nested or multiple EXECUTION DOMAINs. • Not all rights of the subject are taken for the process, which might require only a subset of the subject’s rights. Solution: This pattern makes use of three other patterns. First, AUTHORIZATION is used to grant and define access rights and roles for the subject. A subset of these rights is used to define the EXECUTION DOMAIN of the process running on behalf of the subject. Finally the requests to create and manage a process are controlled by the REFERENCE MONITOR (or the specialized variation, the CONTROLLED OBJECT MONITOR 20 ). Example: In Figure 17 a class diagram is presented. In this class diagram a process wants to access a ProtectionObject. The process is assigned a UserID and it is executed in an ExecutionDomain which also depends on the privileges associated with the UserID. This CONTROLLED EXECUTION ENVIRONMENT includes a REFERENCE MONITOR as shown in figure 18 which intercepts all access requests and checks them if they are conform with the access right of the EXECUTION DOMAIN before allowing or denying the access to the protected object. 20 [Schumacher,
2006]
48
10.4
Operating System Level
10
SECURITY DESIGN PATTERNS
* Domain Process
1
Executes In
*
CompositeDomain
ID create() enter() delete()
ID
SimpleDomain
*
Activates
Authorization
*
right 1 User
ProtectionObject *
*
ID
ID create() close() delete()
Resource {A} name address amount
ConcreteResource
Figure 17: Class diagram after Schumacher et al
:User
:Process
:Domain
:RefMonitor
:Authorization
x:
activate enter
write(x)
exists(x)
exists(write)
write(x)
Figure 18: Sequence diagram after Schumacher et al
(From Schumacher:2006)
49
10.4
Operating System Level
10
SECURITY DESIGN PATTERNS
Consequences: When applying this solution the following benefits should be considered: • This pattern allows the realization of the principle of “least privilege”. • This pattern is independent of the resource-type. • This solution allows multiple processes with multiple execution domains. • The rights of a process are only a subset of the rights of the subject. But any combination of rights of the subject is possible. Disadvantages: • This pattern adds complexity and may have impact on the performance. • Often the implementation of this pattern is not independent of the base system or the hardware. Further Information, please refer to: Schumacher et al [Schumacher, 2006] Dependencies: This pattern relies on a few other security design patterns as well: • AUTHORIZATION pattern (see 10.2.2) which is a part of the CONTROLLED EXECUTION ENVIRONMENT • EXECUTION DOMAIN pattern (see 10.4.5) which is a part of the CONTROLLED EXECUTION ENVIRONMENT • REFERENCE MONITOR pattern (see 10.2.10) which is also a part of the CONTROLLED EXECUTION ENVIRONMENT • CONTROLLED VIRTUAL ADDRESS SPACE pattern (see 10.2.4) which can be used to realize the memory-access part. 10.4.2
Controlled Object Factory
or: Secure Factory Intent: The CONTROLLED OBJECT FACTORY addresses the way of granting rights to a new object created by a factory. In the request sent to create the object, the features are described. Included in the features is a list describing the required rights to access the object. Context: This pattern can be applied in information systems which need to control access to its created objects. Also authorization rules or policies have to be available. It can be applied when the system uses different versions of an object dependent on its security context.
50
10.4
Operating System Level
10
SECURITY DESIGN PATTERNS
abstractSecureFactory - defaultInstance: AbstractSecureFactory + getInstance(): AbstractSecureFactory + setInstance(newInstance: AbstractSecureFactory) + getObject(givenCredentials: SecCredentials): someObject
defaultInstance
concreteSecureFactoryN + getObject(givenCredentials: SecCredentials): someObject concreteSecureFactory2 concreteSecureFactory1 + getObject(givenCredentials: SecCredentials): someObject + getObject(givenCredentials: SecCredentials): someObject
Figure 19: Class diagram after Dougherty From Dougherty 2009 Problem: In an object-oriented system environment, some processes access objects on behalf of the user. These objects may already exist, e.g. they have been created at the start of the application, or they may be created dynamically on request. Nonetheless access of processes to these objects may be critical and therefore access rights, based on the trust-level of the requesting processes or users, must be defined and enforced. Forces: • The solution should be independent of the type of the object. • Objects from a resource pool require that access rights are assigned dynamically when they are being used. Solution: Every time an object is created, an access control list for these objects is defined. This list contains the information which subject can access the object and in which way. The process creating the object may take the trust-level information from the user’s security credentials or the environments trust-level. The solution could decouple the logic of choosing which object to create from the object itself and the application code. Different objects can apply for similar functions but on different trust levels. This decoupling is done by the CONTROLLED OBJECT FACTORY which creates or chooses the appropriate object depending on the trust level. Example: In figure 19 a class diagram of the CONTROLLED OBJECT FACTORY is presented. A process can request an instance of an object and, taking the security credentials into account the secure object factory chooses the object instance appropriate to the trust level of the requesting process. This typically works well together with the CONTROLLED OBJECT MONITOR (see 10.7.5) which intercepts all requests and then can use the CONTROLLED OBJECT FACTORY (or in the figure called SecureFactory) to provide the request with the appropriate objects. Consequences: When applying this solution the following benefits should be considered: • All objects will have appropriate access rights assigned because they need to be created by the CONTROLLED OBJECT FACTORY.
51
10.4
Operating System Level
10
SECURITY DESIGN PATTERNS
• Access rights can be assigned due to the trust-level or sensitivity of information and the roles of the requesting processes. • The access rights can be inherited from the creating processes or user. • This solution creates a black box to apply the appropriate object for the requested process and current security environment. • Since the SECURE FACTORY makes use of a pool of objects for the same processrequests, each object only needs to implement the functions appropriate for its security environment which makes misuse more difficult. • The objects themselves do not need to check the security circumstances and access rights since this is already done by the CONTROLLED OBJECT FACTORY. • Changes to the security-checks and the logic which selects the objects, have no effect on the implementation of the objects. Disadvantages: • This solution may have impact on the performance. • If objects are created at application-start, the initial rights may not be clear. Further Information, please refer to:
• Schumacher et al [Schumacher, 2006] • Dougherty et al [Chad Dougherty, 2009] Dependencies: • In some cases this pattern can make use of the STRATEGY pattern or the SECURE STRATEGY pattern (see 10.4.8) to vary between different security check mechanisms or object creating mechanisms. • The SECURE BUILDER FACTORY is a specialization of this pattern (see 10.7.14). • In some implementations CONTROLLED OBJECT FACTORY can make use of an AUTHORIZATION mechanism like the ROLE-BASED ACCESS CONTROL (RBAC) to compare the requesting user-credentials with the permission to use a certain object or trust-level. 10.4.3
Controlled Process Creator
Intent: When a new process is created, the CONTROLLED PROCESS CREATOR pattern defines how to grant appropriate access rights to it. Context: This pattern can be applied to every operating system where new processes or threats are created due to applications needs.
52
10.4
Operating System Level
10
SECURITY DESIGN PATTERNS
*child
CreationRequest 1
Process id create() delete() runAsParent()
* AccessRight
1
*parent
ControlledProcessCreator createProcess()
*
createRights
*
accessType object
Figure 20: Class diagram after Schumacher Problem: New processes are created by the operating system and not by the application. An application requests to create a child-process which has access to certain resources. The application and its processes need appropriate access rights to perform their work, but if the processes are not controlled, they could interfere with each other or expand their rights and access data they are not allowed to. Therefore their rights should be carefully assigned due to the “least-privilege” principle. Forces: • A standardized way for selecting a policy and granting access rights is required. • A policy is required. If there is none, conflicting and non-systematic access restrictions could be easily undermined. • A child process may require all privileges of the parent for specific actions, but it usually does not and therefore shouldn’t be granted too many privileges. • The amount of child-processes should be monitored and restricted. • There can be situations where the process requires more than its usual access rights, e.g. by accessing a certain file. Solution: A child process is created when an application makes a system call or message to the operating system to create one. This pattern describes a CONTROLLED PROCESS CREATOR class which is part of the operating system. This class receives the system calls or messages from the parent process to create a child. It describes that the parent also assigns the specific set of privileges for the child process and sends them in the message. With some exceptions these assigned rights cannot extend the privileges of the calling parent. Example: In figure 20 the class diagram of the CONTROLLED PROCESS CREATOR pattern is shown. The specialty here is that the CreationRequest also includes the authorization rights defined by the parent and accordingly a subset of the parent’s access rights.
53
10.4
Operating System Level
10
SECURITY DESIGN PATTERNS
Consequences: When applying this solution the following benefits should be considered: • Security policies can be applied by creating a new process and providing its privileges • The amount of child processes can be monitored and controlled. Disadvantages: • This pattern has implications on the system-performance. Further Information, please refer to: Schumacher et al [Schumacher, 2006] Dependencies: No known dependencies on other patterns apply. 10.4.4
Distrustful Decomposition
or: Privilege Separation Intent: This pattern describes a way of securing an application by separating its functions into mutually untrusted programs. Context: This pattern works for information systems where many user-supplied data have to be dealt with by different processes, which require different privileges. Problem: Attacks often use the fact that processes dealing with the input run with higher privileges than required. How can we apply the principle of “least privilege” to an application which has to deal with different types of user-input? Forces: • Apply the “least-privilege” principle. • At the same time allow to deal with different user-supplied data which require different privileges for processing. Solution: This pattern isolates processes, which are potential security vulnerabilities, into a separate small subset of functions in a way that compromising one subset does not compromise the whole system. The system will be broken up into smaller programs which run as separate processes and communicate with messages like RPC, sockets, SOAP, etc. Each small program or process deals with only a small, well-defined subset of functions. Example: As an example the Unix SSH implementation can be used. In there the different tasks are separated into single programs. The first program listens on port 22. If a requests is being delivered, this process will fork a child process to do the authorization negotiations. Once the authorization was successful, another child process is launched to do the networking stuff. These processes work as separate sub-programs.
54
10.4
Operating System Level
10
SECURITY DESIGN PATTERNS
Consequences: When applying this solution the following benefits should be considered: • The attack surface or the smaller sub-programs are reduced. • If properly done, the principle of “least-privilege” for the processes can be applied. • Potential loss of data to possible attackers can be reduced, since each sub-program has only the privileges to access the data it really requires for processing its functions. Drawbacks: • Potential overhead which can have impact on the system-performance. • Implementation of communication between the processes may become complicated. • Possible duplicated code if similar functions are required in different processes. Further Information, please refer to: Dougherty et al [Chad Dougherty, 2009] Dependencies: • Processes can check their privileges using the functions provided by the CHECK POINT pattern (see 10.2.3). • This pattern can use different access control mechanisms, like the ROLE-BASED ACCESS CONTROL (see 10.2.11). • The PRIVILEGE SEPARATION pattern is a specialized variation of this pattern. For further information see Dougherty21 . 10.4.5
Execution Domain
Intent: This pattern has similarities with the CONTROLLED VIRTUAL ADDRESS SPACE. System- and user-processes use resources, either in memory segments or others like I/O devices. This pattern describes how to control the access of processes to resources by setting up execution domains described by descriptors. Context: Operating systems with a variety of system- and user-processes, possibly with a variety of users. Processes belonging to one user and one program have to be able to access and share resources and ask for privileges. This access to resources has to be managed. Problem: One basic step towards securing processes is to restrict the process to a specified set of resources. Malicious processes could otherwise access forbidden information and modify or destroy them. Forces: • We need a solution to restrict a process in its actions. 21 [Chad
Dougherty, 2009]
55
10.4
Operating System Level
10
SECURITY DESIGN PATTERNS
* Domain Process
1
Executes In
*
CompositeDomain
ID create() enter() delete()
ID
SimpleDomain
Descriptor base limit access_type
*
Figure 21: Class diagram after Schumacher (From Schumacher:2006)
• Resources can be files, I/O devices, data structures or instructions. They should all be addressed. • A process should be able to extend its access-domains for special purposes. Solution: Each process will get a set of descriptors representing its rights. These descriptors are collected into an EXECUTION DOMAIN. A process can enter and leave a domain. Also domains can be nested inside each other. Example: Figure 21 outlines the following actors in the class diagram. • Domains are described and can be entered by a process. • Descriptors in a domain define the rights for resources. • A process can change domains as required. • Also domains can be nested.
Consequences: When applying this solution the following benefits should be considered: • This solution allows to apply the principle of “least-privilege” to processes • The type of the resource is not relevant, it could be data or I/O devices. • It allows that a process can have many execution domains. • Predefined special domains, e.g. for supervisor, user programs and external processes are possible. • Compared to the CONTROLLED VIRTUAL ADDRESS SPACE this includes also resources which are not mapped to the memory, like I/O. Drawbacks:
56
10.4
Operating System Level
10
SECURITY DESIGN PATTERNS
• This pattern adds extra complexity and usually extra hardware is required to manage descriptors and domains. • It results in a performance overhead. Some systems, e.g. the Intel X86 uses only two “rings”. • The realization is system-dependent. Further Information, please refer to: Schumacher et al [Schumacher, 2006] Dependencies: • CONTROLLED VIRTUAL ADDRESS SPACE pattern (see 10.2.4) can be used for the memory accessing part. • This pattern is an implementation of the AUTHORIZATION pattern (see 10.2.2) • This pattern is part of the CONTROLLED EXECUTION ENVIRONMENT pattern (see 10.4.1) 10.4.6
Secure Chain Of Responsibility
Intent: This pattern describes how to implement the CHAIN OF RESPONSIBILITY22 pattern in a secure manner. The intent is to decouple the logic which determines functionality dependent on the user-authorization from the actual application which requests the functionality. This simplifies the user-authorization to functionality logic and reduces complexity in the application requesting the functionality which also makes it easier to change authorization-dependent functionality. This pattern is not only used in an operating-system context but also for securing applications. Context: A system using the CHAIN OF RESPONSIBILITY to choose the appropriate functions to process data in a certain order. Additionally access to some of these functions are restricted to users with certain roles or authorizations, e.g. in a ROLE-BASED ACCESS CONTROL. Problem: An organization has a system where one, or more applications request data processing. This data processing is done by a set of different functions at a certain order. This makes use of the CHAIN OF RESPONSIBILITY pattern (Erich Gamma 1995) to select the correct behavior in a chain of handlers. However, these functions are dependent on different user-authorizations. How can we determine that the selection of the correct handler also determines the user’s access rights and trust-level? Forces: • Users with different access rights can only make use of certain functions. Depending on the user’s access rights the proper handlers have to be chosen. • A user with a higher authorization level can perform more functions. • In the implementation of the CHAIN OF RESPONSIBILITY the functions called have to verify security credentials and access rights too, before processing the request or passing it on to the next function. 22 [Gamma
et al., 1995]
57
10.4
Operating System Level
10
user
SECURITY DESIGN PATTERNS
handler handleRequest(secCredentials, request) checkCredentials(secCredentials)
successor
concreteHandler1
concreteHandler2
handleRequest() checkCredentials()
handleRequest(secCred, request) checkCredentials(secCred)
Figure 22: Class diagram after www.dofactory.com Solution: A solution similar to the CHAIN OF RESPONSIBILITY is implemented. The CHAIN OF RESPONSIBILITY is described in detail by Erich Gamma23 . There are only a few differences which apply for the SECURE CHAIN OF RESPONSIBILITY: • Security credentials of each user are included as arguments in the request method of the handlers. • Each handler-class may also implement a method to check the appropriate credentials and if the class is permitted to handle this request. Example: Similar to the CHAIN OF RESPONSIBILITY the SECURE CHAIN OF RESPONSIBILITY chooses the concrete handlers after criteria in the attributes of the request. The difference, as seen in figure 22, is that the request includes security credentials too. This allows that the concrete handlers are also chosen after the trust level of the requesting process or user. In addition the SECURE CHAIN OF RESPONSIBILITY can make use of the SECURE STATE MACHINE (see 10.4.7) to keep track of the state of the functions and of the security context. Consequences: When applying this solution the following benefits should be considered: • The complexity of the requesting application is reduced since the logic to determine the selection of the appropriate behavior dependent on access rights is moved from the application to the handlers. • It is easier to change security dependencies of functions due to the “black-box” behavior. • Changing the behavior of the SECURE CHAIN OF RESPONSIBILITY can be done dynamically by modifying the links in the chain. Disadvantages: • Performance may be impacted due to additional security checks by each handler, especially if many handlers have to be processed in one chain. • Security checks have to be implemented for each handler. 23 [Gamma
et al., 1995]
58
10.4
Operating System Level
10
SECURITY DESIGN PATTERNS
Further Information, please refer to:
• Dougherty et al [Chad Dougherty, 2009] • CERT publications: www.cert.org/archive/pdf/09tr010.pdf Dependencies: • This solution is a security hardened version of the CHAIN OF RESPONSIBILITY pattern24 • Typically it also makes use of the ROLE-BASED ACCESS CONTROL pattern (see 10.2.11) 10.4.7
Secure State Machine
Intent: This is the approach of a secure implementation of the STATE-pattern25 . The SECURE STATE MACHINE intents to separate security functionality from applicationfunctionality by using two separated state machines for each type. Context: The software makes use of the STATE pattern to change the behavior of a class depending on the state of the class. In addition the selection of the behavior should consider security states too. This works well if the access control model which is considered for changing the state, can be represented as a state machine too. Problem: Merging security level behavior-switching and user-level behavior switching in one implementation can have huge impact on the complexity of the whole implementation. More complexity also increases the possibility of a vulnerability and makes change and maintenance of the system difficult. Solution: Implement a SecurityContext class which will handle all user operations at first place. The SecurityContext class maintains the SecurityState and the UserFunctionContext classes. The SecurityState class, or its concrete implementation, defines the state from a security perspective, while the UserFunctionContext is again a state machine, this time similar to the original STATE pattern, defining the state from a user-level perspective. This means we have two STATE-patterns in one, while the SecurityContext stateclass handles user-operations before the other, which ensures that the security is handled first before the user-level functions. Example: In figure 23 a class diagram is shown. This figure outlines the composition of these two STATE patterns working together. While the primary one handles the security state, the other one is responsible for the user function state. This allows the separation of security and user-function levels but also enforces the use of the security state. Consequences: When applying this solution the following benefits should be considered: Benefits (after Dougherty26 ): 24 [Gamma
et al., 1995] et al., 1995] 26 [Chad Dougherty, 2009] 25 [Gamma
59
10.4
Operating System Level
SecurityContext - securityState - userMachine + request()
-userMachine
UserFunctionContext - userFunctionState + request()
10
SECURITY DESIGN PATTERNS
-state
SecurityConcreteState1 + handle()
-state
SecurityState + handle()
SecurityConcreteState2 + handle()
UserFunctionState + handle()
UserFunctionConcreteState1 + handle() UserFunctionConcreteState2 + handle()
(from dougherty:2009)
Figure 23: Class diagram after Dougherty • Instead of mixing security and user-level states together we get a clear separation between the two. • Testing, implementing changes to security or user-level functions and maintenance is made easier. • To circumvent the security state machine is hard or impossible, because the security state machine is required to create the user-function state machine. Further Information, please refer to:
• Dougherty et al [Chad Dougherty, 2009] • Erich Gamma et al [Gamma et al., 1995] Dependencies: • This pattern makes use of the non-security STATE pattern27 • and due to the STATE pattern it typically also makes use of the SINGLETON pattern28 10.4.8
Secure Strategy
Intent: This pattern intents to implement a secure variation of the STRATEGY pattern29 . While the STRATEGY pattern only considers user-functions to provide the necessary object for further processing, the SECURE STRATEGY also takes security measures into consideration when creating a class consisting of special functions. This pattern is an extension of the SECURE FACTORY pattern. 27 [Gamma
et al., 1995] et al., 1995] 29 [Gamma et al., 1995] 28 [Gamma
60
10.4
Operating System Level
10
SECURITY DESIGN PATTERNS
Context: A system which makes use of the STRATEGY pattern. In addition the data which the variations of the algorithms make use of, differ in their access restrictions. Therefore the algorithms and the classes which make use of the algorithms are access restricted, while the use of classes which make use of a slightly different algorithm, not processing access restricted data, do not need to be restricted. Problem: A system where the STRATEGY pattern is used to deliver concrete objects with variations of processing algorithms. In addition the access to these algorithms or functions is security sensitive and should be accessible only to users with certain access rights. How can we verify that the created objects and their functions also meet the security measures? Forces: • The STRATEGY pattern is used. • The access to different variations of the algorithm depend on proper security credentials, e.g. roles. This results in many classes which are similar to each other except slight differences in the algorithms they use. • The access restrictions may be necessary because some variations of the algorithm make use of data which is access restricted, while other variations of the algorithm do not. Solution: If a user, represented by a caller, asks for a certain operation, this request is processed by the SECURE STRATEGY. Depending on the provided security credentials the SECURE STRATEGY calls the strategy with the required trust level, which then decides about the delivered object functions. Example: In figure 24 a class diagram is shown. The difference to the typical STRATEGY pattern is, that with a request for a strategy the abstractSecureStrategyFactory also receives security credentials and chooses the concreteSecureStrategyFactoryX according to the given trust level. This allows to have different strategy factories, each for another trust-level. In this example the “getStrategy()”-method can make use of an AUTHORIZATION mechanism, like the use of ROLE-BASED ACCESS CONTROL to verify that the chosen strategy fits the trust level of the requesting process, which is represented by its role. Consequences: When applying this solution the following consequences should be considered: • This approach allows a separation of security concerns and user-level functions. • The decision which algorithms are used is hidden from the user. • It is easy to change and test security decisions and behavior of the SECURE STRATEGY. Further Information, please refer to: • Dougherty et al [Chad Dougherty, 2009] • Erich Gamma for the Secure Strategy [Gamma et al., 1995]
61
10.4
Operating System Level
10
SECURITY DESIGN PATTERNS
abstractSecureStrategyFactory - defaultInstance: AbstractSecureStrategyFactory + getInstance(): AbstractSecureStrategyFactory + setInstance(newInstance: AbstractSecureStrategyFactory) + getStrategy(givenCredentials: SecCredentials): someObject
defaultInstance
concreteSecureStrategyFactory2 concreteSecureStrategyFactory1 + getStrategy(givenCredentials: SecCredentials): Strategy + getStrategy(givenCredentials: SecCredentials): Strategy
Strategy + doSomething()
TrustLevel1Strategy
TrustLevel2Strategy
TrustLevel3Strategy
+ doSomething()
+ doSomething()
+ doSomething()
Figure 24: Class diagram after Dougherty Dependencies: • STRATEGY FACTORY pattern [Gamma et al., 1995] • ROLE-BASED ACCESS CONTROL is typically useful • This is also an implementation of the SINGLE ACCESS POINT for a specific subset of functions 10.4.9
Secure Visitor
Intent: Often, systems need to process different operations on data which is ordered in a hierarchical order, presented by nodes. Each data-node might have different access rights, e.g. based on roles. This pattern intents that each node is locked and will allow access only after a successful authentication and authorization with the proper access rights. The SECURE VISITOR is the gate through which the data-nodes are being accessed and ensures enforcing access restrictions. Context: A system in which different data nodes are processed and which makes use of the VISITOR pattern30 . In addition there are varying access restrictions to different data-nodes. Problem: A system with the above mentioned context but additionally to the user-level functions we want to consider security in form of access restrictions and user-roles when processing the data. Solution: This pattern implements an additional visitor-object. This object is almost identical to the one described in the VISITOR pattern by Erich Gamma. The difference 30 [Gamma
et al., 1995]
62
10.4
Operating System Level
10
SECURITY DESIGN PATTERNS
Visitor UserCredentials
- visitDataNodeType1(unlockedDataNodeType1) - visitDataNodeType2(nlockedDataNodeType2)
ConcreteVisitor1 ConcreteVisitor2 - visitDataNodeType1(unlockedDataNodeType1) - visitDataNodeType2(unlockedDataNodeType2) - visitDataNodeType1(unlockedDataNodeType1) - visitDataNodeType2(unlockedDataNodeType2)
UnlockedDataNode accessor1() accessor2()
UnlockedDataNodeType1
LockedDataNode
accessor2a()
accept(visitor, userCredentials) checkCredentials(userCredentials) : bool unlock() : unlockedDataNode
UnlockedDataNodeType2 accessor2b()
LockedDataNodeType1 accept(visitor, userCredentials) unlock() : unlockedDataNodeType1
LockedDataNodeType2
accept(visitor, userCredentials) unlock() : unlockedDataNodeType2
(from Dougherty:2009)
Figure 25: Class diagram after Dougherty is that this pattern deals with locked data. The data-nodes themselves then have the functionality of unlocking the data. This means that the visitor-object itself is not concerned with the verification of access rights but instead the nodes themselves verify if the access rights are correct or not. Example: In figure 25 a possible class diagram of the SECURE VISITOR pattern is presented. It outlines the additional functionality of dealing with locked nodes while the nodes themselves implement the locking and unlocking functions. Consequences: When applying this solution the following benefits should be considered: • Applying the SECURE VISITOR pattern allows a separation between security concerns and user-level functionality. • Security is dealt with by the nodes themselves, this makes it easy to modify access restrictions because the Visitor object does not need to know about these access restrictions. • Modifications and maintenance of the security mechanisms are easy because they do not effect the visitor object. • This implements one security principle which says that security checks should be placed as close as possible to the effected data and not only somewhere far away in the front. Further Information, please refer to: Dougherty et al [Chad Dougherty, 2009] Dependencies: • This pattern is a special security-hardened version of the VISITOR pattern31 . 31 [Gamma
et al., 1995]
63
10.5
Client-Server
10
SECURITY DESIGN PATTERNS
• The methods used in the nodes to check the access rights can make use of AUTHORIZATION mechanisms like the ROLE-BASED ACCESS CONTROL (see 10.2.11) or the MULTILEVEL-SECURITY (see 10.2.9). In fact, this pattern can be a realization of these other access-control patterns.
10.5
Client-Server
10.5.1
Demilitarized Zone
Intent: Web application services have to be easily accessible to clients. Also every system accessible over the internet is a possible goal for attacks, either for compromising data or for data-theft. The approach of the DEMILITARIZED ZONE separates webserver and business logic by establishing a two-zone system, surrounded by FIREWALLS. Context: The organization has a server architecture containing one web-server or proxy and at least one application server. The business logic is situated on the application server while the web-server, e.g. an INTEGRATION REVERSE PROXY provides nonsensitive web-content and session management. On the application server sensitive useror business-information is stored. Problem: Application servers, especially the ones used over the internet, are exposed to possible attackers. Protection of these systems is required, but how can this be done? Forces: • The costs of the security solution have to be in proportion to the possible costs of the damage if an attacker can successfully steal data, compromise data or functions or just make the system unavailable. • Security improvements have to be balanced against usability impacts to the system due to this security improvements. The system-usability directly influences the user-acceptance and therefore is also critical to most systems. A trade-off between security and usability has to be made. Solution: We separate the business logic on the application servers from the servers that provide the web-based functions to the user. To achieve this we set up a separate zone, surrounded by firewalls. The demilitarized zone in the middle is accessible from the internet and all internet-communication is filtered by the firewall. In this zone is the web-server, delivering the less-sensitive web-content and direct user-functions. Behind a second firewall, in the so-called application zone is the application server situated, which holds the business functions. This zone is not directly accessible from the web, but instead only from the Web-Server. Here too, all communication is filtered. Example: In figure 26 the structure of a DEMILITARIZED ZONE is shown. As already described the web-server is surrounded by two firewalls. While one firewall protects the web-server from the untrusted network, the other tries to ensure that only valid traffic is able to get from the web-server to the application server. This network setup sets an extra layer, the DMZ, in between the untrusted network and the application server and thus make it harder for attackers to reach the application server. Consequences: When applying this solution the following benefits should be considered:
64
10.5
Client-Server
10
client browser
SECURITY DESIGN PATTERNS
Web Server
Application Server Firewall
Firewall
Demilitarized Zone (DMZ)
Figure 26: Structural diagram after Schumacher et al • Security is improved by minimizing the attack-surface: fewer system-functions are directly accessible from the web and therefore can be filtered more efficiently. • It is easy to vary the level of security by establishing more than one separated region. This also supports the principle of “Defense in Depth”. • The servers / hosts can be individually hardened to fit exactly their needs and do not need to be hardened to fit all functionality equally. This reduces complexity for each single host. Disadvantages: • Availability: The firewall becomes a single-point of failure. If the firewall is taken down, e.g. by an attack, all application-servers are inaccessible from outside. • Manageability: managing application servers will be more difficult because access from outside and access from internal networks will be more difficult. • Costs: typically new hardware is required, often new software purchases too. Also implementation and maintenance costs can increase. • Performance: Increased filtering and more hops through the network will have impact on performance. Further Information, please refer to:
• Schumacher et al [Schumacher, 2006] • Wikipedia DMZ http://en.wikipedia.org/wiki/DMZ_(computing) Dependencies: • PROTECTION REVERSE PROXY, INTEGRATION REVERSE PROXY or FRONT DOOR • FIREWALL (typically stateful firewalls)
65
10.5
Client-Server
10.5.2
10
SECURITY DESIGN PATTERNS
Front Door
or: Web Entry Server; Web Single Sign-On Intent: Securing a web application from possible attacks is necessary, especially when the application has access or contains sensible user or business data or is business-critical in other ways. The FRONT DOOR is a more specialized version of the PROTECTION REVERSE PROXY and the INTEGRATION REVERSE PROXY. The additional features it provides in contrast to the INTEGRATION REVERSE PROXY is, that the FRONT DOOR is an implementation of the SINGLE ACCESS POINT and the CHECK POINT. This allows in addition to provide authentication and authorization features. This is done by setting up a web entry server. Context: This solution is applicable for any server-side application, consistent of multiple servers, accessible through the internet or another untrusted network. This setup is protected by an INTEGRATION REVERSE PROXY and additionally users should be authenticated and authorized at this SINGLE ACCESS POINT, providing access to the underlying applications only for authorized users. Problem: In a setup of multiple servers, providing features over an untrusted network, typically the internet, we want to provide Single Sign On (SSO) to users for our webservices. Forces: • One single identity for all web-services. • Only one user-authentication process for all applications. This means that a user does not need to log-in for each web-service. • Session time-out should be managed, e.g. to re-authenticate users after a certain time to prevent session-misuse if a user does not log-out. • The authentication and SSO should be independent of the web-services and their systems. Additionally there can be different authentications required, e.g. for one web-service a simple authentication is enough while another with more sensitive data requires a strong authentication with a one-time password. • All different access rights and authorizations should be dealt with by a single solution. • The integration effort into the existing application architecture should be as simple as possible. • Single Log-off should be provided too in addition to the SSO. This should be realized in a way, that when a user is logged off, the log-off should be valid for all web-services. Solution: The FRONT DOOR is implemented as a special variation of the INTEGRATION REVERSE PROXY and as an implementation of the SINGLE ACCESS POINT and CHECK POINT. The FRONT DOOR presents a web-entry service and handles authentication, authorization and SECURITY SESSION management. One possibility is also to use another application server providing the web-entry services. In this case the FRONT DOOR will redirect to this application server and then handle the established sessions. For the Single Sign On (SSO) the FRONT DOOR uses a central database for user credentials and authorizations, e.g. an LDAP instance. Additionally the FRONT DOOR can implement the features of the PROTECTION REVERSE PROXY.
66
10.5
Client-Server
10
SECURITY DESIGN PATTERNS
User identities, e.g. as tokens, are passed on with requests
ApplicationServer1
serviceDB FrontDoor
outer firewall
inner firewall
client browser
ApplicationServer2
ApplicationServer3
userDB
FRONT DOOR can implement identification and authentication mechanism. Also Logging is implemented here
UserDirectory
e.g. an LDAP system
Untrusted Network
Demilitarized Zone
Application Zone
Figure 27: Structural diagram after Schumacher et al Example: User identification can be delegated to a back-end server. Alternatively the FRONT DOOR implements the identification and authentication mechanisms itself. In figure 27 the structural network-diagram a FRONT DOOR is shown, making use of an LDAP-server for AUTHENTICATION and therefore being used as a Single-Sign On solution. Consequences: When applying this solution the following benefits should be considered: • This pattern provides a Single Sign-On and Single Sign-Off solution for internet or intranet application servers, they do not need to take care of authentication anymore. • One user-profile can be shared across several back-end application servers. • Logging can be done centralized and includes all user-actions. Disadvantages: • It might be difficult to handle different user-databases if an application might need its own one. • An extra user-management solution is required, e.g. LDAP. • Different authentication policies, with different security needs may conflict each other and can make the SSO complicated and hard to maintain. • It can be complicated and hard to debug how the FRONT DOOR and the different application servers handle sessions, e.g. time-outs. Further Information, please refer to: Schumacher et al [Schumacher, 2006] for further information.
67
10.5
Client-Server
10
SECURITY DESIGN PATTERNS
Dependencies: • FIREWALL • this is a variation of the CHECK POINT pattern (see 10.2.3) • SECURE CHANNEL (see 10.5.7) can be implemented here • SECURE SESSION (see 10.2.12) can be managed here • This is an implementation of the SINGLE ACCESS POINT pattern (see 10.2.13) • This is a specialized variation of the INTEGRATION REVERSE PROXY and the PROTECTION REVERSE PROXY 10.5.3
Information Encryption
or: Information Obscurity Intent: There is nothing like a 100% secure system. It is possible that attackers might gain access to a system and its data. Therefore the sensitive information in this data should be protected. The term “obscurity” has to be used carefully. In the book of Schumacher and Sommerlad32 , the term information obscurity is used in a way which means obscuring information by encrypting it. On the one hand this is against the principle of “no security by obscurity”, while on the other hand obscuring the location of information is used in some circumstances simply to make it harder to access information. Nowadays the term obscurity typically is used in a way which means hiding data or information by obscuring the way to find it. This pattern presents a solution to protect data by encrypting parts of it. Context: An application on the web uses sensitive data, like user-credentials for its functions. Other sensitive user-information can be gathered and stored by the application. Typically the application server is also protected by other measures like a DEMILITARIZED ZONE (see 10.5.1). Problem: How can we ensure that the sensitive data gathered by the application or the system is protected from an unauthorized intruder? Forces: • Most data is non-sensitive, but some of the data is sensitive and therefore security relevant. This sensitive data needs to be protected but nonetheless has to be accessible and available for the application itself. • Encryption and decryption can impact performance and therefore have to be used carefully in case of large amounts of data or large number of accesses to the system. In case of smaller data and less user-accesses the performance boost of modern computers allows that typical encryption mechanisms work with almost no noticeable effect. • Encrypting the sensitive data is not enough, also the encryption-key must be protected. 32 [Schumacher,
2006]
68
10.5
Client-Server
10
Key storage mechanism
SECURITY DESIGN PATTERNS
Provides
Data
ApplicationComponent
EncryptionKey
Hides
Encryption mechanism
Protected Location
Figure 28: Block diagram after Dougherty (From Schumacher:2006)
Solution: The information is categorized for their sensitivity. The more sensitive information is encrypted, like user-passwords and credit-card information while the nonsensitive part is left unencrypted. Additionally the encryption artifacts, like the encryption key need to be protected appropriately, e.g. by applying the FIPS 140-2 or equivalent standards. These standards to also make use of obscuring information because at some point an unencrypted key is necessary to decrypt the wanted information. Example: Elements shown in figure 28: • Encryption keys (for encryption and decryption). • A storage and distribution mechanism for the keys. • An encryption algorithm or mechanism. • Components of an application to obtain and use encryption of sensitive data. • A location to store the encryption keys. This location itself has to be protected.
Consequences: When applying this solution the following benefits should be considered: • If an intruder can get hands on the data, they are useless for him. • If encrypting only the small amount of sensitive data, the performance impact can be minimized. • It is harder for an attacker to get hands on all necessary information required, to read the data, e.g. the data itself, the encryption key and the encryption mechanism. Disadvantages: • Independent of the type of mechanism the performance is impacted. Due to the fact of faster algorithms and huge performance boosts of computers this effect can be ignored if not dealing with large amounts of data or large amounts of simultaneous accesses to the system. • The complexity is increased and therefore debugging and manageability is effected.
69
10.5
Client-Server
10
SECURITY DESIGN PATTERNS
• Development costs can increase when applications can’t simply make use of mechanisms provided by the system / environment. • Additional software and/or hardware components may be required, this has an impact on the overall costs. • There is a problem how to deal with the encryption key. Some mechanisms can help solve this problem like using some key-storage mechanisms or hardware-keys. Then the problem is shifted to the question who is eligible to use the key and how to verify the authorization? Further Information, please refer to: • Schumacher et al [Schumacher, 2006] • NIST http://csrc.nist.gov/groups/STM/cmvp/standards.html# 02 • Wikipedia http://en.wikipedia.org/wiki/FIPS_140-2 Dependencies: This solution can make use of the SECURE ACCESS LAYER pattern (see 10.6.2) which can provide encryption and decryption mechanisms. 10.5.4
Integration Reverse Proxy
Intent: Securing a web application from possible attacks is necessary, especially when the application has access or contains sensible user or business data or is business-critical in other ways. The INTEGRATION REVERSE PROXY is a more specialized version of the PROTECTION REVERSE PROXY (see 10.5.6). Basically the INTEGRATION REVERSE PROXY presents the interface to all external clients. In addition to the features of the PROTECTION REVERSE PROXY it can also contain additional logic, e.g. handling the certificates, caching and load-balancing. Context: This solution is applicable for any server-side application accessible through the internet or another untrusted network. Typically the server-side application consists of multiple application servers or web applications. Problem: We can use a PROTECTION REVERSE PROXY, but how can we manage consistency to the outside if we have multiple application servers and change the topology? Also there is need for more flexibility in the network topology. In addition, fail-over strategies and load balancing should be taken care of somehow. Forces: • If there are different functions, requiring different systems and applications, there is need for multiple servers, each containing one or a few of the functions or applications. • Network topology should be hidden from clients. If there is change to the topology, e.g. by adding additional servers, this should not be visible, and not effect clients accessing the web-applications from outside. • Fail-over and load-balancing should be handled and being hidden to the users. • Certificates should be reduced to only one certificate instead of multiple ones for each application server.
70
10.5
Client-Server
10
SECURITY DESIGN PATTERNS
ApplicationServer1
client browser
IntegrationReverseProxy
ApplicationServer2 Firewall
Firewall
ApplicationServer3
Untrusted Network
Demilitarized Zone
Application Zone
Figure 29: Structural diagram after Schumacher et al Solution: The INTEGRATION REVERSE PROXY integrates all application and web servers behind one URL. This allows active mapping of URL-paths to the application servers by the proxy. If network topology changes, the mapping of the paths can be changed without any effect to the users entering the application from outside. In addition, a SSL-certificate can be implemented at the INTEGRATION REVERSE PROXY which secures connections between the users and the proxy. Therefore this server can also be used as the point of implementation for SECURE CHANNELS and KNOWN PARTNERS pattern. Example: In figure 29 a similar approach to the PROTECTION REVERSE PROXY is presented. However, the INTEGRATION REVERSE PROXY makes use of additional functions, combining different application servers in one web-server by mapping their paths individually. Because the INTEGRATION REVERSE PROXY is the one gate to the outside, this server also manages the SSL-certificates. Consequences: When applying this solution the following benefits should be considered: • The client-browser sees only one URL and one IP-address so that the network topology is hidden for outside users. • Change, extending and integrating new features is easier. • Load-balancing can be done by the INTEGRATION REVERSE PROXY. • Access logging can be done centralized at the proxy. • To have only one certificate for the proxy is cheaper than having one for each application server. Drawbacks: • Point of Failure: if the INTEGRATION REVERSE PROXY goes down, the application servers are not available anymore. • It increases complexity and is an additional piece which needs to be maintained. • Load balancing can be a problem for sticky sessions (see FRONT DOOR) • Testing of the single applications can become more difficult.
71
10.5
Client-Server
10
SECURITY DESIGN PATTERNS
Further Information, please refer to: Schumacher et al [Schumacher, 2006] for further information. Dependencies: • FIREWALL • The FRONT DOOR pattern (see 10.5.2) is a more specialized variation. • The PROTECTION REVERSE PROXY pattern (see 10.5.6) is a more general and lightweight variation of this pattern. 10.5.5
Known Partners
Intent: A web-service should be easily accessible for its users. However, in some cases the information on these services may be sensitive business or user information. To make sure that this information is not accessed by unauthorized users, we want to make sure that the user, accessing our system really is who he says he is. Also the user might want to be sure that our server really is what they assume he is. To achieve this we use KNOWN PARTNERS where the communication partners are identified uniquely. This process ensures an authenticated way to identify each partner to the other. Context: A company provides a web-application on a server-architecture which consists of application servers and a PROXY server. All the business logic lies on the application server while static content and authentication services are placed on the proxyserver, the FRONT DOOR. Only a restricted set of users use the application which holds business-sensitive information. Therefore the access to this information has to be restricted. Problem: To ensure that data is revealed only to authorized users, we need to ensure that our application communicates with the correct person and not an imposter, or the other way around. The user has to be sure that the application server he is communicating with, is who he thinks it is. How can this problem be solved? Forces: • The system still needs to be as easily accessible as possible, otherwise the useracceptance will be impacted. • On the other hand we need to ensure correct identification of the users and the service. • A username-password authentication mechanism is typically only a one-way authentication. This can be part of our solution, but the other side has to be authenticated too. • The costs and benefits have to be balanced. Solution: All access to application functionality and data is only possible for known partners. Regarding this, it has to be ensured that there is a secure way of authentication and only securely authenticated users are “known partners”. For this authentication we need at least a two-way exchange to identify the user to the system and vice versa. Both identify each other as KNOWN PARTNERS.
72
10.5
Client-Server
10
SECURITY DESIGN PATTERNS
Example: A common way is this two-way possibility. The user accesses the application which is identified by a server-certificate, signed by a Certifying Authority (CA) which the client-browser can verify. Then the user identifies and authenticates himself with a username-password combination over a SECURE CHANNEL (see 10.5.7). Finally a SECURE SESSION (see 10.2.12) is set up to prevent annoying re-authentication. Consequences: When applying this solution the following benefits should be considered: • The system can verify the identity of the client. • The client can be sure that the application is who it says it is. Disadvantages: • Performance: This will impact the performance, especially when establishing a connection and verifying the partners. • Availability: If the identity verification service fails, the whole application will not be available anymore. • Manageability: active maintenance of the identities of users and system has to be done to keep the necessary security-level. • Costs: costs for development and implementation are significantly higher than that of a simple one-way identification process. Further Information, please refer to:
• Public Key Infrastructure (PKI) • Schumacher et al [Schumacher, 2006] Dependencies: • This solution can make use of SECURE CHANNELS (see 10.5.7) • This solution can make use of SECURE SESSION (see 10.2.12) • CERTIFICATE INFRASTRUCTURE 10.5.6
Protection Reverse Proxy
Intent: Securing a web application from possible attacks is necessary, especially when the application has access or contains sensible user or business data or is business-critical in other ways. The PROTECTION REVERSE PROXY is basically an application firewall. This means that in contrast to a typical firewall which filters only the protocols up to the tcp-level, the PROTECTION REVERSE PROXY also filters the request up to the application layer. Context: Any server-side application accessible through the internet or another untrusted network.
73
10.5
Client-Server
10
client
Demilitarized Zone
ApplicationServer Firewall
Firewall
Untrusted Network
ProtectionReverse Proxy
SECURITY DESIGN PATTERNS
Application Zone
Figure 30: Structural diagram after Schumacher et al Problem: A simple FIREWALL only filters the lower protocol layers33 but cannot protect an application from attacks addressing vulnerabilities on application layer. How can we achieve a protection also including these upper layers? Forces: • A simple Firewall cannot protect attacks on higher layers, e.g. using HTTP GET or POST requests. • Packet filters working on the network packet level (up to tcp) usually cannot detect attacks based on buffer overflows, e.g. using extra long parameters. • Hardening the application server itself against all possible attacks requires special skills and can be very complicated, depending on the offered functions. • Known vulnerabilities to the application server software can usually be patched, but sometimes these patches require extensive testing to verify all components still work properly. • Patches are only available for known vulnerabilities, but in future more vulnerabilities might be detected. Solution: The solution offered by this pattern describes to change your network topology in a way that you create a DEMILITARIZED ZONE between your application servers and the untrusted network. In this DMZ the PROTECTION REVERSE PROXY is placed. With this topology every single request coming from the untrusted network towards the application server has to pass the proxy before. The PROTECTION REVERSE PROXY can understand application layer protocols like HTTP, SMTP, FTP and IMAP and can filter for possible vulnerable requests. E.g. on an IMAP-connection the proxy can filter files, attached to e-mails, for viruses and prohibit such e-mails. Also available commands can be limited, like HTTP DELETE and HTTP TRACE. Example: An example is the ModSecurity module for the Apache Web-Server: http: //www.modsecurity.org. Also in figure 30 an example structure can be found. The PROTECTION REVERSE PROXY is set into the DEMILITARIZED ZONE and filters the network traffic on an application level protocol. In addition it makes the networkinfrastructure of the application zone intransparent to the outside. 33 [ISO,
1996]
74
10.5
Client-Server
10
SECURITY DESIGN PATTERNS
Consequences: When applying this solution the following benefits should be considered: • Exploitation of application-protocol vulnerabilities is made more difficult. • At the PROTECTION REVERSE PROXY the exploitation of known vulnerabilities for which no patch is installed yet, can be prevented. • This solution makes the administration of patches easier. • Additional functionality can be implemented, see INTEGRATION REVERSE PROXY or FRONT DOOR Disadvantages: • Performance: the latency can be impacted since there is additional filtering and additional hops in network traffic between the client and the application server. • Point of Failure: this practice adds another point of failure. If this system is compromised or is taken down by an attack, the application is no longer available. This needs to be taken care of, e.g. with a fail-over strategy. • Cost and Maintenance: the additional hardware and software bring in additional costs, additional configuration necessity and additional maintenance needs. Further Information, please refer to:
• ModSecurity http://www.modsecurity.org (For Linux and Apache Server) • Schumacher et al [Schumacher, 2006] • see INTEGRATION REVERSE PROXY (see 10.5.4) or FRONT DOOR (see 10.5.2) for extended versions of this pattern Dependencies: This pattern primarily depends on FIREWALLs. 10.5.7
Secure Channels
Intent: This pattern describes the approach to ensure integrity and confidentiality of data passed over an untrusted network by using package encryption and therefore securing the communication channel. The most common approach of this pattern in client-server communication is the Diffie-Hellman key exchange. Context: We have two partners, respectively client and server, who may not know each other, communicating over an untrusted network and some of the communication data is sensitive in nature. Some systems may use multiple servers protected by a DEMILITARIZED ZONE (see 10.5.1). Problem: How can we send data securely over an untrusted network so that confidentiality and integrity are ensured? Forces: • Typically only a small amount of sent data is security relevant.
75
10.5
Client-Server
10
SECURITY DESIGN PATTERNS
• Encryption algorithms produce a more or less significant performance overhead. This is less important nowadays since the enormous performance boost in computing and more efficient encryption algorithms. E.g. the use of an https:// protocol does almost have no effect on the user experience. Nonetheless, of this effect hast to be taken care of if dealing with a huge amount of simultaneous secure channels. Then the quite small performance overhead can add up quickly. • Encryption with known partners is easier, but in client-server communication, like in the internet, the partners are often previously unknown to each other. Typically many provided mechanisms already include some sort of authentication mechanism. Solution: To ensure secure communication of sensitive data we exchange information between the two parties to allow exchange of an encryption key. Following sensitive information is then encrypted and decrypted using the exchanged key. To reduce performance overhead split sensitive and non-sensitive information and encrypt only the sensitive ones. Typically these protocols are provided by operating systems too, therefore this pattern can make use of the SECURE ACCESS LAYER (see 10.6.2). Example: An example is the Diffie Hellman key exchange, used in HTTPS. See Wikipedia: http://en.wikipedia.org/wiki/Diffie%E2%80%93Hell man_key_exchange Consequences: When applying this solution the following benefits should be considered: • Security is improved because the sensitive data is encrypted and therefore of no use to a possible attacker intercepting this data. • Most systems / software already provide common implementation of this pattern. Therefore it is easy to make use of it, e.g. using the SECURE ACCESS LAYER. • Even previously unknown partners are able to securely exchange sensitive data. • performance overhead can be minimized by only encrypting the small percentage of sensitive data and leaving non-sensitive data unencrypted. Disadvantages: • This solution has impact on performance. Nowadays most computers are fast enough to run standard encrypting algorithms without significant performance loss. The server-side performance loss is therefore more significant. • Fail-over strategies if a server goes down are more complicated or even ineffective. • Setup and maintenance-costs are increased. New hardware may be required as well as buying and managing necessary certificates. Further Information, please refer to: • Schumacher et al [Schumacher, 2006] • Wikipedia http://en.wikipedia.org/wiki/Diffie%E2%80%93Hell man_key_exchange • OWASP https://www.owasp.org/index.php/Top_10_2010-A9
76
10.6
Securing Applications
10
SECURITY DESIGN PATTERNS
Dependencies: The SECURE ACCESS LAYER pattern (see 10.6.2) can be used for implementing secure channels and make use of system-functionality
10.6
Securing Applications
10.6.1
Input Validator
Intent: Many applications are vulnerable to attacks through their application protocol. These attacks usually are not being checked by a PROTECTION REVERSE PROXY or a firewall. Therefore another mechanism is required to check untrustworthy input at the application protocol level. Context: An application server environment is typically protected by a PROTECTION REVERSE PROXY or INTEGRATION REVERSE PROXY and firewalls. However, these measures typically do not prevent attacks over messages using the HTTP-protocol. Problem: Many attacks could be prevented if the application would scan and filter untrustworthy input, while every user-input has to be considered untrustworthy. Some of the OWASP top-ten attacks do take advantage of false or missing input validation like SQL-injection or Cross-Site-Scripting (XSS). How can we protect applications from these attacks over message contents? Force: • Every validation has an impact on performance, therefore the solution should provide as minimal as possible computational overhead. • The solution must be flexible to adapt to new requirements which occur out of new attacks. This flexibility should be considered in the system-design. • Usability should not be impacted too much, for not impacting user acceptance too much. • The OWASP describes two categories of validation, a) “validation” and b) “business rules”. Each of these categories should be addressed. Solution: Never trust any input to your application. Typically a white-list validation approach is recommended34 35 . Either in front of the application, as an additional communication layer, or in the application itself where all input is run through it, a validation mechanism is implemented (see figure 32). The following Steps apply: • System administrators and developers identify all systems which are possibly vulnerable, this means that they receive and process messages from untrusted resources. All message-receiving components of the application are separated and modified to make use of the validator. • All possible “legal” input and the sources where it comes from is determined. • Rules are constructed to only allow “valid” input and put them into the validatormethods. • The validator methods are deployed to the application where the input receiving methods make use of the validators. 34 [owa,
2010]
35 [Lars-Helge
Netland, 2006]
77
10.6
Securing Applications
10
SECURITY DESIGN PATTERNS
Figure 31: Block diagram after Netland et al
Figure 32: Block diagram Example: Figure 31 shows an abstract class diagram after Netland et al36 where the TargetObject represents the message content to be validated, while the TargetMethod represents the requested method, which processes the input. The Rules describe which input is “legal” and which one is not. The TargetMethod uses the Validator which validates the TargetObject for its compliance with the rules. In addition a ValidationSummary is done, which means that all input which does not comply with the rules is logged, so that attack attempts can be detected. It is recommended to make use of already existing validators. Either already developed in the own company, or alternatively make use of other used validators, e.g. provided by the OWASP Enterprise Security API (see link in Further Information below). Consequences: When applying this solution the following benefits should be considered: 36 [Lars-Helge
Netland, 2006]
78
10.6
Securing Applications
10
SECURITY DESIGN PATTERNS
• Application protocol-messages are validated and can prevent attacks. • The white-list approach can protect from attacks using yet unknown exploits, as long as these attacks do not match the described “legal” input. • Accounting and detection of attempted attacks can be enabled. • The input-validator is separated from the application and provides a centralized point for all input validation. Therefore, a validation code is not spread out through the application code. This makes it flexible to change and easy to maintain. • The validators can be reused at other applications, maybe in some slightly modified way. Disadvantages: • System performance will be impacted everywhere input validation is used. • The input validators can present new points-of-failure which could offer entry to the system when exploited. • System complexity is increased which can add development and maintenance costs. Further Information, please refer to: • Netland et al [Lars-Helge Netland, 2006] • BlackHatBriefings [Briefings, ] • OWASP Data Validation www.owasp.org/index.php/Data_Validation • OWASP Input Validation Cheat Sheet https://www.owasp.org/index. php/Input_Validation_Cheat_Sheet • OWASP Enterprise Security API https://www.owasp.org/index.php/ Category:OWASP_Enterprise_Security_API Dependencies: This pattern should be considered in combination with certain other patterns: • Typically used with accounting measures like the SECURE LOGGER • Best used together with other measures like PROTECTION REVERSE PROXY and firewalls. • A similar approach but for message output is the OUTPUT VALIDATOR (see 10.7.11) 10.6.2
Secure Access Layer
or: Using Low-Level Security; Using Non-Application Security Intent: Often application security is built around existing operating system, networking and database security mechanisms. Regarding the principle “a system is only as secure as its weakest link”, this pattern describes how to implement an additional secure access layer for implementing these security mechanisms and securing the communication coming in and out of the application.
79
10.6
Securing Applications
10
SECURITY DESIGN PATTERNS
Application
incomming / outgoing communication
Providing interfaces for standard communication Protocols
Secure Access Layer
using security mechanisms
underlying systems
Figure 33: Structural Diagram of the Secure Access Layer
Montag, 13. August 12
Context: This applies to applications using existing security mechanisms from the operating system, networking or database. Problem: The whole application will be insecure if it is not properly integrated into the surrounding security mechanisms of the external systems it uses. Forces: • The development of application security mechanisms should be independent of the specifics of the operating system, networking or database. • Implementing low-level security code throughout the application makes it difficult to make changes, to debug or to port to another system. • The interface-communication with external systems can be difficult. • Assuming the application is secure, a hacker still could find a possibility to intercept the messages going in and out. • The external systems may not provide the required security mechanisms for some reasons. Solution: Build an own lower-level layer, encapsulating the incoming and outgoing communication. this secure access layer is build around existing OS, networking and database security mechanisms. If the mechanism does not exist, build them into the secure access layer for incoming and outgoing secure communication. Important is that this layer isolates the developer from change to underlying systems and mechanisms. Example: in figure 33 a system topology is shown where the SECURE ACCESS LAYER is an own block, lying between the original application and the operating system. All communication from or to the application has to pass the SECURE ACCESS LAYER. The clue is that the SECURE ACCESS LAYER implements additional functions and / or protocols, which are not provided by the operating system. The SECURE ACCESS LAYER offers this interfaces to this functions and protocols to the application.
80
10.6
Securing Applications
10
SECURITY DESIGN PATTERNS
Consequences: When applying this solution the following benefits should be considered: • Isolation of the communication with external sources makes it easier to integrate new security-components or upgrade existing ones. • Also porting to other systems is easier since only the secure access layer needs to be adapted, the application is independent of that. Drawbacks: • Developing a SECURE ACCESS LAYER which works for a number of different systems is difficult and may create unnecessary overhead. • Retrofitting a SECURE ACCESS LAYER into existing applications can be hard since the secure communication code may be spread out through the existing application. Further Information, please refer to:
• Yoder, Barcalow [Yoder and Barcalow, 1998] • Wang et al [Wang et al., 2005] • Babar et al [Babar et al., 2005] • OWASP https://www.owasp.org/index.php/Top_10_2007-Insecu re_Communications Dependencies: This pattern makes use of the non-security design pattern LAYERS37 . 10.6.3
Secure Blackboard
Intent: This pattern provides an approach for securing the BLACKBOARD pattern in order to prevent violation of integrity and confidentiality. Therefore the reading and updating rights will be controlled and logged. Also the processing sources have to be authenticated. Context: The blackboard pattern describes a process where data is mapped to a “blackboard” and several systems process these data and rewrite them onto the blackboard until the solution evolves. The systems are usually distributed. Problem: A knowledge-source needs access to the blackboard, usually reading and updating. How to ensure an acceptable level of security in terms of integrity and confidentiality for the whole system? Forces: • How the shared data of the blackboard are used is important for security. The danger is badly manipulated or leaked information. • Only authenticated and authorized knowledge-sources should be able to access data from the blackboard. 37 [Gamma
et al., 1995]
81
10.6
Securing Applications
10
SECURITY DESIGN PATTERNS
• The order and number of knowledge sources and processes can be changed and this changes should be easy to maintain and have to be controlled. • Logging of access, actions, which and how data have been processed is important. • It should be transparent to users which and how the security controls work, otherwise they won’t be used. Solution: This pattern describes how to add to the control component some basic security mechanism, which provide functions of different other patterns, especially authentication, role-based access control and secure logging. Example: As Ortega38 describes, similar structures are already in use, e.g. at ATM’s, where different parties need to get access to data while this data still needs to be protected from unauthorized access. Before any change the ATM needs to identify itself to the system before certain access rights are granted. Another example mentioned are Wikis which make use of this pattern. There different people want to process data and it is ensured that every user altering data has to be authenticated and authorized. Consequences: When applying this solution the following benefits should be considered: • Roles and rights can be precisely defined, e.g. some knowledge-source (like an expert) can only add information, but not update it. • Controlled access is enforced by the access control mechanisms. • Logging of access for future auditing will be done. Drawbacks: • The performance of the blackboard system will be affected due to additional security capabilities and checks. • The usually loose controls and components will become more complex. Many other patterns should be considered like REFERENCE MONITOR, AUTHENTICATOR, SECURE LOGGER and others. Further Information, please refer to: Ortega et al [Ortega-Arjona and Fernandez, 2008]. Dependencies: This pattern does make use or is a specialization of some other patterns. • AUTHENTICATOR pattern • REFERENCE MONITOR • SECURE LOGGER • ROLE-BASED ACCESS CONTROL • non-security pattern BLACKBOARD 38 [Ortega-Arjona
and Fernandez, 2008]
82
10.7 10.6.4
Additional Patterns - not described in detail 10
SECURITY DESIGN PATTERNS
Secure Chain of Responsibility
This pattern is described in the “Operating-System” category, but can also be used for securing applications. Please see 10.4.6.
10.7
Additional Patterns - not described in detail
This section includes only short descriptions of some patterns inclusive a reference for further information. That this paper chooses this format for some patterns has different reasons: • Not enough references - For some of the patterns not enough literature has been found to describe the pattern in full detail. This could be a point for further work to search for additional literature and evidence if and how these patterns are used and to describe them as a pattern in full detail. • The do not belong to the design phase of a project - some patterns are associated with other project phases, e.g. the requirements phase of a software project. Nonetheless they may be useful or even necessary for some patterns mentioned previously. Therefore these patterns will also be mentioned shortly with references for further information. 10.7.1
Access Control Requirements
The ACCESS CONTROL REQUIREMENTS pattern belongs to the requirement’s gathering phase of a project, and therefore can be considered before going into the design phase. This pattern provides a strategy how to apply a common set of requirements for access control. This is especially helpful when using access control patterns like the ROLE-BASED ACCESS CONTROL (10.2.11). For further information please see Schumacher et al [Schumacher, 2006] 10.7.2
Audit Requirements
This paper categorizes the AUDIT REQUIREMENTS pattern into the requirement’s phase of a project. It will be mentioned here because it can be useful if considered when using accounting patterns in the design phase. This pattern provides a strategy how to apply a generic set of audit requirements to specific situations. For further information please see Schumacher et al [Schumacher, 2006] 10.7.3
Audit Trail and Logging Requirements
This paper categorizes the AUDIT TRAIL AND LOGGING REQUIREMENTS pattern into the requirement’s phase of a project. It will be mentioned here because it can be useful if considered when using accounting patterns in the design phase. This pattern provides a strategy how to apply a generic set of audit trail and logging requirements to specific situations. For further information please see Schumacher et al [Schumacher, 2006] 10.7.4
Automated Identification and Authentication Design Alternatives
This pattern belongs to the requirement phase but can be helpful when considering security patterns in the design phase of a project. It describes alternative ways of identification and authentication. It provides help with the application of an appropriate strategy. For further information please see Schumacher et al [Schumacher, 2006]
83
10.7 10.7.5
Additional Patterns - not described in detail 10
SECURITY DESIGN PATTERNS
Controlled Object Monitor
The CONTROLLED OBJECT MONITOR describes a specialized variation of the REFERENCE MONITOR pattern (see 10.2.10). For further information please see Schumacher et al [Schumacher, 2006] 10.7.6
Defer to Kernel
The DEFER TO KERNEL pattern is the specialized OS-variation of the REFERENCE MONITOR pattern (see 10.2.10). For further information please see the paper by Dougherty et al [Chad Dougherty, 2009] 10.7.7
Exception Manager
This pattern describes a common generic way how to deal with exceptions. The problem with exceptions is, that on the one hand they usually inform users about errors, on the other hand they tell them what they are allowed to do or not to do.. In addition processes can use exceptions of other processes to check if a task has been done or if an error occurred. In these ways errors are necessary and best practice to use in process communication as well as in graphical user interfaces. On the other hand exceptions can expose system information if not treated and filtered correctly. This system information can be of value not only for developers but for attackers as well. This pattern presents ways how to deal with exceptions and errors to provide useful information to authorized persons but no sensitive information to unauthorized persons or processes. The EXCEPTION MANAGER pattern has been put in this section due to lack of resources. Due to that this pattern couldn’t be described in enough detail. For further (not very detailed information) please refer to: • BlackHatBriefings39 • The CHECKS pattern describes ways of dealing with error messages in a graphical user interface (GUI) [Gamma et al., 1995] • The OWASP also describes best practices to error handling https://www.ow asp.org/index.php/Error_Handling 10.7.8
Identification and Authentication Requirements
This pattern belongs to the requirement phase and describes a common set of requirement for identification and authentication. Additionally it provides strategies to apply these requirements to specific project situations. For further information please see Schumacher et al [Schumacher, 2006] 10.7.9
Intrusion Detection Requirements
This paper categorizes the INTRUSION DETECTION REQUIREMENTS pattern into the requirement’s phase of a project. It is mentioned here because it can be useful if considered when using accounting patterns in the design phase. This pattern provides a strategy how to apply a generic set of intrusion detection requirements to specific situations. For further information please see Schumacher et al [Schumacher, 2006] 39 [Briefings,
]
84
10.7
Additional Patterns - not described in detail 10
10.7.10
SECURITY DESIGN PATTERNS
Non-Repudiation Requirements
This paper categorizes the NON-REPUDIATION REQUIREMENTS pattern into the requirement’s phase of a project. It is mentioned here because it can be useful if considered when using accounting patterns in the design phase. This pattern provides a strategy how to apply a generic set of non-repudiation requirements to specific situations. For further information please see Schumacher et al [Schumacher, 2006] 10.7.11
Output Validation
In contrast to the INPUT VALIDATION 10.6.1 the output validator describes a similar approach, but checking and validating which content is being delivered to the outside. E.g. this implements a solution similar to the input validator, checking outgoing data for SQL-syntax or error messages which could present sensitive data about the system itself. This pattern is not yet described in the standard literature but it is applied often. Therefore it would be worth looking for more evidence and describe this solution as an own security pattern. For further information please refer to: • Security Ninja on applying Output Validation with the help of the OWASP ESAPIproject http://www.securityninja.co.uk/application-security /output-validation-using-the-owasp-esapi/ • Wikipedia http://en.wikipedia.org/wiki/Secure_input_and_out put_handling 10.7.12
Privilege Separation
This pattern describes a specialized variation of the DISTRUSTFUL DECOMPOSITION pattern (see 10.4.4). For further information please see the paper by Dougherty et al [Chad Dougherty, 2009] 10.7.13
RSBAC
This is not really a pattern since this is more the realization of access control. The RULE-SET BASED ACCESS CONTROL40 41 42 is a Linux-based security solution with which ROLE-BASED ACCESS CONTROL and other access control mechanisms can be realized. This can be taken into consideration when planning to implement access control features like AUTHORIZATION and ROLE-BASED ACCESS CONTROL. • RSBAC website [Ott, ] • OASIS group [group, a] • XACML documentation by the OASIS group [group, b] • RSBAC at WIKIPEDIA [Wikipedia, ] 10.7.14
Secure Builder Factory
This pattern is a specialization of the CONTROLLED OBJECT FACTORY pattern (see 10.4.2). For further information please refer to Dougherty et al [Chad Dougherty, 2009] 40 [group,
b]
41 [Wikipedia, 42 [Ott,
]
]
85
10.8
Pattern Candidates
10.7.15
10
SECURITY DESIGN PATTERNS
Security Accounting Requirements
This paper categorizes the SECURITY ACCOUNTING REQUIREMENTS pattern into the requirement’s phase of a project. It will be mentioned here because it can be useful if considered when using accounting patterns in the design phase. This pattern provides a strategy how to apply a common set of accounting requirements to specific situations. For further information please see Schumacher et al [Schumacher, 2006]
10.8
Pattern Candidates
This chapter includes two patterns, VIRTUALIZATION and SANDBOX. These two are not yet described as patterns but are commonly used and already mentioned as patterns in several resources. Since they haven’t been described as patterns in the findings of this research, this paper putt together the information from the different resources and does an approach to describe them in the style of a pattern. (Also see section “future work”.) 10.8.1
Sandbox
or: Server Sandbox; Security Policy Pattern This solution is widely used but not yet described in standard literature. Although a variation, the SECURITY POLICY PATTERN43 has been described. Intent: The SANDBOX pattern allows to run an untrusted code in an environment with sensitive information where the untrusted code should have no access to this sensitive data. Another specialization of this pattern is the SERVER SANDBOX which is not described in detail in this paper. Context: Typically a system environment in which different applications are launched. These applications are untrusted, e.g. because they may run code or process data from untrusted sources and the access and communication of these applications to the rest of the system should be restricted and controlled. Problem: An attacker may use some known or unknown exploits to insert a malicious code into an application and get the application to run this malicious code. E.g. this can be JavaScript run in a web-browser or a hacked web-server running on another system. How can it be prevented that a malicious code who managed to get into an application and be executed there, can access information outside this application? Forces: • In some cases, e.g. in some web-applications where java applets are used, it is necessary to run a third-party code. It cannot be guaranteed that this code is not a malicious code. • To prevent that the application can access any files is often also not useful since the application may require certain access rights to perform their tasks. On the other hand, e.g. a web-server, once launched requires only very few privileges. Often they run with much more privileges than they really require which would be a threat to the underlying system if the web-server was hacked. 43 [Mahmoud,
2000]
86
10.8
Pattern Candidates
10
SECURITY DESIGN PATTERNS
• Security policies often exist and an enforcement mechanism is necessary to verify that applications only do what the security policy allows. • Any additional checks and scans impact performance. Often a complete emulation is simply an overkill. Therefore the solution needs to be as little intrusive as possible, but should still be able to enforce security policies. Solution: The SANDBOX pattern is a mechanism to enforce security policies and to restrict application privileges to only the necessary ones. There are different examples of sandboxes. Though, they have some measures in common. At first, the security policy has to be defined which maps a “set of properties that characterize running code to a set of access permissions granted to the code” [Mahmoud, 2000]. The SANDBOX differentiates between local code, which is considered trusted code and third-party code, e.g. which is a downloaded code and is considered as an untrusted code. This untrusted code can access only limited resources provided inside the sandbox and is controlled via a security policy. To enforce this policy, different options are used (see below); Example: Like in Unix systems or the Java security model, the SANDBOX is realized by providing an observer which intercepts all system calls and checks them for their compliance with the security policy as described by Mouratidis44 . For realization two components are being used, the observer which intercepts the system calls and the policyagency which knows about the applications privileges. If a system call does not comply with the security policy, the sandbox can prevent this call from happening, can log this event and can even shut down the requesting process. Another option, described at the SERVER SANDBOX on Unix system is, that they launch with administrator privileges and then switch into a user-account where the system automatically limits the access rights of the application. This is a one-way switch, so the application cannot return to administrator privileges [Darrell-M.-Kienzle:kx]. This is a specialization of the SANDBOX pattern. Further implementations can be found here: • Google Native Client http://en.wikipedia.org/wiki/Google_Nati ve_Client and http://code.google.com/p/nativeclient • Java 2 Runtime -> here e.g. the class SecurityManager provides sandboxing features. • Another example is the Apache Web-Server which also makes use of this pattern to run the incoming requests inside of sandboxed processes. • Finally the Apple Development Environment forces developers since its operating system 10.8 to use the Apple Sandbox45 when publishing applications to the AppStore. Consequences: When applying this solution the following benefits should be considered: • Third-party code or untrusted applications can be executed without compromising the security of the underlying system or other applications. • Possible attacks can be detected by observing and logging violations of the security policy. 44 [Haralambos. 45 [Blazakis,
Mouratidis, 2006] 2011]
87
10.8
Pattern Candidates
10
SECURITY DESIGN PATTERNS
• Often frameworks already provide sandbox environments which makes it easier to use (like Apple XCode or the Java 2 Framework). • This solution can be implemented system-independently. In fact it is already used in different environments like mobile systems, web-browsers or operating systems. Disadvantages: • This solution results in additional complexity of the system. In some systems, e.g. when developing for Apple Operating System, the sandbox-API’s have to be considered in an application too. This has impact on the complexity of the application itself. • If a sandbox is too restrictive, or an application requires some extra privileges, it can hinder an application from performing its task. • This solution has impact on performance. • Different applications and systems working together can result in multiple security policies which makes it very complicated and can expose a threat too. Further Information, please refer to: • Javaworld http://www.javaworld.com/javaworld/jw-08-1997/jw08-hood.html • Google Chromium Project http://www.chromium.org/developers/de sign-documents/sandbox • Server Sandbox pattern [Darrell M. Kienzle, ] • Security Policy pattern [Mahmoud, 2000] • Phung, Desmet [Phung and Desmet, 2012] • Mouratidis et al in [Haralambos. Mouratidis, 2006] and [Haralambos Mouratidis, 2003] Dependencies: This pattern makes use of some sort of ACCESS RIGHTS pattern. In addition it can be implemented as some sort of SECURE ACCESS LAYER provided by the system itself and not by the application. 10.8.2
Virtualization
Intent: Virtualization is already common practice in client-server setups. Often the main goal is not security but more efficient resource management and maintainability46 . Nonetheless virtualization has as well negative as positive impacts on some security problems. This section tries to focus on virtualization from the view-point of a security design pattern. The VIRTUALIZATION pattern presents a solution and a threat from a security perspective. A solution to minimize the attack surface area and to reduce the complexity of system configuration, for the minimized system configurations below the application as well as for the physical and networking configuration since it allows to run multiple systems on just a single hardware. But it also poses threads to the system, e.g. in performance and denial of service attacks. 46 [Tal
Garfinkel, 2007]
88
10.8
Pattern Candidates
10
SECURITY DESIGN PATTERNS
Context: The VIRTUALIZATION can be applied in many different circumstances. VIRTUALIZATION is often used when companies make use of lots of different systems which all are available over a network, e.g. the intranet and the internet. Problem: Ever more heterogeneous systems and applications are being used by single companies to fit to the different tasks in a company environment. How can all these different systems be setup, managed and maintained? Forces: • Many different systems should be managed. • With many different applications on one system the configuration complexity increases and the attack surface area becomes bigger. • The use of hardware-resources should be more efficient. • Often applications contain business-critical content which is valuable for attackers. Solution: There are three basic approaches to Virtualization: “Paravirtualization (PVM): PVM requires no special hardware to realize virtualization, instead relying on special kernels and drivers.”47 (E.g. XEN from Amazon cloud) “Hardware Virtual Machine: The guest simply interacts with hardware drivers unaware that it is running in a VM and actually communicating with an emulated interface.”48 49 (E.g. VMware) “Container Virtualization: or OS-level virtualization, creates multiple secure containers to run different applications in.”50 (E.g. Solaris Zones) Each application can run in an own Virtual Machine. Some of the Virtual Machine approaches are relatively similar to the SANDBOX approach. “VIRTUALIZATION serves as a method to intercept device access or system execution in order to multiplex the underlying hardware.”51 Example: In figure 34 a block diagram of a Hardware Virtual Machine (VM) is shown. The VM allows to run several systems on one hardware. The systems are specialized for the applications running on it. Consequences: When applying this solution the following benefits should be considered: Benefits (according to Garfinkel et al52 and Bratus et al53 ): • Independence from the underlying hardware which makes an exchange of the hardware easier.. • Copying and moving the system to another system is easier because there are no changes to the application and system inside the VIRTUALIZATION. 47 [Shea
and Liu, 2012] and Liu, 2012] 49 [Shea and Liu, 2012] 50 [Shea and Liu, 2012] 51 [Bratus et al., 2008] 52 [Tal Garfinkel, 2007] 53 [Bratus et al., 2008]) 48 [Shea
89
10.8
Pattern Candidates
10
SECURITY DESIGN PATTERNS
is ing e VM lat ar u dw em ar h
Application 1
Application 2
Application 3
Application 4
Virtual Machine
Virtual Machine
Virtual Machine
Virtual Machine
Software
Hypervisor
Hardware Hardware
Network
Figure 34: Block diagram of a hardware virtual machine • Applications are less vulnerable because systems are running on minimal configuration and only allow the really necessary features for the applications which minimizes the attack surface area. • It reduces the complexity of the system on which the application runs which makes setup and maintenance easier. • Much stricter security policies can be applied to each system since they are very specialized to one application. This allows more granular security mechanisms. • Additional security mechanisms can be applied at the VM-level like logging, traps and jail. • Hardware resources can be managed more efficiently. Disadvantages: • The complexity of the system-configuration can increase. Typically the amount of hardware-components and their setup decreases which makes it easier to maintain. In the end the setup of a virtualization-solution can be quite complex and difficult but the overall maintenance complexity typically decreases. • The Hypervisor exposes a single point of failure which could lead to damage on several systems simultaneously. • The VM presents another point of failure which does impact the application. • VIRTUALIZATION in any form presents an overhead which impacts performance costs.
90
10.8
Pattern Candidates
10
SECURITY DESIGN PATTERNS
• According to a study by Shea54 VIRTUALIZATIONS are vulnerable to denial of service attacks. Further Information, please refer to:
• Garfinkel and Warfield [Tal Garfinkel, 2007] • InfoQ Website [InfoQ, ] • Bratus et al [Bratus et al., 2008] and [Bratus et al., 2010]
54 [Shea
and Liu, 2012]
91
11
OUTLINING PATTERN DEPENDENCIES
MANAGER
CH
ITH
KS
M AC ETAD CE AT SS A-B CO AS NT ED RO L
C AC
AN
NM TIO EP
AU
N
URE SEC
PASS WOR D DE SIGN & US E CO A NTR D DR OLLE ESS D SPA VIRT CE UAL ID
G APPLICATIONS URIN SEC
UL USTF N DISTR POSITIO M DECO
TOR INPUT VALIDA
OUTPUT VALIDATOR
VIRTUALIZA TION
SANDBOX
EXECU
D TION
OMAIN
L VE LE
OF N AI TY CH ILI S RE SIB ES CU ON OC PR SE P S ED RE LL RO NT R CO EATO CU CR EXE T ED N OLL NME NTR IRO CO ENV N TIO
OS
GER
ST AT E
DO O
LOG
R
T IEN CL
N
R VE ER -S
T TEC PRO XY PRO
VE
RE E
RS
ERS
REV E
E ZON
ANNELS
RIZED
ILITA
ION
DEM
SECURE CH
STRATE GY
E
KNOWN PARTNERS
SECURE
Y
E ST ATE MAC HIN
SEC UR
EF AC TO R
UR
SE C
SING
T
RE AC CESS LAYER
LAYERS
ACCO UNT ING
SECU
INF OB ORM SC AT UR IO ITY N
TIO RA EG INT OXY PR
SE
ISI TO R
EV
R TO
SI VI security design pattern non-security pattern makes use of a specialization of complementary to
RD OA CKB BLA
SEC URE
FR ON
ER AG
D
FIL
IZA TIO
OR
EA UT H
C
EX
CU R
TY OF IBILI AIN NS CH SPO RE
SANDBOX VISITOR
S ES
ED AS -B L LE RO RO ONT C
R OA KB AC BL
T H OR IZA TI ON
F RE
LIMIT
ED A CCE
SS
EC
FU L ER L AC RO RS CESS W
SESSION SECURITY
VEL SECU MULTILE
CHECK POINT
RITY
T POIN S CES C LE A SING
R TO ICA NT HE
E ER
S
ONTROL ESS C ACC
T AU
R ITO ON
L OB JECT
GY TE RA ST
EM NC
NUL
LETO
N
Figure 35: Pattern dependencies and categorizations
11
Outlining Pattern Dependencies
To make use of one security design pattern doesn’t necessarily secure the application, because a pattern usually addresses only one security problem. As seen above, many patterns depend on each other or preferably make use of certain other patterns. This exactly outlines two things, at first, some patterns depend on other patterns in one way or the other. And in second place, some compositions of patterns are able to provide certain solution-packages for some environments. Some compositions could almost be seen as security design patterns themselves. In this section I want to outline both of these points.
11.1
Pattern Dependencies
Some patterns depend, complement or use other patterns. Figure 35 presents a full presentation of all security patterns described here in this paper between each other. However, to reduce complexity it doesn’t show the way how they are connected, e.g. if they compete with each other or they typically use the other pattern. Another possibility may be one pattern is a specialization of the other one. In the outer circle, represented in grey font, are patterns which are not directly security relevant where some security design patterns make use of, or are specialized and security-hardened variations.
92
11.2
11.2
Pattern Compositions
11
OUTLINING PATTERN DEPENDENCIES
Pattern Compositions
The aim of this section is to present some examples how a set of patterns can be used together and in which relation they stand to each other. This paper has chosen five pattern compositions which will be described in detail. As each software project is different, these pattern compositions have to be made fit for the special situation. Therefore this is meant to provide a starting point for developers and software architects for further discussion. For a systematic approach I will describe the pattern compositions using the following structure: • Name of the composition • Involved patterns • Example and Description • Consequences Further Reading: There are many recommendations on how to use or implement security patterns. Besides of the below described sets of patterns this paper can recommend some other sources which can be interesting for further information about how patterns can be implemented in a software engineering process. • Schmidt et al about connecting Security Requirements and Security Patterns using UML [Schmidt and Juerjens, 2011] • Kampffmeyer and Zschaler about “Finding The Pattern You Need: The Design Pattern Intent Ontology” [Kampffmeyer and Zschaler, 2007] 11.2.1
Single Access Point and Check Point
This is probably one of the most-frequented combinations. In most systems the SINGLE ACCESS POINT is used in combination with the CHECK POINT in which some AUTHORIZATION and AUTHENTICATION patterns hook into. Involved Patterns: • SINGLE ACCESS POINT • CHECK POINT • AUTHENTICATOR • AUTHORIZATION • SECURITY SESSION • ROLE-BASED ACCESS CONTROL • METADATA-BASED ACCESS CONTROL • MULTILEVEL SECURITY • REFERENCE MONITOR
93
11.2
Pattern Compositions
11
use
Single Access Point
OUTLINING PATTERN DEPENDENCIES
Check Point
hook in
hook in
Authenticator
hook in
Authorization
use use
Security Session
RBAC
use
use
Multilevel Security
use
Reference Monitor
MBAC
complement or replace
Figure 36: Block diagram of a typical composition or patterns around the CHECK POINT pattern Example and Description: In figure 36 a block diagram of the used patterns is presented. The basis is the SINGLE ACCESS POINT which ensures that every communication is going through this point. At this point the CHECK POINT is implemented which provides the features for AUTHENTICATION and AUTHORIZATION. At a successful authentication and authorization a SECURITY SESSION is being created at the check point. The AUTHORIZATION pattern itself makes use of some more specialized patterns, the ROLE-BASED ACCESS CONTROL, the METADATA-BASED ACCESS CONTROL, the MULTILEVEL SECURITY and the REFERENCE MONITOR. The multilevel-security pattern is used to classify the system resources after their security level, while the role-based access control defines the access rights of users to the different security levels of the resources. To complement this the metadata-based access control can be used to map process-rights, based on their attributes to the resource-levels in cases where there is no direct role behind the process. Finally the reference monitor is used to intercept all requests and to check the access rights, be it role-based or metadata-based. Consequences: This composition outlines the structure of basic components used for authentication and authorization. Benefits: • This solution is almost system independent. • It provides a basic mechanism to ensure identification, authentication and authorization, together with a session which prevents that a user has to re-authenticate at every request. • This composition is quite flexible since it makes it easy to change certain implementations. E.g. how a user is authenticated can be a two-factor authentication with user-name and password or a more complicated and secure solution. These changes do not effect the other systems if the implementation is done well. Disadvantages: • It certainly increases performance costs
94
11.2
Pattern Compositions
11
OUTLINING PATTERN DEPENDENCIES
• Complexity is increased and therefore the costs for development, deployment and maintenance will be increased. • Usability can be impacted. Usability and security should be balanced well, so that users do not get too annoyed about the system. • In an early stage of the project it can be very difficult to define the interfaces of the different components to each other. If these interfaces are not defined well, this can lead to problems later, which require greater impacts into other components and therefore are very expensive. 11.2.2
Full Access With Errors
This composition outlines a possible implementation of the FULL ACCESS WITH ERRORS pattern. A quick outline: The full access with errors pattern intents to provide full view of all functionality at the graphical user interface (GUI). Only if a function is requested by a user, the pattern checks the access rights and either returns the response or, if the user has no privileges to user this function, it will return an error message. Involved Patterns: Often the following patterns are considered together: • FULL ACCESS WITH ERRORS • some sort of access control, like the ROLE-BASED ACCESS CONTROL in combination with the REFERENCE MONITOR. • the EXCEPTION MANAGER or the CHECKS-pattern to manage exceptions and error messages. The use of these different patterns typically requires other patterns accordingly. E.g. the ROLE-BASED ACCESS CONTROL typically uses the SINGLE ACCESS POINT and CHECK POINT patterns too. But these won’t be outlined here because they are only of secondary importance to the FULL ACCESS WITH ERRORS. Example and Description: Figure 37 presents a block diagram outlining a very abstract overview of the relations between the mentioned patterns. If a user sends a request, e.g. the –help request in a Unix terminal, the system responds with a view of all available options. Though, if a user then tries to perform one of these operations, only then the system will check for the authorization and will respond accordingly. To stay in the Unix example, the system will check the role-based access rights of the user. If the user is allowed to perform this operation, the system will run it and will return the results. If the user is not eligible to perform this task, then an error-message will be shown, e.g. the user is not privileged to perform this task and a sudo command should be used. This may not apply to this form in the Unix system, but for example on Web-based applications where many different users have access to. It is also important to check which errormessages are presented, to not provide sensibly information about the system. To deal with error messages in the graphical user interface (GUI), either the CHECKS-pattern or the EXCEPTION MANAGER pattern can be used. A competing pattern is the LIMITED ACCESS pattern (see below). They both present the extremes of a range of options. Something in between would be for example a “gray out” solution, where possible options are shown, but grayed out to make it visible to users that they are not eligible to perform these operations.
95
11.2
Pattern Compositions
11
OUTLINING PATTERN DEPENDENCIES
User
result or error message request
Interface Role-Based Access Control
check access rights
Full Access With Errors
check
Access Rights
filter and create error messages
Exception Manager / CHECKS
Figure 37: Block diagram of the typical patterns used by the FULL ACCESS WITH ERRORS pattern Consequences: The consequences which go with the used patterns apply here too. The most relevant consequences are listed below: Benefits: • Since only one view is required, the GUI is relatively simple to implement. • Documentation needs to be done only once. • A user can see all available options, even if he has not the access rights to perform them. This can also be useful if the user is able to make an upgrade and expand his privileges, e.g. with a premium user model. Disadvantages • It may not be suitable for every situation to present all possible options. • To display all possible options can irritate users, especially if they receive many error messages when trying to perform operations they are not allowed to. • Even if the FULL ACCESS WITH ERRORS pattern checks each request for its compliance with the security policy, it might be useful to provide other access restriction mechanisms as well to follow the principle of “defense in depth”. To see other consequences, see 10.2.6. 11.2.3
Limited Access
The LIMITED ACCESS pattern presents an alternative to the FULL ACCESS WITH ERRORS. Where the full access with errors shows all possible options and checks access rights only before performing a task, the limited access pattern already checks the authorization before returning the graphical user interface. It modifies the view in a way, that only the options are presented for which the user has appropriate access rights.
96
11.2
Pattern Compositions
11
OUTLINING PATTERN DEPENDENCIES
User present View
cache access rights
request
View trust level 1
Null Object
Security Session
choose render
View trust level 2
Null Object Null Object
Limited Access
Vie w the s ar tru e ch os st lev en a cc el NUL of ordi L O the ng BJE use to as CTs r emp are ty r gap ende red s
check access rights
Role-Based Access Control
check
Access Rights
Figure 38: Block diagram of the typical patterns used for implementing the LIMITED ACCESS pattern Involved Patterns: This pattern typically is used with a set of other patterns together: • LIMITED ACCESS • ROLE-BASED ACCESS CONTROL or another access control mechanism. • SECURITY SESSION (sometimes used) to cache access rights. • NULL OBJECT Example and Description: This pattern is complementary to the FULL VIEW WITH ERRORS pattern. To represent this pattern composition, the setting of a web-server infrastructure is chosen. As seen in figure 38 already with the first user-request the access rights of the user to each operation and element (resource) are checked using the ROLEBASED ACCESS CONTROL pattern. Resources for which the user has no access rights, are being replaced by a NULL OBJECT. All accessible resources and the null objects are rendered into the view and are delivered to the user’s browser. It is a difficulty and has to be considered how to deal with empty rendered NULL OBJECTS which can pose ugly gaps in the user interface. A solution would be to use different views which are optimized for the available resources of certain trust levels (or roles according to the role-based access control). In addition the access rights of a user can be cached in the SECURE SESSION object which allows to lower performance costs for future requests. Consequences: For this pattern composition the consequences of the used patterns apply. Probably the most relevant consequences are that it allows a very simplified user interface where only the accessible resources are available. Users are neither being annoyed with error messages. The greatest drawback is that it can become very complex and difficult to retrofit this pattern into existing applications. The ugly empty gaps, where a resource has not been available, has to be considered and can impact the user experience.
97
11.2 11.2.4
Pattern Compositions
11
OUTLINING PATTERN DEPENDENCIES
Protection Reverse Proxy
This set of patterns does primarily belong into the “Client-Server” category. It’s functionality can be easily extended by using the INTEGRATION REVERSE PROXY or the FRONT DOOR instead of the PROTECTION REVERSE PROXY. Using these other patterns does widen the range of other used patterns too. This adds further functionality but also more complexity to the setup. The PROTECTION REVERSE PROXY (see 10.5.6) is a setup with the main goal to filter requests from an untrusted network on an application level protocol. A usual firewall does not filter the content of an application message, but only filters the network protocols. This setup can typically be combined with some other additional behavior to follow the principle of “Defense in Depth”. Involved Patterns: Following patterns are involved in this composition: • PROTECTION REVERSE PROXY • SINGLE ACCESS POINT • SECURE CHANNELS • VALIDATOR • DEMILITARIZED ZONE Example and Description: In figure 39 a block diagram is shown. The PROTECTION REVERSE PROXY is set inside a DEMILITARIZED ZONE to filter all traffic between an untrusted network and the application server on an application level protocol. In this setup the PROTECTION REVERSE PROXY is a realization of the SINGLE ACCESS POINT on a server-network level. To support the principle of “Defense in Depth” the application itself makes use of the INPUT VALIDATOR to filter the requests not only for typical malicious code, but also to reject logical illegal requests. The PROTECTION REVERSE PROXY may not know which formally correct requests may be logically illegal and therefore permitted. Finally the PROTECTION REVERSE PROXY can be the point where the SECURE CHANNELS pattern is implemented to guarantee a secure communication from the client to the servers over an untrusted network. Consequences: The consequences which go with the used patterns apply here too. The most relevant consequences are listed below: Benefits: • This solution is directly supporting the principle of “Minimizing the Attack Surface Area” since only the Protection Reverse Proxy is visible to the outside and therefore is also the Single Access Point. • It allows to filter for known vulnerabilities of the application. • The whitelist-approach of the Input Validator allows also to prevent attacks from unknown exploits as long as they are not within the allowed range of the security policy. • It is easy to add additional functions, like the INTEGRATION REVERSE PROXY. • The Secure Channels allow secure communication to a client over an untrusted network.
98
11.2
Pattern Compositions
11
OUTLINING PATTERN DEPENDENCIES
Single Access Point is an implementation se cu re d co nn ec ti on
Validator
Secure Channels
Application
Firewall
Protection Reverse Proxy Firewall
User
Is implemented in
DMZ
Figure 39: Block diagram of the typical patterns in a network architecture with PROTECTION REVERSE PROXY pattern Drawbacks: • All three, the Protection Reverse Proxy and the Input Validator filtering requests and the Secure Channels which encrypts the communication, are slowing down the connection and increase performance costs. • Configuration can become very complex and may require special skills. This will also increase setup and maintenance costs. • This adds additional possible vulnerable systems which can become the single point of failure. 11.2.5
Login and Secure Logger
This set of patterns presents a possible abstract architecture of the SECURE LOGGER pattern used at a LOGIN procedure. The login process is a critical one. On the one hand it is the point where the user is identified and authenticated, on the other hand a Security Session is set up. The other applications need to trust the login process. Therefore the login-process is the first contact-point of an unknown user to the system. This means, that if an attacker is not registered, this will be the first point where he will try to break into the system. The login-process has to balance between usability and security. The loginprocess should not be made too complicated to use but also should be secure enough for the security level of the information lying on the applications behind this process. How can a login-process be implemented which checks for violations, allows detection of attacks and doesn’t expose sensitive information? Involved Patterns: This set of patterns involves: • SECURE LOGGER • INPUT VALIDATOR • EXCEPTION MANAGER
99
11.2
Pattern Compositions
11
OUTLINING PATTERN DEPENDENCIES
Figure 40: Class diagram after Black Hat Briefings Example and Description: The figure 40 presents a class diagram of a possible implementation of the secure logger in a log-in process. When a user wants to log in into the system we make use of a special login-component. This component extends the INPUT VALIDATOR to check all content which is delivered by the user before further processing. The INPUT VALIDATOR itself implements a SERVICE FACTORY to make use of different other classes. The SERVICE FACTORY itself extends the EXCEPTION MANAGER and the SECURE LOGGER. If now the INPUT VALIDATOR finds a violation of the security policies it throws an error which is processed by the SERVICE FACTORY. The error is being handled by the EXCEPTION MANAGER which will return an appropriate error message to the user while on the other hand the SERVICE FACTORY will make use of the SECURE LOGGER to store the violating information for further investigation and attack detection measures. In addition the SECURE LOGGER itself can and should make use of an INPUT VALIDATOR to check if the logging information is valid and not malicious itself. If the INPUT VALIDATOR doesn’t find a violation, the login-process goes on and checks the credibility of the provided user-credentials. Consequences: The consequences which go with the used patterns apply here too. The most relevant consequences are listed below: Benefits: • The secure logging of violations of the security policies at the login process allows a detection of possible attacks. It also allows investigations when an attack has occurred. • The use of the Exception Manager helps to prevent that critical validation information is presented to the user. • The Input Validation before the user credentials are being processed, it helps preventing exploitation of these processes, e.g. by trying to perform an SQL-injection
100
12
CONCLUSION AND FUTURE WORK
• Performance overhead is minimized since the Exception Manager and the Secure Logger are only used if the Input Validator really finds a violation. Disadvantages: • Since every request is filtered, performance costs are increased. • The Input Validator can expose a single point of failure to the system. • If the Exception Manager and the Secure Logger don’t do Input Validation themselves, they again could be used for exploitation and pose a threat to the system. • The complexity of the Input process is increased.
12
Conclusion and Future Work
This paper uses a systematic literature review methodology to provide an overview over the landscape of security design patterns. During this process 36 security design patterns have been found and described in a structured way, similar to the one Schumacher et al55 have already made. In contrast to the work of Schumacher, and to provide guidance for software engineers, this paper gives an outline for each pattern, where developers can find further information about the pattern and which other patterns should be considered in a combination with the described one. Two of these 36 patterns, the SANDBOX pattern and the VIRTUALIZATION pattern, have not yet been described in standard literature as patterns. These two are commonly used and have already been mentioned as patterns in several resources. This paper puts together information from the different references and made an approach to describe them as patterns. In addition this paper puts a focus on how the described patterns are related to each other. Security design patterns are meant to solve an individual security problem, but typically leave other problems untouched. But different security problems often appear together. Therefore it is not surprising to see, that certain patterns are used in combination, to solve a certain set of problems. The relations between the patterns are described as: • A pattern can make use of another pattern. • A pattern can be an alternative to another pattern. Sometimes these alternative patterns can be used together, and in some other circumstances they cannot be used together. • A pattern can be a specialized variation of another pattern. This is presented in figure 35 which shows an overview of the relations between the patterns, which are described in this paper. It can be said that there is a strong relation between certain groups of patterns. Therefore this paper does recommend to make use of pattern-compositions, although these compositions vary heavily, due to the special project situations. The described compositions present a starting point for further discussions in the project teams. Regarding possible compositions, this thesis describes five sets of patterns which are being used together. • Access control patterns which are grouped around the SINGLE ACCESS POINT and the CHECK POINT. • Two sets of patterns representing the opposing structures around FULL ACCESS WITH ERRORS and LIMITED ACCESS. 55 [Schumacher,
2006]
101
13
ACKNOWLEDGMENT
• A set of patterns situated in the Client-Server category, using the DEMILITARIZED ZONE and the PROTECTION REVERSE PROXY. • And finally a set of patterns, presenting how the SECURE LOGGER can be used in a LOGIN process. Future Work: There are some things in this paper to be considered for future work. • First, the pattern candidates VIRTUALIZATION and SANDBOX. The work with these two patterns would be, to describe them more detailed and provide example implementations. • Secondly, the compositions. The structure how pattern compositions are described in this paper is only fundamental. Future work could deal with describing these pattern compositions in detail, maybe even providing some sample implementations. • Thirdly, It would be beneficial to develop further guidelines how to appropriately fit these sets of patterns to the specific project and product requirements.
13
Acknowledgment
The author wants to thank Joachim Charzinski (Hochschule der Medien, Stuttgart), Manfred Schäfer and Rainer Schmitz (Nokia Siemens Networks Management International GmbH) for the support, for answering many questions and their thoughtful comments and ideas on this research.
102
14
14 14.1
APPENDIX
Appendix Appendix A
Kitchenham suggested a table similar the following to estimate the quality of the findings. 1 Evidence obtained from at least one properly-designed randomized controlled trial 2 Evidence obtained from well-designed pseudo-randomized controlled trials (i.e. non- random allocation to treatment) 3-1 Evidence obtained from comparative studies with concurrent controls and allocation not randomized, cohort studies, case-control studies or interrupted time series with a control group 3-2 Evidence obtained from comparative studies with historical control, two or more single arm studies, or interrupted time series without a parallel control group 4-1 Evidence obtained from a randomized experiment performed in an artificial setting 4-2 Evidence obtained from case series, either post-test or pre-test/post-test 4-3 Evidence obtained from a quasi-random experiment performed in an artificial setting 5 Evidence obtained from expert opinion based on theory or consensus
14.2
CD
103
REFERENCES
15
Bibliography
References [ISO, 1996] (1996). Information technology - open systems interconnection - basic reference model: The basic model. In ISO/IEC 7498-1, number ISO/IEC 7498-1:1994(E), page 68. ISO/IEC, http://standards.iso.org/ittf/PubliclyAvaila bleStandards/s020269_ISO_IEC_7498-1_1994(E).zip. 33 [owa, 2010] (2010). Url: www.owasp.org/index.php/Data%5C_Validati on, last-checked: 12.08.2012 34 [Babar et al., 2005] Babar, M., Wang, X., and Gorton, I. (2005). Supporting security sensitive architecture design. In Reussner, R., Mayer, J., Stafford, J., Overhage, S., Becker, S., and Schroeder, P., editors, Quality of Software Architectures and Software Quality, volume 3712 of Lecture Notes in Computer Science, pages 140–154. Springer Berlin / Heidelberg. 10.2.3, 10.2.6, 10.2.7, 10.2.11, 10.2.12, 10.2.13, 10.6.2 [Blazakis, 2011] Blazakis, D. (2011). The apple sandbox. (http://www.semantis cope.com/research/BHDC2011):26. 45 [Bratus et al., 2008] Bratus, S., Locasto, M. E., Ramaswamy, A., and Smith, S. W. (2008). Traps, events, emulation, and enforcement: managing the yin and yang of virtualization-based security. In Proceedings of the 1st ACM workshop on Virtual machine security, VMSec ’08, pages 49–58, New York, NY, USA. ACM. 51, 53, 10.8.2 [Bratus et al., 2010] Bratus, S., Locasto, M. E., Ramaswamy, A., and Smith, S. W. (2010). Vm-based security overkill: a lament for applied systems security research. In Proceedings of the 2010 workshop on New security paradigms, NSPW ’10, pages 51–60, New York, NY, USA. ACM. 10.8.2 [Briefings, ] Briefings, B. H. Security design patterns. In Hat, B., editor, Black Hat Briefings, page 36. 10.3.1, 10.6.1, 39 [Chad Dougherty, 2009] Chad Dougherty, Kirk Sayre, R. C. S. (2009). Secure design patterns. Technical Report, CMU/SEI-2009-TR-010(ESC-TR-2009-010):118. 10.2.10, 10.3.1, 10.4.2, 10.4.4, 21, 10.4.6, 26, 10.4.7, 10.4.8, 10.4.9, 10.7.6, 10.7.12, 10.7.14 [Darrell M. Kienzle, ] Darrell M. Kienzle, Matthew C. Elder, D. T. J. E.-H. Security Patterns Repository Version 1.0. PhD thesis. 10.8.1 [F. Lee Brown, 1999] F. Lee Brown, E. B. F. (1999). The authenticator pattern. In PLoP99 Conference, page 8. 10.2.1 [Gamma et al., 1995] Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995). Design patterns: elements of reusable object-oriented software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. 1, 10.2.3, 13, 14, 15, 16, 19, 22, 23, 24, 25, 10.4.7, 27, 28, 29, 10.4.8, 10.4.8, 30, 31, 37, 10.7.7 [group, a] group, O. Oasis group. url: https://www.oasis-open.org, lastchecked: 17.8.2012 10.7.13 [group, b] group, O. Xaml documents. url: http://docs.oasis-open.org/xa cml/, last-checked: 17.8.2012 10.7.13, 40
104
REFERENCES
REFERENCES
[Haralambos Mouratidis, 2003] Haralambos Mouratidis, Paolo Giorgini, M. S. (2003). Security patterns for agent systems. In Proceedings of the 8th European Conference on Pattern Languages of Programs 2003, Irsee-Germany, number isbn: 978-3-87940788-0, page 17, http://www.uvk.de/buch.asp?ISBN=9783879407880. University of East London, University of East London Institutional Repository. 10.8.1 [Haralambos. Mouratidis, 2006] Haralambos. Mouratidis, Michael Weiss, P. G. (2006). Modelling secure systems using an agent oriented approach and security patterns. International Journal of Software Engineering and Knowledge Engineering, (DOI: 10.1142/S0218194006002823):28. 44, 10.8.1 [Helkala, 2011] Helkala, K. (2011). Password education based on guidelines tailored to different password categories. Journal of Computers, 6(doi:10.4304/jcp.6.5.969975):7. 10.1.1 [Homeland Security, ] Homeland Security, U. G. Principles. Url: https: //buildsecurityin.us-cert.gov/bsi/articles/knowledge/p rinciples.html, last-checked: 16.8.2012 3, 9, 11 [InfoQ, ] InfoQ. Virtualization and security. Url: http://www.infoq.com/arti cles/virtualization-security, last-checked: 19.8.2012 10.8.2 [Kampffmeyer and Zschaler, 2007] Kampffmeyer, H. and Zschaler, S. (2007). Finding the pattern you need: The design pattern intent ontology. In Engels, G., Opdyke, B., Schmidt, D., and Weil, F., editors, Model Driven Engineering Languages and Systems, volume 4735 of Lecture Notes in Computer Science, pages 211–225. Springer Berlin / Heidelberg. 11.2 [Kitchenham, 2004] Kitchenham, B. (2004). Procedures for performing systematic reviews. Joint Technical Report, page 33. 5, 6, 7 [Lars-Helge Netland, 2006] Lars-Helge Netland, Yngve Espelid, K. A. M. (2006). Security pattern for input validation. In Aino Vonge Corry, Pavel Hruby, K. E. S., editor, Proceedings of the Fifth Nordic Conference on Pattern Languages of Programs, number ISBN 978-87-92411-00-6. Hillside Group, REA Technology. 35, 36, 10.6.1 [Mahmoud, 2000] Mahmoud, Q. H. (2000). Security policy: A design pattern for mobile java code. page 8. School of Computer Science, Carleton University. 43, 10.8.1, 10.8.1 [Mariemma I. Yagüe, 2005] Mariemma I. Yagüe, Antonio Maña, J. L. (2005). A metadata-based access control model for web services. In Limited, E. G. P., editor, Internet Research, volume 15, page 18, www.emeraldinsight.com/1066-22 43.htm; DOI 10.1108/10662240510577095. Emerald Group. 10.2.8 [Ortega-Arjona and Fernandez, 2008] Ortega-Arjona, J. L. and Fernandez, E. B. (2008). The secure blackboard pattern. In Proceedings of the 15th Conference on Pattern Languages of Programs, PLoP ’08, pages 22:1–22:5, New York, NY, USA. ACM. 10.6.3, 38 [Ott, ] Ott, A. Rsbac - website. Url: http://www.rsbac.org/why, last-checked: 24.8.2012 10.7.13, 42 [OWASP, ] OWASP. Owasp principles. Url: https://www.owasp.org/index. php/Category:Principle, last-checked: 16.8.2012 4, 9 [Phung and Desmet, 2012] Phung, P. H. and Desmet, L. (2012). A two-tier sandbox architecture for untrusted javascript. In Proceedings of the Workshop on JavaScript Tools, JSTools ’12, pages 1–10, New York, NY, USA. ACM. 10.8.1
105
REFERENCES
REFERENCES
[Schmidt and Juerjens, 2011] Schmidt, H. and Juerjens, J. (2011). Connecting security requirements analysis and secure design using patterns and umlsec. In Proceedings of the 23rd international conference on Advanced information systems engineering, CAiSE’11, pages 367–382, Berlin, Heidelberg. Springer-Verlag. 11.2 [Schumacher and Schumacher, 2003] Schumacher, M. and Schumacher, M. (2003). A theoretical model for security patterns. In Security Engineering with Patterns, volume 2754 of Lecture Notes in Computer Science, pages 121–140. Springer Berlin / Heidelberg. 12 [Shea and Liu, 2012] Shea, R. and Liu, J. (2012). Understanding the impact of denial of service attacks on virtual machines. In Proceedings of the 2012 IEEE 20th International Workshop on Quality of Service, IWQoS ’12, pages 27:1–27:9, Piscataway, NJ, USA. IEEE Press. 47, 48, 49, 50, 54 [Schumacher, 2006] Sommerlad, M. S. E. F.-B. D. H. F. B. P. (2006). Security Patterns: integrating security and systems engineering. Number 978-0-470-85884-4 in Software Design Patterns. Wiley, Chichester. 2, 8, 9, 10, 10.1.1, 10.1.1, 10.2.1, 10.2.2, 10.2.3, 10.2.4, 10.2.5, 10.2.6, 10.2.7, 10.2.9, 10.2.10, 10.2.11, 10.2.12, 10.2.13, 20, 10.4.1, 10.4.2, 10.4.3, 10.4.5, 10.5.1, 10.5.2, 32, 10.5.3, 10.5.4, 10.5.5, 10.5.6, 10.5.7, 10.7.1, 10.7.2, 10.7.3, 10.7.4, 10.7.5, 10.7.8, 10.7.9, 10.7.10, 10.7.15, 55 [Tal Garfinkel, 2007] Tal Garfinkel, A. W. (2007). what virtualization can do for security. LOGIN, 32(6):7. 46, 52, 10.8.2 [Torsten Priebe, 2004] Torsten Priebe, E. B. F. (2004). A pattern system for access control. In Proc. of the 18th. Annual IFIP WG 11.3 Working Conference on Data and Applications Security, page 15. 10.2.2, 10.2.8, 10.2.11, 10.2.12 [Wang et al., 2005] Wang, J., Song, Y.-T., and Chung, L. (2005). Analysis of secure design patterns: A case study in e-commerce system. In Proceedings of the Third ACIS Int’l Conference on Software Engineering Research, Management and Applications, SERA ’05, pages 174–183, Washington, DC, USA. IEEE Computer Society. 10.2.3, 10.2.6, 10.2.7, 10.2.11, 10.2.12, 10.2.13, 10.6.2 [Wikipedia, ] Wikipedia. Rule-set based access control. Url: http://en.wikiped ia.org/wiki/RSBAC, last-checked: 17.8.2012 10.7.13, 41 [Yoder and Barcalow, 1998] Yoder, J. and Barcalow, J. (1998). Architectural patterns for enabling application security. Urbana, 51:61801. 10.2.3, 10.2.6, 10.2.7, 10.2.11, 10.2.12, 10.2.13, 10.6.2
106
