security uml -1 security analysis/design for uml alberto de la rosa algarín, jaime...

Security UML -1

Security Analysis/Design for UMLSecurity Analysis/Design for UML

Alberto De la Rosa Algarín, Jaime Pavlich-Mariscal,Steven A. Demurjian, Laurent D. Michel

Computer Science & Engineering Department371 Fairfield Road, Box U-2155The University of Connecticut

Storrs, Connecticut 06269-2155http://www.engr.uconn.edu/~steve

[email protected]@cse.uconn.edu

Security UML -2

Motivation Motivation Software Engineering 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 ConcernsSoftware 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 -3

Motivation Motivation Incorporating Security into UML DesignIncorporating 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 -4

Objectives Objectives Span from Requirements/Design to Development of Span from Requirements/Design to Development of

the Software Process, its Models, and Toolsthe 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 -5

Overview of Remainder of TalkOverview of Remainder of Talk Secure Software Design Secure Software Design Principles of Secure DesignPrinciples of Secure Design Extending UML for Secure DesignExtending UML for Secure Design

UML Extensions for Security Tracking Design and Security State Security Assurance via Constraint Checking Prototyping Effort

Transition from Design to DevelopmentTransition from Design to Development Role Slice Diagram Aspect Oriented Programming Prototyping Effort

Push to Information SecurityPush to Information Security Conclusions and Ongoing ResearchConclusions and Ongoing Research

Security UML -6

Principles of Secure DesignPrinciples of Secure Design Principle 1 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 Principle 2 TThe Security Assurance is Satisfied Relatively to

the Period of Software Design Principle 3 Principle 3

The Security Incorporating Process Should Neither Counter the Intuition Nor Decrease the Productivity of the Stakeholders

Principle 4Principle 4 Security Definition via a Unified Perspective that

Collects Privileges into a Cohesive Abstraction

Security UML -7

Tier 2: Associating Classes Used in Use Cases Choosing Needed Classes in Sequence Diagrams

Tier 3: Sequence Diagrams (and Other Diagrams) Specify Messages (Methods Without Code) Between

Objects

Multiple Design Tiers:Multiple Design Tiers: Tier 1: Use Case Diagrams, Class Diagrams

Define Use Cases, Actors, and Their Relationships Define Classes (High Level:Only Attributes/Methods

Signatures) and Relationships Among Classes

Principle 1 Principle 1 The Software Design Has The Software Design Has Multiple Iterative PhasesMultiple Iterative Phases

and The Security Features Should Be Incorporated and and The Security Features Should Be Incorporated and Adjusted Adjusted During Each ofDuring Each of and and AmongAmong Those Phases Those Phases

Security UML -8

Principle 2 Principle 2 The Security Assurance is Satisfied Relatively to the The Security Assurance is Satisfied Relatively to the

Period of Software Design 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: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 -9

Principle 3 Principle 3 The Security Incorporating Process Should The Security Incorporating Process Should Neither Neither

CounterCounter the Intuition the Intuition nor Decreasenor Decrease the Productivity of the Productivity of the Software Designer.the Software Designer.

Our Perspective: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 -10

Principle 3Principle 3 The Security Incorporating Process Should The Security Incorporating Process Should Neither Neither

CounterCounter the Intuition the Intuition nor Decreasenor Decrease the Productivity of the Productivity of the Software Designer 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: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 -11

Principle 3Principle 3 The Security Incorporating Process Should The Security Incorporating Process Should Neither Neither

CounterCounter the Intuition the Intuition nor Decreasenor Decrease the Productivity of the Productivity of the Software Designer.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 -12

Principle 4Principle 4 Security Definition via a Unified Perspective that Security Definition via a Unified Perspective that

Collects Privileges into a Cohesive AbstractionCollects Privileges into a Cohesive Abstraction Our Perspective: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 -13

Objective and ApproachObjective and Approach ObjectiveObjective

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 Approach Introduces the ““Role-Slice DiagramRole-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 -14

