MAC and UML for Secure Software Design - Semantic Scholar

Download PDF
7 downloads 44742 Views 354KB Size Report
Comment
secure software design, our MAC enhancements for UML have been integrated into ... [5, 14, 23] and others into a standard, so that the best features of the constituent .... (business processes) in the system, with a generalization relationship ...
MAC and UML for Secure Software Design Thuong Doan

Steven Demurjian

T.C. Ting

Andreas Ketterl

University of Connecticut 271 Fairfield Road, U-2155 Storrs, CT 06269, USA 1-860-486-3719

University of Connecticut University of Connecticut University of Connecticut 271 Fairfield Road, U-2155 271 Fairfield Road, U-2155 271 Fairfield Road, U-2155 Storrs, CT 06269, USA Storrs, CT 06269, USA Storrs, CT 06269, USA 1-860-486-3719 1-860-486-3719 1-860-486-3719

[email protected]

[email protected]

ABSTRACT Security must be a first class citizen in the design of large scale, interacting, software applications, at early and all stages of the lifecycle, for accurate and precise policy definition, authorization, authentication, enforcement, and assurance. One of the dominant players in software design is the unified modeling language, UML, a language for specifying, visualizing, constructing and documenting software artifacts. In UML, diagrams provide alternate perspectives for different stakeholders, e.g.: use case diagrams for the interaction of users with system components, class diagrams for the static classes and relationships among them, and sequence diagrams for the dynamic behavior of instances of the class diagram. However, UML's support for the definition of security requirements for these diagrams and their constituent elements (e.g., actors, systems, use cases, classes, instances, include/extend/generalize relationships, methods, data, etc.) is lacking. In this paper, we address this issue by incorporating mandatory access control (MAC) into use case, class, and sequence diagrams, providing support for the definition of clearances and classifications for relevant UML elements. In addition, we provide a framework for security assurance as users are defining and evolving use case, class, and sequence diagrams, bridging the gap between software engineers and an organization's security personnel in support of secure software design. To demonstrate the feasibility and utility of our work on secure software design, our MAC enhancements for UML have been integrated into Borland's Together Control Center Environment.

Categories and Subject Descriptors D.2.2 [Software Engineering]: Design Tools and Techniques – Object-oriented design methods. K.6.5 [Management of Computing and Information Systems]: Security and Protection – Unauthorized access.

General Terms: Design, Security. Keywords Security, Mandatory Access Control, UML, Software Design.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. FMSE’04, October 29, 2004, Washington, DC, USA. Copyright 2004 ACM 1-58113-971-3/04/0010...$5.00.

[email protected]

[email protected]

1. INTRODUCTION The ability to design, build, and maintain functionally rich, large scale, interacting, software applications seems limitless, especially given increases in computing power, memory, and disk storage (at a reasonable cost), and the advancement of software design and development environments tools. The integral nature of the WWW in daily life and the increasing concern of homeland defense have caused security to be elevated to a critical position. However, the inclusion of security in software design and development has often been an afterthought, delayed to latter stages or delegated to database administration. The scope includes: security policy definition for what needs to be protected, the anticipated users, user privileges, etc.; authorization to grant/revoke privileges to users based on the policy; authentication to verify the users and limit their actions to authorized privileges; and, security assurance to attain the security policy within the enforcement framework for an active application. These minimal security considerations strongly argue for security as a first class citizen in the software design and development process at early and all stages of the lifecycle. To address security during software design/development, this paper details our research on incorporating mandatory access control (MAC) into the unified modeling language, UML [6], a language for specifying, visualizing, constructing and documenting software artifacts. UML unified the approaches of [5, 14, 23] and others into a standard, so that the best features of the constituent models were included. In UML, diagrams provide alternate perspectives and complementary representations of the system for different stakeholders (e.g., users, designers, software engineers, etc.). UML has nine different types of diagrams to model an application's behavior, interactions, and implementation, and while there are parallels between security and UML elements, direct support for security specification in UML [18] is not provided. There have been other efforts on security and UML: [11, 24] used UML as a language to represent RBAC modeling and notation; [15, 16] on theoretical security definition with UML; [17] introduced SecureUML for model-driven security with extended meta-model elements for RBAC only; [22] used UML elements to model MAC and RBAC based systems; and, [1, 2] presented a framework to incorporate security into use cases only. However, we believe that our approach breaks new ground by the integration of MAC into use case, class, and sequence diagrams, and by providing design-time. security assurance Specifically, in this paper, we report on our research on the incorporation of MAC into UML use case, class, and sequence diagrams, for the definition of clearances and classifications for relevant UML elements, which augments our efforts on including role-based access control into UML [9]. We initially focus on

three popular UML diagrams: use case diagrams for the interaction of users with system components, class diagrams for the static classes and relationships among them, and sequence diagrams for the dynamic behavior of instances of the class diagram. For these diagrams, we provide a framework for defining MAC security levels (classifications and clearances) as properties of the various elements (e.g., use cases, actors, methods, classes, etc.) with the objective of bridging the gap between software engineers and an organization's security personnel in support of secure software design. The work presented herein also proposes security assurance rules, SARs, which enforce, as users are defining and evolving use case, class, and sequence diagrams, the attainment of security-level domination, and MAC Simple Security (“read down - no read up”), Simple Integrity (“write down – no write up”), Liberal * (“write up - no write down”), and Strict * (“write equal”) Properties. These SARs are realized as dynamic checks that analyze, as a design is created, the consistency of the security definition in the context of an application's content and dependencies. To demonstrate the feasibility and utility of our work on secure software design, our MAC enhancements for UML have been integrated into Borland's Together Control Center Tool. In the remainder of this paper: Section 2 details background information on MAC, and relevant UML concepts with an example to be used in the paper; Section 3 examines the relationship of software and security design by introducing principles that impact the process; Section 4 explores our research on incorporating MAC into UML with accompanying security assurance rules that can be algorithmically verified in real-time (as a software engineer is designing) or at regular design intervals; Section 5 explores our prototyping effort on integrating MAC into the UML tool Together Control Center; Section 6 briefly reviews related research and its relevance to our work; and, Section 7 concludes this paper and outlines ongoing research.

2. BACKGROUND CONCEPTS In this section, we review background concepts on mandatory access control (MAC) model [3], relevant UML diagrams (use case, class, and sequence) and elements, two versions of inheritance that UML supports, and our example to be used throughout the remainder of the paper. To begin, in the MAC model, security levels (typically unclassified (U), confidential (C), secret (S), and top secret (T) forming a partial order U < C < S < T) are assigned to each subject (clearance - CLR) and each object (classification - CLS). The permission of the subject to perform some operation on the object depends on the relation between clearance and classification as dictated by: Simple Security Property (“read down - no read up”) [3]: a subject can read an object only if its clearance is greater than or equal to the classification of that object; Strict *-Property (“write equal”) [19]: a subject can write an object only if its clearance is equal to the classification of that object; Liberal *-Property (“write up – no write down”) [3, 19]: a subject can write an object only if its clearance is less than or equal to the classification of that object; Simple Integrity Property (“write down – no write up”) [4]: a subject can write an object only if its clearance is greater than or equal to the classification of that object.

