1. Security 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. Security UML -2Motivation  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 Lifecycle Problem: 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. Security UML -3Motivation  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. Security UML -4Objectives  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. Security UML -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. Security UML -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  T  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. Security UML -7  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  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 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

8. Security UML -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. Security UML -9 Principle 3  The Security Incorporating Process Should Neither Counter the Intuition nor Decrease the Productivity of the Software Designer.  Our Perspective:  (e i, e j.behavior jk ): Whether Element e i Can Employ Some Behavior behavior jk of Element e j  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. Security UML -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. Security UML -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. Security UML -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. Security UML -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. Security UML -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. Security UML -15 Survey Management Example

16. Security UML -16 Survey Management Class Diagram

17. Security UML -17 Simplified Class Model of the Survey Application

18. Security UML -18 Defining a 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 Secure Subsystem

19. Security UML -19 Defining Access Control Policy  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

20. Security UML -20 Integration is Automatable  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)  Methods Identified via Actor-Use Case- Class-Method Link  by Disallowed Usage Secure Subsystem

21. Security UML -21 Recall the Transition Secure Subsystem

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

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

24. Security UML -24 Simplified Class Model of the Survey Application

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

26. Security UML -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. Security UML -27 Formal Role-Slice Policy

28. Security UML -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. Security UML -29 Composed Role Slices

30. Security UML -30 Another Example

31. Security UML -31 Role Slice Diagram

32. Security UML -32 Composed Role Slices

33. Security UML -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-Oriented Programming (AOP)

34. Security UML -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. Security UML -35 Prototyping Effort - Role-slice Inspector  Role-slice View of Actor Staff

36. Security UML -36 Prototyping Effort – Code Generator  Uses the Role Slice Information to Generate Enforcement Code in AspectJ

37. Security UML -37 Prototyping Effort – Code Generator  Generation of the AspectJ File AccessControl.java

38. Security UML -38 Prototyping Effort – Code Generator  Generated AspectJ File

39. Security UML -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. Security UML -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. Security UML -41 Information Security

42. Security UML -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. Security UML -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. Security UML -44 Example of an XML schema (CCR segment)

45. Security UML -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. Security UML -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. Security UML -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. Security UML -48 XSCD of CCR Segment «complexType» StructuredProductType «element» Product «complexType» «sequence» «type» CodedDescriptionType «element» ProductName «type» CodedDescriptionType «constraint» minOccurs=0 «element» BrandName «element» Strength «constraint» minOccurs=0 «constraint» maxOccurs=-1 «extension» CCRCodedDataObjectType XSCD

49. Security UML -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. Security UML -50 Example of XRSDs «XRSD» Physician «RoleDescription» «RoleRequirements» «read/write» «element» Product «read/write» «element» ProductName «read/write» «element» BrandName «read/write» «element» Strength «read/write» «element» StrengthSequencePosition «read/write» «element» VariableStrengthModifier «XRSD» Nurse «RoleDescription» «RoleRequirements» «read/nowrite» «element» Product «read/nowrite» «element» ProductName «read/nowrite» «element» BrandName «read/nowrite» «element» Strength «read/nowrite» «element» StrengthSequencePosition «read/nowrite» «element» VariableStrengthModifier

51. Security UML -51 What is XACML?  Aims to Define a Common Language and Processing Model  Permits a Level of Security Interoperability  XACML schema Provides Several Structures and Elements to Represent Policies  PolicySet, Policy, Rule  PolicySets and Rules Combined by Policy/Rule Combination Algorithm  Permit-overrides  Deny-overrides  First-applicable  Only-one-applicable

52. Security UML -52 XACML General Structure PolicySet Policy Rule Subject Action Resource Rule Combination Algorithm Policy Combination Algorithm

53. Security UML -53 Mapping to a Security Policy (XACML)  Policies’ Language Structure and Processing Model  PolicySet, Policy, Rule  Policy and Rule Combination Done with Normative Algorithms  Deny-overrides, permit-overrides, first-applicable, only-one-applicable  Use Deny-overrides as Combination Algorithm for Enforcement  If the Evaluation of One Rule Results in Deny, the Policy Evaluation is Deny  Mapping Process Divided in 3 Sub-Mappings  Role, Element and Permission

54. Security UML -54 Mapped Policy Role Mapping Permission Mapping

55. Security UML -55 Mapped Policy Element Mapping

56. Security UML -56 Enforcement in a Security Architecture   The architecture has a number of components:  Policy Enforcement Point (PEP)  Allows a request to be made on a resource  Policy Decision Point (PDP)  Evaluates the request and provides a response according to the policies in place  Policy Administration Point (PAP)  Utilized to write and manage policies  Policy Information Point (PIP)  Arbitrate very fine grained security issues

57. Security UML -57 Enforcement in a Security Architecture Physician Nurse XRSDs XACML Policy Mapping XACML Policy – Schema 1 XACML Policy – Schema 2 Policy Retrieval Point (PRP) PAP PDP PEP PIP XACML Architecture

