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

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]
Security UML -2
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
Security UML -3
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
Security UML -4
Global Objectives


Security Features from Design to Development
 Extend UML to Support MAC, DAC, and RBAC
 Security Properties (Simple Security, Strict *, etc.)
plus Constraint Checking (Mutual Exclusion)
 New UML Diagram that Collects Security Design
into a Logical, Well-Organized Abstraction
 Automatic Generation of Security Enforcement
Code Integrated with Application
Maintain Security Information in Database
 Track Design and Security State
 Provide Single Locale for Security Definitions
(Users, Roles, and their Authorized Privileges)
 Serve as a Means to Support Run-Time
Authentication
Security UML -5
Detailed Objectives





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
 Security Checks as Design is Created/Change
 Overall Security Analysis of Entire Design
Security Abstraction that Collects Security Definitions
 Cohesive and Coherent UML Diagram
 Generated from Security Definitions
Security Enforcement Code Generation
 Aspect-Oriented Programming Approach
 Security Code Integrated with Application Code
Security UML -6
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
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
RBAC99 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




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
Security UML -10
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
Security UML -11
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
Security UML -12
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
Security UML -13
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
Security UML -14
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
Security UML -15
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
Security UML -16
Extending UML for Secure Design


Work of Thuong Doan, Ph.D. student
Defining a Framework for Assurance in Secure
Software Design with UML
 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


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



Extend “Most Utilized” UML Diagrams
 Use Cases
 Class
 Sequence Diagram
Security Extensions for Privileges and Authorization
 MAC – Assignment of Security Levels to UML
Entities (Use Cases, Actors, Class, Methods, etc.)
 RBAC – Alignment of “Actor” with “Role”
 Lifetimes –Element or Association (ISA, include,
extend, etc.) Availability w.r.t. Security
Real-Time Security Analysis
 Maintain Design State
 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

Assumptions
 Utilizing UML
 Security
Specifications
 Communicating
with the Customer
Design
Action

Design Time
Security
Constraints
Checker
Security UML -19
Use-Case UML Extensions




Security Levels
 (TS, S, C, U) are Associated with Each Element
(Use Case and Actor)
 Levels are the Security Sensitivity for the Element
Lifetimes
 A Lifetime Represents the Availability of an
Element with respect to Security Usage
 Start and End Date/Time
 End Date can be Infinite (no end)
Connections
 As Use Cases are Connected and Actors are
Connected – Levels and Lifetimes are Checked
 Consistency of Connections Checked
First – Let’s Consider Extensions Informally …
Security UML -20
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
Security UML -21
Use Case Diagram in UML


A Survey Institution Manages Public Surveys
Use Case Diagram for Creating a New Survey Entry
Security UML -22
Use Case Diagram with Security Levels

Taking Security Concern
 MAC: Security Level (e.g. U<C<S<TS) Assigned
for Elements (Use Cases and Actors)
Valid Connection:
Actor with Confidential Level can Utilize
Use Case with Confidential Level
Security UML -23
UML Use Case Diagram with Security Levels

Taking Security Concern
 MAC: Security Level (e.g. U<C<S<TS) Assigned
for Elements
Invalid Connection:
Actor with Confidential Level cannot
Utilize Use Case with Secret Level
Security UML -24
Extensions for Security + Lifetime

Actor Senior Staff is Represented as
(“Senior Staff”, A,
[“01/01/2005”,“12/31/2006”], S, S)

Min = Max for Actors
Security UML -25
Extensions for Security + Lifetime

Use Case Add Survey Header is Represented As
(“Add Survey Header”, UC,
[“01/01/2005”, “12/31/2006”], S, S)

Min = Max for Use Cases
Security Property of Use
Case Add Survey Header
Security UML -26
UML Class Diagram




Security Levels
 (TS, S, C, U) are Associated with Each Element
(Class and Method)
 Classes have Minimum and Maximum Levels
Lifetimes
 Classes and Methods have Start/End Date/Time
 End Date can be Infinite (no end)
Containment/Connections
 All Methods of a Class Must have Security Level
Between its Class’ Minimum and Maximum
 As Classes are Connected – Levels and Lifetimes
are Checked
 Consistency of Connections Checked
First – Let’s Consider Extensions Informally …
Security UML -27
Survey Management Class Diagram
Security UML -28
Extensions for Security + Lifetime

Min = Max for Methods
Security Property of
Class Survey_List
Security Property of Method
Add_Survey_Header
Security UML -29
UML Use-Case Connections


Relationships Track Dependencies Across Designs
Two Groups of UML Connection Kinds

Group 1 – Explicitly in UML
 Use Case/Actor (Role)/Class Inheritance: Child Inherits