For the enhancement of UML with MAC, we concentrate on use case, class, and sequence diagrams. A use case diagram is a collection of use cases and actors. A use case represents an encapsulation of behavior for a specific portion of an application. Use cases can be related by: generalization - a child use case A inherits behaviors and meaning of a parent use case B for specialization or limitation; inclusion - from a base use case C to an included use case D specifies that C contains the behaviors defined in D; and extension - from an extending use case E to a base use case F specifies that F may be augmented with (incorporates under certain condition) some behaviors defined in E. An actor is an external entity that interacts with software (use cases) at some level, to represent the simulation of possible events (business processes) in the system, with a generalization relationship from a child actor A to a parent actor B indicating that A inherits properties from B for specialization or limitation, and an association relationship utilized when it is involved in a use case. A class diagram, composed of classes, is for the static structure of the conceptual model. A class is an abstraction for a set of objects that have the same attributes and operations of their behaviors. In implementation, an operation of the class is called method. A sequence diagram in UML is intended to capture and represent the dynamic behavior of instances (objects) of the class diagram. For a given task (often a use case), a sequence diagram indicates the object interactions over time to accomplish the task. The purpose of a sequence diagram is to model flow of control, and in doing so, to illustrate a typical scenario or processing, thereby providing perspective on usage and flow across the various objects that comprise an application. There are two types of inheritance in UML. In specialization inheritance, the child inherits the parent with properties that may be extended, e.g., the parent “physician” has children “consultant physician” and “surgery physician” with more extended properties. In limitation inheritance, the child has more restricted behavior than the parent, e.g., a double ended queue can be restricted to stack and queue, which can then be restricted to LIFO and FIFO ([7]). To illustrate UML and our proposed security extensions, we provide a simple example that will be used throughout the paper. “Survey Management” Example: A Survey Institution performs and manages public surveys. After the raw data of the survey is collected, the senior staff person will add a survey header into the database. Then another staff person (senior or junior staff) will add questions into that survey, and also have the ability to categorize questions and add a new question category if needed. However, there are some special questions that have more sensitive content, with only senior staff allowed to perform data entry. Figure 1 depicts a use case diagram for creating a new survey entry in the “Survey Management” example. The actor Staff has two children Junior Staff and Senior Staff inherited for specialization with additional extended properties. Generally, the Staff actor can perform the use case Add Question which includes the use case Categorize Question, and can be extended to the use case Add Question Category if a new category must be added to the database. But, only the Senior Staff actor can perform the use case Add Survey Header to include a new survey header entry and the use case Add Special Question to include special sensitive questions in a survey. Figure 2 illustrates the sequence diagram for the use case Add Survey Header with only the main flow of events shown. To create a new survey header “Internet Usage”, the senior staff person enters data and then enables the submit

button in the Survey_Header_Add_Page, which will search for the survey title in the Survey_Repository object (of class Survey_List) and then send new header data to Survey_Repository via the Add_Survey_Header message. The Survey_Repository object, in turn, creates a new survey header object Internet_Usage of class Survey_Header, and then updates itself as a new item in the list of survey.♦

In UML, the use case diagrams (with use cases and actors) are usually designed first after an analysis of a customer’s requirements to describe the behaviors of the application. Next, the classes (at a high level with only attributes/method signatures) are specified by identifying application objects and their relationships as required by the customer. The addition of classes requires the designer to return to the use cases diagrams and associate which classes are needed by which use cases, and may result in the design of new classes between actors and use cases. As the design matures, use cases and associated classes are combined into sequence diagrams with the messages (methods without code) between objects specified. As the design process progresses, other UML diagrams (e.g., collaboration, object, state, activity, etc.) may be supplied (note these are not considered for this paper). To achieve the first principle, we must integrate MAC into the process of designing/revising UML elements/diagrams. In the process, we augment the UML/software design process by providing security assurance rules (SARs) for these new security capabilities, which can be enforced during all phases of design. The second principle addresses the question of how to assess security that is attained in the design.

Figure 1. Use case Diagram for New Survey Entry.

Principle 2: Security assurance is relative to the phase of software design and the chosen SARs. This principle stipulates that the security assurance be evaluated against the respective software design phase (e.g., use case, class, or sequence diagrams) to constantly enforce the SARs against the evolving design. As a design changes context from one diagram to the next in UML, different SARs are utilized to enforce the security features for that phase of design. The SARs at each level may be stricter or more tolerant depending on the security policy that is available in the secure software design environment, e.g., in the closed meta-policy one cannot do anything except the allowed actions, in the open meta-policy one can do anything except the prohibited actions, and in the least privilege principle, one should be granted the permissions needed for his required jobs and no more. The granularity level of SAR checks will be dependent on the level of detail in the software design phase.

Figure 2. Sequence diagram for “Add Survey Header”.

3. SECURE SOFTWARE DESIGN The integration of security into the software design process cannot occur in a vacuum, but must be an indistinguishable part of the process, and is impacted by both software design concepts and security methods. In this section, we propose an approach to incorporate security into object-oriented (OO) software design. In Section 3.1, we propose three software/security design principles intended to associate software and security design concepts. In Section 3.2, we discuss our proposed security access control model for MAC and its application to the OO paradigm.

3.1 Software/Security Design Principles The first principle addresses the question of how to integrate security and software design. Principle 1: The software design has multiple iterative phases and the security features should be incorporated and adjusted during each of and among those phases.

The third principle addresses the question of the impact of security design on software design. Principle 3: The security incorporating process should neither counter the intuition nor decrease the productivity of the software designer. This principle is often overlooked when security is discussed and implemented in practice. The MAC model concerns the flow of information among subjects and “objects” via some “operations” (quoted for a MAC context), where an “object” is an information atom and an “operation” is an atomic action. This contrasts with the OO paradigm where object means an instance of a class containing a set of attributes (with possibly different security sensitive levels) and operation indicates a custom-definable action for a specific behavior of the class. Further, each OO attribute of an instance may refer to other attributes or instances of other classes, and each operation may perform atomic actions or call other operations (on itself or other objects). OO software designers emphasize encapsulation “who can use which methods (as the implementation of operations) of classes” as their security concern, not “who can read or write certain attributes”. Typically, only public methods of the class are accessible to outside entities which indirectly access private attributes (a good practice of class

design). Moreover, during initial UML design for class and sequence diagrams, the concern is with the intention of the operations (i.e., the behaviors of the class) as captured via a method's signature (i.e., there is no code). Thus, in UML, the security consideration is: “who can exercise which behaviors of the application (use cases) and class behaviors (methods),” which can be answered by drawing connections in UML diagrams (e.g., actor to use case in use case diagrams, or message passing in sequence diagrams). If we can incorporate security via SARs in these connections, it will naturally provide security checks during the normal activity of designers. To summarize, to adhere to Principle 3, we must reinterpret MAC principles so that they can be more aptly applied to UML.

