Security Analysis/Design for UML

1. Security Analysis/Design for UML Alberto De la Rosa Algarín, Jaime Pavlich-Mariscal, Steven A. Demurjian, Laurent D. Michel Computer Science & Engineering Department 371 Fairfield Road, Box U-2155 The University of Connecticut Storrs, Connecticut 06269-2155 http://www.engr.uconn.edu/~steve steve@cse.uconn.edu ldm@cse.uconn.edu

2. Motivation • Software Engineering • Phases of Requirements, Design, Implementation, Testing, Maintenance. • Effort: E.g., 60% for Requirement & Design, 15% Implementation, and 25% Testing [Boehm 87] • Software Applications with Security Concerns • When is Security Incorporated into Software Development? • Traditional: Deferred to Latter Stages of the LifecycleProblem: Error-Prone, Difficult to Verify, Costly • Microsoft Report: >50% Security Problems are Design Flaws [McGraw 03] • Return on Security Investment (ROSI): 21% if Integrating at Design; 15% Implementation;12% Testing [Hoo 01]

3. Motivation • Incorporating Security into UML Design • Object-Oriented Software Design: • Using the De Facto UML (Unified Modeling Language)[OMG03], a Language for Specifying, Visualizing, Constructing, and Documenting Software Artifacts • When is Security Incorporated into Software Design? • Security Must Be a First Class Citizen - Integrated at Early and All Stages of the Lifecycle • Security Assured, Synchronized, Convenient • Provide Automated Transition from Security Definitions to Security Enforcement Code • Integration of Enforcement Code with Application

4. Objectives • Span from Requirements/Design to Development of the Software Process, its Models, and Tools • Integrated: • Rigid Methodology to Express Security Concerns • Seamlessly Capture Security Requirements at Design • Assured: • Specific Means to Verify Security Concerns • Easy-To-Use: • Intuitive Solution Facilitates Inclusion of Security for Different Stakeholders • Transition: Requirements - Design – Development • Security Code Generation (Authorizations) • Run-time Authentication

5. Overview of Remainder of Talk • Secure Software Design • Principles of Secure Design • Extending UML for Secure Design • UML Extensions for Security • Tracking Design and Security State • Security Assurance via Constraint Checking • Prototyping Effort • Transition from Design to Development • Role Slice Diagram • Aspect Oriented Programming • Prototyping Effort • Push to Information Security • Conclusions and Ongoing Research

6. Principles of Secure Design • Principle 1 • The Software Design has Multiple Iterative Periods • Security Features Should be Incorporated and Adjusted During Each of and Among Those Periods • Principle 2 • The Security Assurance is Satisfied Relatively to the Period of Software Design • Principle 3 • The Security Incorporating Process Should Neither Counter the Intuition Nor Decrease the Productivity of the Stakeholders • Principle 4 • Security Definition via a Unified Perspective that Collects Privileges into a Cohesive Abstraction

7. Principle 1 • The Software Design Has Multiple Iterative Phases and The Security Features Should Be Incorporated and Adjusted During Each of and Among Those Phases • Multiple Design Tiers: • Tier 1: Use Case Diagrams, Class Diagrams • Define Use Cases, Actors, and Their Relationships • Define Classes (High Level:Only Attributes/Methods Signatures) and Relationships Among Classes • Tier 2: Associating Classes Used in Use Cases • Choosing Needed Classes in Sequence Diagrams • Tier 3: Sequence Diagrams (and Other Diagrams) • Specify Messages (Methods Without Code) Between Objects

8. Principle 2 • The Security Assurance is Satisfied Relatively to the Period of Software Design • Security Assurance Evaluated Against the Respective Software Design Phase To Enforce the Security Assurance Rules (SARs) • The Granularity Level of SAR Checks Is Dependent on the Level of Detail in the Software Design Phase • Example: • Tiers 1 & 2: Use Case Diagrams, Class Diagrams • Check the Security Levels of Use Cases, Actors, and Classes • Tier 3: Sequence Diagrams • Check the Security Levels of Methods

9. Principle 3 • The Security Incorporating Process Should Neither Counter the Intuition nor Decrease the Productivity of the Software Designer. • Our Perspective: • (ei, ej.behaviorjk): Whether Element ei Can Employ Some Behavior behaviorjk of Element ej • Security Consideration in UML: “Who Can Exercise Which Behaviors of the Application (Use Cases) and Class Behaviors (Methods)?” • Answer: Drawing Connections in UML Diagrams • Productivity: Incorporating Security Via SARs in Connections Provides Security Checks During the Normal Activity of Designers