(Specializes) Parent
 Use Case Inclusion/Extension: <<Include / Extend>>
 Actor-Use Case Association:a Interacts with uc

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




Use Case or Actor (Role) Inheritance: Child Inherits
(Specializes) Parent
 Child at Level or More Secure than Parent
Use Case Inclusion/Extension: <<Include / Extend>>
 X Includes Y: Y at Level or Less Secure than X
 X Extends Y: X at Level or Less Secure than Y
Actor-Use Case Association:
 Actor A Interacts with UC X
 A at Level or More Secure than X
Connections Cause Detailed Checks
 Not only Source and Destination of Connection
 Also Must Check Related UCs and/or Actors
Security UML -31
Use Case Group 1 Connections


All Associations (Connections) Must Satisfy MAC
Constraints on Prior Slide
Intent – Keep Design in Correct/Consistent State
Security UML -32
Group 2 Connections




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
 Classes and Methods Utilized to Implement a UC
Security UML -33
Group 2 Connections: UC to Classes

Use Case-Class Utilization: uc Utilizes c
 UC Add Survey Header Utilize Survey_List,
Survey_Hdr_Add_Pg, and Survey_Header Classes
 Means UC Add Survey Header Will Utilize
Portions of those Classes for its Implementation
 Again – Consistency Checks From UC to Classes
Security UML -34
Survey Management Class Diagram
Security UML -35
Group 2 Connections: UC to Methods

Use Case-Method Utilizing: uc Directly Utilizes m
 UC Add Survey Header Utilizes Methods
 onSubmit 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


Previous Slides Illustrate the Ability to Maintain a
Correct “Security” State as Design Created/Changed
Objective Now is to:
 Define Design Security State
 Formalize Prior Definitions of Security Level,
Lifetime, UML Element, UML Connection
 Introduce Security Constraint Hierarchy and
Checking
 Define Application’s Security Requirement
 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

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

Use Functional Model and Track Design Instances
 State is a Function
State Function si
Design Element ID
Design Time

si
Design Element Contents
Error Status
Action is a (Meta)Function on States
Design Action a
si
a
si+1
Security UML -39
Security Model for UML Design

Extending UML with Security Features (MAC, RBAC
and Lifetime)
 Def. 3.2.1 (Security Level Set)
 The Security Level Set (LSL): a Partial Ordered Set with
Relation < where for lSL and lSL’  LSL, lSL < lSL’
Means that the Level lSL’ has a Higher Security
Concern than that of lSL

Def. 3.2.2 (Lifetime)
 Let T be a Set of Discrete Time of the Form “monthday-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

Augmenting UML Elements with Security Levels
(SLs) and Lifetimes (LTs)

Formal Definition:
 Def. 3.2.4 (UML Element)
 D = LIDLEKILSLLSL : the Set of UML Elements
 A UML element d: a Tuple (id, k, lt, slmin, slmax)  D
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


UML Connections Have Lifetimes
Formal Definition:
 Def. 3.2.6 (UML Connection)
 F = LIDLCKILIDLID: the Set of UML Connections
 A Connection j: a Tuple (id, k, lt, ids, idt) F 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 j.id,
j.k, j.lt, j.ids and j.idt)

Example:
 (“j4”, AU_Asc, [“01/01/2005”, “12/31/2005”],
“Senior Staff ”, “Add Survey Header ”)
Security UML -42
Security Constraint


Security as “Enforcing a Policy that Describes Rules
for Accessing Resources.” (Viega and McGraw 2002)
Considering Three Types of Security Constraint
 MAC: Checking the Domination of Security
Levels of Connected Elements
 Lifetime: Checking the Temporal Window of
Activity for Entities and Users.
 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


Application’s Security Requirements have Lifetimes
Formal Definition:
 Def. 3.2.7 (Security Requirement for RBAC)
 Qi = LIDLSRI (LID)i (i= 2, 3,…)
 An Application’s Security Requirement (SR) q Involved
In i elements: a Tuple (id, k, lt, h1, h2,…, hi)  Qi
where id, k, lt, h1, h2,…, and hi, are the ID Label
(Denoted as q.id), the Kind of the Security Requirement
(q.sk), the Lifetime (j.lt), and the i Involved Element’s
IDs (Denoting q.els = {h1, h2,…, hi}), Respectively

SRs  Q = Q2  Q3, LSR = {DisU, MESRO, MESOR}
 DisU: Disallowed Usage (Negative Permission)
 MESRO and MESOR: Mutual Exclusions
Security UML -44
Application’s Security Requirements

Disallowed Usage – DisU: Negative Permission
 (id, DisU, lt, h1, h2)  Q2: Element h1 is Not