58. Security UML -58 Benefits of Approach  Secure Information Engineering  Information access control tackled at the design phase  Information security augmented to a first-class citizen  Decoupled security from the data  Lower cost of updating policies that target a large volume o  Visual representation of information security schemas  UML diagrams describe the roles, XML schemas targeted, and the interplay of all the elements in security

59. Security UML -59End-Purpose  Merging and combining  Functional Security (Jaime’s work)  Collaborative Security (Solomon’s work)  Information Security (Alberto’s work)  A secure software engineering approach that tackles the major concepts of an application  Methods and Operations  Collaboration and Adaptive Workflows  Information and Resources used  Leveraging access control models across all three topics  RBAC  MAC  DAC

60. Security UML -60 Overall View (1)Main Security Design of the Application (2a,b) Initial Functional Security and Collaboration Design (2a,b.1) Define Functional Security and Collaboration Use Cases (2a,b.2) Define Secure SubSystem + Collaboration Capable Subsystem (2c) Initial Information Security Design (2c.1) Define XML Schema Class Diagram (2c.2) Define Information Security Requirements Generated Functional, Collaborative & Information Secure System (4) Refinement of Functional, COD/AWF and Information Security Design (5) Combine Three Facets and Transition into Final Design (6) Mapping to Enforcement Code and XACML Policies (3a) Functional Security Design Define Security Features Group Users into Roles Separation of Duty, Delegation Authority Select MAC Features [NEEDS MAC] Security Refinement Process [DONE] [NOT DONE] Create Collaboration Workflow Name Create Collaboration Step/Workflow Security Refinement Process Collaboration Team Collaboration Obligation (3b) Collaboration Security Design [DONE] [NOT DONE] Define set of Roles with Information Access Determine Permissions of Roles to Information Create XML Role Slice Diagrams for each Role (3c) Information Security Design Security Refinement Process [DONE] [NOT DONE]

61. Security UML -61 Overall View – Initial Design (1)Main Security Design of the Application (2a,b) Initial Functional Security and Collaboration Design (2a,b.1) Define Functional Security and Collaboration Use Cases (2a,b.2) Define Secure SubSystem + Collaboration Capable Subsystem (2c) Initial Information Security Design (2c.1) Define XML Schema Class Diagram (2c.2) Define Information Security Requirements

62. Security UML -62 Overall View – Functional Security (3a) Functional Security Design Define Security Features Group Users into Roles Separation of Duty, Delegation Authority Select MAC Features [NEEDS MAC] Security Refinement Process [DONE] [NOT DONE]

63. Security UML -63 Overall View – Collaborative Security Create Collaboration Workflow Name Create Collaboration Step/Workflow Security Refinement Process Collaboration Team Collaboration Obligation (3b) Collaboration Security Design [DONE] [NOT DONE]

64. Security UML -64 Overall View – Information Security Define set of Roles with Information Access Determine Permissions of Roles to Information Create XML Role Slice Diagrams for each Role (3c) Information Security Design Security Refinement Process [DONE] [NOT DONE]

65. Security UML -65 Overall View – Refinement and Mappings Generated Functional, Collaborative & Information Secure System (4) Refinement of Functional, COD/AWF and Information Security Design (5) Combine Three Facets and Transition into Final Design (6) Mapping to Enforcement Code and XACML Policies

66. Security UML -66 Complete View (1)Main Security Design of the Application (2a,b) Initial Functional Security and Collaboration Design (2a,b.1) Define Functional Security and Collaboration Use Cases (2a,b.2) Define Secure SubSystem + Collaboration Capable Subsystem (2c) Initial Information Security Design (2c.1) Define XML Schema Class Diagram (2c.2) Define Information Security Requirements Generated Functional, Collaborative & Information Secure System (4) Refinement of Functional, COD/AWF and Information Security Design (5) Combine Three Facets and Transition into Final Design (6) Mapping to Enforcement Code and XACML Policies (3a) Functional Security Design Define Security Features Group Users into Roles Separation of Duty, Delegation Authority Select MAC Features [NEEDS MAC] Security Refinement Process [DONE] [NOT DONE] Create Collaboration Workflow Name Create Collaboration Step/Workflow Security Refinement Process Collaboration Team Collaboration Obligation (3b) Collaboration Security Design [DONE] [NOT DONE] Define set of Roles with Information Access Determine Permissions of Roles to Information Create XML Role Slice Diagrams for each Role (3c) Information Security Design Security Refinement Process [DONE] [NOT DONE]

67. Security UML -67 Other areas of interest for info security  Modeling of other access control models  Lattice Based Access Control (LBAC)  Attribute Based Access Control (ABAC)  Collaboration and adaptive workflows from the perspective of information security  Documents that are utilized by multiple roles/individuals at the same time  Hierarchically structured data with no validation agents  Specialized XML  JSON and JSON-LD  RDF  OWL