3.2 Applying the MAC Model to OO Design In MAC, the access control is based on the relationship (s, op, o) which indicates that the subject s can perform the “operation” op (e.g., read, write, append, execute, etc.) on the “object” o (a piece of atomic information with only one assigned security classification). While this approach is appropriate for relational database content, there are a number of reasons why this triple (s, op, o) is inappropriate for OO design. First, an OO object is an instance with many attributes, which may be simple or reference another object, each with possibly different security classification levels, and as such, this does not correlate to the single object o in the MAC triple. Second, the MAC operation op typically represents a set of standard operations (e.g., read, write, etc.) on the object o, while the methods (operations) of an OO class (instance) contain complex sets of operations of all types that are not easily applied to MAC standard operations. Third, the underlying basis of any OO design/application is the set of public methods that represent its behavior. These methods may be custom, part of standard libraries (e.g., string or math operations), or conceptualized in abstract classes. Simplifying this methodbased approach in order to map it to the MAC triple would likely be an impossible task. As an alternative to literally applying the triple (s, op, o) of the MAC model to the OO paradigm, we propose using the constraint (ei, ej.behaviorjk) which specifies whether element ei can employ some behavior behaviorjk of element ej. Our approach is distinguished from others (e.g. [20, 25]) by conceptualizing (s, op, o) in a manner that is more consistent with the precepts and principles of the OO paradigm. For example, use case Add_Survey_Header represents one behavior of the “Survey Management” application (Figure 1). During use case design, it is possible to perceive whether actor Senior_Staff can invoke this behavior depending on a security constraint defined on (Senior_Staff, Add_Survey_Header) which can be verified via a specific SAR. Later, when the sequence diagram is being defined, the OO designer can explore security questions such as “can Senior_Staff employ the Survey_Title_Search behavior of the class Survey_List by invoking the behavior On_Submit of the class Survey_Header_Add_Page.”

4. SECURITY ASSURANCE FOR UML In this section, we propose security assurance rules, SARs, to enforce MAC for UML. The SARs are assertions based on the domination of security levels (clearance dominates clearance or clearance dominates classification) of UML modeling elements, with the direction of the domination influenced by the

connections (relationships) between the different elements. As given in Section 2, each relationship (i.e., generalize, include, extend, actor-use case connections, message passing, etc.) dictates the direction of domination of security levels. As a designer is defining and modifying UML diagrams, the SARs are constantly enabled so that any new connections between existing elements always satisfy domination. When security violations are detected, the designer must adjust the design. To organize the SARs, we define three different security/software design tiers for the UML: Tier 1 in Section 4.1 focuses on the use case diagram; Tier 2 in Section 4.2 emphasizes the associations between the classes that are utilized by each use case; and, Tier 3 in Section 4.3 represents the creation of a UML sequence diagram with actor/method and method/method interactions. In the tiers, we focus on constraints such as (ei, ej.behaviorjk) which specifies whether element ei can employ some behavior behaviorjk of element ej (see Section 3.2 again). Lastly, in Section 4.4, we unify the SARs into two algorithms for security assurance that traverses the connections between elements across use case, class, and sequence diagrams. To serve as a formal basis for the SARs, we introduce notation. First, we only consider basic UML element sets: use case set UC = {uc1, uc2, ...}, actor set AC = {ac1, ac2, ...}, class set Cl = {c1, c2, ...}, and method set M = {m1, m2, ...}. Each UML element is assigned a clearance (CLR) or classification (CLS) from the partially ordered set Σ = {⊥=σ1, σ2, …, σS} where the order relation σi < σj (i < j) means the security level σj has a higher security concern than that of σi. Conventionally, we denote sli ≤ slj (less than or equal) for sli < slj ∨ sli = slj and slj ≥ sli (also called the “dominate” relation) for sli ≤ slj. In examples, we use Σ = {U, C, S, TS} with ⊥ = U < C < S < TS. We denote ac.CLR, uc.CLS, c.CLSmin, c.CLSmax and m.CLS as the CLR of actor ac, the CLS of use case uc, the min and max CLS of class c, and the CLS of method m, respectively. The value of ac.CLR is chosen by the designer based on the security policy to reflect the CLR of the user that needs to employ some behaviors of the application (i.e., some use cases connected to actor ac) when taking the role of actor ac. uc.CLS indicates the degree of security sensitivity of the behavior of the application represented by use case uc. The values of c.CLSmin, and c.CLSmax describe the range of the security sensitivities for class c. And finally, m.CLS specifies the security sensitivity of the behavior of a class implemented in method m.

4.1 Tier 1 MAC Security Assurance Rules This section considers the SARs for the creation of use case diagrams with actors, use cases, actor-use case associations, actor and use case inheritance, and use case inclusion and extension relationships, which represents Tier 1. Actor-use case associations are a critical link between actors and the use cases that they employ. For every actor acm that is associated with the use case uci (as a behavior of the application), the CLR of the actor acm must dominate the CLS of the use case uci: SAR AUC (Actor with Use case): ∀actor acm and use case uci, acm is securely (MAC) associated with uci ⇔ acm.CLR ≥ uci.CLS. Example: In “Create New Survey” (Figure 1), the actor Staff is securely associated with use case Add Question. Since Staff.CLR = C ≥ Add_Question.CLS = C, actor Staff can (securely) perform use case Add Question. However, actor