Allowed To Use Element h2 During lt
 E.g. (“SR1”, DisU, [“01/01/2005”, “12/31/2006”],
“Junior Staff ”, “Add Survey Header”)

[“01/01/2005”, “12/31/2006”]
Security UML -45
Application’s Security Requirements

Static Role-Objects Mutual Exclusion - MESRO
 (id, MESRO, lt, h1, h2, h3)Q3: Actor h1 is Not
Allowed to Use Both Elements h2 and h3 During lt
 E.g. (“SR2”, 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

Static Object-Roles Mutual Exclusion - MESOR
 (id, MESOR, lt, h1, h2, h3)  Q3: Actors h1 and h2
are Not Allowed to Use Element h3 At the Same
Time During lt
 E.g. (“SR3”, 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



State Function Provides the Transition from One
Design State to Next When Given Design Action
 Adding/Deleting/Modifying a UML Element
 Adding/Deleting/Modifying a UML Connection
Three Aspects of Design State Space
 UML Elements
 Application’s Security Requirements
 UML Connections
State Functions Triggered on Insertion, Deletion, etc.
Security UML -51
Three Design State Spaces and Actions
UML Element State
Space
D

Design Time
Design
Action
Application’s
Q
Security Requirement
State Space
Design Action a
si
a
si+1
Insert/Update/
Delete
Security Constraint
UML Connection Design
State Space
F
Security UML -52
State Functions


Extended Sets: D^ = {^}  D, F^ = {^}  F, and Q^
= {^}  Q 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
 Def. 3.3.1 (State Function Signatures)
 For UML Elements: sD: LIDT  D^Err
UML Element ID
Design Time
sDi
UML Element Contents
Error Status
 For UML Connections: sF: LIDT  F^Err
 For Security Requirements: sQ: LIDT  Q^Err

Design State i: (sDi, sFi, sQi)   = DFQ
Security UML -53
Inserting a UML Element

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

stat
D
UML Element Contents
Error Status
Def. 3.4.3 (Status Function for UML Element
Space): statD: 2DLIDT  D^Err
statD L h t =
if L ==  then (^, 0)
else let e  L in // Pick an element e in L
if e.id  h then statD L\{e} h t
else intra_chkD e t 
Security UML -54
Inserting a UML Element

intra_chkD Function for the Intra-element Check on
the Properties (Lifetime and Security Levels) of an
UML Element at a Specific Time

Def. 3.4.2 (Intra-Element Checking for a UML Element)
intra_chkD: DT  D^Err
intra_chkD 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

Remember:
 Design State Function Signature For UML
Elements: sD: LIDT  D^Err
UML Element ID
Design Time

sDi
Status Function for UML Element Space:
statD: 2DLIDT  D^Err
Current UML Element Set
UML Element ID
statD
Design Time

UML Element Contents
Error Status
UML Element Contents
Error Status
Cast the Form of sDi Function as sDi = (statD LDi) h t
 LDi (=sDi.set): The Set of Designed UML Elements
in State i. Define LD0 = sD0.set =   sD0= (^, 0)
Security UML -56
Inserting a UML Element


Function of Inserting a UML Element
 Def. 3.4.4 (The Insert Action on UML Element
Space): InsD: D  
InsD si e = si+1 where sDi+1 = statD (insert e sDi.set),
sFi+1 = sFi and sQi+1 = sQi 
Example: Design From Scratch (From State 0)
 Add Use-Case uc1: Add Survey Header, min SL =
max SL = “S”, and LT = [“01/01/05”, “12/31/06”]
 State 0: (sD0, sF0, sQ0) = ((^, 0), (^, 0), (^, 0))
 State 1: sD1  statD (insert uc1 sD0.set)
= statD (insert uc1 ) = statD {uc1};
sF1 = sF0 and sQ1 = sQ0
 sD1 uc1 “06/15/05” = (statD {uc1}) uc1 “06/15/05” =
((Add Survey Header, UC, [01/01/05,12/31/06], S, S),1)
Security UML -57
Status Function for UML Connections

Status of a UML Element h Based on the UML
Element State sD and the Current Set of Designed
UML Connections L at the Design Time t
 Def. 3.4.6 (Status Function for UML Connection
Space): statD: D2DLIDT  D^Err
statF sD L h t =
if L ==  then (^, 0)
else let e  L in // Pick an element e in L
if e.id  h then statF sD L\{e} h t
else intra_chkF sD e t 
Security UML -58
Inserting Action

Function of Inserting a UML Connection
 Def. 3.4.7 (The Insert Action on UML Connection
Space): InsF: F  
InsF si e = si+1 where sDi+1 = sDi,
sFi+1 = statF sDi+1 (insert e sFi.set), and sQi+1 = sQi 

Function of Inserting a Security Requirement
 Def. 3.4.7 (The Insert Action on SR Space):
InsQ: Q  
InsQ si e = si+1 where sDi+1 = sDi, sFi+1 = sFi, and
sQi+1 = statQ sDi+1 (insert e sQi.set) 

Deletion and Update of UML Elements Also Require
Analogous Modification to the Design State Space
Security UML -59
Recall Design Tiers and Design Process

Recall the three Prior 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



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

Three Security/Software Design Tiers for the UML
 Tier 1: Use-Case Diagrams
Intra-Checks
 Tier 2: Classes  Use-Cases
Inter-Checks
 Tier 3: Sequence Diagrams

Intra-Checks Occur within Individual UML Elements
Inter-Checks for MAC/RBAC/Lifetime Constraints
 CstrMAC: FT  Boolean
 CstrRBAC: QT  Boolean
 CstrLT: FT  Boolean
 Lifetime Check at the Design Time: Necessary
Condition
 Also Checked at Run-Time in the Code Generated
for Security Enforcement

Security UML -61
Security Constraints Checking

Inter-Element Check for MAC (Simple Sec/Integrity)
 The MAC Constraint CstrMAC(si, j, t) for a
Connection j from x to y
 For a Connection j (Not Use Case-Class and ClassMethod 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

Inter-Element Check for MAC
 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

Inter-Element Check for MAC
 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

Inter-Element Check for Lifetime
 The Lifetime Constraint CstrLT(si, j, t) for a
Connection j from x to y at t
 x Utilizes y: Work Time WT = j.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]
[1/1/05, 12/31/07]
Lifetime Satisfied Connection at t =
“1/15/06” < WT.et = “12/31/07”
Security UML -66
Security Constraints Checking

Inter-Element Check for RBAC
 The RBAC Constraint CstrRBAC(si, q, t) for a
Security Requirement q
 DisAllowed Usage: (id, DisU, lt, h1, h2)  Q2: No Path
h1  h2 from Element h1 to Element h2 During lt
 Static Role-Objects Mutual Exclusion: (id, MESRO, lt,
h2 h1, h2, h3)Q3: The Path Coverage (i.e. All the Paths)
h1 
from Actor h1 Cannot Contain Elements h2 and h3
h3
During lt
 Static Object-Roles Mutual Exclusion: (id, MESOR, lt,
h1
h1, h2, h3)Q3: Element h3 is NOT in the Intersection
 h3 of two Path Coverages from Actor h and Actos h
1
2
h2
During lt
Security UML -67
Towards Security Assurance



When is Design Acceptable with Respect to Security?
 Define Security Compliance Properties
 Represents Constraints that Must Hold as Design is
Created and Modified
Does the Design have Expected Security Properties?
 Security Conformity Support Program
 Design-Time and Post-Design Modes
Goal:
 Each Design Element is Legitimate to Use via
Intra-Checks
 All Application's Security Requirements Hold via
Inter-Checks at a Design Time t
Security UML -68
Towards Security Assurance

Design-Time Checking
 As Discussed so Far, Security Checks Occur as
Design is Created and Modified
 However – Design Can be Too Complicated to
Develop without Constant Nagging Error
 In Use Case – Perhaps any Remaining Connections
will Cause Errors
 However – Designer May Intend to Make Changes
to Remove Problems in
Later Design Iterations
 Need the Ability to Turn
off Design-Time Checking
 Result: Require Checking
of Design Iterations
Security UML -69
Towards Security Assurance

Post-Design Checking
 Turn off Design-Time Security Checking
 Initiated by Security Designer
 Allows Design to be in an Inconsistent State w.r.t.
Security Compliance and Conformity
 Design State is Still Tracked
 Represents All Design Actions
 Can Track All Security Errors
 Doesn’t Report Errors

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

A Design State si = (sDi, sFi, sQi) is said to Be
 Admissible at Design Time t if Every Design
Element in sDi, sFi, and sQi Evaluates to be
Applicable at t



MAC/LT Constraint-Compliant at Design Time t if
si is Admissible and for Every UML Connection in
sFi, CstrMAC/ CstrLT(si, j, t) Yields true at t
RBAC Constraint-Compliant at Design Time t if si
is Admissible and for Every Application's Security
Constraint in sQi, CstrRBAC(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


Security Conformity Design Support (SCDS) Program
For Design-Time Mode PDT
 Designer’s Action
 Event Trigger
 Security Constraint Check on the Current State
& Design Time
 Materialize Connection | Error
 Materialize Connection: Update GUI and Design Space

For Post-Design Mode PPD
 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
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
Post-Design Checking - Error Case
MAC Violation
Security UML -75
Security Conformity Design Support

SCDS Program for Design-Time Mode PDT
 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
<stemp, err_no> = Response(a, e, snow, t)
if err_no  1 then ReportError(err_no)
else {Materialize e in the design
snow = stemp}
end while
}
Security UML -76
Security Conformity Design Support

Example of a Design State Construction Process
 Use Case Diagram for Creating a New Survey
Entry
Security UML -77
Security Conformity Design Support

Example of a Design State Construction Process
 Use Case Diagram for Creating a New Survey
Entry
Security UML -78
Security Conformity Design Support

Example of a Design State Construction Process
 Use Case Diagram for Creating a New Survey
Entry
Security UML -79
Security Conformity Design Support

Example of a Design State Construction Process
 Use Case Diagram for Creating a New Survey
Entry
Security UML -80
Security Conformity Design Support

Example of a Design State Construction Process
 Use Case Diagram for Creating a New Survey
Entry
Security UML -81
Algorithmic Complexity Discussion



The Design-Time Security Conformity Support
Program PDT
 Check Performed whenever a UML Element, UML
Connection or SR is Created/Modified
 Checks Occur in the UML Design Tool
 Reasonable Computational Cost So As to Not Add
Overhead to the Design Process
The Post-Design Security Conformity Support
Program PPD
 When Designs Become More Complex, or are
Partially Checked (Imported)
 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


Together Architect (TA): UML Tool with Open APIs
for JAVA and a Modular Plug-in Structure
 Thanks to Andy, Phil, Frank, and Vijaya, et al.
 TA Allows Our Own Custom Code to be Added
 Custom Code for MAC/RBAC/LT Constraints
 Provides a Tool for Secure Software Design
On-Going Prototyping Effort Supports
 Definition of SLs and LTs, for Use-cases, Actors,
Classes, and Methods and Constraints into TA
 Security Level Analyses for UML Designs
 Real-Time as Design is Created and Modified
 Post-Design for Design Iterations/Increments

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
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 -85
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 -86
Together Architect Plug-In
Turning the MAC Design-Time Checking On/Off
Security UML -87
Design-Time Checking
Design-Time Checking: MAC Constraint Violation
Security UML -88
Post-Design Checking
Post-Design Checking: No Constraint Violation
Security UML -89
Post-Design Checking
Post-Design Checking - Error Case
MAC Violation
Security UML -90
Retrospective on Work


Visual/Non-Visual Modeling Extensions for RBAC,
MAC, & Lifetimes in UML
 Extensions Integrate Security Requirements,
RBAC, MAC, and Lifetimes, into Design Phase
Formal Functional Model for Security/Non-Security
Design Features/State
 Formal Functional Model Capturing the Security &
Non-security Features of an Application’s Design
 Track the Design State Retaining Design Time As
a Parameter
 Convenient for Time-Sensitive Applications with
Lifetime Constraints
 “Design Once, Re-use Many Times” - Advanced
Step for the Style “Write Once, Run Anywhere”
Security UML -91
Retrospective on Work

Strong Security Assurance (on MAC/LT/RBAC)
 Design-time and Post-design Algorithms Against
MAC, Lifetime, and RBAC Constraints
 Disallowed Usage and Mutual Exclusions
 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

Potential Result: Reducing the Cost of Repairing
Errors in the Life Cycle
Security UML -92
Transition from Design to Development




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 …
 Role-Slice Diagram Contains a Combined
Privilege Perspective Across Entire Application
 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




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
Security UML -95
Principle 3


The Security Incorporating Process Should Neither
Counter the Intuition Nor Decrease the Productivity of
the Stakeholders
How is Principle 3 Attained?
 UML Extensions are Relatively Seamless in their
Definition (Properties for MAC, Lifetimes, etc.)
 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
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
Security UML -97
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
Security UML -98
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
Security UML -99
Survey Management Example
Security UML -100
Survey Management Class Diagram
Security UML -101
Simplified Class Model of the Survey Application
applicatio n = {Survey _ List , Survey _ Header , Public _ Survey _ Re sults},{}
 Add _ Survey _ Header , Survey _ Title _ Search, 
Survey _ List = 

Update
_
Survey
_
List
,
Delete
_
Survey
_
Header


Create _ Survey _ Header , Add _ Question ,
Survey _ Header = 

Add
_
Special
_
Question


Public _ Survey_Results = {Get _ GeneralStatistics , Get _ Questions}
Security UML -102
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
subs = {Survey _ List , Survey _ Header},{}
Security UML -103
Integration with Doan’s work


Each Use Case is Associated to a Set of Methods
Secure Subsystem
 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

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
Security UML -105
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)
 <pos> Methods Identified via Actor-Use CaseClass-Method Link
 <neg> by Disallowed Usage
Secure Subsystem
Security UML -106
Recall the Transition
Secure Subsystem
Security UML -107
Framework Overview

Security
Concern Models
Main Application
Design Model
Access Control
Policy
Auditing Policy
Authentication

m a p p i ng
m a p p in g


Security Aspect -Oriented
Implementation
Access Control
Main Application
Aspect
Implementation

Auditing Aspect
Authentication
Aspect
Applicationspecific Model
Concern-specific
Composable Units
Implementation of
the Application
Implementation of
Concerns
Composition into
the Final
Application
Compilation and
Aspect Weaving
Final Application
Security UML -108
Framework Overview
Security
Concern Models
Policy
Auditing Policy
m a p p i ng
Design Model
Access Control
Security Aspect -Oriented
Implementation
Access Control
Main Application
Aspect
Implementation
Auditing Aspect
Role-Slice
Extensions

Aspect-Oriented
Security
Enforcement Code
Generation
Authentication
m a p p in g
Main Application

Authentication
Aspect
Compilation and
Aspect Weaving
Final Application
Security UML -109
Role-Slice Policy
Staff , JuniorStaff ,  JuniorStaff , Staff
policy = 
, 
SeniorStaff
  SeniorStaff , Staff
,
, subs

Survey _ Title _ Search,Update _ Survey _ List ,
Staff = 
,{}, true
 Add _ Question

JuniorStaff = {}, {Update _ Survey _ List }, false
 Add _ Survey _ Header , Create _ Survey _ Header ,
SeniorStaff = 
,{}, false
 Add _ Special _ Question

Security UML -110
Integration with Doan’s Work

Roles and Hierarchies
Roles
Role Hierarchy
Relation
Security UML -111
Integration with Doan’s work

Permissions
 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

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
Security UML -113
Step Back to Formalize



Approach so Far Demonstrates the Ideas and
Transitions
 UML Secure Design (Doan’s Work) to
 Secure Subsystem (UC-Classes Relationship) to
 Role Slices (Actor-UC-Method Relationship)
We’ll Proceed to Formal Definitions of each Concept
Formalizations will be Kept as Simple as Possible
 Several Elements whose Details are not Relevant
to our Approach will be Abstracted
 Elements that are not Referenced by the
Definitions will be Purposefully Omitted
Security UML -114
Basic Object-Oriented Definitions


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



Method Abstracted as Method Invocation Sequence
 Worst Case (All Methods that May be Called)
Formally a Method is a Record <name, impl>
 name: Name of the Method
 impl: Its Implementation
Individual Method Invocation is a Record <m,s,arg>
 m: Invoked method
 s: The Environment
 arg: Arguments of the Method
Security UML -116
Class and Application




Methods are Grouped into Classes
 Attributes are Excluded from the Definition
 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 <C,H>
 C: Set of Classes of the Application
 H: Inheritance Relation Between Classes in C
Security UML -117
Subsystem



A Subsystem is a Subset of an Application
Formally a Subsystem of an Application <C,H> is a
Record <SC,SH>
 SC  C
 SH is the Projection of H onto SC
Differentiate Secure and Non-Secure Portions
 Secure Subsystem Definitions
 Method Invocations are Intercepted for Security

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



Program Execution must be Carefully Controlled to
for the Intervention of Method Invocations
 Carried out by an Interpreter Function that Chains
Method Invocations to Object Instances
 Some Invocations Proceed without Intervention
 Others (Secure Subsystem) must be Intercepted
An Structure Called Environment is Used to Keep
Track of the State of Variables
Environment Tracks:
 Return Value of a Method
 Active User Credentials (Active/Authenticated
Role)
 Access Control Policy (Roles and Role Hierarchy)
 Exit Value of the Program
Security UML -119
Interpreter Function



Traverses the Application Structure and Executes All
of its Instructions
Formally, a Function I : M→S →Arg →N that Takes
as Input
 M: Method
 S: Environment (see Previous Slide)
 Arg: Argument (Can be a Tuple of Values)
Outputs:
 N: Exit Status (Natural Number) which Denotes
Success or Failure
Security UML -120
Environment Function



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
 [‘activeRole’ → R, ‘exit’ → R, ‘policy’ → P]
 ‘exit’ is Value of Application (previous slide)
Environment Can Also Store Return Value of Method
 [‘returnValue’ → 5]
Security UML -121
Simplified Class Model of the Survey Application
applicatio n = {Survey _ List , Survey _ Header , Public _ Survey _ Re sults},{}
 Add _ Survey _ Header , Survey _ Title _ Search, 
Survey _ List = 

Update
_
Survey
_
List
,
Delete
_
Survey
_
Header


Create _ Survey _ Header , Add _ Question ,
Survey _ Header = 

Add
_
Special
_
Question


Public _ Survey_Results = {Get _ GeneralStatistics , Get _ Questions}
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
subs = {Survey _ List , Survey _ Header},{}
Security UML -123
Integration with Doan’s work


Each Use Case is Associated to a Set of Methods
Secure Subsystem
 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
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
Security UML -125
Formalizing Role Slices


A Role Slice is a Unified Abstraction to Specify Who
Can do What w.r.t. Roles Against Methods
 Generated from Earlier Secure UML Design
 Created from Scratch by Security Designer
A Role Slice is a Record <PP,NP,abstract>
 PP: Set of Methods with Positive Permissions
 NP: Set of Methods with Negative Permissions
 abstract: Indicates whether the Role Slice is
Abstract or Concrete
Security UML -126
Formalizing Access Control Policy


Access Control Policy is Defined by All the Role
Slices in the Model and their Inheritance Relationships
An Access-control Policy is a Record <RS,CR,S>
 RS: Set of Role Slices Defined over Subsystem S
 CR  RS  RS: Role-Slice Composition Relation
that Defines the Role Hierarchy
 Each pair in CR is of the form <a,b>, where a is the
Child Role Slice and b is the Parent Role Slice
Security UML -127
Formal Role-Slice Policy
Staff , JuniorStaff ,  JuniorStaff , Staff
policy = 
, 
SeniorStaff
  SeniorStaff , Staff
,
, subs

Survey _ Title _ Search,Update _ Survey _ List ,
Staff = 
,{}, true
 Add _ Question

JuniorStaff = {}, {Update _ Survey _ List }, false
 Add _ Survey _ Header , Create _ Survey _ Header ,
SeniorStaff = 
,{}, false
 Add _ Special _ Question

Security UML -128
Integration with Doan’s Work

Roles and Hierarchies
Roles
Role Hierarchy
Relation
Security UML -129
Integration with Doan’s work

Permissions
 The Set of Use Cases Allowed to an Actor Defines
the Methods Allowed to the Corresponding Role
Authorized Methods
Security UML -130
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
Security UML -131
The Ancestors Function




Ancestors is a Convenience Function that Obtains all
the Ancestors of a Role Slice in a Hierarchy
Ancestors (anc) is a Function with Arguments:
 A Role Slice RS
 A Role-slice Composition Relation CR
 An ordering relation < derived from cr
Ancestors Outputs an Ordered Set of Role Slices that
are Ancestors of rs
anc = λrs. λcr. λ<. ({a:<rs,a>  cr+},<)
 The Elements are Ordered According to their
Distance to rs in the Role Hierarchy
Security UML -132
Vertical Composition


Vertical Composition is a Function that Performs
Composition Between Child and Parent Role Slices
Formally, Vertical Composition (vc) is a Function
 Takes Two Role Slices as Arguments
 Outputs a New Role Slice that Combines
Permissions of Both


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



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:
 The Vertical Composition Function vc
 A Role Slice rs
 A Composition Relation cr
It Outputs the Role Slice rs Composed with All of its
Ancestors

Security UML -134
Composed Role Slices
fc vc JuniorStaff policy .CR =
Survey _ Title _ Search, AddQuestion,, Update _ Survey _ List , false
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
Security
Concern Models
Access Control
Policy

Auditing Policy
Authentication

m a p p in g


Security Aspect -Oriented
Implementation
Access Control
Aspect
Auditing Aspect
Authentication
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)
Aspect
Security UML -139
What is AOSD/AOP?

