1. Integrating Access Control Design into the Software Development Process G. Brose (Xtradyne AG) M. Koch, P.Löhr (FU Berlin) IDPT‘02, 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 VPL IDL functional requirements functional design security design + + security requirements + generation

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 Role Calendar owner Role Other Role Secretary

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 >

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. 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 – > 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. 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 XMI export XML Policy Server Policy Server Role Server Role Server VPL XSLT RACCOON

29. VPL Generation policy Calendar { roles Other Secretary: Other CalendarOwner: Secretary } UMLVPL

30. VPL Generation UML VPL View RoomBooking controls Room restricted to Secretary { allow book cancel }

31. VPL Generation UML VPL 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 Object/Type Role/Subject o:PaperPaper AuthorReading Reviewer JackWriting, Submit Access Control Matrix

36. Client Server access_object() Object allow/deny access? Roles Domain Policy Role Mgmt.Domain Mgmt. Policy Mgmt. Role Server Policy Server Domain Server Raccoon - Architecture

37. Raccoon VPL Development IDL RACCOON Deployment 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 > 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