Integrating Access Control Design into the Software Development Process

1
Integrating Access Control Design into the
Software Development Process

• G. Brose (Xtradyne AG)
• M. Koch, P.Löhr (FU Berlin)
• IDPT02, June 2002

2
Overview

• Motivation
• View-based Access Control
• Integrating Access Control in UML
• security analysis
• security design
• Generation of the Access Control Policy
  specification
• Conclusion

3
Motivation

• Security aspects are inherent in any modern
  software system
• But Security is not a part in the development
  process
• Why ?
• security requirements are difficult to analyze
  and model
• system engineers are not security experts
• Problems
• Unsatisfied security requirements
• Integration difficulties

4
Our approach - Aims

• Systematic support for software engineers who
  need to produce secure software
• Integration into the software development process
  with UML
• How ?
• Use of existing UML model elements
• Security design with UML tools
• No security expert knowledge neccessary
• UML design for the generation of security
  specifications

5
Our approach What we have done

• Integration of view based access control policy
  design into the software development process with
  UML
• Generation of the access control specification
  from the UML design model to configure a
  CORBA-based infrastructure (Raccoon)

6
View-based Access Control

• Design and management of access control policies
  in object-oriented systems
• Extension of role-based access control by views
• View is a set of access rights
• Views are specified in the View Policy Language
  (VPL)

7
View Policy Language (VPL)
IDL
VPL interface Paper view Reading
controls Paper void read(out string s)
allow read void write(in string s)
void append(in string s) view
Writing Reading void correct(in string s)
restricted_to Author void
submit() allow
write
append
view Submit controls Paper allow
submit
8
View Policy Language
policy Conference view Reading ... view
Writing ... view Submit ... roles
Chair Reviewer Author
9
Integrating Access Control Overview
functional requirements
functional design
IDL
VPL

IDL
10
Integrating Access Control
Security Requirements
11
Security analysis

• Functional requirements are expresed in use cases
• Security requirements are added to the use case
  models
• Access control information is inherent in
  functional system requirements and facilitates
  the integration

12
Example Digital Calendar
13
Actors and Role Identification

• UML actor
• a coherent set of specific behaviors that users
  of an entity have when interacting with an
  entity.
• VBAC role
• sets of functions that an individual user has as
  part of an organization
• VBAC role UML Actor

14
Actors and Role Identification
15
Identification of use case accesses

• Extracting accesses from the informal use case
  descriptions
• Attaching notes to communication associations in
  the use case diagram
• allowed and denied accesses
• high-level and informal
• Analyst considers and expresses security aspects
  already in the analysis phase

16
Identification of use case accesses
edit entry The calendar owner can read his/her
entries and modify them. Modifications may cover
the time, the day, and the room. The secretary of
the calendar owner can read the calendar entries
and make the calendar modifications, too.
update room A secretary books a room on behalf
of the calendar owner. The calendar owner is not
allowed to book a room by her-/himself.
17
Identification of use case accesses
ltltdenygtgt
18
Security analysis - summary

• UML Actors VBAC Roles
• Modeling of denied communications in use cases
• Making implicit access information in natural use
  case description explicit in notes

19
Integrating Access Control
Security Design
20
Security Design

• Starting point is the use case diagram
• Class diagram (for CORBA interfaces)
• View Diagram
• views on CORBA interfaces

21
Security Design
22
View Diagram

• Notes in use case diagrams are the starting point
  for view definition

23
View Diagram

• For each note N
• View V(N,I) all access rights with respect to
  interface I
• access rights are permissions to access the
  operation
• ltltdenygtgt association defines a view with denials
• View diagram contains all views for one interface
• View diagram is drawn like a class diagram

24
View Diagram
roles to which the view can be assigned
25
View Diagram
26
View Diagram
denials
27
View Diagram

• Explicit representation of views and assignment
  to roles
• Designer can check the assignment and detect too
  powerful roles

28
VPL Generation
UML CASE Tool
Policy Server
Role Server
RACCOON
29
VPL Generation
UML
VPL
policy Calendar roles Other
Secretary Other CalendarOwner
Secretary
30
VPL Generation
VPL
UML
View RoomBooking controls Room restricted
to Secretary allow book cancel
31
VPL Generation
VPL
UML
View RoomBooking controls Room restricted
to Secretary deny book cancel
32
Conclusion

• Systematic approach to integrate access control
  policy design into the devlopment process with
  UML
• Security requirments are considered early
• UML model is used to genarte the VPL
• UML tools can be used
• No security expert knowledge necessary

33
Weitere Folien
34
Access Control

• Preventing unauthorized access to resources
• Authorized accesses are specified in access
  control policies
• Security models are ...
• discretionary access control (e.g., Access Contol
  List)
• mandatory access control (e.g. lattice-based
  access control)
• role-based access control
• view-based access control
• ....

35
View Policy Language
Access Control Matrix
Object/Type Role/Subject oPaper Paper
Author Reading
Reviewer
Jack Writing,Submit
36
Raccoon - Architecture
Role Mgmt.
Domain Mgmt.
Policy Mgmt.
Role Server
Domain Server
Policy Server
Object
Client
Server
allow/deny access?
37
Raccoon
Development
Deployment
IDL
VPL
IDL
management infrastructure
38
Actors and Role Identification

• UML role
• named specific behavior of an entity
  participating in a particular context
• modeled by named association ends
• UML actor
• a coherent set of roles that users of an entity
  can play when interacting with an entity. An
  actor has one role for each use case with which
  it communicates

39
Role Diagram

• Access Control roles and specialization of roles
• Actors of the use cas diagram

40
Forbidden Use Cases

• Specification of possible, but unallowed use case
  accesses
• Documentation of unauthorized accesses
• Stereotype ltltdenygtgt for denied communication
  associations

41
Forbidden Use Cases
42
Security design - summary

• View Diagrams are based on informal accesses in
  the notes of use cases
• Role Diagram is based on the actors in use case
  diagrams