Staff cannot perform Add Survey Header and Add Special Question since Staff.CLR = C < Add_Survey_Header.CLS = Add_Special_Question.CLS = S. Only actor Senior Staff can perform Add Survey Header and Add Special Question, i.e., its CLR equals the CLS of the use cases (S).♦ The SAR AUC is very important to verify domination among actors, methods, and use cases (see Section 4.3 – Tier 3), and for the algorithms in Section 4.4 for use case and sequence diagrams. The next SAR is used whenever two actors are connected with one another via inheritance with the intent to alert the software engineer when CLRs are in conflict. As stated in [18, p.2-136] (“An instance of a child can always be used where an instance of the parent is expected”), the actor inheritance relationship is defined via the substitution principle. Hence, we focus only on actor inheritance for specialization (satisfying the substitution principle). Namely, for two actors acm and acn connected by an inheritance for specialization (the arrow from acn to acm), the CLR of the child actor acn must dominate the CLR the parent actor acm: SAR AIS (Actor Inheritance for Specialization): ∀ actors acm and acn, acn securely (MAC) inherits acm (the generalization arrow from acn to acm) ⇔ acn.CLR ≥ acm.CLR. Example: Actor Senior Staff securely inherits actor Staff in the use case diagram “Create New Survey” (Figure 1) as Senior_Staff.CLR ≥ Staff.CLR.♦ In MAC, a user can open a working session with the option of choosing any CLR (currently active CLR) which is less than or equal to his maximum assigned CLR. When the user takes the role of the child actor acn, by inheritance, the role of the parent actor acm is acquired, which we suppose is directly associated with uci. If there is no direct association from acn (child) to uci, then to employ uci, the user should be viewed from uci as having the CLR of acm.CLR (parent) instead of acn.CLS (child). Thus, if the SAR AUC holds for (acm, uci), then the SAR AIS for (acm, acn) guarantees the user with the role of the child acn can employ uci from the parent via an implicit (indirect) association. The next three SARs, UCIS, UCI, and UCE, are used whenever two use cases are connected with one another using inheritance, , or relationships, respectively. From [18, p.2-138], the inheritance type of use cases is for specialization (containing all of the common behaviors of the parent use case and some other ones). For two use cases uci and ucj connected by an inheritance for specialization (the generalization arrow from ucj to uci), the CLS of the child use case ucj must dominate the CLS of the parent use case uci. SAR UCIS (Use Case Inheritance for Specialization): ∀ use cases uci and ucj, ucj securely (MAC) inherits uci (the generalization arrow from ucj to uci) ⇔ ucj.CLS ≥ uci.CLS. Example: In “Create New Survey” (Figure 1), the use case Add Special Question is securely connected to use case Add Question by specialization as Add_Special_Question.CLS = S ≥ Add_Question.CLS = C.♦ For two use cases uci and ucj connected by an , the CLS of uci on the origin of the include arrow must dominate the CLS of ucj on the destination of the include arrow:

SAR UCI (Use Case Inclusion): ∀ use cases uci and ucj, uci securely (MAC) includes ucj ⇔ uci.CLS ≥ ucj.CLS. Example: In “Create New Survey” (Figure 1), the use case Add Question securely includes use case Categorize Question as Add_Question.CLS = C ≥ Categorize_Question.CLS = C.♦ For two use cases uci and ucj connected by an , the CLS of the extending ucj on the origin of the extend arrow must be less than or equal to the CLS of the base uci on the destination of the extend arrow: SAR UCE (Use Case Extension): ∀ uci and ucj, ucj securely (MAC) extends uci ⇔ uci.CLS ≥ ucj.CLS. Example: In “Create New Survey” (Figure 1), the use case Add Question Category securely extends use case Categorize Question as Categorize_Question.CLS = C ≥ Add_Question_Category.CLS = C.♦ As software designers are defining use cases and establishing dependencies (inheritance, inclusion, and extension) among them, the SARs UCIS, UCI, and UCE insure that the assigned CLSs of the use cases remain consistent with respect to domination in the appropriate direction of the relationship.

4.2 Tier 2 MAC Security Assurance Rules In Tier 2 of the software/security design process, the emphasis is on defining the classes that are utilized by each use case. We have added this step to the software/security design process, as a prelude to the message passing dependencies that are defined in sequence diagrams. The UML does not support an explicit diagram type to associate use cases with the classes that will be utilized to realize them; rather, it is accomplished implicitly when the designer chooses the classes (objects) that are involved in the sequence diagram in order to describe the activities of the related use cases. In Tier 2, for a class c (intended) to be used in a sequence diagram to serve the goal (i.e., realize the functionality) of use case uc, the CLS of the uc must dominate the minimum CLS of c. SAR UCC (Use Case-Class): ∀ use cases uc and c, uc securely (MAC) uses c ⇒ uc.CLS ≥ c.CLSmin. Note that Tier 2 represents the initial creation stage of the sequence diagram when the use cases and associated classes/objects are chosen, and does not include the method dependencies. Note also that in order to explicitly support the associations of classes with use cases for Tier 2, we are planning on adding this capability as a property for secure software design in UML into our prototype environment (see Section 5). The objective would be to provide the means to perform the SAR UCC checks at an even earlier stage than the sequence diagram creation.

4.3 Tier 3 MAC Security Assurance Rules Tier 3 is a refinement of Tier 2 to support method calls between the different entities (use case and objects) in a sequence diagram. To present the SARs for Tier 3, it is necessary to provide additional notation. A method m defined in a class c (denoted c.m) is the implementation of an operation to describe a set of activities for a specific behavior of the class c. Let c.M be the set of all of

the methods defined in c. In support of OO design, we assume that all of the attributes of a class are private by default (secure), attributes can only be modified by public or private methods they cannot be modified directly (without a method call). Further, we adopt from [26] that there are two types of disjoint methods in a class: mutators that alter the state of an instance and observers that report on the state of an instance. This leads to: (1). c.MW = {c.m | c.m modifies attribute(s) of an object of class c} (mutators) and (2). c.M¬W = c.M \ c.MW as the set of methods that do not modify attribute(s) of an object of class c (observers). An element of c.MW (c.M¬W, respectively) is called a mutable (immutable) method or MuM (IMuM) for short. Using these method sets, we can define SARs in a sequence diagram for the actor ac directly calling method cj.my and method ci.mx directly calling method cj.my (message passing). Note that the classes ci and cj may be the same but mx must be different from my, at this time, we do not support recursion in sequence diagrams for security assurance. The relevant SARs to enforce actor/method and method/method interactions are: SAR AM (Actor Calling Method): ∀ actor ac and method cj.my, ac securely (MAC) uses cj.my ⇔ (1).

If cj.my ∈ cj.M¬W: ac.CLR ≥ cj.my.CLS.

(2).

If cj.my ∈ cj.MW:

2a.

ac.CLR = cj.my.CLS for the Strict *-Property

2b.

ac.CLR ≤ cj.my.CLS for the Liberal *-Property

2c.

ac.CLR ≥ cj.my.CLS for the Simple Integrity Property.

SAR MM (Method Calling Method): ∀ methods ci.mx and cj.my, ci.mx securely (MAC) calls cj.my ⇔ (1).

If cj.my ∈ cj.M¬W: ci.mx.CLS ≥ cj.my.CLS.

(2).

If cj.my ∈ cj.MW:

2a.

ci.mx.CLS = cj.my.CLS for the Strict *-Property

2b.

ci.mx.CLS ≤ cj.my.CLS for the Liberal *-Property

2c.

ci.mx.CLS ≥ cj.my.CLS for the Simple Integrity Property.

