Classifying Security Patterns - Springer Link

6 downloads 17252 Views 216KB Size Report
1 Department of Computer Science and Engineering, Florida Atlantic University,. Boca Raton, FL ... They are also useful to compare security standards and to.
Classifying Security Patterns Eduardo B. Fernandez1, Hironori Washizaki2, Nobukazu Yoshioka2, Atsuto Kubo3, and Yoshiaki Fukazawa3 1

Department of Computer Science and Engineering, Florida Atlantic University, Boca Raton, FL, USA [email protected] 2 National Institute of Informatics, 2-1-2 Hitotsubashi, Chiyoda-ku, Tokyo 101-8430, Japan {washizaki, nobukazu}@nii.ac.jp 3 Department of Computer Science and Engineering, Waseda University, 3-4-1 Ohkubo, Shinjuku-ku, Tokyo 169-8555, Japan {a.kubo, fukazawa}@fuka.info.waseda.ac.jp

Abstract. Patterns combine experience and good practices to develop basic models that can be used for new designs. Security patterns join the extensive knowledge accumulated about security with the structure provided by patterns to provide guidelines for secure system design and evaluation. In addition to their value for new system design, security patterns are useful to evaluate existing systems. They are also useful to compare security standards and to verify that products comply with some standard. A variety of security patterns has been developed for the construction of secure systems and catalogs of them are appearing. However, catalogs of patterns are not enough because the designer does not know when and where to apply them, especially in a large complex system. We discuss here several ways to classify patterns. We show a way to use these classifications through pattern diagrams where a designer can navigate to perform her pattern selection. Keywords: Pattern classification, security patterns, secure system development, system architecture.

1 Introduction A pattern is a packaged reusable solution to a recurrent problem. Design patterns embody the experience and knowledge of many designers and when properly catalogued, they provide a repository of useful solutions for different types of problems [8]. They have shown their value in many projects and have been adopted by many institutions. Design patterns have been extended to other aspects of software, first to architectural aspects of design, then to the analysis stage. Analysis and design patterns are now well established as a convenient and reusable way to build highquality object-oriented software. Security has become an important concern in current systems. The main objectives of security are to protect the confidentiality, integrity, and availability of data. Data is Y. Zhang et al. (Eds.): APWeb 2008, LNCS 4976, pp. 342–347, 2008. © Springer-Verlag Berlin Heidelberg 2008

Classifying Security Patterns

343

a valuable resource and it has become the target of many attacks by people who hope to gain monetary advantages, make political statements, or just vandalize. Security countermeasures are usually classified into five groups: Identification and Authentication, Access Control and Authorization, Logging, Cryptography, and Intrusion Detection. Security patterns describe mechanisms that fall into these categories (or combinations thereof) to stop or mitigate attacks as well as the abstract models that guide the design of these mechanisms. Security patterns join the extensive knowledge accumulated about security with the structure provided by patterns to provide guidelines for secure system construction and evaluation. A good number of security patterns have been described in the literature and several catalogs have appeared [3, 9, 11, 12, 13, 14]. However, it is not enough to have a catalog of security patterns, we also need a guidance for the designers about how to select appropriate patterns. We are seeing the appearance of more and more complex systems, incorporating web access and all kinds of distribution structures. Security should be applied in the whole life cycle of applications and at each stage patterns can be applied to provide specific security controls. A designer who is not a security expert would be lost trying to apply them into her design. Designers need guidance about how to select appropriate patterns. A step in this direction is a good classification of security patterns. We present here some possible classifications based on architectural concerns, architectural layers, and some relationships between patterns. We show the use of these classifications through a pattern diagram, where the designer can navigate in order to select appropriate patterns. Sections 2 and 3 show several classifications based on different viewpoints for security patterns. Section 4 introduces a diagram for describing relationships based on those classifications. The last section presents some conclusions and future work.

2 Classifications Based on Architectural Concerns and Architectural Layers Because we consider security patterns to be architectural patterns, we should look at software architecture classifications. [1] classifies architectural patterns using the type of concerns they address, e.g. Layered Structure, Data Flow, Adaptation, User Interaction, Distribution. This means we should classify security patterns according to their concerns, e.g. patterns for access control, cryptography, file control, identity, etc. For example, authentication in distributed systems is considered in: Authenticator, Remote Authenticator /Authorizer, and Credential (see [3] for references to these patterns). Chapters 7 and 8 of [12] are organized in this way. We can think of a computer system as a hierarchy of layers, where the application layer uses the services of the database and operating system layers, which in turn, execute on a hardware layer. These layers provide another dimension for classification. We can define patterns at all levels. This allows a designer to make sure that all levels are secured, and also makes easier propagating down the high-level constraints. At the highest level we have patterns that describe the use of security models to define access control to the application objects: Authorization (Access Matrix), Role-Based