Jump to Companion Presentation
Security UML -140
AOP Security Enforcement Code Generation


Code Generator takes a Role Slice Specification as
Input and Outputs:
 An Access Control Aspect
 A Policy Database
AOP + Policy DB Provides Means for Changing
Access Control without Recompiling Code
Security UML -141
Aspect-Oriented Definitions




To Formalize the Mapping, it is Necessary to Define
Basic Aspect-oriented Concepts
 Definitions are Simplified
 Formalizes the Ideas in Companion Presentation
A Point Cut is Represented as a Record <caller,callee>
 caller is a Method where all Invocations of callee
must be Modified to Include the Aspect Code
An Advice is a Record <PC,T>
 PC: a Point Cut
 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


Weaving is the Process by Which we can Integrate
Aspects into Application’s Code
 Customizable
 Only Weave Aspects that are Desired
Weaving Function W: App → A → App takes as Input
an Application and an Aspect and Outputs
 Application with All the Advices of the Aspect
Woven to its Structure
Security UML -144
Weaving Algorithm

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

Access-Control Aspect

Login Advice
 References any Call to the login Method
 For this Example, we assume that there Exists a
login Method that Returns a Tuple <u,r>
 u is the User who logged in, and r is his/her Active Role

Rewriting Function Obtains the Active Role and
Stores it in the Environment
Security UML -146
Enforcing an Access Control Policy using AOP