10. Principle 3 • The Security Incorporating Process Should Neither Counter the Intuition nor Decrease the Productivity of the Software Designer • Security Consideration in UML: “Who Can Exercise Which Behaviors of the Application (Use Cases) and Class Behaviors (Methods)?” • Example: The System has Two Usage Modes: • Design-Time: Real-Time Check • Drag – Check – “Drop/Pop”: Realization of the Intended Design Element or Pop Up Error Message Depending on the Security Checking Result • Post-Design: On-Demand Check • Security Compiler Executed on a Whole Design

11. Principle 3 • The Security Incorporating Process Should Neither Counter the Intuition nor Decrease the Productivity of the Software Designer. • MAC: (Subject, Operation, Object): Operation = Read|Write|Call Object = A Piece of Atomic Information With Only One Assigned Security Classification • Object-Oriented: Operation = (Read*Write*Call*)* (as Method) Object = An Instance of Class with Many Attributes

12. Principle 4 • Security Definition via a Unified Perspective that Collects Privileges into a Cohesive Abstraction • Our Perspective: • Security as Supported via Principles 1, 2, and 3, Spreads Requirements Across Multiple Diagrams • As a Result, Security is “Tangled” and “Scattered” Across Design • Propose a “Role-Slice Diagram” that Collects Definitions into a Central Location • Allows Stakeholders to See the “Big Picture” • Provides Basis for Security Enforcement Code Generation

13. Objective and Approach • Objective • Propose and Design Techniques that Integrate Security Concerns into the Software Process. • MAC, RBAC, and DAC (Delegation) • Lifetime of Access • Authentication • Logging • Approach Introduces the “Role-Slice Diagram” • Preserve Separation of Security Concerns from Modeling through Implementation • Provide the Tools to Integrate them at Every Level • Allow a Customized Generation of Secure Code on an Application-by-Application Basis

14. Recall Survey Management Example • A Survey Institution Performs and Manages Public Surveys • The Senior Staff Person Adds a Survey Header Into the Database • Staff Person (Senior or Junior Staff) Adds Questions Into that Survey, Categorize Questions and Adds a New Question Category If Needed • Some Special Questions that have More Sensitive Content - Only Senior Staff Allowed to Process

15. Survey Management Example

16. Survey Management Class Diagram

17. Simplified Class Model of the Survey Application

18. Defining a Secure Subsystem Secure Subsystem • We do not Want to Define Security over Every Class in the System • Security is Defined over a Secure Subsystem • Represents those Classes on Which Privileges will be Defined

19. A Role Slice is a Specialized Class Diagram that Represents Permissions for the RBAC Model Roles are Represented as Packages Permissions are Represented as Stereotyped Methods Role Hierarchy is Represented by a Stereotyped Dependency Relation Defining Access Control Policy

20. Integration is Automatable Secure Subsystem • Recall the Transition from Use Cases to the: • Classes Utilized to Realize their Functionality • Methods of those Classes (Subset) • Provides • Definition of Secure Subsystem (Include a Class if at Least One Method is Assigned to a Use Case) • <pos> Methods Identified via Actor-Use Case-Class-Method Link • <neg> by Disallowed Usage

21. Recall the Transition Secure Subsystem

22. Framework Overview • Application-specific Model • Concern-specific Composable Units • Implementation of the Application • Implementation of Concerns • Composition into the Final Application

23. Framework Overview • Role-Slice Extensions • Aspect-Oriented Security Enforcement Code Generation

24. Simplified Class Model of the Survey Application

25. Defining the Security Policy Secure Subsystem • We do not Want to Define Security over Every Class in the System • Security is Defined over a Secure Subsystem

26. Composition of Role Slices • To Obtain the Final Set of Permissions • Positive Permissions are Inherited by Child Role Slices from their Parents • Negative Permissions are Used to Override Permissions that are Positive in Parent Role Slices

27. Formal Role-Slice Policy

28. Composition of Role Slices • To Obtain the Final Set of Permissions • Positive Permissions are Inherited by Child Role Slices from their Parents • Negative Permissions are Used to Override Permissions that are Positive in Parent Role Slices

29. Composed Role Slices

30. Another Example

31. Role Slice Diagram

32. Composed Role Slices

33. Mapping to Security Enforcement Code • Role Slices Define an Access Control Policy • This Policy Must be Enforced in the Code • OOP is not Enough to add Security to Software • Leverage Aspect-OrientedProgramming (AOP)

34. Prototyping Effort - Role-slice Inspector • A Plugin for Together Architect that Generates a Role Slice from the Information of an Actor • Defines whether the Role is Abstract or Not • Shows the Role Slice Associated to the Selected Actor

35. Prototyping Effort - Role-slice Inspector • Role-slice View of Actor Staff

36. Prototyping Effort – Code Generator • Uses the Role Slice Information to Generate Enforcement Code in AspectJ