The MuM cj.my may be used by actor ac indirectly via the calling of other methods. For the Simple Integrity Property, due to the transitivity of the ≥ relation, no matter the type of method cj.my (MuM or IMuM), we always have ac.CLR ≥ cj.my.CLS. However, we have to check explicitly whether ac.CLR = cj.my.CLS (for Strict *-Property) or ac.CLR ≤ cj.my.CLS (for Liberal *-Property) if the MuM cj.my is used by actor ac indirectly via the calling of at least an IMuM ci.mx.CLR. Similarly for the case of an IMuM cj.my, we also need to check explicitly whether ac.CLR = cj.my.CLS (for Strict *-Property) or ac.CLR ≥ cj.my.CLS (for Liberal *-Property) if the IMuM cj.my is used by actor ac indirectly via the calling of at least a MuM ci.mx.CLR. While SARs AM and MM contain both the Simple Integrity Property and Liberal *-Property, since they are opposites of one another, one must be chosen by the security administrator based on the customer’s security policy requirement. Simple Integrity prevents “blind write” (i.e., modify an object without seeing it allowed by the Liberal *-Property), but may allow information leakage (i.e., transfer of information from a higher to a lower security level - prohibited by the Liberal *-Property). In our approach, we can mitigate both “information leakage” (for Simple

Integrity Property) and “blind write” (for Liberal *-Property) for use cases to a limited extent by using the CLS of the use case as the lower bound threshold for the CLS of MuMs utilized by that use case. Particularly, for any MuM c.m ∈ c.MW that is utilized in a sequence diagram Dseq describing actions of use case uc, the CLS of c.m must dominate the CLS of uc. This leads to the SAR: SAR UCM (Use Case-Method): ∀ use case uc and sequence diagram Dseq, uc is securely (MAC) described by methods in Dseq ⇔ uc.CLS ≤ min(ci1.mx1.CLS,…, cik.mxk.CLS) where ci1.mx1,…, cik.mxk are MuMs used in Dseq to describe actions of uc. If the Simple Integrity Property is active, uc.CLS can be viewed as the lower bound of the sensitivity level that allows the information to flow downward. If in use case uc, the designer uses some MuM with the CLS less than uc.CLS, the SAR UCM will report that information is leaking beyond the acceptable range. Note that the SAR UM does not affect the SARs AM and MM, thus maintaining the “blind write” prohibition. To prohibit information leakage downward, all MuMs with CLS equal to uc.CLS (and greater than or equal to CLS of IMuMs) must be chosen for that use case (Strict *-Property usage locally in uc). Conversely, if the Liberal *-Property is active, the value of min(ci1.mx1.CLS,…, cik.mxk.CLS) can be a hint for adjusting the value of uc.CLS downward to a sensitivity level that allows limited “blind write” for an actor. The higher the value of uc.CLS is raised to restrict the gap between uc.CLS and min(ci1.mx1.CLS,…, cik.mxk.CLS) in SAR UCM, the more responsibility and knowledge are needed by the users (as reflected in CLRs of their actors) in order to play the actor roles associated with use case uc (to satisfy the SAR AUC: acn.CLR ≥ uc.CLS). For good security practice, actors with low CLR must be prohibited from performing “blind write”. For example, if min(ci1.mx1.CLS,…, cik.mxk.CLS) = TS, the value of uc.CLS should be TS or S rather than C (too dangerous) or U (very dangerous). On the other hand, if SAR UCM does not hold (uc.CLS is set too high and greater than min(ci1.mx1.CLS,…, cik.mxk.CLS)), but SAR AUC holds for some actor acn associated with uc (acn.CLR ≥ uc.CLS > min(ci1.mx1.CLS,…, cik.mxk.CLS)), then acn.CLR may not satisfy SAR AM.2b for some cij.mxj.CLS (1≤ j ≤ k), which violates “no write down” of the Liberal *-Property. In such cases, the designer must decrease the value of uc.CLS to satisfy both SAR UCM and SAR AM.2b. Finally, we need a rule that estimates the range of CLS of the class based on its defining methods. SAR CM (Class with its Methods): - CMa: c.CLSmin ≤ min{c.mx.CLS | method mx defined in class c} - CMb: c.CLSmax ≥ max{c.mx.CLS | method mx defined in class c} The class c must have at least one IMuM c.mk to report the status of class instances (otherwise it is a useless “black hole” object). Under the guideline of the least privilege principle, the value of c.mk.CLS should be as low as possible according to the attributes that the method reveals as a result of the invocation. For example, if the attributes of a class used by a method are evaluated only at the C level, it is not reasonable to assign c.mk.CLS as S or TS, as this would require actors with unnecessarily high CLR (S or TS) to obtain information at the C level via the method call. Hence, the SAR CMa provides a hint for the c.CLSmin.

By combining SAR CM with the SAR UCC in Tier 2 (see Section 4.2), the designer can verify classes and the associated class methods that are utilized for a use case. Consider a situation where classes are being defined at the conceptual level, and for some class c, c.CLSmin is estimated at a low value. Later in the process, after defining methods (with CLSs) of c for use case ucm in Tier 3, if the designer finds that c.CLSmin is too low (i.e., all methods in c are more sensitive than expected), the c.CLSmin can be raised as high as needed as long as the SAR CMa still holds. Then, when a sequence diagram for another use case ucn is defined, by using SAR UCC, the designer has a better indication of whether the class c is appropriate for use case ucn. If ucn needs only low sensitivity actions (methods), it is better to choose classes other than c. If ucn really needs a method of c, the CLS of ucn should be raised higher than its previously underestimated value. Conversely, if the designer finds that c.CLSmin was previously defined too high (i.e., all methods in c are less sensitive than expected) and does not satisfy CMa, then c.CLSmin can be decreased. The SAR UCC allows more use cases to have a chance to utilize class c if needed. In summary, as stated in Principle 1 in Section 3, the process of secure software design is iterative along with the calibration of proper security levels assigned to concerned UML elements for the application, while maintaining the satisfaction of the SARs for Tiers 1, 2, and 3, as we have described.

4.4 Algorithms for MAC Security Assurance In this section, we define algorithms for overall security assurance for the situation when a software engineer provides an existing UML design of use case, class, and sequence diagrams in which the assigned security levels occurred in isolation from the SARs. In this case, there must be automated algorithms that can verify whether the design as a whole satisfies the SARs by conducting a comprehensive analysis of an entire design. To begin, we formalize terminology related to UML diagrams and dependencies. Let DUC represent a use case diagram and define an actor inheritance graph DUC.GAI = (VA, EAI) as a directed graph of actors in DUC where VA is the set of actors (each node is an actor) and EAI is the set of edges in DUC such that there exists an edge e ∈ EAI from v2 to v1 iff v2 inherits v1 (v1, v2 ∈ VA). Similarly, define a use case inheritance graph DUC.GUI, use case inclusion graph DUC.GUInc, and use case extension graph DUC.GUExt in DUC as directed graphs for use case inheritance, inclusion and extension. Further, let DUC.GAUC = (VA, VU, EAUC) be the actor-use case association (bipartite) graph in DUC where EAUC = {(acm, uci) | actor acm is associated with use case uci where acm ∈ VA, uci ∈ VU} (we consider the edge is from the actor to the use case). Collectively, DUC is defined as a tuple of (VA, VU, GAI = (VA, EAI), GUI = (VU, EUI), GUInc = (VU, EUInc), GUExt = (VU, EUExt), GAUC = (VA,VU, EAUC)). Note that there cannot be a cycle in actor or use case inheritance directed graphs since an element cannot (indirectly) inherit from itself. Additionally, for this first phase of our work, we assume that there is no cycle in use case inclusion and extension directed graphs. We make this assumption based on an email interaction with OMG to get a clarification on the issue of inclusion and extension cycles, and based on their response (cycles unlikely), we believe our assumption is reasonable. Given these assumptions, we can formulate an algorithm for overall security