Access-control Enforcement Advice
 Intercepts Every Call that Comes from Outside to
Inside the Secure Subsystem subs
subs = {Survey _ List , Survey _ Header},{}

Rewriting Function Changes the Target Method to
Add Access-control Checking
Security UML -147
Example for the Survey Management Application

Join Points Depend on the External/Internal Methods
M ext = {Get _ General _ Statistics, Get _ Questions}
 Add _ Survey _ Header , Survey _ Title _ Search, 
Update _ Survey _ List , Delete _ Survey _ Header ,


M in = 

Create _ Survey _ Header , Add _ Question ,

 Add _ Special _ Question ,


Suppose that One of the Methods is Defined as:

Get _ General _ Statistics, Survey _ Title _ Search, s, slist ,

Where the Variable slist is Supposed to be an
Instance of Survey_List

Security UML -148
Example Courseware Application

Functional Implementation of the Invocation to the
Method Survey_Title_Search from
Get_General_Statistics after the Weaving:
( λs.λarg. if Survey_Title_Search  (s 'activeRole').PP
then (Survey_Title_Search s arg)
else Exception),s, slist
Security UML -149
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
Security UML -150
Prototyping Effort - Role-slice Inspector

Role-slice View of Actor Staff
Security UML -151
Prototyping Effort – Code Generator