37. Prototyping Effort – Code Generator AccessControl.java • Generation of the AspectJ File

38. Prototyping Effort – Code Generator • Generated AspectJ File

39. Prototyping Effort – Code Generator • Generated Code • Obtaining the Active User public aspect AccessControl { pointcut login():call(User SecurityAdmin.logIn(..)); User around():login() { User u = proceed(); activeUser.set(u); return u; } private ThreadLocal activeUser = new ThreadLocal() { protected Object initialValue() {return null;} }; private User getActiveUser() { return (User)activeUser.get(); } ... }

40. Prototyping Effort – Code Generator • Checking Permissions public aspect AccessControl { ... pointcut externalCall() : (call(* Survey_List.*(..)) || call(* Survey_Header.*(..))) && !within(Survey_List) && !within(Survey_Header); before() : externalCall() { Role r = getActiveUser().getActiveRole(); if (!r.hasPosPermission(thisJoinPointStaticPart)) { throw new org.aspectj.lang.SoftException( new PermissionDeniedException()); } } }

41. Information Security

42. Push for Information Security • Today’s Applications and Systems Built around Multiple Technologies • APIs, Cloud Computing, Web Services, Data Mining, etc. • Alternative Data Structure Standards • XML, RDF, JSON, OWL, etc. • Can we Incorporate RBAC, MAC, and DAC ? • XML Security Schemas Set • Roles, Users, Constraints • RBAC, MAC, DAC • Apply Security Schemas to XML Documents • Security Schema Filters Document • XML Document Appears Differently Based on Role, MAC, Delegation

43. What is XML? • Provides a Common, Structured Language • Independent of Systems • Information Hierarchically Structured and Tagged • Tags can Offer Semantics • XML schemas • Blueprints for new Instances • Validation Agents • Achieved with • XML Schema Definition (XSD) • XML Schema Language (XSL)

44. Example of an XML schema (CCR segment)

45. Secure Information Engineering • Given an XML Application of Schemas and Associated Instances, can we: • Define Schemas for Security Levels, Roles, User-Role Authorizations, and Delegation • Augment Application’s Schemas/Instances with MAC Security Classifications (if Needed) • XML Instances are Dynamically Filtered to Suit a User’s Needs for an Application: • Based on User’s Role, MAC, Delegation • Deliver Filtered Instance(s) to User • Exploit eXtensible Access Control Markup Language (XACML) for Policy Generation

46. XML sScurity Oriented UML diagrams • UML provides diagrams to model applications • Lack of diagrams for Security • Pavlich-Mariscal 2008 defined new UML diagrams for RBAC in the Meta-model layer • We Extend with XML Oriented UML Artifacts • XML Schema Class Diagram (XSCD) • UML Representation of the XML schema • For RBAC, XML Role Slice Diagram (XRSD) • Security Augmented Representation of XML schema Elements, Roles and Permissions

47. XML Schema Class Diagram • Artifact that holds all the characteristics of an XML schema • Structure, Data Type, Value Constraints • Hierarchical nature of XML schemas is modeled • xs:complexType, xs:element, xs:sequence • UML Class with respective Stereotypes • Child Relations (xs:element, xs:sequence, xs:simpleType) • UML Subclass • xs:extension • Association between Classes • Data-type Cardinality Requirements and Constraints; type • «constraint»; «type» stereotypes

48. XSCD of CCR Segment «complexType» StructuredProductType «complexType» «extension» CCRCodedDataObjectType «sequence» «element» BrandName «element» Product «type» CodedDescriptionType «constraint» minOccurs=0 «element» ProductName «type» CodedDescriptionType «element» Strength «constraint» minOccurs=0 «constraint» maxOccurs=-1 XSCD

49. XML Role Slice Diagram • Represents Access Control Definitions • With respect to XSCD Attributes • Fine Grained Control through • Security Policies and Definitions to the XSCD • Permissions on XML Documents • Read, Write, No Read, No Write • Represented in the XRSD with Stereotypes: • «read/write» • «read/nowrite» • «noread/write» • «noread/nowrite»

50. Example of XRSDs «XRSD» Physician «RoleDescription» «RoleRequirements» «XRSD» Nurse «RoleDescription» «RoleRequirements» «read/nowrite» «element» Product «read/write» «element» Product «read/write» «element» ProductName «read/write» «element» BrandName «read/write» «element» Strength «read/nowrite» «element» ProductName «read/nowrite» «element» BrandName «read/nowrite» «element» Strength «read/nowrite» «element» StrengthSequencePosition «read/nowrite» «element» VariableStrengthModifier «read/write» «element» StrengthSequencePosition «read/write» «element» VariableStrengthModifier