Recall Survey Management ExampleRecall Survey Management Example A Survey Institution Performs and Manages Public A Survey Institution Performs and Manages Public

SurveysSurveys The Senior Staff Person Adds a Survey Header Into The Senior Staff Person Adds a Survey Header Into

the Databasethe Database Staff Person (Senior or Junior Staff) Adds Questions Staff Person (Senior or Junior Staff) Adds Questions

Into that Survey, Categorize Questions and Adds a Into that Survey, Categorize Questions and Adds a New Question Category If NeededNew Question Category If Needed

Some Special Questions that have More Sensitive Some Special Questions that have More Sensitive Content - Only Senior Staff Allowed to ProcessContent - Only Senior Staff Allowed to Process

Security UML -15

Survey Management ExampleSurvey Management Example

Security UML -16

Survey Management Class DiagramSurvey Management Class Diagram

Security UML -17

Simplified Class Model of the Survey ApplicationSimplified Class Model of the Survey Application

Security UML -18

Defining a Secure SubsystemDefining a Secure Subsystem We do not Want to Define Security over Every Class We do not Want to Define Security over Every Class

in the Systemin the System Security is Defined over a Secure SubsystemSecurity is Defined over a Secure Subsystem

Represents those Classes on Which Privileges will be Defined

SecureSubsystem

Security UML -19

Defining Access Control PolicyDefining Access Control Policy A Role Slice is a Specialized A Role Slice is a Specialized

Class Diagram that Represents Class Diagram that Represents Permissions for the RBAC ModelPermissions 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 -20

Integration is Automatable Integration is Automatable Recall the Transition from Use Cases to the:Recall the Transition from Use Cases to the:

Classes Utilized to Realize their Functionality Methods of those Classes (Subset)

ProvidesProvides Definition of Secure Subsystem (Include a Class if

at Least One Method is Assigned to a Use Case) <pos> Methods Identified via Actor-Use Case-

Class-Method Link <neg> by Disallowed Usage

Secure Subsystem

Security UML -21

Recall the Transition Recall the Transition

Secure Subsystem

Security UML -22

Security

Concern Models

Security

Concern Models

Main Application

Design Model

Main Application

Implementation

ma

pp

ing

Access Control

PolicyAuditing Policy Authentication

Access Control

AspectAuditing Aspect

Authentication

Aspect

Compilation and

Aspect Weaving

Security Aspect -Oriented

Implementation

ma

pp

ing

Main Application

Design Model

Main Application

Implementation

ma

pp

ing

Access Control


Access Control


Access Control


Authentication

Aspect

Access Control


Authentication

Aspect

Compilation and

Aspect Weaving


Implementation

ma

pp

ing

Final ApplicationFinal Application

Framework OverviewFramework Overview Application-

specific Model Concern-specific

Composable Units Implementation of

the Application Implementation of

Concerns Composition into

the Final Application

Security UML -23

Security

Concern Models

Security

Concern Models

Main Application

Design Model

Main Application

Implementation

ma

pp

ing

Access Control


Access Control


Authentication

Aspect

Compilation and

Aspect Weaving


Implementationm

ap

pin

g

Main Application

Design Model

Main Application

Implementation

ma

pp

ing

Access Control


Access Control


Access Control


Authentication

Aspect

Access Control


Authentication

Aspect

Compilation and

Aspect Weaving


Implementationm

ap

pin

g


Framework OverviewFramework Overview Role-Slice

Extensions

Aspect-Oriented Security Enforcement Code Generation

Security UML -24

Simplified Class Model of the Survey ApplicationSimplified Class Model of the Survey Application

Security UML -25

Defining the Security PolicyDefining the Security Policy

We do not Want to Define Security over Every Class in the System

Security is Defined over a Secure Subsystem

SecureSubsystem

Security UML -26

Composition of Role SlicesComposition of Role Slices To Obtain the Final Set of PermissionsTo 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 -27

Formal Role-Slice PolicyFormal Role-Slice Policy

Security UML -28

Composition of Role SlicesComposition of Role Slices To Obtain the Final Set of PermissionsTo 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 -29

