Security Analysis Design for UML Thuong Doan Jaime Pavlich-Mariscal

Скачать презентацию Security Analysis Design for UML Thuong Doan Jaime Pavlich-Mariscal

c8d00f100673b5be29966333f13eebfe.ppt

Количество слайдов: 166

Security Analysis/Design for UML Thuong Doan, 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 thuongdoan@yahoo. com jaime. pavlich@uconn. edu steve@cse. uconn. edu ldm@cse. uconn. edu Security UML -1

Motivation m Software Engineering q Phases of Requirements, Design, Implementation, Testing, Maintenance. Ø Effort: E. g. , 60% for Requirement & Design, 15% Implementation, and 25% Testing [Boehm 87] m Software Applications with Security Concerns q 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 [Mc. Graw 03] Ø Return on Security Investment (ROSI): 21% if Integrating at Design; 15% Implementation; 12% Testing [Hoo 01] Security UML -2

Motivation m Incorporating Security into UML Design q Object-Oriented Software Design: Ø Using the De Facto UML (Unified Modeling Language) [OMG 03], a Language for Specifying, Visualizing, Constructing, and Documenting Software Artifacts q 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 Security UML -3

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

Global Objectives m m Security Features from Design to Development q Extend UML to Support MAC, DAC, and RBAC q Security Properties (Simple Security, Strict *, etc. ) plus Constraint Checking (Mutual Exclusion) q New UML Diagram that Collects Security Design into a Logical, Well-Organized Abstraction q Automatic Generation of Security Enforcement Code Integrated with Application Maintain Security Information in Database q Track Design and Security State q Provide Single Locale for Security Definitions (Users, Roles, and their Authorized Privileges) q Serve as a Means to Support Run-Time Authentication Security UML -5

Detailed Objectives m m m Track Design State that Contains All Actions Related to Security and Application Definition Employ Functional Notation that Tracks All Actions and Maintains Historical Record Support Security Consistency and Assurance by q Security Checks as Design is Created/Change q Overall Security Analysis of Entire Design Security Abstraction that Collects Security Definitions q Cohesive and Coherent UML Diagram q Generated from Security Definitions Security Enforcement Code Generation q Aspect-Oriented Programming Approach q Security Code Integrated with Application Code Security UML -6

Overview of Remainder of Talk m m m Secure Software Design Principles of Secure Design Extending UML for Secure Design q UML Extensions for Security q Tracking Design and Security State q Security Assurance via Constraint Checking q Prototyping Effort Transition from Design to Development q Role Slice Diagram q Aspect Oriented Programming q Prototyping Effort Conclusions and Ongoing Research Security UML -7

Secure Software Design - Conceptual Extending UML for the Design and Definition of Security Requirements Address Security in Use-Case Diagrams, Class Diagrams, Sequence Diagrams, etc. Bi-Directional Translation – From Security Definitions (Extensions) to Underlying formal Functional Model Iterate, Revise Formal Security Policy Definition that Track Design State via a Functional Representation Must Prove Generation Captures all Security Requirements Many Alternative Security Model Solutions Security Model Generation RBAC 99 RBAC/MAC GMU/ UConn NIST (Distributed Security) Oracle Security Role Slice Diagram and AOP Security Enforcement Security UML -8

Secure Software Design - Architecture Customer’s Requirements Designer’s Input UML Diagrams UML Design Tool UML Diagrams Java Triggers Security Constraints Checking Module (Algorithm) Internal UML Structures Database Server Role Slice Extensions Aspect-Oriented Security Enforcement Code Generation Security UML -9

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

Principle 1 m The Software Design Has Multiple Iterative Phases and The Security Features Should Be Incorporated and Adjusted During Each of and Among Those Phases m Multiple Design Tiers: q 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 q Tier 2: Associating Classes Used in Use Cases Ø Choosing Needed Classes in Sequence Diagrams q Tier 3: Sequence Diagrams (and Other Diagrams) Ø Specify Messages (Methods Without Code) Between Objects Security UML -11

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

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

Principle 3 m m The Security Incorporating Process Should Neither Counter the Intuition nor Decrease the Productivity of the Software Designer q 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: q 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 q Post-Design: On-Demand Check Ø Security Compiler Executed on a Whole Design Security UML -14

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

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

Extending UML for Secure Design m m Work of Thuong Doan, Ph. D. student Defining a Framework for Assurance in Secure Software Design with UML q Capable of Capturing All of the Critical Security Requirements Ø Aligning Roles with Actors in Use-Case Diagram Ø Adding Security Properties and Constraints Checking Ø MAC, RBAC, and Lifetimes to Use-Case, Class, and Sequence Diagrams q q Simultaneously Tracking All of the States of a Design from a Security Perspective Maintaining the Security Assurance as Requirements/Designs are Defined and Changed Security UML -17

Extending UML for Secure Design m m m Extend “Most Utilized” UML Diagrams q Use Cases q Class q Sequence Diagram Security Extensions for Privileges and Authorization q MAC – Assignment of Security Levels to UML Entities (Use Cases, Actors, Class, Methods, etc. ) q RBAC – Alignment of “Actor” with “Role” q Lifetimes –Element or Association (ISA, include, extend, etc. ) Availability w. r. t. Security Real-Time Security Analysis q Maintain Design State q As Connections are Made, Check Security Privileges for their Consistency/Correctness Security UML -18

Extending UML for Secure Design Functional Model UML + Security Extensions Captured in Design State Checked in m Assumptions q Utilizing UML q Security Specifications q Communicating with the Customer Design Action Design Time Security Constraints Checker Security UML -19

Use-Case UML Extensions m m Security Levels q (TS, S, C, U) are Associated with Each Element (Use Case and Actor) q Levels are the Security Sensitivity for the Element Lifetimes q A Lifetime Represents the Availability of an Element with respect to Security Usage q Start and End Date/Time q End Date can be Infinite (no end) Connections q As Use Cases are Connected and Actors are Connected – Levels and Lifetimes are Checked q Consistency of Connections Checked First – Let’s Consider Extensions Informally … Security UML -20

Survey Management Example m m 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 Security UML -21

