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) 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 basedaccess 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. + + security requirements security design generation 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. Role Calendar owner Role Secretary Role Other 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 <<deny>>

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 • <<deny>> 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. XML XSLT VPL XMI export VPL Generation UML CASE Tool Role Server Policy 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

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

37. RACCOON 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 <<deny>> for denied communication associations

41. <<deny>> 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