Composed Role SlicesComposed Role Slices

Security UML -30

Another ExampleAnother Example

Security UML -31

Role Slice DiagramRole Slice Diagram

Security UML -32

Composed Role SlicesComposed Role Slices

Security UML -33

Mapping to Security Enforcement CodeMapping to Security Enforcement Code Role Slices Define Role Slices Define

an Access Control an Access Control PolicyPolicy

This Policy Must be This Policy Must be Enforced in the Enforced in the CodeCode

OOP is not Enough OOP is not Enough to add Security to to add Security to SoftwareSoftware

Leverage Leverage Aspect-OrientedAspect-OrientedProgramming (AOP)Programming (AOP)

Security

Concern Models

Security

Concern Models

Main Application

Design Model

Main Application

Implementation

ma

pp

ing

Access Control


Access Control


Authentication

Aspect

Compilation and

Aspect Weaving


Implementation

ma

pp

ing

Main Application

Design Model

Main Application

Implementation

ma

pp

ing

Access Control


Access Control


Access Control


Authentication

Aspect

Access Control


Authentication

Aspect

Compilation and

Aspect Weaving


Implementation

ma

pp

ing


Security UML -34

Prototyping Effort - Role-slice InspectorPrototyping Effort - Role-slice Inspector A Plugin for Together Architect that Generates a Role A Plugin for Together Architect that Generates a Role

Slice from the Information of an ActorSlice 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 -35

Prototyping Effort - Role-slice InspectorPrototyping Effort - Role-slice Inspector Role-slice View of Actor StaffRole-slice View of Actor Staff

Security UML -36

Prototyping Effort – Code GeneratorPrototyping Effort – Code Generator Uses the Role Slice Information to Generate Uses the Role Slice Information to Generate

Enforcement Code in AspectJEnforcement Code in AspectJ

Security UML -37

Prototyping Effort – Code GeneratorPrototyping Effort – Code Generator Generation of the AspectJ FileGeneration of the AspectJ File

AccessControl.java

Security UML -38

Prototyping Effort – Code GeneratorPrototyping Effort – Code Generator Generated AspectJ FileGenerated AspectJ File

Security UML -39

Prototyping Effort – Code GeneratorPrototyping Effort – Code Generator Generated CodeGenerated 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 -40

Prototyping Effort – Code GeneratorPrototyping Effort – Code Generator Checking PermissionsChecking 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 -41

Information SecurityInformation Security

Security UML -42

Push for Information SecurityPush for Information Security Today’s Applications and Systems Built around Today’s Applications and Systems Built around

Multiple TechnologiesMultiple Technologies APIs, Cloud Computing, Web Services, Data

Mining, etc. Alternative Data Structure StandardsAlternative Data Structure Standards

XML, RDF, JSON, OWL, etc. Can we Incorporate RBAC, MAC, and DAC ?Can we Incorporate RBAC, MAC, and DAC ? XML Security Schemas SetXML Security Schemas Set

Roles, Users, Constraints RBAC, MAC, DAC

Apply Security Schemas to XML DocumentsApply Security Schemas to XML Documents Security Schema Filters Document XML Document Appears Differently Based on

Role, MAC, Delegation

Security UML -43

What is XML?What is XML? Provides a Common, Structured LanguageProvides a Common, Structured Language

Independent of Systems Information Hierarchically Structured and TaggedInformation Hierarchically Structured and Tagged

Tags can Offer Semantics XML schemas XML schemas

Blueprints for new Instances Validation Agents Achieved with

XML Schema Definition (XSD) XML Schema Language (XSL)

Security UML -44

Example of an XML schema (CCR segment)Example of an XML schema (CCR segment)<xs:complexType name="StructuredProductType"> <xs:complexContent> <xs:extension base="CCRCodedDataObjectType"> <xs:sequence> <xs:element name="Product" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="ProductName" type="CodedDescriptionType"/> <xs:element name="BrandName" type="CodedDescriptionType" minOccurs="0"/> <xs:element name="Strength" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:complexContent> <xs:extension base="MeasureType"> <xs:sequence> <xs:element name="StrengthSequencePosition" type="xs:integer" minOccurs="0"/> <xs:element name="VariableStrengthModifier" type="CodedDescriptionType" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element>

