Problem Frames and Architectures for Security Problems Denis Hatebur‡ and Maritta Heisel§
Abstract: We present two (?) problem frames that serve to structure, characterize and analyze software development problems in the area of software and system security. These problem frames constitute patterns for representing security problems, variants of which occur frequently in practice. Solving such problems starts with the development of an appropriate software architecture. To support that process, we furthermore present architectural patterns associated with the problem frames.
1 Introduction Problem frames were developed by Michael Jackson [Jac01]. He describes them as follows (emphasis ours): A problem frame is a kind of pattern. It defines an intuitively identifiable problem class in terms of its context and the characteristics of its domains, interfaces and requirement. Pattern-orientation is a promising approach to software development. Patterns are a means to reuse software development knowledge on different levels of abstraction. They classify sets of software development problems or solutions that share the same structure. Patterns have been introduced on the level of detailed object oriented design [GHJV95]. Today, patterns are defined for different activities at different stages of the software life cycle. Problem Frames [Jac01] are patterns that classify software development problems. Architectural styles are patterns that characterize software architectures [SG96, BCK98]. They are also called “architectural patterns”. Design Patterns are used for finer-grained software design, while idioms are low-level patterns related to specific programming languages [BMR+ 96]. Using patterns, we can hope to construct software in a systematic way, making use of a body of accumulated knowledge, instead of starting from scratch each time. The problem frames defined by Jackson (see Section ) cover a large number of software development problems, because they are quite general in nature. To support software development in more specific areas, however, specialized problem frames are needed. In this paper, we present two problem frames that capture software development problems occurring frequently in the area of software and system security. The first problem frame deals with the secure (i.e., encrypted) transmission of data. The second one is suitable for generating and storing security information (such as public and private keys, PINs). We call these problem frames security frames. They are described in Section . Problems are fitted into problem frames by instantiating the variable parts of the frame. Successfully fitting a problem into a given problem frame means that the concrete problem indeed exhibits the propteries that are characteristic for the problem class defined by the problem frame. Since all problems fitting in a problem frame share the same characterstic properties, their solutions will have common characteristic ‡ Universit¨ at Duisburg-Essen, Fachbereich Ingenieurwissenschaften, Institut f¨ur Medientechnik und Software-Engineering, Germany, email:
[email protected] and Institut f¨ur technische Systeme GmbH, email:
[email protected] § Universit¨ at Duisburg-Essen, Fachbereich Ingenieurwissenschaften, Institut f¨ur Medientechnik und Software-Engineering, Germany, email:
[email protected]
properties, too. Therefore, it is worthwhile to look for solution structures that match the problem structures defined by problem frames. Architectural patterns are suitable solution structures for problem frames, because architectural design is one of the first activities in solving software development problems. Hence, the gap between the problem desciption and the software architecture is not too large, and we can establish direct relations between problem structures and solution structures. As we have shown for the problem frames defined by Jackson, one can define architectural patterns that reflect the different characteristics of the problem frames [CHH04]. Similarly to Jackson’s problem frames, we equip our security frames with corresponding architectural patterns. These patterns are described in Section . We illustrate our approach in demonstrating how the problem of developing a secure electronic purse card is addressed in Section .
2 Problem Frames and Architectural Patterns In this paper, we present new problem frames for security problems and the corresponding architectural patterns. As a notation for our architectural patterns, we use composite structure diagrams of UML 2.0. In the following, we give brief descriptions of the three basics of our work.
2.1 Problem Frames Problem frames are described by frame diagrams, which basically consist of rectangles and links between these, see Figure . The task is to construct a machine that improves the behavior of the environment it is integrated in. Plain rectangles denote application domains (that already exist), a rectangle with a double vertical stripe denotes the machine to be developed, and requirements are denoted with a dashed oval. They are linked together by lines that represent interfaces, also called shared phenomena. Jackson distinguishes causal domains that comply with some laws, lexical domains that are data representations, and biddable domains that are people. Jackson defines five basic problem frames (Required Behaviour, Commanded Behaviour, Information Display, Workpieces and Transformation). An important variant is the Commanded Information frame. In order to use a problem frame, one must instantiate it, i.e., provide instances for its domains, interfaces and requirements.
2.2 Architectural Styles According to Bass, Clements, and Kazman [BCK98], the software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. Architectural styles are patterns for software architectures. A style is characterized by [BCK98]: • a set of component types (e.g., data repository, process, procedure) that perform some function at runtime, • a topological layout of these components indicating their runtime interrelationships, • a set of semantic constraints (for example, a data repository is not allowed to change the values stored in it),
CM!C1 GD!C2
Control machine
CM!C1
C3
Controlled domain C
CD!C2
Required behaviour
Controlled domain
C3 C
Control machine
Commanded behaviour OP!E4
E4
Operator B
Commanded Behaviour
Required Behaviour IN!Y1
E!E1 WP!Y2
Y3
Inputs
IO relation
Command effects
Editor
US!E3
TM!Y2
Y4
Outputs X
Workpieces RW!C1
Real world
Real world
C2 C
C3 C
Information machine
Display ~ Real world IM!E2
E3
User B
Transformation
RW!C1
Y4 X
X Transform machine
Workpieces
Answering machine
AM!E3
Y4
Display
Answer rules
C
Y4
Display
EO!E5
C
Information Display
Enquiry operator
E5 B
Commanded Information Figure 1: Frame diagrams
• a set of connectors (e.g., subroutine call, remote procedure call, data streams, sockets) that mediate communication, coordination, or cooperation among components. Important architectural styles are Data-Centered with substyles Repository and Blackbord, Data Flow with substyles Batch Sequential and Pipe-and-Filter, Virtual Machine with substyles Interpreter and Rule-Based Systems, Call-and-Return with substyles Main Program and Subroutine,Layered, Object-Oriented and Abstract Data Types, and Independent Components with substyles Communicating Processes and Event Systems (implicit/explicit invocation) [SG96]. In the following, we will give an architectural pattern for each of our newly defined security frames in order to facilitate the design. We chose to use UML 2.0 composite structure diagrams (see Section ) to show the layout as done for instance in Figure for the Layered (on the right-hand side) and the Repository (on the left-hand side) architectural styles.
2.3 Composite Structure Diagrams Composite structure diagrams [UML] are a means to describe architectures. They contain named rectangles, called parts. Parts may have ports, denoted by small rectangles. Ports denote interaction points of a part with its environment. A line between two ports is a connector. Ports may have interfaces associated to them. Provided interfaces are denoted using the “lollipop” notation, and required interfaces using the “socket” notation, but these notations will not be used in this paper.
Application Client
Client
Interface Abstraction Layer Client
Data Storage (Repository)
Client
Hardware Abstraction Layer
Figure 2: Repository and Layered architectural styles
3 Security Frames 4 Architectural Patterns for Security Frames 5 Case Study: Electronic Purse Card Cite [RHHH02].
6 Discussion Contributions: • defined new kind of problem frames, taylored for security problems • given corresponding architectural patterns • shown how to decompose a typical security problem into subproblems and how to fit these into problem frames • shown how architectures of subproblems can be recomposed.
References [BCK98]
L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice. Addison-Wesley, 1998.
+
[BMR 96] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, 1996. [CHH04]
Christine Choppy, Denis Hatebur, and Maritta Heisel. Architectural Patterns for Problem Frames. Submitted for publication, 2004.
[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns – Elements of Reusable Object-Oriented Software. Addison Wesley, Reading, 1995. [Jac01]
M. Jackson. Problem Frames. Analyzing and structuring software development problems. AddisonWesley, 2001.
[RHHH02] Thomas Rottke, Denis Hatebur, Maritta Heisel, and Monika Heiner. A Problem-Oriented Approach to Common Criteria Certification. In Stuart Anderson, Sandro Bologna, and Massimo Felici, editors, Proceedings of the 21st International Conference on Computer Safety, Reliability and Security (SAFECOMP), LNCS 2434, pages 334–346. Springer-Verlag, 2002. [SG96]
M. Shaw and D. Garlan. Software Architecture. Perspectives on an Emerging Discipline. Prentice-Hall, 1996.
[UML]
UML Revision Task Force. OMG UML Specification. http://www.uml.org.