344

E.B. Fernandez et al.

Access Control (RBAC), Reference Monitor, Multilevel Security, Attribute-Based Access Control (ABAC). A recent paper defines Session-Based versions of those patterns [5]. At the operating system level we have patterns such as Secure Process, Controlled Virtual Address Space, and others. Patterns for web services security include: Application Firewall, XML Firewall, XACML Authorization, XACML Access Control Evaluation, and WSPL [2] (References for all these are found in [3]). Fig. 1 shows the combination of concerns and levels where patterns with the same concern, e.g. Authentication, may appear in multiple levels. The life cycle stage where the pattern is applied is another dimension. For example, security models are selected in the analysis stage while distribution approaches are selected at the design stage.

A p p lic a tio n F i r e w a ll

R e f e r e n c e M o n ito r

O S R e f M o n ito r

X M L F i r e w a ll

X A C M L A ccess C o n tr o l E v a lu a to r

P ro x y F ire w a ll

A u th e n ti c a to r

O S A u th e n tic a to r

S A M L A u th e n ti c a to r

R e m o te A u th e n t ic a to r

P a c k e t F ilte r F ire w a ll

Fig. 1. Types of patterns and levels

3 Automatic Relationships between Patterns Kubo et al. [10] have proposed an automated relationship analysis technique for patterns. This technique utilizes existing text processing techniques (such as TF-IDF and vector space model) to extract patterns from documents and to calculate the strength of pattern relationships based on document similarity. We apply now this technique to security patterns belonging to four catalogs: Fernandez’ firewall patterns [12], legal cases pattern [6], and other patterns, together with Yoder's architectural patterns [15]. Fig. 2 visualizes some of the results. The resulting graph is a specific classification, which suggests several useful relationships

Classifying Security Patterns

345

including some which are not explicitly specified in the original documents. For example: •



The pattern Secure Handling of Legal Cases [6] is recognized as a sub-pattern included in the resulting context of another pattern Packet Filter Firewall [12] denoted by a Sub In Resulting relation. This relation is not specified in [6, 12]; however it is reasonable because the domain model of Secure Handling of Legal Cases assumes the use of reference monitors such as the packet filter firewall. In other words, the use of a Packet Filter Firewall leads to a resulting context in which legal cases (such as when clients are sued by another party) can be handled in a secure way. As another example, there is a Similar Forces relation (i.e. relation in which forces of two patterns are similar) between Roles [15] and Secure Handling of Legal Cases. This cross-cutting relation over different catalogs is reasonable because those patterns share similar constraints such as the existence of a large number of users for the target system and the inconvenience of customizing security for each person.

These newly found relations are useful for selecting security patterns belonging to several catalogs. This technique can extract appropriate relationships in a catalog and across different catalogs. Since this technique is automated, this technique is more scalable than other manual classification techniques. However, there is a tradeoff between scalability and validity; manual classification techniques are superior in terms of result’s validity because they are based on experts’ considerations.

Session

Similar Result

Checkpoint

Similar Result

Similar Result Similar Result

Single Access Point

Full View With Errors

Similar Result Limited View

Similar Forces Roles Similar Forces Secure Handling Of Legal Cases Sub In Resulting

Pattern in ref.[15] Pattern in ref.[6] Pattern in ref.[12]

Packet Filter Firewall Fig. 2. Automated relation analysis result for security patterns

346

E.B. Fernandez et al.

4 Pattern Diagrams Fig. 3 shows a pattern diagram that relates some operating system security patterns [12]. A pattern diagram uses these classifications to help the designer navigate in the design space. For example, an operating system designer can start from a Secure Process and use a Controlled Process Creator to create new processes in a secure way (controlling their initial rights). These processes can then execute in a Controlled Virtual Address Space (with controlled rights). The general structure of the virtual address space is defined through a Virtual Address Space Structure Selection. V irt u a l A d d re ss S p a ce S t r u ct u re S e l e c tio n us es e xe c u te s i n

Co n tro ll e d V ir t ua l A d d re s s S p a c e d e fi n es a c ce s s

