© Duminda Wijesekera, 2003 Consistent and Complete Access Control Policies in Use Cases Khaled Alghathbar George Mason University, USA and King Saud University, Riyadh, Saudi Arabia Duminda Wijesekera Center for Secure Information Systems George Mason University, USA

© Duminda Wijesekera, Current situation “Most security requirements come to light only after functional requirements have been completed.” Devanbu and Stubblebine

© Duminda Wijesekera, Why security is considered after functional requirement? –Security is considered a non-functional requirements (NFRs) which describes how the software will do the requirement not what the software will do. Chung et al. –“None functional requirements (NFR) are generally more difficult to express in a measurable way, making them more difficult to analyze. In particular, NFRs tend to be properties of system as a whole.” Nuseibeh and Easterbrook.

© Duminda Wijesekera, What if non-functional requirements have been ignored? –low quality and inconsistent software. –unsatisfied software’s stakeholders. –more time and cost to reengineer.

© Duminda Wijesekera, What cause the difficulties/obstacles when considering security requirements? –Lack of unified modeling notations for security. –Lack of tools. –Lack of security expertise.

© Duminda Wijesekera, What are the advantages of considering security earlier in the software development process? –Integrating security requirements with functional to reduce conflict. –“Attention to quality in the early in the life cycle of a project leads to defect detection and avoidance” Devanbu and Stubblebine

© Duminda Wijesekera, What is needed? 1.A unified language for representing security features such as access control policy in the early phases of the software development life cycle [A]. 2.Formally analysis and validate the requirements to make sure that the specification is consistent with requirements definition [B]. [A] According to: Devanbu et al., Chung et al. [B] According to: Nuseibeh et al., Pfleeger, Rushby

© Duminda Wijesekera, Our Proposal This paper proposes several design artifacts that specify the details of access control policies formally and precisely in the requirement and analysis phases. –The work is based on extending the Use Case, with access control schemas and tables. –In addition, the paper proposes a methodology to resolve several issues such as consistency and completeness of access control specifications that are not totally resolved before.

© Duminda Wijesekera, Related Work Fernandez and Hawkins proposed to extend use cases with rights. The extension is by means of a stereotype that states the access constraints. Sendall and Strohmeier introduced the concept of operation schemas to describe the effect of system operation and its functionality. Fernandez-Medina et al proposed an extension to the use case and Class models. Brose et al extended UML to support the automatic generation of access control policies in order to configure a CORBA-based infrastructure.

© Duminda Wijesekera, Background – Use Case In UML, requirements are specified with use cases at the beginning of the life cycle. Use cases specify actors and their intended usage of the envisioned system. “A use case is a description of the possible sequences of interaction between the system under discussion and external actors, related to the goal of one particular actor.” Cockburn. Use cases are written in an informal natural language. Thus, different people may write varying degrees of details for the same use case. Use case diagram visualizes actors and their relationships with scenarios.

© Duminda Wijesekera, Background – Operation Schema Operation schemas enriches use cases by introducing conceptual operations and specifying their properties using Object Constraints Language (OCL) syntax. Operation schemas can be directly mapped to collaboration diagrams. It is our position that high-level access control policies should be applied at this level of detail.

© Duminda Wijesekera, However Use cases are not sufficient to model the details of access control policies. Although operation schemas are precise, they do not specify system security. Therefore, we extended the operation schemas to cover access control, and we refer to the extended schemas as access control schemas.

© Duminda Wijesekera, Access control schema advantages: First, it isolates access control policies from other functional requirements. Second, this separation facilitates several access control policies to one use case, thereby modularizing the design.

© Duminda Wijesekera, Access Control Schema Format Use Case: the use case name. Object: the object of the use case. Description: short textual description of the action. Declares: constants, variables, objects and data types used in the pre and post conditions. Authorized (user, group, and role): a list of users, groups or roles that are authorized to access this operation on this object. Denied (user, group, and role): a list of users, groups or roles that are denied to access to this operation on this object. Integrity Constraints (Pre): specify all integrity constraints that must be satisfied before executing the operation written in OCL. Integrity Constraints (Post): specify all integrity constraints that must be satisfied after the operation is executed. It is written in OCL.