<xs:element name="Concentration" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:complexContent> <xs:extension base="MeasureType"> <xs:sequence> <xs:element name="ConcentrationSequencePosition" type="xs:integer" minOccurs="0"/> <xs:element name="VariableConcentrationModifier" type="CodedDescriptionType" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> • • • </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

Security UML -45

Secure Information EngineeringSecure Information Engineering Given an XML Application of Schemas and Given an XML Application of Schemas and

Associated Instances, can we:Associated Instances, can we: Define Schemas for Security Levels, Roles, User-

Role Authorizations, and Delegation Augment Application’s Schemas/Instances with

MAC Security Classifications (if Needed) XML Instances are Dynamically Filtered to Suit a XML Instances are Dynamically Filtered to Suit a

User’s Needs for an Application:User’s Needs for an Application: Based on User’s Role, MAC, Delegation Deliver Filtered Instance(s) to User

Exploit Exploit eXtensible Access Control Markup Language eXtensible Access Control Markup Language (XACML) for Policy Generation(XACML) for Policy Generation

Security UML -46

XML sScurity Oriented UML diagramsXML sScurity Oriented UML diagrams UML provides diagrams to model applicationsUML provides diagrams to model applications

Lack of diagrams for Security Pavlich-Mariscal 2008 defined new UML diagrams for

RBAC in the Meta-model layer We Extend with XML Oriented UML ArtifactsWe Extend with XML Oriented UML Artifacts

XML Schema Class Diagram (XSCD) UML Representation of the XML schema

For RBAC, XML Role Slice Diagram (XRSD) Security Augmented Representation of XML schema

Elements, Roles and Permissions

Security UML -47

XML Schema Class DiagramXML Schema Class Diagram Artifact that holds all the characteristics of an XML Artifact that holds all the characteristics of an XML

schemaschema Structure, Data Type, Value Constraints

Hierarchical nature of XML schemas is modeledHierarchical nature of XML schemas is modeled xs:complexType, xs:element, xs:sequence

UML Class with respective Stereotypes Child Relations (xs:element, xs:sequence,

xs:simpleType) UML Subclass

xs:extension Association between Classes

Data-type Cardinality Requirements and Constraints; type «constraint»; «type» stereotypes

Security UML -48

XSCD of CCR SegmentXSCD of CCR Segment

«complexType»

StructuredProductType

«element»

Product

«complexType»

«sequence»

«type» CodedDescriptionType

«element» ProductName

«type» CodedDescriptionType

«constraint» minOccurs=0

«element» BrandName

«element» Strength«constraint» minOccurs=0

«constraint» maxOccurs=-1

«extension»

CCRCodedDataObjectType

<xs:complexType name="StructuredProductType"> <xs:complexContent> <xs:extension base="CCRCodedDataObjectType"> <xs:sequence> <xs:element name="Product" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="ProductName" type="CodedDescriptionType"/> <xs:element name="BrandName" type="CodedDescriptionType" minOccurs="0"/> <xs:element name="Strength" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:complexContent> <xs:extension base="MeasureType"> <xs:sequence> <xs:element name="StrengthSequencePosition" type="xs:integer" minOccurs="0"/> <xs:element name="VariableStrengthModifier" type="CodedDescriptionType" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="Concentration" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:complexContent> <xs:extension base="MeasureType"> <xs:sequence> <xs:element name="ConcentrationSequencePosition" type="xs:integer" minOccurs="0"/> <xs:element name="VariableConcentrationModifier"

XSCD

Security UML -49

XML Role Slice DiagramXML Role Slice Diagram Represents Access Control DefinitionsRepresents Access Control Definitions

With respect to XSCD Attributes Fine Grained Control through Fine Grained Control through

Security Policies and Definitions to the XSCD Permissions on XML DocumentsPermissions on XML Documents