Uses the Role Slice Information to Generate
Enforcement Code in AspectJ
Security UML -152
Prototyping Effort – Code Generator

Generation of the AspectJ File
AccessControl.java
Security UML -153
Prototyping Effort – Code Generator

Generated AspectJ File
Security UML -154
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();
}
...
}
Security UML -155
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());
}
}
}
Security UML -156
Retrospective on Role Slices + AOP


We Presented an Approach to Preserve Separation of
Security Concerns
Separation of Concerns at the Model Level
 Role-slice Notation
 Helps in the Conceptualization of a Method-based
Security Policy
 Facilitates its Evolution During the Design Process.

Separation of Concerns at the Code Level
 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

We are Currently Working in Improving the Role-slice
Model
 Dynamic Permissions: Permissions Constrained on
Runtime Elements
 Adding Support for Other Security Policies
 Mandatory Access Control
 Delegation

Software Prototype
 Integration of Role Slices and Previous Work of Doan
et al.
Security UML -158
Overall Work: Available Technologies


Work of Both Doan and Pavlich
Java Data Structures and Algorithms
 Data Structure to Capture and Track an Entire
UML Design and its Current (Past) States
 Security Algorithms for:
 Design-Time Checks of Security
 Post-Design Check of Entire UML Design

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


Security UML -159
Current Ongoing Prototyping