S e cu r e P r o c e ss

A dm i n is t r at o r H ierarc hy

fas t e r co n te xt s w it ch

au th o ri z e d b y

S e c u re Th re a d

c re a t e d b y

R BA C C o n tr o ll e d P ro ce s s C r e a to r

R e fe r e n c e M o n i to r

(R o le B a se d A cc ess Co ntro l)

d e fi ne ri g h ts

sp e ci a li z e s

A u th o r i za ti o n e n fo rc e d b y

Fig. 3. Pattern diagram for some operating system patterns

5 Conclusions and Future Work Patterns can be classified according to many viewpoints. A good classification can make their selection easier and more precise. We have shown three possibilities: using as reference the architectural/functional objectives of the patterns, using as reference the architectural layers of a system, and looking at linguistic similarities in their descriptions. Combining these classifications and expressing them as pattern diagrams which summarize the relevant patterns at a given stage or for a given concern, can guide designers in the selection of appropriate patterns. Future work will include refining these classifications and incorporate them in a proposed methodology [7] and the development of further patterns. We are also working on the use of patterns combined with Model-Driven Development to produce secure systems. We will also check the tradeoff between manual and automatic classifications and clarify the applicability of each classification technique. Composition of patterns to accomplish more complex properties is another open problem. Finally, how well the patterns cover the space of requirements needs to be evaluated.

Classifying Security Patterns

347

References 1. Avgeriou, P., Zdun, U.: Architectural patterns revisited—A pattern language. In: Procs. EuroPLoP 2005, pp. 1–39 (2005) 2. Delessy, N., Fernandez, E.B., Larrondo-Petrie, M.M.: A pattern language for identity management. In: Procs. of the 2nd IEEE Int. Multiconference on Computing in the Global Information Technology (ICCGI 2007), Guadeloupe, French Caribbean, March 4-9 (2007) 3. Fernandez, E.B.: Security patterns. In: Procs. of the Eigth International Symposium on System and Information Security - SSI 2006 (Keynote talk) Sao Jose dos Campos, Brazil, November 08-10 (2006) 4. Fernandez, E.B., Larrondo-Petrie, M.M., Sorgente, T., VanHilst, M.: A methodology to develop secure systems using patterns. In: Mouratidis, H., Giorgini, P. (eds.) Integrating security and software engineering: Advances and future vision, ch. 5, pp. 107–126. IDEA Press (2006) 5. Fernandez, E.B., Pernul, G.: Patterns for session-based access control. In: Procs. of the Pattern Languages of Programming Conference (PLoP 2006) (2006) 6. Fernandez, E.B., la Red Martinez, D.L., Forneron, J., Uribe, V.E., Rodriguez, G.: A secure analysis pattern for handling legal cases. In: Proc. 6th Latin American Conference on Pattern Languages of Programming (2007) 7. Fernandez, E.B., Yoshioka, N., Washizaki, H., Jurjens, J.: Using security patterns to ‘build secure systems. In: Procs. 1st Int. Workshop on Software Patterns and Quality (SPAQu 2007), Nagoya, Japan, December 3 (2007) 8. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design patterns –Elements of reusable object-oriented software. Addison-Wesley, Reading (1994) 9. Kienzle, D.M., Elder, M.C., Tyree, D., Edwards-Hewitt, J.: Security patterns repository, Version 1.0., http://www.modsecurity.org/archive/securitypatterns/ dmdj_repository.pdf 10. Kubo, A., Washizaki, H., Takasu, A., Fukazawa, Y.: Extracting relations among embedded software design patterns. Journal of Integrated Design and Process Science 9(3), 39–52 (2005) 11. The Open Group, Security Design Patterns Technical Guide, http://www.opengroup.org/security/gsp.htm 12. Schumacher, M., Fernandez, E.B., Hybertson, D., Buschmann, F., Sommerlad, P.: Security Patterns: Integrating systems and software engineering. J. Wiley, Chichester (2006) 13. Schumacher, M.: The Security Patterns page, http://www.securitypatterns. org 14. Steel, C., Nagappan, R., Lai, R.: Core Security Patterns: Best Strategies for J2EE, Web Services, and Identity Management. Prentice Hall, New Jersey (2005) 15. Yoder, J., Barcalow, J.: Architectural Patterns for Enabling Application Security. In: 4th Conference on Pattern Languages of Programs (PLoP 1997) (1997)