Read, Write, No Read, No Write Represented in the XRSD with Stereotypes:Represented in the XRSD with Stereotypes:

«read/write» «read/nowrite» «noread/write» «noread/nowrite»

Security UML -50

Example of XRSDsExample of XRSDs

«XRSD» Physician

«RoleDescription» «RoleRequirements»

«read/write» «element» Product

«read/write» «element» ProductName

«read/write» «element»

BrandName


Strength


StrengthSequencePosition


VariableStrengthModifier

«XRSD» Nurse

«RoleDescription» «RoleRequirements»

«read/nowrite» «element» Product

«read/nowrite» «element»

ProductName


BrandName


Strength

«read/nowrite»

«element»

StrengthSequencePosition


VariableStrengthModifier

Security UML -51

What is XACML?What is XACML? Aims to Define a Common Language and Processing Aims to Define a Common Language and Processing

ModelModel Permits a Level of Security Interoperability

XACML schema Provides Several Structures and XACML schema Provides Several Structures and Elements to Represent PoliciesElements to Represent Policies PolicySet, Policy, Rule

PolicySets and Rules Combined by Policy/Rule PolicySets and Rules Combined by Policy/Rule Combination AlgorithmCombination Algorithm Permit-overrides Deny-overrides First-applicable Only-one-applicable

Security UML -52

XACML General StructureXACML General Structure

PolicySet

Policy

Rule

Subject

Action

Resource

Rule Combination Algorithm

Policy Combination Algorithm

Security UML -53

Mapping to a Security Policy (XACML)Mapping to a Security Policy (XACML) Policies’ Language Structure and Processing ModelPolicies’ Language Structure and Processing Model

PolicySet, Policy, Rule Policy and Rule Combination Done with Normative Policy and Rule Combination Done with Normative

AlgorithmsAlgorithms Deny-overrides, permit-overrides, first-applicable,

only-one-applicable Use Deny-overrides as Combination Algorithm for Use Deny-overrides as Combination Algorithm for

EnforcementEnforcement If the Evaluation of One Rule Results in Deny, the

Policy Evaluation is Deny Mapping Process Divided in 3 Sub-MappingsMapping Process Divided in 3 Sub-Mappings

Role, Element and Permission

Security UML -54

Mapped PolicyMapped Policy

Role Mapping

Permission Mapping

Security UML -55

Mapped PolicyMapped Policy

Element Mapping

Security UML -56

Enforcement in a Security ArchitectureEnforcement in a Security Architecture The architecture has a number of components:

Policy Enforcement Point (PEP) Allows a request to be made on a resource

Policy Decision Point (PDP) Evaluates the request and provides a response

according to the policies in place Policy Administration Point (PAP)

Utilized to write and manage policies Policy Information Point (PIP)

Arbitrate very fine grained security issues

Security UML -57

Enforcement in a Security ArchitectureEnforcement in a Security Architecture

Physician Nurse

XRSDs

XACML Policy Mapping

XACML Policy – Schema 1

XACML Policy – Schema 2

Policy Retrieval Point (PRP)

PAP

PDP

PEP

PIP

XACML Architecture

Security UML -58

Benefits of ApproachBenefits of Approach Secure Information Engineering Secure Information Engineering

Information access control tackled at the design phase Information security augmented to a first-class citizen

Decoupled security from the dataDecoupled security from the data Lower cost of updating policies that target a large

volume o Visual representation of information security schemasVisual representation of information security schemas

UML diagrams describe the roles, XML schemas targeted, and the interplay of all the elements in security

Security UML -59

End-PurposeEnd-Purpose Merging and combiningMerging and combining

Functional Security (Jaime’s work) Collaborative Security (Solomon’s work) Information Security (Alberto’s work)

A secure software engineering approach that tackles A secure software engineering approach that tackles the major concepts of an applicationthe major concepts of an application Methods and Operations Collaboration and Adaptive Workflows Information and Resources used

Leveraging access control models across all three Leveraging access control models across all three topicstopics RBAC MAC DAC