Together Architect 1.1
 Transitioning Software from Together Control
Center 6.2 into Together Architect 1.1
 Integrating Multiple Versions into one Prototype
 Role-Slice Diagram as a New Diagram
Eclipse UML
 Exploring the Potential of a Simultaneous
Prototyping Effort in Eclipse UML
 Looking to Transition the Ideas over Upcoming
Semesters
Rhapsody by I-Logix – Embedded UML Tool
 Explore the Integration with another Platform
 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
Assurance
RBAC, Delegation
MAC Properties:
Simple Integrity,
Simple Security,
etc.
Safety
Liveness
Secure MAC/RBAC
Secure Information
via Middleware
Exchange
(Service Oriented Arch)
via XML
in Distributed Setting
with MAC/RBAC
Security UML -161
Other Ongoing Research at UConn

UML with Security, Performance, and Reliability
(Demurjian, Ammar, Rajasakeran, Gokhale, Michel)

Intrusion Detection via Application Data
(Demurjian, Rajasakeran, Gokhale, Michel)

Middleware-Based Security – SOA (Demurjian)

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



Artifacts: DB, Legacy, COTS,
GOTS, with APIs
Database
New/Existing Clients use APIs
Can we Control Access to APIs
(Methods) by …
Database
Client
 Role (who)
 Classification (MAC)
Java
 Time (when)
Client
 Data (what)
 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


Emergence of XML for
Document/Information Exchange
Extend RBAC/MAC to XML
 Collection of Security DTDs
 DTDs for Roles, Users, and
Constraints
 Capture RBAC and MAC

Apply Security DTDs to XML
Documents
 An XML Document Appears
Differently Based on Role,
MAC, Time, Value
 Security DTD Filters Document
Security DTDs
 Role DTD
 User DTD
 Constraint DTD
Security Officer
Generates Security
XML files for the
Application
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