Layers and non-functional patterns Eduardo B. Fernandez Dept. of Computer Science and Eng. Florida Atlantic University Boca Raton, FL 33431
[email protected] Abstract We consider the use of a hierarchically layered architecture for object-oriented systems and we look at the specification of security or other nonfunctional aspects of the system as a set of local level specifications. These specifications are realized using patterns. The enforcement of the constraints defined at a high level is performed through mappings to the lower levels. This approach is the basis for a secure system development methodology. Introduction. Security and other non-functional requirements affect all the architectural levels of a system. The Layers architectural pattern [Bus96] is therefore a good starting point to apply these requirements. Using layers we can define patterns at all levels that together implement a secure or reliable system. The main idea of the Layers pattern is the decomposition of a system into hierarchical layers of abstraction, where the higher levels use the services of the lower levels. We have discussed earlier, why all these levels must be coordinated to assure security [Fer99] and how the definition of non-functional specifications should be done at a specific level [Fer95]. Security is a very important aspect of any computing system, and has become a serious problem since institutions have opened their databases to the Internet. Most web systems in current use have not been designed with security in mind and patches have failed to make them more resistant to attacks. It is important to develop systems where security has been considered at all stages of design and at all architectural levels, which not only satisfy their functional specifications but also satisfy security and other non-functional requirements [Fer00a]. To do this we need to start with high-level models that represent the security policies of the institution. There are three models currently used by most systems: the access matrix, the Role-Based Access Control (RBAC) model, and the multilevel model. We presented patterns for these models in [Fer01]. These models can be used to define security constraints in the application. The conceptual model of the application defines the highest level and authorization constraints should also be defined at this level. The lower levels of the architecture should enforce these constraints using appropriate mechanisms. We start with a discussion of architectural levels, followed by a description of some of the patterns we are considering. We end with a general evaluation of this approach.
1
Architectural levels The structure of a computer system can be decomposed into a hierarchy of layers and various decompositions have been proposed; for example, one of these considers functional and nonfunctional layers [Fer95]. In that view, the definition of non-functional aspects, e.g. security, fault tolerance, is assigned to a specific layer; for example, realtime constraints are defined in a special sublayer of the application layer. Figure 1 shows some of the implementation layers of an object-oriented system. At the highest level we have a metalevel that defines the relevant application classes. This is followed by an application layer that includes the objects active at a given time. The system layer provides an environment for process execution and persistence, and includes operating systems and DBMSs. The distribution layer separates the processes and objects into autonomous nodes. Each node includes one or more CPUs, connected through some type of network utilizing one of several possible protocols. The conceptual enterprise models, both static and dynamic, are defined at the application level. It is here where the security (and other type) policies of the institution should be applied. At this level the semantics of the application are well understood and roles can be used to apply the need-to-know policy; i.e., we can define the needed rights according to the functions of each role [Fer97]. Other non-functional aspects are also specified here, e.g., degree of reliability required. The lower levels enforce the restrictions defined at the higher levels. Each level has its own security mechanism and should participate in enforcing the security constraints. For example, a DBMS enforces the authorizations in the application by restricting access to database items; this restriction is propagated down to control access to the files where this data resides. Authorization patterns We use the access matrix and RBAC as reference models. Multilevel models are also possible but when used at the application level they are too rigid; however, they are useful at lower levels. When we apply the access matrix model, the next step is to define patterns that represent authorization rules or policies, as shown in Figure 2 [Fer93, Fer01]. This model describes an entry of the access matrix, (s, o, t, p, f), where s is a subject, o is a protection object, t an access type, p a predicate constraining the application of the rule, and f a copy flag, indicating if the right can be transferred [Pfl03]. The classes of Figure 2 are abstract classes and specific authorization models are defined by concrete classes. These security patterns can be applied to analysis patterns to define semantic subsystems that combine the advantages of patterns with the advantages of high-level authorization definition. In this case, the user of the pattern would have a structure to define the specific rights his application requires. For example, Figure 3 shows an analysis pattern for an inventory system. The UML stereotype indicates the authorized actors. The auditor is authorized to check for discrepancies in stock, while the stock keeper is authorized to correct or adjust these discrepancies. Similarly, the stock manager can add new stockrooms, etc. The specific rights for each role come from use cases and are derived as in [Fer97]. Each use case has a set of actors who interact with the system. If actors are given rights according to their functions in the use cases of the system, we are implementing a need-to-know policy. Starting from
2
patterns at the application level we need to define patterns for the lower levels. For example, we have developed a pattern to define file access control in operating systems [Fer02]. Since files contain the data needed for the use cases, the security constraints at the application level must be reflected into file access constraints. Building secure systems The constraints defined at the application level are enforced by the lower levels, although the general problem of mapping them down is a work in progress. The combination of multilayer architectures with patterns provides a framework to develop a systematic and reusable approach to building systems that satisfy specific non-functional requirements. Security patterns embody good design principles and by using them, the designer is implicitly applying these principles.
classes
A
B
Metalayer
C
a:A
b:B
Application layer
c:C
a.m1
executing processes
b.m2
Node1
CPU1
System layer (OS/DBMS)
c.m3
Node2
CPU2
Distribution layer
CPU3
} Protocol
Hardware Configuration
Figure 1. The layers of a computer system The actual implementation of these patterns depends on the architectural level where they are applied. For example, the Authorization pattern can be implemented using Access Control Lists (ACLs), as is done in most operating systems. Another implementation
3
approach is the use of capabilities, as it has been done at the hardware and operating system level to control resources. The use of metaclasses and reflection is another interesting way to implement these models [Anc99, Fer98]. Requests for resources must be intercepted and validated with the information in the ACLs or capabilities; this requires a special program (another pattern) known as the Reference Monitor [Fer02]. This means that there is a variety of patterns that implement a high-level model such as the access matrix. Subject
*
Authorization_rule
id
*
ProtectionObject id
Right access_type predicate copy_flag checkRights
Figure 2. A pattern for authorization rules. Patterns for some of the architectural levels have appeared: • Yoder and Barcalow [Yod97] describe the Single Access Point (a general secure system design pattern), Check Point (a kind of Reference Monitor), a basic form of roles, and others. • Cryptographic patterns are described in [Bra00]. • A general discussion of security patterns including some network security patterns is presented in [Sch01]. • A framework for access control and filtering of distributed objects, combining several patterns, is described in [Hay00]. • Several security patterns for Java appear in [Jaw00]. • Patterns for security models are given in [Fer01]. • Some patterns for operating system access control are discussed in [Fer02]. Includes patterns for file access, the Reference Monitor, and Virtual Address Space control. Work is needed to add more patterns in each level and to collect and unify these patterns. We are working now in a catalog of security patterns [Sch03]. No systematic work for fault tolerance or other non-functional patterns has been done, although several patterns of this type have appeared [Sar02].
4
Another approach to include non-functional aspects in patterns to build systems uses composition of non-functional aspects [Ara02]. We think that the composition of patterns should be done at several levels; i.e., it is not just a composition but also a hierarchical mapping. Both approaches could be combined to produce a better design methodology. There are also more encompassing layered approaches that include not just the levels of the software system but the whole enterprise [Hea02]. Their objectives are about planning and enterprise security evaluation. Our approach could be used to refine some of their levels.
StockRoom
*
1
StockManager
add_StockRoom *
Right add_ StockRoom
* Inventory transferStock checkDiscrepancy adjDiscrepancy 1
*
*
InventoryManager
Right transferStock
*
Stock
Item
*
addItem 1
Right addItem
1
*
Procurement
Right adjDiscrepancy
Auditor
Right checkDiscrepancy
1
StockKeeper
Figure 3. An authorized inventory pattern References [Anc99] M. Ancona, W. Cazzola, and E.B. Fernandez, "Reflective authorization systems: Possibilities, benefits, and drawbacks", in Secure Internet Programming, J. Vitek and C.D. Jensen (eds.), LNCS State of the Art Survey, LNCS 1603, Springer, 1999, 35-49.
5
[Ara02] I. Araujo and Weiss, “Linking patterns and non-functional requirements”, Procs. of PLoP 2002, http://jerry.cs.uiuc.edu/~plop/plop2002/proceedings.html [Bra00] A. Braga, C. Rubira, and R. Dahab, “Tropyc: A pattern language for cryptographic object-oriented software”, Chapter 16 in Pattern Languages of Program Design 4 (N. Harrison, B. Foote, and H. Rohnert, Eds.). Also in Procs. of PLoP’98, http://jerry.cs.uiuc.edu/~plop/plop98/final_submissions/ [Bus96] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland, and M. Stal., Patternoriented software architecture, Wiley 1996. [Fer93] E.B.Fernandez,M.M.Larrondo-Petrie and E.Gudes, "A method-based authorization model for object-oriented databases", Proc. of the OOPSLA 1993 Workshop on Security in Object-oriented Systems , 70-79. [Fer95 ] E. B. Fernandez and R. B. France, ``Formal specification of real-time dependable systems ", Proc. of First IEEE Int. Conf. on Eng. of Complex Comp. Systems, Fort Lauderdale, FL, November 6-10, 1995, 342-348. [Fer97] E.B.Fernandez and J.C.Hawkins, “Determining role rights from use cases”, Procs. 2nd ACM Workshop on Role-Based Access Control, November 1997, 121-125. http://www.cse.fau.edu/~ed/RBAC.pdf [Fer98] L.L.Ferreira, and C.M.F.Rubira, "The reflective state pattern", Procs. PLoP99, http://jerry.cs.uiuc.edu/~plop/plop98/final-submissions [Fer99] E.B.Fernandez, "Coordination of security levels for Internet architectures", Procs. 10th Intl. Workshop on Database and Expert Systems Applications, 1999, 837841. http://www.cse.fau.edu/~ed/Coordinationsecurity4.pdf [Fer01] E B. Fernandez and R.Y. Pan, “A pattern language for security models”, Procs. of PLoP 2001, http://jerry.cs.uiuc.edu/~plop/plop2001/accepted_submissions/acceptedpapers.html [Fer02] E.B.Fernandez, "Patterns for operating systems access control", Procs. of PLoP 2002, http://jerry.cs.uiuc.edu/~plop/plop2002/proceedings.html [Hay00] V. Hays, M. Loutrel, and E.B.Fernandez, “The Object Filter and Access Control framework”, Procs. Pattern Languages of Programs (PLoP2000) Conference, http://jerry.cs.uiuc.edu/~plop/plop2k [Hea02] J. Heaney et al., “Information assurance for enterprise engineering”, Procs. of PLoP
2002, http://jerry.cs.uiuc.edu/~plop/plop2002/proceedings.html [Jaw00] J. Jaworski and P.J. Perrone, Java security handbook, SAMS, Indianapolis, IN, 2000.
6
[Pfl03] C.P.Pfleeger, Security in computing, 3rd. Ed., Prentice-Hall, 2003. [Sar02] T. Saridakis, “A system of patterns for fault tolerance”, Procs. of EuroPLoP 2002, [Sch01] M. Schumacher and U. Roedig, “Security engineering with patterns’, Procs. of PLoP 2001. [Sch03] M. Schumacher, E.B.Fernandez, D. Hybertson, and F. Buschmann, Security Patterns, to be published by J. Wiley & Sons, 2003. [Yod97] J. Yoder and J. Barcalow, "Architectural patterns for enabling application security". Procs. PLOP’97, http://jerry.cs.uiuc.edu/~plop/plop97 Also Chapter 15 in Pattern Languages of Program Design, vol. 4 (N. Harrison, B. Foote, and H. Rohnert, Eds.), Addison-Wesley, 2000.
7