Security UML -60

Overall ViewOverall View(1) Main Security Design of the Application

(2a,b) Initial Functional Security and Collaboration Design

(2a,b.1) Define Functional Security and

Collaboration Use Cases

(2a,b.2) Define Secure SubSystem

+ Collaboration Capable Subsystem

(2c) Initial Information Security Design

(2c.1) Define XML Schema Class

Diagram

(2c.2) Define Information Security

Requirements

Generated Functional, Collaborative & Information Secure System

(4) Refinement of Functional, COD/AWF and Information Security Design

(5) Combine Three Facets and Transition into Final Design

(6) Mapping to Enforcement Code and XACML Policies

(3a) Functional Security Design

Define Security

Features

Group Users

into Roles

Separation of Duty,

Delegation Authority

Select MAC

Features

[NEEDS MAC]

Security

Refinement

Process

[DONE]

[DONE]

[DONE]

[DONE]

[DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]

Create Collaboration

Workflow Name


Step/Workflow

Security Refinement

Process

Collaboration

Team

Collaboration

Obligation

(3b) Collaboration Security Design

[DONE]

[DONE]

[DONE]

[DONE] [DONE][NOT DONE] [NOT DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]

Define set of Roles with

Information Access

Determine Permissions

of Roles to Information

Create XML Role Slice

Diagrams for each Role

(3c) Information Security Design

Security Refinement

Process

[DONE]

[DONE]

[DONE]

[DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]

Security UML -61

Overall View – Initial DesignOverall View – Initial Design

(1) Main Security Design of the Application


(2a,b.1) Define Functional Security

and


(2a,b.2) Define Secure

SubSystem

+

Collaboration Capable

Subsystem


(2c.1) Define XML Schema

Class

Diagram

(2c.2) Define Information

Security Requirements

Security UML -62

Overall View – Functional SecurityOverall View – Functional Security


Define Security

Features

Group Users

into Roles

Separation of Duty,


Select MAC

Features

[NEEDS MAC]

Security

Refinement

Process

[DONE]

[DONE]

[DONE]

[DONE]

[DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]

Security UML -63

Overall View – Collaborative SecurityOverall View – Collaborative Security


Workflow Name


Step/Workflow

Security Refinement

Process

Collaboration

Team

Collaboration

Obligation


[DONE]

[DONE]

[DONE]


[NOT DONE]

[NOT DONE]

[NOT DONE]

Security UML -64

Overall View – Information SecurityOverall View – Information Security


Information Access






Security Refinement

Process

[DONE]

[DONE]

[DONE]

[DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]

Security UML -65

Overall View – Refinement and MappingsOverall View – Refinement and Mappings





Security UML -66

Complete ViewComplete View(1) Main Security Design of the Application


(2a,b.1) Define Functional Security and


(2a,b.2) Define Secure SubSystem

+ Collaboration Capable Subsystem


(2c.1) Define XML Schema Class

Diagram

(2c.2) Define Information Security

Requirements






Define Security

Features

Group Users

into Roles

Separation of Duty,


Select MAC

Features

[NEEDS MAC]

Security

Refinement

Process

[DONE]

[DONE]

[DONE]

[DONE]

[DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]


Workflow Name


Step/Workflow

Security Refinement

Process

Collaboration

Team

Collaboration

Obligation


[DONE]

[DONE]

[DONE]


[NOT DONE]

[NOT DONE]

[NOT DONE]


Information Access






Security Refinement

Process

[DONE]

[DONE]

[DONE]

[DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]

[NOT DONE]

Security UML -67

Other areas of interest for info securityOther areas of interest for info security Modeling of other access control modelsModeling of other access control models

Lattice Based Access Control (LBAC) Attribute Based Access Control (ABAC)

Collaboration and adaptive workflows from the Collaboration and adaptive workflows from the perspective of information securityperspective of information security Documents that are utilized by multiple

roles/individuals at the same time Hierarchically structured data with no validation Hierarchically structured data with no validation

agentsagents Specialized XML JSON and JSON-LD RDF OWL