Post on 19-Jan-2018
description
© Duminda Wijesekera, 2003
Consistent and Complete Access Control Policies in Use
Cases
Khaled AlghathbarGeorge Mason University, USA and
King Saud University, Riyadh, Saudi Arabia
Duminda WijesekeraCenter for Secure Information Systems
George Mason University, USA
© Duminda Wijesekera, 2003 2
Current situation
“Most security requirements come to light only after functional requirements have been completed.” Devanbu and Stubblebine
© Duminda Wijesekera, 2003 3
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, 2003 4
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, 2003 5
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, 2003 6
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, 2003 7
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, 2003 8
Our ProposalThis 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, 2003 9
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, 2003 10
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, 2003 11
Background – Operation SchemaOperation 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, 2003 12
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, 2003 13
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, 2003 14
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, 2003 15
Access Control Schema ExampleUse Case: Authorize PaymentObject: InvoiceDescription: 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--RoleDenied (User, Group, Role): noneIntegrity Constraints (Pre):
Invoice.verified=”true”;Invoice.TotalAmount<=1000000 implies Invoice.authorized= “false”; Invoice.TotalAmount>1000000 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>1000000 AND invoice.partialAuthorized@pre=“false”) then --the invoice has not been partially authorized by different Supervisor before.
Invoice.partialAuthorized=“true”;else
invoice.authorized= “true”; Endif;
© Duminda Wijesekera, 2003 16
Contrarians RepresentationAuthorizations 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, 2003 17
Access Control TableUse 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, 2003 18
ExamplePurchasing Payment
Clerk
Supervisor
Record invoice arrival
Verify invoice validity
Authorize payment
Purchasing Officer
Write a checkClerk
Clerk
Supervisor
Purchasing Officer
Role\Use case Record Invoice Arrival Verify Invoice Validity Authorize Payment Write a Check
Clerk
Purchasing Officer
Supervisor
© Duminda Wijesekera, 2003 19
Example (Cont.)Purchasing Payment
Clerk
Supervisor
Record invoice arrival
Verify invoice validity
Authorize payment
Purchasing Officer
Write a checkClerk
Clerk
Supervisor
Purchasing Officer
Role\Use case Record Invoice Arrival Verify Invoice Validity Authorize Payment Write a Check
Clerk
Purchasing Officer
Supervisor
Access Control Table After Applying Propagation
© Duminda Wijesekera, 2003 20
Example (Cont.)Purchasing Payment
Clerk
Supervisor
Record invoice arrival
Verify invoice validity
Authorize payment
Purchasing Officer
Write a checkClerk
Clerk
Supervisor
Purchasing Officer
Role\Use case Record Invoice Arrival Verify Invoice Validity Authorize Payment Write a Check
Clerk
Purchasing Officer
Supervisor Access Control Table After Applying Decision Policies (Closed Policy)
© Duminda Wijesekera, 2003 21
Access Control Table for Operations Role\
OperationRead ::Invoice Record ::Invoice Read ::Agreement WritePrice ::Invoice Verify ::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, 2003 22
An Algorithm for Enforcing Integrity Constraint of DSOD Policies
If n=m thenif there are no dependent entities trees then
for each independent entity doWrite the integrity constraint on the entity.
else //there are dependent entities treesif 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 dowrite the integrity constraint on the last entity of each tree.End IfEnd Ifelse // m<n
if there are no dependent entities trees thenfor each independent entity do
Write the integrity constraint on the entity. else //there are dependent entities trees for each independent entity doWrite the integrity constraint on it. for each dependent entities tree do
if m z thenk=1
elsek=i
End Ifwrite integrity constraints on use cases from the kth level to the highest level of the dependent tree. End loop
End IfEnd If
© Duminda Wijesekera, 2003 23
The Refined Use Case Diagram Purchasing Payment
Clerk
Supervisor
Record invoice arrival
Verify invoice validity
Authorize payment
PurchasingOfficer
Writing a checkClerk
Precedes
Precedes
Prece
des
Invoice.recorded=”true”;Invoice.verified=”false”;History_Log select (User= CurrentUser ANDOperation=”Record_Invoice_Arrival” AND Object=CurrentObject) size<2
Invoice.authorized=”true”Check.writen=”false”
Integrity Constraints (Pre):Invoice.verified=”true”;Invoice.TotalAmount<=1000000 implies Invoice.authorized= “false”;Invoice.TotalAmount>1000000 implies
(Invoice.partialAuthorized= “false” OR Invoice.Authorized=“false”)UserWhoDidPrevoiusOperations isEmpty; -- The current user did notdo other operation on the current invoice(Dynamic Separation Of Duty)
Integrity Constraints (Post):If (invoice.TotalAmount>1000000 AND
invoice.partialAuthorized@pre=“false”) then --the invoice has notbeen partially authorized by different Supervisor before.Invoice.partialAuthorized=“true”; elseinvoice.authorize= “true”; Endif;
© Duminda Wijesekera, 2003 24
The desirable features of refined 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, 2003 25
ConclusionWe 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, 2003 26
Questions!