Use Case Diagram in UML m m A Survey Institution Manages Public Surveys Use Case Diagram for Creating a New Survey Entry Security UML -22

Use Case Diagram with Security Levels m Taking Security Concern q MAC: Security Level (e. g. U

UML Use Case Diagram with Security Levels m Taking Security Concern q MAC: Security Level (e. g. U

Extensions for Security + Lifetime m Actor Senior Staff is Represented as m Min = Max for Actors (“Senior Staff”, A, [“ 01/01/2005”, “ 12/31/2006”], S, S) Security UML -25

Extensions for Security + Lifetime m Use Case Add Survey Header is Represented As m Min = Max for Use Cases (“Add Survey Header”, UC, [“ 01/01/2005”, “ 12/31/2006”], S, S) Security Property of Use Case Add Survey Header Security UML -26

UML Class Diagram m m Security Levels q (TS, S, C, U) are Associated with Each Element (Class and Method) q Classes have Minimum and Maximum Levels Lifetimes q Classes and Methods have Start/End Date/Time q End Date can be Infinite (no end) Containment/Connections q All Methods of a Class Must have Security Level Between its Class’ Minimum and Maximum q As Classes are Connected – Levels and Lifetimes are Checked q Consistency of Connections Checked First – Let’s Consider Extensions Informally … Security UML -27

Survey Management Class Diagram Security UML -28

Extensions for Security + Lifetime m Min = Max for Methods Security Property of Class Survey_List Security Property of Method Add_Survey_Header Security UML -29

UML Use-Case Connections m m Relationships Track Dependencies Across Designs Two Groups of UML Connection Kinds q Group 1 – Explicitly in UML Ø Use Case/Actor (Role)/Class Inheritance: Child Inherits (Specializes) Parent Ø Use Case Inclusion/Extension: <> Ø Actor-Use Case Association: a Interacts with uc q Group 2 – Result of Tracking Use-Case/Class Interactions – For Each Use Case Track … Ø Classes Utilized to Implement the Use Case (Initial Phases of Design) Ø Methods of those Classes Utilized to Implement the Use Case (Later Phases of Design) Security UML -30

Group 1 Connections m m Use Case or Actor (Role) Inheritance: Child Inherits (Specializes) Parent q Child at Level or More Secure than Parent Use Case Inclusion/Extension: <> q X Includes Y: Y at Level or Less Secure than X q X Extends Y: X at Level or Less Secure than Y Actor-Use Case Association: q Actor A Interacts with UC X q A at Level or More Secure than X Connections Cause Detailed Checks q Not only Source and Destination of Connection q Also Must Check Related UCs and/or Actors Security UML -31

Use Case Group 1 Connections m m All Associations (Connections) Must Satisfy MAC Constraints on Prior Slide Intent – Keep Design in Correct/Consistent State Security UML -32

Group 2 Connections m m Secure Design with UML Requires the Ability to Establish Associations Between UML Use Case Diagrams are Relatively Independent In Sequence Diagrams, Actor and UC Can Interact with Classes (and Methods) – Not Required Group 2 Connections Provide Ability to Track q Classes and Methods Utilized to Implement a UC Security UML -33

Group 2 Connections: UC to Classes m Use Case-Class Utilization: uc Utilizes c q UC Add Survey Header Utilize Survey_List, Survey_Hdr_Add_Pg, and Survey_Header Classes q Means UC Add Survey Header Will Utilize Portions of those Classes for its Implementation q Again – Consistency Checks From UC to Classes Security UML -34

Survey Management Class Diagram Security UML -35

Group 2 Connections: UC to Methods m Use Case-Method Utilizing: uc Directly Utilizes m q UC Add Survey Header Utilizes Methods Ø on. Submit of Class Survey_Hdr_Add_Pg Ø Create_Survey_Header of Class Survey_Header Ø Add_Survey_Header, Survey_Title_Search, and Update_Survey_List of Class Survey_Header Security UML -36

Tracking Design and Security State m m Previous Slides Illustrate the Ability to Maintain a Correct “Security” State as Design Created/Changed Objective Now is to: q Define Design Security State q Formalize Prior Definitions of Security Level, Lifetime, UML Element, UML Connection q Introduce Security Constraint Hierarchy and Checking q Define Application’s Security Requirement q Formalize Constraint Checking w. r. t. Ø Disallowed Usage (Negative Permissions) Ø Mutual Exclusion (Excluding Actions by UML Elements within Time Periods) Security UML -37

Design State Space m How do we Represent and Keep Track of the Design States? Design Time 06/01/2006 One Can Consider the Design State As a Set of Design Elements 06/01/2005 Design Elements Time-Sensitive They have Lifetimes Security UML -38

Design State Space m Use Functional Model and Track Design Instances q State is a Function State Function si Design Element ID Design Time q si Design Element Contents Error Status Action is a (Meta)Function on States Design Action a si+1 Security UML -39

Security Model for UML Design m Extending UML with Security Features (MAC, RBAC and Lifetime) q Def. 3. 2. 1 (Security Level Set) Ø The Security Level Set (LSL): a Partial Ordered Set with Relation < where for l. SL and l. SL’ LSL, l. SL < l. SL’ Means that the Level l. SL’ has a Higher Security Concern that of l. SL q Def. 3. 2. 2 (Lifetime) Ø Let T be a Set of Discrete Time of the Form “month-day -year [hour: minute: second]” (As a Subset Cartesian Product of Sets of Integers), a Lifetime lt is a Time Interval [st, et] where et and st T are the Start Time and End Time (lt. st and lt. et), Respectively, with et st (the Point of Time st Occurs Not After et). Security UML -40

Extended UML Elements with Security m Augmenting UML Elements with Security Levels (SLs) and Lifetimes (LTs) m Formal Definition: q Def. 3. 2. 4 (UML Element) Ø = LID LEK I LSL : the Set of UML Elements Ø A UML element d: a Tuple (id, k, lt, slmin, slmax) where id, k, lt, slmin, and slmax are its Element Identification, Element Kind, Lifetime, Minimum and Maximum Security Levels (Denoted as d. id, d. k, d. lt, d. slmin and d. slmax) Ø For a Class c: c. slmin £ c. slmax; Other Non-Class Element: e. slmin = e. slmax = e. sl Example: (“Senior Staff”, A, [“ 01/01/2005”, “ 12/31/2006”], S, S) Security UML -41

Extended UML Connections with Security m m UML Connections Have Lifetimes Formal Definition: q Def. 3. 2. 6 (UML Connection) Ø = LID LCK I LID: the Set of UML Connections Ø A Connection : a Tuple (id, k, lt, ids, idt) where id, k, lt, ids and idt are the ID of the Connection, the Connection kind, Connection Lifetime, and the IDs of the Source and Target UML Elements (Denoted as . id, . k, . lt, . ids and . idt) m Example: q (“ 4”, AU_Asc, [“ 01/01/2005”, “ 12/31/2005”], “Senior Staff ”, “Add Survey Header ”) Security UML -42

Security Constraint m m Security as “Enforcing a Policy that Describes Rules for Accessing Resources. ” (Viega and Mc. Graw 2002) Considering Three Types of Security Constraint q MAC: Checking the Domination of Security Levels of Connected Elements q Lifetime: Checking the Temporal Window of Activity for Entities and Users. q RBAC: Maintaining the Interest Conflict-Free Working Environment for User Roles Security Constraint MAC Constraint RBAC Constraint Lifetime Constraint Security UML -43

Application’s Security Requirements m m Application’s Security Requirements have Lifetimes Formal Definition: q Def. 3. 2. 7 (Security Requirement for RBAC) Ø i = LID LSR I (LID)i (i= 2, 3, …) Ø An Application’s Security Requirement (SR) Involved In i elements: a Tuple (id, k, lt, h 1, h 2, …, hi) i where id, k, lt, h 1, h 2, …, and hi, are the ID Label (Denoted as . id), the Kind of the Security Requirement (. sk), the Lifetime (. lt), and the i Involved Element’s IDs (Denoting . els = {h 1, h 2, …, hi}), Respectively m SRs = 2 È 3, LSR = {Dis. U, MESRO, MESOR} q Dis. U: Disallowed Usage (Negative Permission) q MESRO and MESOR: Mutual Exclusions Security UML -44

Application’s Security Requirements m Disallowed Usage – Dis. U: Negative Permission q (id, Dis. U, lt, h 1, h 2) 2: Element h 1 is Not Allowed To Use Element h 2 During lt Ø E. g. (“SR 1”, Dis. U, [“ 01/01/2005”, “ 12/31/2006”], “Junior Staff ”, “Add Survey Header”) [“ 01/01/2005”, “ 12/31/2006”] Security UML -45

Application’s Security Requirements m Static Role-Objects Mutual Exclusion - MESRO q (id, MESRO, lt, h 1, h 2, h 3) 3: Actor h 1 is Not Allowed to Use Both Elements h 2 and h 3 During lt Ø E. g. (“SR 2”, MESRO, [“ 01/01/2005”, “ 12/31/2006”], “Junior Staff ”, “Add Question”, “Approve Question”) [“ 01/01/2005”, “ 12/31/2006”] Security UML -46

Application’s Security Requirements m Static Object-Roles Mutual Exclusion - MESOR q (id, MESOR, lt, h 1, h 2, h 3) 3: Actors h 1 and h 2 are Not Allowed to Use Element h 3 At the Same Time During lt Ø E. g. (“SR 3”, MESOR, [“ 01/01/2005”, “ 12/31/2006”], “Supervisor ”, “Editor”, “Activate/Deactivate Survey”) Security UML -47

Together Architect Plug-In The Interface to Enter a Security Requirement Enter the Static Role-Objects Mutual Exclusion that the Junior Staff Cannot Use Both “Add Question” and “Approve Question” Use Cases from 01/01/2005 to 12/31/2006. Security UML -48

Together Architect Plug-In The List of Security Requirements The Interface Allows to Add a New Security Requirement, Edit/Remove a Current Security Requirements, and Generate the Set of Current Security Requirements in Specified Formats. Security UML -49

Complete Security Constraint Taxonomy Security Constraint Lifetime Constraint RBAC Constraint MAC Constraint 2 -element Constraint 3 -element Constraint Disallowed Usage Mutual Exclusion Static Role-Objects ME n-element Constraint Static Object-Roles ME Security UML -50

Design State and Transitioning m m m State Function Provides the Transition from One Design State to Next When Given Design Action q Adding/Deleting/Modifying a UML Element q Adding/Deleting/Modifying a UML Connection Three Aspects of Design State Space q UML Elements q Application’s Security Requirements q UML Connections State Functions Triggered on Insertion, Deletion, etc. Security UML -51

Three Design State Spaces and Actions UML Element State Space Design Time Design Action Application’s Security Requirement State Space Design Action a si+1 Insert/Update/ Delete Security Constraint UML Connection Design State Space Security UML -52

$State Functions m m Extended Sets: ^ = {^} È , and ^ =$ State Functions m m Extended Sets: ^ = {^} È , and ^ = {^} È where ^ is the null Element Err ={0, 1, 2, …}: Set of Error Numbers with “ 0” As an Initial Value (for Initial State) and “ 1” As No Error q Def. 3. 3. 1 (State Function Signatures) Ø For UML Elements: s : LID T ^ Err UML Element ID Design Time s i UML Element Contents Error Status Ø For UML Connections: s : LID T ^ Err Ø For Security Requirements: s : LID T ^ Err m Design State i: (s i, s i) = Security UML -53

Inserting a UML Element m Status Function for UML Elements the Status of a UML Element h Based on the Current Set of Designed UML Elements L at the Design Time t Current UML Element Set UML Element ID Design Time q stat UML Element Contents Error Status Def. 3. 4. 3 (Status Function for UML Element Space): stat : 2 LID T ^ Err stat L h t = if L == then (^, 0) else let e L in // Pick an element e in L if e. id h then stat L{e} h t else intra_chk e t Security UML -54

Inserting a UML Element m intra_chk Function for the Intra-element Check on the Properties (Lifetime and Security Levels) of an UML Element at a Specific Time q Def. 3. 4. 2 (Intra-Element Checking for a UML Element) intra_chk. D: T ^ Err intra_chk d t = //d: the added UML element; t: the design time if d. lt. et £ t then (d, 2) // Error: the life time ended before the design time else if d. ek == Cl then // Adding a class if d. slmin £ d. slmax then (d, 1) // Return the applicable element without error else (d, 3) // Error: The SL max of a class must dominate its SL min else // adding a non-class if d. slmin == d. slmax then (d, 1) // Return the applicable element without error else (d, 4) // Error: The SL max of a non-class must be equal to its SL min Security UML -55

State Functions m Remember: q Design State Function Signature For UML Elements: s : LID T ^ Err UML Element ID Design Time q s i Status Function for UML Element Space: stat : 2 LID T ^ Err Current UML Element Set UML Element ID stat Design Time m UML Element Contents Error Status Cast the Form of s i Function as s i = (stat L i) h t q L i (=s i. set): The Set of Designed UML Elements in State i. Define L 0 = s 0. set = s 0= (^, 0) Security UML -56

Inserting a UML Element m m Function of Inserting a UML Element q Def. 3. 4. 4 (The Insert Action on UML Element Space): Ins : Ins si e = si+1 where s. Di+1 = stat. D (insert e s. Di. set), s i+1 = s i and s i+1 = s i Example: Design From Scratch (From State 0) q Add Use-Case uc 1: Add Survey Header, min SL = max SL = “S”, and LT = [“ 01/01/05”, “ 12/31/06”] Ø State 0: (s 0, s 0) = ((^, 0), (^, 0)) Ø State 1: s 1 º stat (insert uc 1 s 0. set) = stat (insert uc 1 ) = stat {uc 1}; s 1 = s 0 and s 1 = s 0 Ø s 1 uc 1 “ 06/15/05” = (stat {uc 1}) uc 1 “ 06/15/05” = ((Add Survey Header, UC, [01/01/05, 12/31/06], S, S), 1) Security UML -57

Status Function for UML Connections m Status of a UML Element h Based on the UML Element State s and the Current Set of Designed UML Connections L at the Design Time t q Def. 3. 4. 6 (Status Function for UML Connection Space): stat : 2 LID T ^ Err stat s L h t = if L == then (^, 0) else let e L in // Pick an element e in L if e. id h then stat s L{e} h t else intra_chk s e t Security UML -58

Inserting Action m Function of Inserting a UML Connection q Def. 3. 4. 7 (The Insert Action on UML Connection Space): Ins : Ins si e = si+1 where s i+1 = s i, s. Fi+1 = stat. F s. Di+1 (insert e s. Fi. set), and s i+1 = s i m Function of Inserting a Security Requirement q Def. 3. 4. 7 (The Insert Action on SR Space): Ins : Ins si e = si+1 where s i+1 = s i, and s. Qi+1 = stat. Q s. Di+1 (insert e s. Qi. set) m Deletion and Update of UML Elements Also Require Analogous Modification to the Design State Space Security UML -59

Recall Design Tiers and Design Process m Recall the three Prior Design Tiers q 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 q Tier 2: Associating Classes Used in Use Cases Ø Choosing Needed Classes in Sequence Diagrams q Tier 3: Sequence Diagrams (and Other Diagrams) Ø Specify Messages (Methods Without Code) Between Objects m m m Tiers Represent a Typical Design Process with UML Not Only Process – but One Scenario Objective is to Understand Placement of Security in the Process – Particularly w. r. t. Assurance Security UML -60

Security Constraints Checking m Three Security/Software Design Tiers for the UML q Tier 1: Use-Case Diagrams Intra-Checks q Tier 2: Classes Use-Cases Inter-Checks q Tier 3: Sequence Diagrams m Intra-Checks Occur within Individual UML Elements Inter-Checks for MAC/RBAC/Lifetime Constraints q Cstr. MAC: T Boolean q Cstr. RBAC: T Boolean q Cstr. LT: T Boolean q Lifetime Check at the Design Time: Necessary Condition q Also Checked at Run-Time in the Code Generated for Security Enforcement m Security UML -61

Security Constraints Checking m Inter-Element Check for MAC (Simple Sec/Integrity) q The MAC Constraint Cstr. MAC(si, , t) for a Connection from x to y Ø For a Connection (Not Use Case-Class and Class. Method Connection), x Utilizes y : x. SL y. SL MAC Satisfied Connection: Actor with Confidential Level can Utilize Use Case with Confidential Level Security UML -62

MAC Constraint Checking Enforcing MAC Constraint – Error Case Actor Staff with “C” Cannot Utilize Add Survey Header with “S” Security UML -63

Security Constraints Checking m Inter-Element Check for MAC q Use Case-Class Utilization: uc Utilizes c Ø The Security Level of Use Case uc Dominates the Minimum Security Level of Class c: uc. sl c. slmin Security UML -64

Security Constraints Checking m Inter-Element Check for MAC q Class-Method Defining: c Defines m Ø The Security Level of Method m is Between the Minimum and Maximum Security Levels of Class c: c. slmax m. sl c. slmin Ø Example: The SL of Method Add_Survey_Header as Secret is Between The Max (Secret) and Min (Confidential) SLs of the Class Survey_List Security Property of Method Add_Survey_Header Security Property of Class Survey_List Security UML -65

Security Constraints Checking m Inter-Element Check for Lifetime q The Lifetime Constraint Cstr. LT(si, , t) for a Connection from x to y at t Ø x Utilizes y: Work Time WT = . lt x. lt y. lt and Ø t < WT. et (= The end time of Work Time) [1/1/06, 12/31/07] [1/1/05, 12/31/08] Lifetime Satisfied Connection at t = “ 1/15/06” < WT. et = “ 12/31/07” Security UML -66

Security Constraints Checking m Inter-Element Check for RBAC q The RBAC Constraint Cstr. RBAC(si, , t) for a Security Requirement Ø Dis. Allowed Usage: (id, Dis. U, lt, h 1, h 2) 2: No Path h 1 h 2 from Element h 1 to Element h 2 During lt Ø Static Role-Objects Mutual Exclusion: (id, MESRO, lt, h 1, h 2, h 3) 3: The Path Coverage (i. e. All the Paths) from h 1 Actor h 1 Cannot Contain Elements h 2 and h 3 During lt h 3 Ø Static Object-Roles Mutual Exclusion: (id, MESOR, lt, h 1, h 2, h 3) 3: Element h 3 is NOT in the Intersection of h 1 two Path Coverages from Actor h 1 and Actos h 2 During h 3 lt h 2 Security UML -67

Towards Security Assurance m m m When is Design Acceptable with Respect to Security? q Define Security Compliance Properties q Represents Constraints that Must Hold as Design is Created and Modified Does the Design have Expected Security Properties? q Security Conformity Support Program q Design-Time and Post-Design Modes Goal: q Each Design Element is Legitimate to Use via Intra -Checks q All Application's Security Requirements Hold via Inter-Checks at a Design Time t Security UML -68

Towards Security Assurance m Design-Time Checking q As Discussed so Far, Security Checks Occur as Design is Created and Modified q However – Design Can be Too Complicated to Develop without Constant Nagging Error q In Use Case – Perhaps any Remaining Connections will Cause Errors q However – Designer May Intend to Make Changes to Remove Problems in Later Design Iterations q Need the Ability to Turn off Design-Time Checking q Result: Require Checking of Design Iterations Security UML -69

Towards Security Assurance m Post-Design Checking q Turn off Design-Time Security Checking q Initiated by Security Designer q Allows Design to be in an Inconsistent State w. r. t. Security Compliance and Conformity q Design State is Still Tracked Ø Represents All Design Actions Ø Can Track All Security Errors Ø Doesn’t Report Errors q At Certain Design Milestones (Iterations) Ø Designer can Initiate Post Design Checking Ø Comprehensive Intra- and Inter- Check Across the Entire Design Instance Security UML -70

Security Compliance Properties m A Design State si = (s i, s i) is said to Be q Admissible at Design Time t if Every Design Element in s i, and s i Evaluates to be Applicable at t q q q MAC/LT Constraint-Compliant at Design Time t if si is Admissible and for Every UML Connection in s i, Cstr. MAC/ Cstr. LT(si, , t) Yields true at t RBAC Constraint-Compliant at Design Time t if si is Admissible and for Every Application's Security Constraint in s i, Cstr. RBAC(si, θ, t) Yields true at t Security Constraint-Compliant at Design Time t if si is MAC, LT and RBAC Constraint-Compliant Security UML -71

Security Conformity Design Support m m Security Conformity Design Support (SCDS) Program For Design-Time Mode PDT q Designer’s Action Event Trigger Security Constraint Check on the Current State & Design Time Materialize Connection | Error Ø Materialize Connection: Update GUI and Design Space m For Post-Design Mode PPD q Simulate Designer’s Actions at a Design Time Ø Connections with Non-Actors (MAC and Lifetime Check Only) Ø Connections of Actor-Use-Case then Actor Inheritance Security UML -72

Design-Time Checking Th e. C on nec tio ni s. R em ov ed Design-Time Checking: MAC Constraint Violation Security UML -73

Together Architect Plug-In Turning the MAC Design-Time Checking On/Off Security UML -74

Post-Design Checking - Error Case MAC Violation Security UML -75

Security Conformity Design Support m SCDS Program for Design-Time Mode PDT q Intended to be Active within the Design Environment PDT(s: , t: T){ // s is the beginning security constraint-compliant state // t is the design time specified by the designer snow = s err_no = 0 // No error is defined yet while designer performs action a on e = Response(a, e, snow, t) if err_no 1 then Report. Error(err_no) else {Materialize e in the design snow = stemp} end while } Security UML -76

Security Conformity Design Support m Example of a Design State Construction Process q Use Case Diagram for Creating a New Survey Entry Security UML -77

Security Conformity Design Support m Example of a Design State Construction Process q Use Case Diagram for Creating a New Survey Entry Security UML -78

Security Conformity Design Support m Example of a Design State Construction Process q Use Case Diagram for Creating a New Survey Entry Security UML -79

Security Conformity Design Support m Example of a Design State Construction Process q Use Case Diagram for Creating a New Survey Entry Security UML -80

Security Conformity Design Support m Example of a Design State Construction Process q Use Case Diagram for Creating a New Survey Entry Security UML -81

Algorithmic Complexity Discussion m m m The Design-Time Security Conformity Support Program PDT q Check Performed whenever a UML Element, UML Connection or SR is Created/Modified q Checks Occur in the UML Design Tool q Reasonable Computational Cost So As to Not Add Overhead to the Design Process The Post-Design Security Conformity Support Program PPD q When Designs Become More Complex, or are Partially Checked (Imported) q Employed at Design Iterations to Check the Whole Design (at Some Milestone/version) A Graph Traverse Problem on UML Connections Security UML -82

Prototyping Effort m m Together Architect (TA): UML Tool with Open APIs for JAVA and a Modular Plug-in Structure q Thanks to Andy, Phil, Frank, and Vijaya, et al. q TA Allows Our Own Custom Code to be Added q Custom Code for MAC/RBAC/LT Constraints q Provides a Tool for Secure Software Design On-Going Prototyping Effort Supports q Definition of SLs and LTs, for Use-cases, Actors, Classes, and Methods and Constraints into TA q Security Level Analyses for UML Designs Ø Real-Time as Design is Created and Modified Ø Post-Design for Design Iterations/Increments q Generation of Comments that Capture Defined Security - Longer Term to Generate Secure Code Security UML -83

Together Architect (TA) Plug-In The Modified Inspector Panel of TA Assigning Lifetime and Security Levels to Actor Staff Security UML -84

Together Architect Plug-In Turning the MAC Design-Time Checking On/Off Security UML -87

Design-Time Checking Th e. C on nec tio ni s. R em ov ed Design-Time Checking: MAC Constraint Violation Security UML -88

Post-Design Checking: No Constraint Violation Security UML -89

Post-Design Checking - Error Case MAC Violation Security UML -90

Retrospective on Work m m Visual/Non-Visual Modeling Extensions for RBAC, MAC, & Lifetimes in UML q Extensions Integrate Security Requirements, RBAC, MAC, and Lifetimes, into Design Phase Formal Functional Model for Security/Non-Security Design Features/State q Formal Functional Model Capturing the Security & Non-security Features of an Application’s Design q Track the Design State Retaining Design Time As a Parameter q Convenient for Time-Sensitive Applications with Lifetime Constraints q “Design Once, Re-use Many Times” - Advanced Step for the Style “Write Once, Run Anywhere” Security UML -91

Retrospective on Work m Strong Security Assurance (on MAC/LT/RBAC) q Design-time and Post-design Algorithms Against MAC, Lifetime, and RBAC Constraints q Disallowed Usage and Mutual Exclusions q Two Main Important Effects Ø Immediately Expose Security Flaws of the Design in Design by Discovering the Security Violation Ø Provide a Degree of Security Assurance for the Design Delivery to be Transferred to the Subsequent Phases q Potential Result: Reducing the Cost of Repairing Errors in the Life Cycle Security UML -92

Transition from Design to Development m m Work of Jaime Pavlich-Mariscal, Ph. D. student Security Privileges in UML Extensions Capture Security Across the Entire Design for UML Elements However, this Information is Scattered and Not Captured into a Single, Manageable Abstraction To Transition from Design to Development … q Role-Slice Diagram Contains a Combined Privilege Perspective Across Entire Application q Single, Well Defined, Abstraction that is Created by Using the UML + Security Design and Supports Ø Automatic Generation of Aspect-Oriented Programming Enforcement Code Ø Composable Security Definitions to Customize Security on Application by Application Basis Security UML -93

Introduction Customer’s Requirements Designer’s Input UML Diagrams [Components] UML Design Tool UML Diagrams Triggers Security Constraints Checking Module Internal UML Structures Database Server Role Slice Extensions Aspect-Oriented Security Enforcement Code Generation Security UML -94

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

Principle 3 m m The Security Incorporating Process Should Neither Counter the Intuition Nor Decrease the Productivity of the Stakeholders How is Principle 3 Attained? q UML Extensions are Relatively Seamless in their Definition (Properties for MAC, Lifetimes, etc. ) q Role Slices Ø A New Abstraction that Differentiates Security and Non -Security Capabilities Ø Specialized Class Diagram Consistent with UML Ø Allows Security Engineer to Work Independent of Software Engineers Ø Generate Security Code without User Intervention Security UML -96

Objective and Approach m Objective q Propose and Design Techniques that Integrate Security Concerns into the Software Process. Ø MAC, RBAC, and DAC (Delegation) Ø Lifetime of Access Ø Authentication Ø Logging m Approach Introduces the “Role-Slice Diagram” q 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 Security UML -98

Recall Survey Management Example m m 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 Security UML -99

Survey Management Example Security UML -100

Survey Management Class Diagram Security UML -101

Simplified Class Model of the Survey Application Security UML -102

Defining a Secure Subsystem m m We do not Want to Define Security over Every Class in the System Security is Defined over a Secure Subsystem q Represents those Classes on Which Privileges will be Defined Secure Subsystem Security UML -103

Integration with Doan’s work m m Each Use Case is Associated to a Set of Methods Secure Subsystem q Defined as the Set of All Classes whose Methods are Associated to at Least One Use Case Secure Subsystem Secure Methods Security UML -104

Defining Access Control Policy m A Role Slice is a Specialized Class Diagram that Represents Permissions for the RBAC Model q Roles are Represented as Packages q Permissions are Represented as Stereotyped Methods q Role Hierarchy is Represented by a Stereotyped Dependency Relation Security UML -105

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

Recall the Transition Secure Subsystem Security UML -107

Framework Overview m m m Applicationspecific Model Concern-specific Composable Units Implementation of the Application Implementation of Concerns Composition into the Final Application Security UML -108

Framework Overview m Role-Slice Extensions m Aspect-Oriented Security Enforcement Code Generation Security UML -109

Role-Slice Policy Security UML -110

Integration with Doan’s Work m Roles and Hierarchies Role Hierarchy Relation Security UML -111

Integration with Doan’s work m Permissions q The Set of Use Cases Allowed to an Actor Defines the Methods Allowed to the Corresponding Role Authorized Methods Security UML -112

Composition of Role Slices m To Obtain the Final Set of Permissions q Positive Permissions are Inherited by Child Role Slices from their Parents q Negative Permissions are Used to Override Permissions that are Positive in Parent Role Slices Security UML -113

Step Back to Formalize m m m Approach so Far Demonstrates the Ideas and Transitions q UML Secure Design (Doan’s Work) to q Secure Subsystem (UC-Classes Relationship) to q Role Slices (Actor-UC-Method Relationship) We’ll Proceed to Formal Definitions of each Concept Formalizations will be Kept as Simple as Possible q Several Elements whose Details are not Relevant to our Approach will be Abstracted q Elements that are not Referenced by the Definitions will be Purposefully Omitted Security UML -114

Basic Object-Oriented Definitions m m Represent Application Structure (Design) and Dependencies Among UML Elements Dependencies Include Static Method Call Graph (needed for Code Generation) Application Classes Inheritance relationships Methods Implementation Method Invocations Security UML -115

Methods m m m Method Abstracted as Method Invocation Sequence q Worst Case (All Methods that May be Called) Formally a Method is a Record q name: Name of the Method q impl: Its Implementation Individual Method Invocation is a Record q m: Invoked method q s: The Environment q arg: Arguments of the Method Security UML -116

Class and Application m m Methods are Grouped into Classes q Attributes are Excluded from the Definition q Not a Part of Access Control Model as Yet Classes are Grouped into an Application An Application also Groups all the Inheritance Relations Between classes An Application is a Record q C: Set of Classes of the Application q H: Inheritance Relation Between Classes in C Security UML -117

Subsystem m A Subsystem is a Subset of an Application Formally a Subsystem of an Application is a Record q SC C q SH is the Projection of H onto SC Differentiate Secure and Non-Secure Portions q Secure Subsystem Definitions Ø Method Invocations are Intercepted for Security q All Rest – Un-Secure Ø Don’t Care from Security Perspective Ø Method Invocations to Non-Secure Portions of the Application Proceed without Intervention Security UML -118

Program Execution m m m Program Execution must be Carefully Controlled to for the Intervention of Method Invocations q Carried out by an Interpreter Function that Chains Method Invocations to Object Instances q Some Invocations Proceed without Intervention q Others (Secure Subsystem) must be Intercepted An Structure Called Environment is Used to Keep Track of the State of Variables Environment Tracks: q Return Value of a Method q Active User Credentials (Active/Authenticated Role) q Access Control Policy (Roles and Role Hierarchy) q Exit Value of the Program Security UML -119

Interpreter Function m m m Traverses the Application Structure and Executes All of its Instructions Formally, a Function I : M→S →Arg →N that Takes as Input q M: Method q S: Environment (see Previous Slide) q Arg: Argument (Can be a Tuple of Values) Outputs: q N: Exit Status (Natural Number) which Denotes Success or Failure Security UML -120

Environment Function m m m Utilized as a Storage for all the Information (e. g. , Variables) Used During Application’s Execution Formally is a Function S : Id → T that Associates an Identifier Id (e. g. a String) to an Object of Type T q [‘active. Role’ → R, ‘exit’ → R, ‘policy’ → P] q ‘exit’ is Value of Application (previous slide) Environment Can Also Store Return Value of Method q [‘return. Value’ → 5] Security UML -121

Simplified Class Model of the Survey Application Security UML -122

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 Security UML -123

Integration with Doan’s work m m Each Use Case is Associated to a Set of Methods Secure Subsystem q Is Defined as the Set of All Classes whose Methods are Associated to at Least One Use Case Secure Subsystem Secure Methods Security UML -124

Formalizing Role Slices m m A Role Slice is a Unified Abstraction to Specify Who Can do What w. r. t. Roles Against Methods q Generated from Earlier Secure UML Design q Created from Scratch by Security Designer A Role Slice is a Record q PP: Set of Methods with Positive Permissions q NP: Set of Methods with Negative Permissions q abstract: Indicates whether the Role Slice is Abstract or Concrete Security UML -126

Formalizing Access Control Policy m m Access Control Policy is Defined by All the Role Slices in the Model and their Inheritance Relationships An Access-control Policy is a Record q RS: Set of Role Slices Defined over Subsystem S q CR RS: Role-Slice Composition Relation that Defines the Role Hierarchy Ø Each pair in CR is of the form , where a is the Child Role Slice and b is the Parent Role Slice Security UML -127

Formal Role-Slice Policy Security UML -128

Integration with Doan’s Work m Roles and Hierarchies Role Hierarchy Relation Security UML -129

Integration with Doan’s work m Permissions q The Set of Use Cases Allowed to an Actor Defines the Methods Allowed to the Corresponding Role Authorized Methods Security UML -130

The Ancestors Function m m Ancestors is a Convenience Function that Obtains all the Ancestors of a Role Slice in a Hierarchy Ancestors (anc) is a Function with Arguments: q A Role Slice RS q A Role-slice Composition Relation CR q An ordering relation < derived from cr Ancestors Outputs an Ordered Set of Role Slices that are Ancestors of rs anc = λrs. λcr. λ<. ({a: cr+}, <) q The Elements are Ordered According to their Distance to rs in the Role Hierarchy Security UML -132

Vertical Composition m m Vertical Composition is a Function that Performs Composition Between Child and Parent Role Slices Formally, Vertical Composition (vc) is a Function q Takes Two Role Slices as Arguments q Outputs a New Role Slice that Combines Permissions of Both q q The Set Difference Operation () is Used to Override Permissions Ø If a Permission is Positive in the Parent, it Can be Overridden as Negative in The Child, and Vice Versa Security UML -133

Formalizing Full Composition m m m Full Composition Function Uses the two Previous Functions to Perform a Composition of a Role Slice with all its Ancestors Full Composition is a Function with Arguments: q The Vertical Composition Function vc q A Role Slice rs q A Composition Relation cr It Outputs the Role Slice rs Composed with All of its Ancestors m Security UML -134

Composed Role Slices Security UML -135

Another Example Security UML -136

Role Slice Diagram Security UML -137

Composed Role Slices Security UML -138

Mapping to Security Enforcement Code m m 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) Security UML -139

What is AOSD/AOP? m Jump to Companion Presentation Security UML -140

AOP Security Enforcement Code Generation m m Code Generator takes a Role Slice Specification as Input and Outputs: q An Access Control Aspect q A Policy Database AOP + Policy DB Provides Means for Changing Access Control without Recompiling Code Security UML -141

Aspect-Oriented Definitions m m To Formalize the Mapping, it is Necessary to Define Basic Aspect-oriented Concepts q Definitions are Simplified q Formalizes the Ideas in Companion Presentation A Point Cut is Represented as a Record q caller is a Method where all Invocations of callee must be Modified to Include the Aspect Code An Advice is a Record q PC: a Point Cut q T: Rewriting Function that Modifies the Method Invocations Specified in PC An Aspect is a Set of Advices Security UML -142

Aspect-Oriented Definitions Security UML -143

Weaving Function m m Weaving is the Process by Which we can Integrate Aspects into Application’s Code q Customizable q Only Weave Aspects that are Desired Weaving Function W: App → App takes as Input an Application and an Aspect and Outputs q Application with All the Advices of the Aspect Woven to its Structure Security UML -144

Weaving Algorithm m Weaving Algorithm Applies Each Rewriting Function at the Join Points Specified by the Corresponding Point Cut Security UML -145

Enforcing an Access Control Policy using AOP m Access-Control Aspect m Login Advice q References any Call to the login Method q For this Example, we assume that there Exists a login Method that Returns a Tuple Ø u is the User who logged in, and r is his/her Active Role q Rewriting Function Obtains the Active Role and Stores it in the Environment Security UML -146

Enforcing an Access Control Policy using AOP m Access-control Enforcement Advice q Intercepts Every Call that Comes from Outside to Inside the Secure Subsystem subs q Rewriting Function Changes the Target Method to Add Access-control Checking Security UML -147

Example for the Survey Management Application m Join Points Depend on the External/Internal Methods m Suppose that One of the Methods is Defined as: q Where the Variable slist is Supposed to be an Instance of Survey_List Security UML -148

Example Courseware Application m Functional Implementation of the Invocation to the Method Survey_Title_Search from Get_General_Statistics after the Weaving: Security UML -149

Prototyping Effort - Role-slice Inspector m A Plugin for Together Architect that Generates a Role Slice from the Information of an Actor q Defines whether the Role is Abstract or Not q Shows the Role Slice Associated to the Selected Actor Security UML -150

Prototyping Effort - Role-slice Inspector m Role-slice View of Actor Staff Security UML -151

Prototyping Effort – Code Generator m Uses the Role Slice Information to Generate Enforcement Code in Aspect. J Security UML -152

Prototyping Effort – Code Generator m Generation of the Aspect. J File Access. Control. java Security UML -153

Prototyping Effort – Code Generator m Generated Aspect. J File Security UML -154

Prototyping Effort – Code Generator m Generated Code q Obtaining the Active User public aspect Access. Control { pointcut login(): call(User Security. Admin. log. In(. . )); User around(): login() { User u = proceed(); active. User. set(u); return u; } private Thread. Local active. User = new Thread. Local() { protected Object initial. Value() {return null; } }; private User get. Active. User() { return (User)active. User. get(); }. . . } Security UML -155

Prototyping Effort – Code Generator m Checking Permissions public aspect Access. Control {. . . pointcut external. Call() : (call(* Survey_List. *(. . )) || call(* Survey_Header. *(. . ))) && !within(Survey_List) && !within(Survey_Header); before() : external. Call() { Role r = get. Active. User(). get. Active. Role(); if (!r. has. Pos. Permission(this. Join. Point. Static. Part)) { throw new org. aspectj. lang. Soft. Exception( new Permission. Denied. Exception()); } } } Security UML -156

Retrospective on Role Slices + AOP m m We Presented an Approach to Preserve Separation of Security Concerns Separation of Concerns at the Model Level q Role-slice Notation Ø Helps in the Conceptualization of a Method-based Security Policy Ø Facilitates its Evolution During the Design Process. m Separation of Concerns at the Code Level q Mapping from a Role-slice Diagram to AOP Enforcement Code Ø Provides a Seamless Transition from Security Specification to Code Ø Isolates Access Control in an Aspect. Security UML -157

Conclusions and Future/Ongoing Work m We are Currently Working in Improving the Role-slice Model q Dynamic Permissions: Permissions Constrained on Runtime Elements q Adding Support for Other Security Policies Ø Mandatory Access Control Ø Delegation q Software Prototype Ø Integration of Role Slices and Previous Work of Doan et al. Security UML -158

Overall Work: Available Technologies m m Work of Both Doan and Pavlich Java Data Structures and Algorithms q Data Structure to Capture and Track an Entire UML Design and its Current (Past) States q Security Algorithms for: Ø Design-Time Checks of Security Ø Post-Design Check of Entire UML Design q Role-Slice Algorithms for: Ø Composition of Security Privileges Ø Generation of AOP Security Enforcement Code Oracle Database for Persistently Storing Design Plug-ins for Together Architect 1. 1 q m Security UML -159

Current Ongoing Prototyping m m m Together Architect 1. 1 q Transitioning Software from Together Control Center 6. 2 into Together Architect 1. 1 q Integrating Multiple Versions into one Prototype q Role-Slice Diagram as a New Diagram Eclipse UML q Exploring the Potential of a Simultaneous Prototyping Effort in Eclipse UML q Looking to Transition the Ideas over Upcoming Semesters Rhapsody by I-Logix – Embedded UML Tool q Explore the Integration with another Platform q Transition Data Structures/Algorithms to C++ Security UML -160

UConn’s Three-Pronged Security Emphasis Secure Software Design via UML and AOP with MAC/RBAC Secure Information Exchange via XML with MAC/RBAC Assurance RBAC, Delegation MAC Properties: Simple Integrity, Simple Security, etc. Safety Liveness Secure MAC/RBAC via Middleware (Service Oriented Arch) in Distributed Setting Security UML -161

Other Ongoing Research at UConn m UML with Security, Performance, and Reliability (Demurjian, Ammar, Rajasakeran, Gokhale, Michel) m Intrusion Detection via Application Data (Demurjian, Rajasakeran, Gokhale, Michel) m Middleware-Based Security – SOA (Demurjian) m Security for XML (Demurjian) Security UML -162

UML + Security + Reliability + Performance Security UML -163

Intrusion Detection via Application Data Security UML -164

Middleware-Based Security - SOA m m m Artifacts: DB, Legacy, COTS, GOTS, with APIs Database New/Existing Clients use APIs Can we Control Access to APIs (Methods) by … Database Client q Role (who) q Classification (MAC) Java q Time (when) Client q Data (what) q Delegation Working SOA Prototype using CORBA, JINI, Java, Oracle Security Policy Client (SPC) COTS Client Legacy COTS Legacy Client GOTS NETWORK Security Authorization Client (SAC) Security Delegation Client (SDC) Unified Security Resource (USR) Security Policy Services Security Authorization Services Security Registration Services Security Analysis and Tracking (SAT) Security UML -165

Security for XML m m Emergence of XML for Document/Information Exchange Extend RBAC/MAC to XML q Collection of Security DTDs Ø DTDs for Roles, Users, and Constraints Ø Capture RBAC and MAC q Apply Security DTDs to XML Documents Ø An XML Document Appears Differently Based on Role, MAC, Time, Value Ø Security DTD Filters Document Security DTDs n Role DTD n User DTD n Constraint DTD Security Officer Generates Security XML files for the Application DTDs and XML Application DTDs Application XML Files Appl_Role. xml Appl _User. xml Appl_Constraint. xml Application User’s Role Determines the Scope of Access to Each XML Document Security UML -166