assurance that employs a depth-first search strategy to check the corresponding SARs in Sections 4.1 to 4.3 between a visited node v and a newly reached node w by the edge (v, w), whenever we first encounter the new node w on the traversing path. In the process, we must also check the SAR AUC for association connections from each actor to some use cases to guarantee the security assurance between the actor and use cases. In support of this approach, Figure 3 contains common userdefined types and variables to support the algorithms. The type Node represents UML elements (actors and use cases) in a use case diagram and has properties: security_level for the security level assigned to that element; and, visited and post for the depth-first search strategy to track the traversing status of the node. Initially, the visited property of a node v is false (i.e., v has not been visited) and will be set to true when v is actually visited, starting the depth-first search from v at the beginning of the procedure DFS_T(G, SAR, v). The post property (initial value is 0) is set to the time (whose value is incrementally stored by the Postcount variable) that v has just finished its depth-first search originating from itself (before exiting the procedure DFS_T(G, SAR, v)). Figure 3 also contains a graph definition, and definitions for a use case diagram and its directed graphs for actor inheritance, and use case inheritance, inclusion, and exclusion. We also have a global variable sp for the chosen MAC security property: “SS”, “LS”, and “SI” for Strict *, Liberal *, and Simple Integrity Properties, respectively. Typedef Security_Ordered_Set {label set with ≤ relation} Typedef Node { name: String; security_level: Security_Ordered_Set; // CLS/CLR of node visited: Boolean post: Integer; } Typedef Graph (V, E) where V = {v | v: Node} and E = {(v, w) | v, w: Node} Typedef Use_Case_Diagram { I

I

I

I

VA, VU, GA = (VA, EA ), GU = (VU, EU ), GU GU

Ext

Inc

Inc

= (VU, EU ),

Ext

= (VU, EU ), GAUC = (VA,VU, EAUC);

} postcount:: Integer; sp: String // MAC security property: “SS”, “LS” or “SI”

Figure 3. Common Types and Variables in our Algorithms. Using these definitions, Figure 4 contains the pseudo-code of security assurance checking in a use case diagram, which includes the invocation of the SARs given in Sections 4.1 to 4.3. The main procedure UC_Diag_Sec has the concerned use case diagram UCD as parameter. First, the procedure UCD_Sec_Check is called to check each relationship graph in the use case diagram. UCD_Sec_Check will reset the status of all of the nodes and then call the depth-first search DFS_T to check each connection edge based on the appropriate SAR (by calling Rule_Check). Finally, the main procedure UC_Diag_Sec will check each association connection (a, u) from each actor a to some use case u in the use case diagram by calling Rule_Check(a, u, “AUC”).