© Duminda Wijesekera, Access Control Schema Example Use Case: Authorize Payment Object: Invoice Description: Actor authorizes the payment after it has been verified. If the amount exceeds one million dollar then the authorization is partial until a different supervisor completes it. Declares: UserWhoDidPreviousOperations: Set(History_Log) ::= History_Log  select (User= CurrentUser AND (Operation=”Record_Invoice_Arrival” OR Operation=”Verify_Invoice_Validity”)AND Object= CurrentObject); --it will return a record or more if the current user has done one of the previous use case. Authorized (User, Group, Role): Supervisor--Role Denied (User, Group, Role): none Integrity Constraints (Pre): Invoice.verified=”true”; Invoice.TotalAmount<= implies Invoice.authorized= “false”; Invoice.TotalAmount> implies (Invoice.partialAuthorized= “false” OR Invoice.authorized= “false”) UserWhoDidPreviousOperations  isEmpty; -- The current user did not do other operation on the current invoice(Dynamic Separation Of Duty) Integrity Constraints (Post): If (invoice.TotalAmount> AND then --the invoice has not been partially authorized by different Supervisor before. Invoice.partialAuthorized=“true”; else invoice.authorized= “true”; Endif;

© Duminda Wijesekera, Contrarians Representation Authorizations in the form of authorized or denied clauses in the access control schema do not capture all access control constraints. Therefore, we show how to express –in OCL- application constraints such as: Static Separation of Duty Principles –Mutually exclusive roles. –Business Task. –Mutually exclusive operations. Dynamic Separation of Duty Principles Other Access Control Constraints –Role prerequisites. –Permission Prerequisites. –Cardinality Constraints.

© Duminda Wijesekera, Access Control Table Use cases and their access control schemas may over or under specify authorizations, thereby resulting in inconsistency or incompleteness. We propose using an access control table as a means of visualizing them. We then propose to apply propagation, conflict resolution and decision meta-polices on access control tables in order to resolve inconsistencies and incompleteness.

© Duminda Wijesekera, Example Role\Use caseRecord Invoice ArrivalVerify Invoice ValidityAuthorize PaymentWrite a Check Clerk  Purchasing Officer  Supervisor 

© Duminda Wijesekera, Example (Cont.) Role\Use caseRecord Invoice ArrivalVerify Invoice ValidityAuthorize PaymentWrite a Check Clerk  Purchasing Officer  Supervisor   Access Control Table After Applying Propagation

© Duminda Wijesekera, Example (Cont.) Role\Use caseRecord Invoice ArrivalVerify Invoice ValidityAuthorize PaymentWrite a Check Clerk    Purchasing Officer    Supervisor   Access Control Table After Applying Decision Policies (Closed Policy)

© Duminda Wijesekera, Access Control Table for Operations Role\ Operation Read ::InvoiceRecord ::InvoiceRead ::AgreementWritePrice ::InvoiceVerify ::Invoice Authorize :: Invoice Write :: Check Clerk    Purchasing Officer    Supervisor //   Issues: 1- Invalidating Use Case level permissions. 2- Violating access control constraints. 3- Visually determine roles that may violate an access control policy.

© Duminda Wijesekera, An Algorithm for Enforcing Integrity Constraint of DSOD Policies If n=m then if there are no dependent entities trees then for each independent entity do Write the integrity constraint on the entity. else //there are dependent entities trees if there is only one dependent entities tree then write the integrity constraint on the last entity of this tree. else //there are more than one dependent entities tree. for each independent entity do Write the integrity constraint on that entity. for each dependent entities tree do write the integrity constraint on the last entity of each tree. End If else // m<n if there are no dependent entities trees then for each independent entity do Write the integrity constraint on the entity. else //there are dependent entities trees for each independent entity do Write the integrity constraint on it. for each dependent entities tree do if m  z then k=1 else k=i End If write integrity constraints on use cases from the kth level to the highest level of the dependent tree. End loop End If

© Duminda Wijesekera, The Refined Use Case Diagram

© Duminda Wijesekera, The desirable features of r efined use case diagram The representation of explicit or implicit access policy. Thus, the absence of an association between an actor and a use case is read as a prohibition. The new refined use case diagram adapts the Precedes relationship to specify dependencies and order of invocation among use cases. The association of access control policy schemas in the diagram. Although, this may clutter the diagram especially when integrity constraints are complex, it provides useful information about access control polices.

© Duminda Wijesekera, Conclusion We proposed design artifacts and a methodology to use them in specifying access control policies during the requirement specification and analysis phases. Our proposal specifies access control policies in a formal and precise manner, and is capable of deriving access permissions along hierarchies. We present meta-policies, algorithms and methodologies to resolve conflicting permissions before proceeding to the design phase. Our ongoing work addresses mapping access control policies to other UML’s diagrams, such as, Classes, Statecharts and Sequence Diagrams.

© Duminda Wijesekera, Questions!