Boolean Rule_Check(src, dest:Node, R :String) { c: Boolean; switch R // select corresponding rule “AIS”,“UCIS”,“UCI”,“UCE”,“AUC”: c=src.security_level ≥ dest.security_level “AM”, “MM”: { if (dest is IMuM) c=src.security_level ≥ dest.security_level else // dest is MuM switch sp // select MAC property “SS”: c=src.security_level = dest.security_level “LS”: c=src.security_level ≤ dest.security_level “SI”: c=src.security_level ≥ dest.security_level return c; } DFS_T(G: Graph, R: String, v: Node) { v.visited = true; For each edge (v, w) in G.E { If (! Rule_Check(v, w, R)) Report SAR R is violated; If (! w.visited) // (v, w) is a TREE-EDGE; DFS_T(G, R, w); Else If (w.post = 0) Report Cycle; // (v, w) is a BACK-EDGE; } // End For v.post = postcount ++; } UCD_Sec_Check(G: Graph, Rule: String) { Postcount = 1;

The running time of UCD_Sec_Check is Θ(|V|+|E|) (where |V| and |E| are the numbers of nodes and edges of G, respectively), since the running time of depth-first search (by D DFS_T) on G = (V, E) is Θ(|V| + |E|) ([8]) and the running time of Rule_Check is constant. Thus, the running time of UC_Diag_Sec is Θ(|VA| + |VU| + |EAI| + |EUI| + |EUInc| + |EUExt| + |EAUC|). For the algorithm for the security assurance check of a sequence diagram, we define additional concepts. Let Dseq be a sequence diagram and msg a message in Dseq with a sequence number based on the Dewey decimal numbering system. We define the nested message (directed) tree of an initiating sender s as either an actor or a class method, is denoted by (GMsg, s, uc) which has the root as a special node s and used for describing actions of use case uc; the other nodes are method names used for corresponding nested messages and the directed edges are the nested messages starting from s. As such, the Dewey decimal numbering for the tree (GMsg, s, uc) is constructed by complying with the depth-first search strategy for checking edges in tree (GMsg, s, uc). Figure 5 shows the nested message tree (GMsg, Senior_Staff, Add_Survey_Header) with the nested levels on edges and the actor Senior_Staff as the initial sender for the use case Add_Survey_Header. For our purposes, Dseq contains: a set of instances Dseq.Instance (modeling instances of classes and/or actors) that send and receive messages (by calling methods of those classes), the associated use case set Dseq.UCase, and a forest of nested message directed trees Dseq.MsgForest = {(GMsg, si, ucj) | i = 1,2,…, ucj ∈Dseq.UCase} of initiating senders si occurring in some sequence order. To verify security assurance in Dseq, we visit all of the trees in Dseq.MsgForest, eventually call the DFS_T3 (Figure 4) (also using Rule_Check in Figure 4) to perform three checks: 1.

Compare the CLS of uc with the CLS of MuMs (SAR UCM); (2).

2.

Compare the CLSs of calling method and called method (SAR MM);

3.

If the sender is an actor, compare the CLR of the sender s with the CLS of each called method (SAR AM).

For each v in in G.V { v.visited = false; // reset all nodes as not visited v.post = 0;} For each v in in G.V If (! v.visited) DFS_T(G, Rule, v); } UC_Diag_Sec(UCD: Use_Case_Diagram) { // Actor inheritance security assurance check I

UCD_Sec_Check(UCD.GA , “AIS”); // Use case inheritance security assurance check I

UCD_Sec_Check(UCD.GU , “UCIS”); // Use case inclusion security assurance check Inc

UCD_Sec_Check(UCD.GU , “UCI”); // Use case extension security assurance check Ext

UCD_Sec_Check(UCD.GU , “UCE”); // Actor-Use case association security assurance check For each actor a in UCD.VA For each edge (a, u) in UCD.EAUC If (! Rule_Check(a, u, “AUC”)) Report SAR “AUC” violated; }

Figure 4. Security Assurance Check for Use Case Diagram.

Figure 6 contains the algorithm Seq_Diag_Sec of the assurance check for sequence diagram SeqD, with the running time as the sum of the number of trees in the forest Dseq.MsgForest and the total number of messages in Dseq.

5. PROTOTYPING EFFORT We have been integrating MAC definition and security assurance rules (SARs) as given in Section 4 into Borland’s Together Control Center (TCC), which is a UML tool for analysis, design, development and deployment of applications. TCC provides a rich set of Open APIs and a plug-in structure that has facilitated the integration of MAC and our security assurance rules (SARs) into TCC. Using TCCs OpenAPIs, functions, and objects, we are able to create our own properties for security levels (CLS and CLR) in MAC, which can be used to assign the security levels for each UML element. In addition, we can provide our own custom Java code that realizes the SARs presented in Sections 4.1 to 4.3 and the algorithm in Section 4.4, to dynamically and statically check the security in a UML design. A dynamic check occurs whenever a user acts on a UML diagram by connecting two UML

elements. A static check is utilized when a user is checking an entire diagram at once, to determine if the design has any security conflicts or inconsistencies.

Figure 5. (GMsg, Senior_Staff, Add_Survey_Header) Tree. DFS_T3(G: Graph, v: Node, uc: UCase) { v.visited = true;

In our prototype, we allow the designer to define the ordered set of security levels with user-defined labels, from level 0 to level 5 (more are possible but may not be practical). By editing a configuration file, we are able to modify the Default Options Dialog of TCC which allows the user to define string labels for the security levels. With this information, our security extensions support the definition of MAC CLS or CLR for actors, use cases, classes, and methods, by using the previously defined labels for the security levels. To integrate MAC into TCC, we employ its APIs to extend the TCC-Inspector property window for classes, methods, actors and use cases with an additional page (tab) for “MAC Settings”, which is shown in Figure 7. The new tab represents the crucial component of the security extensions, by providing MAC security levels for all of the UML elements that are supported at this time. The designer chooses a security level from the previously defined security level range for assignment to a UML element. The MAC security level is set by using a drop down combo-box. The names that are shown in the drop down combo-box are the names that have been defined in the Default Options Dialog. For example, in Figure 7, the actor Senior Staff is assigned the security level S (“Secret”). The plug-in also inserts comments for the chosen security level values into the generated code, allowing security to be tracked into later development and maintenance stages, shown in Figure 10 for class Survey_List. To set a security level for an actor, use case, or method, the user must select a single MAC level. However, for classes, the “MAC Security” property tab has two entries, namely CLS Min Level and CLS Max Level. This allows us verify that the security level of the methods for a class fall within this minimum/maximum range.

If (v is for a MuM && (uc.CLS > v.CLS) Report SAR UCM is violated; For each edge (v, w) in G.E { If (! Rule_Check(v,w,”MM”)) Report SAR MM is violated; If (v is for an actor && (! Rule_Check(v,w,”AM”)) Report SAR AM is violated; If (!w.visited) then // (v, w) is a TREE-EDGE; DFS_T3(G, R, w); Else If (w.post = 0) then Report Cycle; // since (v, w) is a BACK-EDGE; } // End For v.post = postcount ++; } SD_Sec_Check(G: Graph, s: Node, uc: UCase) { For each v in in G.V { v.visited = false; // reset all nodes as not visited v.post = 0;} DFS_T3(G, Rule, s, uc); } Seq_Diag_Sec(SeqD: Sequence_Diagram) { For each tree (GMsg, si, ucj) in the forest SeqD.MsgForest { SD_Sec_Check(GMsg, si, ucj); } }

Figure 6. Security Assurance Check for Sequence Diagram.

Figure 7. The CLR Assignment of Actor Senior. The prototype under development supports “dynamic” designtime checking of MAC Security Assurance Rules between UML elements based on the SARs presented in Section 4, as illustrated in Figure 8 for the SAR AUC. Dynamic checking focuses on the security consistency of the MAC levels between two UML elements which have been associated via certain kinds of connections (e.g., include, extend, generalize, etc.). If the software engineer draws a connection between two UML

elements and the corresponding SAR is violated, an error message window will pop up. Suppose there is an association from actor Senior Staff (CLR = S) to use case Add Survey Header (CLS = S). If we attempt to connect an association from actor Staff to use case Add Survey Header, an error dialog is displayed, since the Staff.CLR = C < Add_Survey_Header.CLS = S violates the SAR AUC. The dynamic checking module can be activated or deactivated by the user. It may be deactivated if there are many different connections that must be made, which may cause inconsistencies until all connections have been established.

Figure 8. An Example of Violating SAR AUC.

entire design in search of security conflicts and inconsistencies. In support of static checking, we have implemented the algorithm given in Section 4.4 which conducts a comprehensive security analysis of an entire design by verifying use case diagrams where the assigned security levels occur in isolation from the SARs. If the designer has assigned all of the elements of a use case diagram with MAC security levels s/he can start the “MAC Static Check” and the diagram will be traversed; if a violation of a SAR occurs an error message referring to the affected elements and violated SAR will be displayed. The assurance checks between methods and use cases as well as between methods in Sequence Diagrams are being prototyped (in progress) as part of our Together MAC plug-in. To illustrate their potential usage, a simulated example to enforce the SAR MM is shown in Figure 9 (if we adopt the Simple Integrity Property). If the designer tries to assign the level C to the method Add_Survey_Header, SAR MM will be violated since the Add_Survey_Header method calls Create_Survey_Header method and Add_Survey_Header.CLS = C ≥ Create_Survey_Header.CLS = S is no longer true. We anticipate that the algorithms for all of the checks associated with the SARs in Sections 4.1 to 4.4 will be available for both dynamic and static analysis in the near future.

6. RELATED RESEARCH

Figure 9. An Example of Violating SAR MM. /* Generated by Together */ package Survey_Package; /* Survey List is used to store the list of all survey headers. * Min CLS = "C" and Max CLS = "S" * @stereotype container * @clsPropertyMin Level1: Confidential * @clsPropertyMax Level 2: Secret */ public class Survey_List { /* @clsProperty Level 2: Secret */ public int Add_Survey_Header() { } /* @clsProperty Level 2: Secret */ public int Update_Survey_List() { } /* @clsProperty Level 1: Confidential */ public boolean Survey_Title_Search(String aSurvey_Title) { } private String Survey_Title; }

Figure 10. Code Generated for Survey_list Class. To supplement the dynamic check, the “Static” or post-designiteration check can be performed over UML designs at meaningful increments. For example, if the dynamic check was deactivated for a period of time, the static check can scan the

There have been a number of other research efforts in security for UML, which have similarities and differences to the work presented herein. In this section, we briefly review these efforts, comparing and contrasting them to our work. In [11], a proposed Framework for Network Enterprise utilizes UML notations to describe a role-based access control (RBAC) model, employing UML as a language to represent RBAC requirements. However, the representation is too general to incorporate subtle properties of RBAC such as separation of duty constraints (see [12] for different types of RBAC constraints). In a similar approach, [24] proposed an alternative technique to utilize UML notations to describe RBAC modeling and processing. Both of these efforts have focused on the way that UML elements can be used to model roles rather than taking a larger view of examining secure software design, which has been our focus. In an effort that is similar to our work, [15, 16] has proposed extended UML features to accommodate security requirements. Their effort utilizes a mathematical Abstract State Machine model [13] (cited in [15]) to formalize UML elements (use cases omitted) and extend several stereotypes to accommodate their proposed security framework towards theoretical security verification with UML. This contrasts with our approach to extend properties of essential UML elements (use cases, actors, classes, and methods) in order to directly apply security models (i.e., MAC) for secure software design, and balances a theoretical perspective (MAC model for UML with security assurance checking) with a practical realization of our work into TCC. Another effort [17] has introduced SecureUML for model-driven security with extended meta-model elements for RBAC only, which is similar in concept to our work on RBAC for UML [9]. Likewise, [22] used parameterized UML elements to model an access control framework combining MAC and RBAC which expresses a hybrid access control policy of an organization, rather than inserting MAC features into software design using UML and performing MAC constraints checking as we have done. Lastly, in an effort similar to our work, [1, 2] proposed a framework to incorporate security into UML design. However,

this work only deals with use case modeling without considering sequence diagrams.

[9] Doan, T., et al. RBAC/MAC Security for UML. In Proc. of the 18th Annual IFIP WG 11.3 Working Conference on Data and Applications Security. Sitges, Spain, July, 2004.

7. CONCLUSION AND ONGOING WORK

[10] http://www.engr.uconn.edu/~steve/DSEC/dsec.html.

This paper has examined the incorporation of MAC into the unified modeling language, UML, supporting both design-time and post-design security assurance checking. Section 2 reviewed background on MAC and UML. Section 3 proposed guidelines for secure software design and to interpret MAC for OO design. Section 4 examined security assurance for UML use case, class, and sequence diagrams, focusing on the assignment of security levels to MAC elements (use case, actor, class, and methods), the security assurance rules (SARs) that are automatically fired when users connect elements with relationships, and algorithms for assurance of use case and sequence diagrams for post-design checking. The integration of the work of Section 4 into the Together Control Center prototype for design-time analysis was reviewed in Section 5. Section 6 compared other research on UML and security to our own efforts.

[11] Epstein, P. and Sandhu, R. Towards A UML Based Approach to Role Engineering. In Proc. of the 4th ACM workshop on Role-based Access Control, 1999.

Our ongoing research in this area includes expanding our work to also support RBAC for UML [9]. In addition, we are exploring the generation of formal security requirements (in a logic-based programming paradigm) which can then be executed in order to identify security problems and inconsistencies. From a practical perspective, we are continuing our prototyping efforts, to fully support the SARs presented in this paper in the prototype of Section 5, and to also include RBAC support. The work presented herein is also related to our ongoing efforts in distributed security and security assurance [21]. Please see [10] for further information on our security research.

8. REFERENCES [1] Alghathbar, K. and Wijesekera, D. AuthUML: A Threephased Framework to model Secure Use Cases. In Proc. of the Formal Methods in Security Engineering Wksp (FMSE’03), Washington D.C., USA, 2003. [2] Alghathbar, K. and Wijesekera, D. Consistent and Complete Access Control Policies in Use Cases. In Proc. of UML 2003, San Francisco, CA, LNCS, 2003.

[12] Ferraiolo, D., et al. Proposed NIST Standard for Role-Based Access Control. ACM Trans. on Information and System Security, Vol. 4, No. 3. August 2001. [13] Gurevich, Y. Evolving algebras 1993: Lipari guide. In E. Borger, editor, Specification and Validation Methods. Oxford University Press, 1995. [14] Jacobson, I., et al. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1992. [15] Jürjens, J. Principles for Secure Systems Design. Ph.D. dissertation. Oxford University Computing Laboratory. Oxford University, 2002. [16] Jürjens, J. UMLsec: Extending UML for Secure Systems Development. In Proc. of UML 2002, LNCS, Sept. 30 - Oct. 4, 2002. [17] Lodderstedt, T., et al. SecureUML: A UML-Based Modeling Language for Model-Driven Security. In Proc. of UML 2002, LNCS, 2002. [18] OMG. Unified Modeling Language, v.1.5. UML™ Resource Page. http://www.omg.org/uml/ [19] Osborn, S., et al. Configuring Role-Based Access Control to Enforce Mandatory and Discretionary Access Control Policies. ACM Trans. on Information and System Security. Vol. 3, No. 2, May 2000. [20] Osborn, S. Information Flow Analysis of an RBAC System. In Proc. of SACMAT’02, June, 2002. [21] Phillips, C., et al. Security Assurance for an RBAC/MAC Security Model. In Proc. of the 2003 IEEE Info. Assurance Wksp., 2003.

[3] Bell, D. and La Padula, L. Secure Computer Systems: Mathematical Foundations Model. M74-244, Mitre Corp., 1975.

[22] Ray, I., et al. Using Parameterized UML to Specify and Compose Access Control Models. In Proc. of the 6th IFIP Working Conference on Integrity & Internal Control in Info. Systems, 2003.

[4] Biba, K. Integrity Considerations for Secure Computer Systems. TR-3153, Mitre Corp., 1977.

[23] Rumbaugh, J., et al. Object-Oriented Modeling and Design. Prentice-Hall, 1991.

[5] Booch, G. Object-Oriented Design With Applications. Benjamin/Cummings, 1991.

[24] Shin, M. and Ahn, G. UML-Based Representation of RoleBased Access Control. In Proc. of the IEEE 9th Intl. Wksp. on Enabling Technologies: Infrastructure for Collaborative Enterprises, 2000.

[6] Booch G., et al. The Unified Modeling Language User Guide. Addison Wesley, 1999. [7] Budd, T. An Introduction to Object-Oriented Programming. Addison-Wesley, 1997. [8] Cormen, T., et al. Introduction to Algorithms. The MIT Press and McGraw-Hill, 1990.

[25] Thuraisingham, B. Mandatory Security in Object-Oriented Database Systems. In Proc. of 1989 OOPSLA Conf., 1989. [26] Zdonik, S. and Maier, D. Fundamentals of Object-Oriented Databases, in Readings in Object-Oriented Database Systems, S. Zdonik and D. Maier (eds.), Morgan Kaufmann, 1990.