Transcript PPTX - University of Connecticut

XML Security Framework
CSE
5810
Prof. Steven A. Demurjian, Sr.
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-1155
Storrs, CT 06269-1155
[email protected]
http://www.engr.uconn.edu/~steve
(860) 486 - 4818
XMLSecurity-1
CSE
5810
An XML Security Framework that
Integrates Role-Base, Mandatory, and
Discretionary Access Control Policies
Alberto De la Rosa Algarín
Major Advisor: Dr. Steven A. Demurjian
Associate Advisors: Dr. Jinbo Bi, Dr. Swapna Gokhale
Dr. Xiaoyan Wang,
XMLSecurity-2
Introduction

CSE
5810



Today’s Applications and Systems Built around
Multiple Technologies
 APIs, Cloud Computing, Web Services, Data
Mining, etc.
Alternative Data Structure Standards
 XML, RDF, JSON, OWL, etc.
Meta-Systems that Share, Use and Exchange
Information to fully function
 XML as de-facto Standard
What are the Top Security Challenges?
 Integrate Security Requirements of Existing
Systems
 Consolidate in Support of Newly Developed
Application
XMLSecurity-3
Tree-Structured Documents

CSE
5810


Documents that follow a tree structure
 Root node
 Certain amount of children
 Leaf nodes
Example of tree-structured document formats
 eXtensible Markup Language (XML)
 JSON (if written in a tree-structured form)
 RDF serializations
 Ontologies (e.g. Web Ontology Language, OWL)
XML and JSON extensively used
 Information Exchange
 SOAP
 REST
XMLSecurity-4
Secure Information Exchange

CSE
5810

XML Quickly Emerging as Standard of Choice for:
 Web Content
 Information Exchange
 Database Exchange
 Standard format for Tools (e.g., UML Tools
Export XMI)
 Etc.
Our Perspective, Given a Document Repository
 Each Document has a Schema
 Multiple Documents per Schema
 Users with Particular Roles in Application
 Can We Customize the Displayed Instance Based
on Role?
 How Can we Incorporate RBAC, LBAC, etc.?
XMLSecurity-5
Security for Tree-Structured Documents

CSE
5810



Can we Customize Instance
Based on Role?
Can we Incorporate RBAC,
LBAC, and DAC ?
Security Schemas Set
 Roles, Users, Constraints
 RBAC, LBAC, DAC
Apply Security Schemas to
Documents
 Security Schema Filters
Document
 Document Appears
Differently Based on Role,
MAC, Delegation
Security Schemas
n Role Schema
n User Schema
n Constraint Schema
Security Officer
Generates Security
XML files for the
Application
Application
DTDs and
XML
Application
Schemas
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
XMLSecurity-6
What is a Schema?
CSE
5810
XMLSecurity-7
What is a Schema?
CSE
5810
XMLSecurity-8
What is an Associated Instance?
CSE
5810
XMLSecurity-9
Attaining Security

CSE
5810

Given an Application of Schemas and Associated
Instances, can we:
 Define Schemas/Instances for Clearances, Roles,
Users, User-Role Authorizations, and Delegation
 Augment Application’s Schemas/Instances with
LBAC Security Classifications (if Needed)
Then, as Instances are Dynamically Identified to Suit a
User’s Needs for an Application, can we:
 Retrieve and Filter those Instance(s) Based on
User’s Role, LBAC, and/or Delegation
 Deliver Filtered Instances(s) to User
XMLSecurity-10
Main Research Questions

CSE
5810



How do we Provide a Solution that Operates across
Various Contexts?
 Information Exchange, Databases, Web Services,
etc.
 Integrates Local and Global Security
How do we Integrate and Support Major Access
Control Models?
 Role-Based Access Control (RBAC)
 Lattice-Based Access Control (LBAC)
 Discretionary Access Control (DAC)
How Can we Make Security Policies Changes without
Impacting Each Document?
How do we Enforce Security across Multiple
Interoperating Systems?
XMLSecurity-11
Attaining Security

CSE
5810


Given an Application of Schemas and Associated
Instances, can we:
 Define Schemas for Security Levels, Roles, UserRole Authorizations, and Delegation
 Augment Application’s Schemas/Instances with
MAC Security Classifications (if Needed)
Instances are Dynamically Filtered to Suit a User’s
Needs for an Application:
 Based on User’s Role, MAC, Delegation
 Deliver Filtered Instance(s) to User
Exploit eXtensible Access Control Markup Language
(XACML) or other Policy Languages for Policy
Generation
XMLSecurity-12
What is the Big Picture?

CSE
5810


An Security Framework for Secure Information
Engineering and Enforcement
 Provides Guidance and Structure for Information
Usage and Exchange
 Leverage Health Care Domain
Information Exchanged in Multiple Formats
 XML, JSON, RDF, OWL
Unify (Convert) Data
 Schema and Associated Documents
 Use, Share, Exchange Documents
 Provide Customized View based on User
 Exchange Information over Secure Network
 Provide a “Degree” of Security Assurance
XMLSecurity-13
Why Health Care Domain?

CSE
5810

Health Insurance Portability and Accountability Act
(HIPAA) provides Security Guidelines
 Usage, Transmission, and Sharing of Protected
Health Information (PHI)
 Protect Personally Identifiable Info (PII)
 Encryption and secure transmission of PHI and PII
(e.g., SSL, etc.)
In Practice, Security for Health Care goes well beyond
the Needs of Compliance to HIPAA
 What are the Available Technologies?
 What is the Role of Standards in Exchange?
 What are Standards for Security Policy Defining?
 What Needs to be Exchanged & Controlled?
XMLSecurity-14
Makeup of Health Care Landscape

CSE
5810

Health Information Technology (HIT) Standards
 HL7 Clinical Document Architecture (CDA)
 Continuity of Care Record (CCR)
 SNOMED, UMLS, LOINC, NDF-RT, etc.
HIT Systems
 Electronic Health Records (EHRs)
 VistA
 GE Centricity, AllScripts
 open HER, FreeMD, PatientOS

Personal Health Records (PHRs)
 Microsoft HealthVault

Patient Portals (PPs)
XMLSecurity-15
Interplay of Information in Health Care
Harvard
SMART
EHR
RxTerms
XML
Schema
LOINC
XML
Schema
SNOMED
XML
Schema
XML-C
Secure
XML
JSON
Secure
XML
UMLS
XML DTD
Standards
XML-C
RxNorm
XML
Schema
Secure
XML
XML
openEHR
Secure
XML
Global
Security
Policy and
Control
Health
Information
Exchange
PHA
Patient App
Mobile
JAVA APIs
HL7 CDA
PatientOS
MeSH
XML DTD
ASP.NET API
XML-C
REST API
Open
mHealth
C# Data
JSON-LD
CSE
5810
MS
Health
Vault
Secure
CDA
PHA
Provider
Mobile App
Secure
CDA
FreeMED
PHP APIs
HL7 CDA
Java APIs
XML Converter
Local Security
Policy/Control
SMARTSync
App
PHI
Secure PHI
XMLSecurity-16
Proposed Security Framework

CSE
5810
Security Framework Definition
 Extends the Unified Modeling Language
 Model RBAC, LBAC and DAC for Tree-Structured
Documents

Generates Enforcement policies in eXtensible
Access Control Markup Language (XACML)
 Target Schemas and Instances for any Application

Security Framework Enforcement
 Generating Global Enforcement Policy
 Leveraging UML diagrams
 Develop Mapping Algorithms to Facilitate the
Secure Interactions of Applications
XMLSecurity-17
Why Multiple Access Control Models?

CSE
5810

Filter Documents (Instances) based on:
 RBAC: Limit what Portions of Document can be
Read and/or Written (Nurse vs. MD)
 LBAC: Security Level may Limit Portions of a
Medical Record (Psychiatry Notes)
 DAC: Delegation of Authority for Emergent
Situations (ER MD Access External EHR)
Provide a Breath of Access Control Alternatives for
Multiple Domains
 Health Care
 E-commerce
 National Defense
XMLSecurity-18
What is the Big Picture?
CSE
5810
Secure
Data
HIT System
Data Sources
and Local Schemas
Secure
Data
MS
Health
Vault
ASP.NET API
Lattice-Based
Access
Control
Input
XML-C
Schemas
Discretionary
Access
Control
Enforcement
Mechanism
Secure
Data
HIT Application
Application
Instances
Open
mHealth
JSON
Security Framework
Local Security Policies
Java APIs
C# Data
Role-Based
Access
Control
HL7 CDA
PatientOS
HIE Server
Schemas
Generate
XACML
XACML Policy
Enforcement
Global
Security
Policies
Filtered
Instances
Medical
Provider
PHA
SMARTSync
XMLSecurity-19
Expected Research Contributions

CSE
5810

Security Model for Information Access Control
 RBAC, LBAC and DAC Support
Security Extensions for UML
 Represent schemas as UML-like Diagrams
 Augment with Security Features and Definitions

Security Policy Generation
 XACML Policy Generation
 Mapping from UML Diagrams,
 Algorithm for Automatic Generation

Secure Information Engineering
 Process for Secure System Creation
 Target Data to be Secured
XMLSecurity-20
Remainder of Presentation

CSE
5810







Background
 UML, Access Control, XML, XACML
Security Model for Tree-Structured Documents
 RBAC, LBAC and DAC Support
UML Diagram Extensions and Metamodel
 DSCD, DRSD, SID, LSID, UD, DD, AD
Security Policy Generation
 Mapping Statements and Algorithm
Secure Information Engineering Process
 Development Cycle
 Example Use-Case
Conclusion and Contributions
Ongoing Research and Future Directions
Publications, In Review and Work in Progress
XMLSecurity-21
Unified Modeling Language

CSE
5810
UML Diagrams Exhibit Two Views of a System’s
Model
 Structural View
 Objects, Attributes, Operations, Relationships

Behavioral View
 Collaboration Among Objects and Changes to Internal
States

Different Kinds of Diagrams for System Modeling
 Structure, Representing Components in the System
 Behavior, Representing Series of Events that Must
Happen
 Interaction, Representing Data and Control-Flow
between Components
XMLSecurity-22
Access Control Models

CSE
5810


Role-Based Access Control (RBAC)
 Permissions assigned to Roles, Roles assigned to
Users
Lattice-Based Access Control (LBAC)
 Sensitivity Levels for data (classification) and
users (clearance)
 Policies defined and set by a Security
Administrator
Discretionary Access Control (DAC)
 Access to Objects is Permitted or Denied based on
the Subject’s Identity
 Users are capable of passing Permissions to other
Users
XMLSecurity-23
eXtensible Markup Language (XML)

CSE
5810


Provides a Common, Structured Language
 Independent of Systems
Information Hierarchically Structured and Tagged
 Tags can Offer Semantics
XML schemas
 Blueprints for new Instances
 Validation Agents
 Achieved with
 XML Schema Definition (XSD)
 XML Schema Language (XSL)
XMLSecurity-24
Sample XML from CCR Standard
CSE
5810
<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"
XMLSecurity-25
eXtensible Access Control Markup Language

CSE
5810


Aims to Define a Common Language and Processing
Model
 Permits a Level of Security Interoperability
XACML schema Provides Several Structures and
Elements to Represent Policies
 PolicySet, Policy, Rule
PolicySets and Rules Combined by Policy/Rule
Combination Algorithm
 Permit-overrides
 Deny-overrides
 First-applicable
 Only-one-applicable
PolicySet
Policy Combination
Algorithm
Policy
Rule Combination
Algorithm
Rule
Resource
Subject
Action
XMLSecurity-26
Introducing Security with our Framework
CSE
5810
SchemaCIS1
SchemaCIS3 SchemaCIS4
SchemaLSIA2
Security
Definition
Policy
Generation
Security Model and Policy Generation
Access Control Models
Lattice-Based
Access Control
Role-Based Access
Control
Discretionary
Access Control
Information Security Extensions to UML
Document
Schema Class
Diagram
Document Role
Slice Diagram
SECURITY SCHEMA
MODELING
SECURE INFORMATION ENGINEERING
Schema
Modeling
SchemaCIS2
SchemaLSIA1
LBAC & DAC
Features
Generated Security Policies
Roles, Actions,
Resources
Element Sensitivity
User Clearance
Delegations
and
Authorizations
XMLSecurity-27
Security Model

CSE
5810




Need to provide all relevant stakeholders with some
degree of assurance on the different capabilities of
RBAC, LBAC and DAC
Support any document format that follows a treestructure for representation
 XML, JSON, RDF, OWL, etc.
Support of major NIST RBAC capabilities
 Roles, Permissions, Assignments, Mutual
Exclusion, etc.
Support for LBAC capabilities
 Classifications to all application schemas and their
elements and define clearances for users.
Ability to support DAC
 Delegation of role from user to user and the ability
to pass on the delegation.
XMLSecurity-28
Model: Application, Schema, Instances, and Users
CSE
5810
Information and data is represented in a tree structure with a root node , where non-leaf nodes
provide context (metadata, element name, typing information, cardinality constraints, etc.), and
leaf nodes offer a place to store data values.
A schema is defined to organize the structure and content of a tree and act as a blueprint for
instances. Schemas have the basic structures and context information (such as cardinality
constraints, etc.). Akin to classes in an object-oriented programming languages or relations in
a database, they contain the meta-data that describes the structure, elements, typing, etc. of a
schema.
A schema can be instantiated which means that the actual data is created and defined.
The
structure and data in an instance is validated against it respective schema. This is equivalent to
classes in object-oriented programming languages (create an instance of the person class) and
to databases (create a tuple in a relation).
RBAC and LBAC are orthogonal. That is, each one can live independently from the other in
case an application only needs RBAC or LBAC security.
XMLSecurity-29
Model: Application, Schema, Instances, and Users
CSE
5810
Defn. 1: An element e  eID , eNAME  is defined as an ordered pair component in a
hierarchical data structure that contains information against which operations are
performed, where eID is a unique identifier for the element and eNAME is the tag of
the element.
Defn. 2: A schema S  S ID , S NAME , E  is defined as a hierarchical organization of
n elements represented as a set E  {e1 , e2 ,..., en } for a given purpose in the form of
a tree, where every ei  S and there is a single root node in the tree of the schema
S . In this case, S ID is a unique identifier for the schema S , and S NAME is the tag
of the schema.
Defn. 3: An instance i  iID , iNAME  of a schema S is referred to as a document that
contains values for each of the n elements; instances must follow the structure of
a schema, where iID is the unique identifier for the instance and i NAME is the tag that
describes the instance.
S j has an instance set
I j which is defined as
Defn. 4: Each schema
I j  {i j1 , i j2 ,..., i jms } that contains ms instances where each instance follows the
format of the n elements that are defined by E and is validated against S j .
Defn. 5: An application A is comprised of set of k schemas and g instance set pairs
A  { S1 , I1 ,  S1 , I 2 ,  S 2 , I1 ,...  S k , I g } where each pair represents one
aspect of the information needs of an application.
Defn. 6: A user u is defined as a pair  u ID , u NAME  that will have the ability to
access portions of an application and uniquely identifies each user by uID .
j users for a given
Defn. 7: Let U  {u1 , u 2 ,..., u j } be defined as the set of
application A , where u j  U and u j  uID j , u NAME j  .
XMLSecurity-30
Example of Model
CSE
5810
XMLSecurity-31
CDA Instance
CSE
5810
XMLSecurity-32
CDA Instance
CSE
5810
XMLSecurity-33
CCR Instance
CSE
5810
XMLSecurity-34
CCR Instance
CSE
5810
XMLSecurity-35
Model: Schema Operations for RBAC, LBAC, and DAC
CSE
5810
A schema is a hierarchically structured collection of elements
which can be altered via a
schema projection operation (SPO), denoted as|rP|c|e , that can filter the tree into a proper subtree.
S iP ( r |c|e ) is the result of a projection |rP|c|e of S i that effectively identifies the subset of S i that
has been filtered. Using this notation : S iPr means that a role has been utilized to create a
subtree of the original schema that represents all of the elements allowed for role r; S iPc means
that a CLS c (e.g., TS, C, etc.) has been utilized to create a subtree the original schema that
represents all of the elements allowed for that c; and, S iPe means that a subtree of the original
schema) that represents all of the elements of the schema that need to be protected.
Given a projection S iP ( r |c|e ) of schema S i , the instance set is also projected, creating I iP ( r |c|e )
which are now filtered instances for the schema that must follow the structure of the filtered
schema. This yields an instance that has been project by role r, CLS c, elements e of the schema.
A schema which is a hierarchically structured collection of elements can be extended via a
decoration operation, denoted as |c|Dt , over a criterion that alters the form of the elements by
adding new information in the form of LBAC sensitivity levels or time constraints.
S iD ( c|t ) is the result of a decoration |c|Dt of S i that effectively identifies the decorated version
of S i based on LBAC sensitivity levels. Using this notation: S iDc means that CLSs chosen
from the set of all possible sensitivity levels (e.g., S, TC, C, U) have been added to all of the
elements of the original schema ; and, S iDt means that time constraints have be included that
represent the allowable timeframe for each element.
Given a decoration S iD (c ) of schema S i , the instance set is also decorated, creating I iD (c ) which
are now decorated instances for the schema that must follow thenew structure of the decorated
schema. This yields an instance that has expanded by classification or time.
XMLSecurity-36
Model: Schema Operations for RBAC, LBAC, and DAC
CSE
5810
Defn. 8a. |rP is a schema projection operation (SPO) over an RBAC role r and tree
such that the end result of the action is the creation of a pruned tree by RBAC
role that is a subset of the tree being projected , meaning that the projected subtree
is a subset of the original schema
to represent which portions of the original
~
schema can be access by role . In our notation, for a schema S i , SiPr  Si |rP means
~
that SiPr is a projected version of S i with respect to a role r , the results of a
filtering action.
Defn. 8b. |cP is a schema projection operation (SPO) over an LBAC sensitivity c
and tree such that the end result of the action is the creation of a pruned tree by
LBAC that is a subset of the original schema to represent the portion of original
~
tree that has a sensitivity level c . In our notation, for a schema S i , SiPc  Si |cP
~
means that S iPc is a projected version of S i with respect to an c , the results of a
filtering action.
Defn. 8c. |eP is a schema projection operation (SPO) over elements e and tree such
that the end result of the action is the creation of a pruned tree that is a subset of
the tree being projected , meaning that the projected subtree is a subset of the
original schema to represent the porti on of original tree that has had elements
deleted resulting in a subtree of the original tree that has the elements to be
~
~
secured. . In our notation, for a schema S i , SiPe  Si |eP means that S iPe is a projected
version of S i with respect to elements e , the results of a filtering action.
Defn. 9: |cD is a schema decoration operation (SDO) over LBAC and tree such that
the end result of the decoration is the creation of an expanded tree with sensitivity
level or classifications on the elements of the tree. In our notation, for a schema
~
~
S i , Sid  Si |cD means that SiDc is an expanded version of S i with respect to LBAC,
the results of a decoration action.
~
Defn. 10: A P ( r|c|e)|D (c )  A is a subset of the information in an application’s schemas
that need to be protected through a process of
SPO and/or SDO . Specifically,
~ P ( r |c|e)| D ( c )
~ P ( r|c|e)| D ( c ) ~ P ( r |c|e)| D ( c )
~ P ( r |c|e)| D ( c ) ~ P ( r|c|e)| D ( c )
A
 { S1
, I1
,...,  S m
, In
} is the result of an
SPO and/or SDO on the original k schema/instance set pairs , that results in the
creation of a set of m schemas where the information that needs to be secured
and is available for access control has been identified.
XMLSecurity-37
Projecting Instances – Define Projection
CSE
5810
XMLSecurity-38
Projecting Instances – Apply CDAProjection
CSE
5810
XMLSecurity-39
Projecting Instances – Apply CCR Projection
CSE
5810
XMLSecurity-40
Model: RBAC Security
CSE
5810
A schema that contains a set of elements has defined, for each of the elements, a set of
operations that are allowable, namely: read, aggregate, insert, update, and delete. These
operations dictate the way that each element can be utilized.
A role is a means to characterize privileges that are based on usage behaviors of the application
coupled with needed functionality to arrive at a construct (role) that is able to quantify a
common set of responsibilities that are shared by multiple users. Roles will be authorized to
utilize different portions of the schema and instances for an information application.
Each
application has a set of roles.
A permission is defined on each element in a schema by associating an element (by id) with an
operation. The collection of all permissions for all roles across all schemas of an application is
the role-based permission set, where each set member binds a permission to a role.
The schema projection operation (SPO) (see Defn. 8a) can be applied by role in order to
identify the elements of each schema and the associated permissions per role.
XMLSecurity-41
Model: RBAC Security
CSE
5810
Defn. 9: A role r is defined as a two -pair r rID, rNAME representation of the
responsibilities for a user u U to access some portion (entire or further
restricted) of a schema.
Defn. 10: Let R  {r1, r2 ,..., r j } be defined as the set of j roles for a given application
A , where r j  R and r j  rID , rNAME  .
j
j
Defn. 6 (RBAC Version):
A user that has been authorized to RBAC (but not
LBAC) redefines theuser u as a tuple  u ID , u NAME, u r  , where u r is the role Defn. 19: SoD denotes separation of duty between roles which means that, given rx
SoD ry , with rx R and ry R , a user with role rx cannot be assigned and perform
as defined in Defn. 26. Note that a user can be authorized to more than one role,
but is limited to playing one role in any application session.
any permissions of role ry , where the two tuple  rx , ry  SoD represents the SoD
Defn. 11: There exists a schema projection operation |rP by role that acts on a
between the two roles . The set SoD contains all the pairs of roles that have a
~
separation of duty relation.
schema Si , and yields a filtered version S iPr for any given role r  R . This results
r
Defn.
20: For a given role rx , the set SoD  { rx , ri | rx , ri  SoD"i} where i
in what is referred to as a role-secured schema.
~
~ ~
~
iterates over all of the roles in R.
Defn. 12: The set of role -secured schemas ASPr  (S1Pr , S2Pr ,..., SiPr ) is the set of role
Defn. 21: ME denotes separation of duty between roles that is strictly defined as two
~r
projections of S i for role r , for any given schema i , where i  1,2,..., m .
roles not allowed to have any permissions in common which means that , given rx
Defn. 13: Let O  {read, aggregate, insert, update, delete} be the set of operations
ME ry , with rx R and ry R , the set of RPA does not have pairs with rx and ry
that can be performed against an element in each schema from either an original
where the pID are the same. This defines a set ME that contains all the pair of roles
or a projected and/or decorated tree. The operation is defined at the schema level
that have a mutual exclusion relation. More specifically,  rx , ry  ME .

to be applied at the instance level. For permissions, each op O will be assigned
ID
ID
x
to individual roles.
Defn. 14: A permission p is represented by the four tuple p  pID , sID , eID , op  ,
where pID is the unique identifier of the permission (akin to uID and rID ), s ID is
~
~
the identifier of a schema Si P ( r|c|e )|D ( c )  ASP ( r|c|e )|D ( c ) and e ID is the identifier of an
~
element el  S i P ( r|c|e )|D ( c ) for some i  1,2,..., m , meaning that operation op can be
performed on the element (node) identified by
~ P ( r|c|e )|D ( c )
Si
of the application.
eID constrained to the schema
r
Defn. 22: For a given role rx , the set ME x  { rx , ri | rx , ri  ME A "i} where i
iterates over all of the roles in R.
Defn. 6 (RBAC with SoD and ME): A user that has been authorized to RBAC
with SoD and ME constraints redefines the
user u as a tuple
 u ID , u NAME , rID , SoD rID , ME rID  , where SoDrID is the resulting set of roles that
have a separation of duty for role rID and ME
have a mutual exclusion with rID .
rID
is the resulting set of roles that
Defn. 15: Let P  {p1 , p2 ,..., pz } be defined as the set of all granular permissions in
a given application A, where a p ermission p  P . That is, P is the set of all
permissions defined by the security administrator in a given applicationA.
Defn. 16: The set of all permission
s, the role -permission assignments





RPA { rID , p ID ,..., rID , pID } , where rID is the identifier of a role r as
1
1
k
n
defined in Defn. 12, and pID is the identifier of a permissionp as defined in Defn.
16, contains all the role-permissions pairs meaning that role with identifier rID
can perform the permission with identifier pID .
XMLSecurity-42
Examples
CSE
5810
XMLSecurity-43
Model: LBAC Security
CSE
5810
There exists a lattice of sensitivity labels that covers mandatory access control features in a
generalized manner. These sensitivity levels correspond to classifications that are assigned to
schema elements (see Defn. 1) and clearances that are assigned to users (see Defn. 6).
The lattice L of sensitivity levels is constructed from sensitivity levels thatare bound by upper
(most secure) and lower (least secure) values (see Defns. 19 to 23).
In support of our security model, we specialize from a lattice
L of sensitivity levels to an
ordered set SL  {x1 , x 2 ,..., x q } of sensitivity levels , where SL , x1  x 2  ...  x q . This means
that x q represents the most secure sensitivity level and
x1 represents the least secure sensitivity
level (see Defn. 24).
An element of a schema can be assigned a sensitivity level (classification) with a user being
assigned a clearance. Since schema elements can be either be context nodes (refer to other
elements) or data nodes, and each can be assigned a classification. In a subtree of a schema,
the classification of a node cannot be more secure than the classifications of its children, and
the entire tree’s schema when annotated with classifications must satisfy the lattice relationship
of sensitivity levels (e.g., in MAC, TS > S > C > U) with the least secure level tending toward
the top of the tree and the most secure level tending towards the bottom of the tree.
XMLSecurity-44
Model: LBAC Security
CSE
5810
Defn. 23: A partial order relation
< is a binary relation that is reflexive,
antisymmetric , and transitive.
Defn. 24: A lattice is a structure with a set LS , a partial order <, and two binary
operations: infimum and supremum.
Defn. 25: Let a,bLS . infimum(a,b) is called the greatest lower bound of a and b , or
meet, and, supremum(a,b) is called the least upper bound , or join of a and b, such
that:
a. For any a,bLS , infimum(a, b) < infimum(a, b) < b, and for any g LS , if
g < a and g <b then g < infimum(a, b).
b. For any a,bLS , a < supremum(a, b) and b < supremum(a, b), and for any
g  LS , if a < g and b < g, then supremum(a, b) < g.
Defn. 26: If for any given a,b LS , with < as the partial order relation, we have that
a < b or b < a , then we call LS a chain or totally ordered set.
Defn. 27: We call a lattice L  (LS ,<) bounded if there exist elements top (?) and
bottom (?) such that for any a ? LS, ? < a < ?.
Defn. 28: Define SL  {sl1 , sl2 ,...,slq } to be the partially ordered set of q consecutive
Defn. 33: AM  { AM  READ, AM  WRITE} is the set of access modes that are
AM-READ category
used to categorize the multiple read oriented operations into the
and multiple write operations in theAM-WRITE categorythat act against the secured
tree nodes.
Defn. 34: Each op  O has an access modeassigned based on the operation
. For nondestructive operationssuch as {read, aggregate} have am  AM  READ, while
destructive operationssuch as {insert, update, delete} have am  AM  WRITE .
Defn. 6 (LBAC Version):
A user that has been authorized to LBAC (but not
RBAC) redefines the user u as a tuple  u ID , u NAME , uCLR , u LBACR , u LBACW  , where
u LBAC R / W are either SS, SI, LS, SSR, or SSW.
sensitivity levels for the application where sl1 represents the least secure and sl q
represents the most secure; an individual level is referred to as sl  SL .
Defn. 29: Given a, b  SL, the expression a  b denotes that b has a higher sensitivity
(classification or clearance) than a, which means that b is more secure. Similarly,
the expression a  b denotes that a and b have the same sensitivity.
Defn. 30: We define a lattice L  (SL, ) as the lattice of sensitivity levels in an
application A, ordered by the relation < which has replaced < as defined in Defn.
19.
D
Defn. 31: Let S~iDc be the subtree that results from the decoration
Si |c as defined in
~
Dc
Defn. 9 . The nodes of
Si are LBAC decorated and in the form of
el eID,eNAME,eSL , where el  Si or el  SiP(r|c|e) and eSL  SL for any i. As a result,
the schema has been extended due to the addition of an element for
eSL .
~ P( r|c|e)
Defn. 18:
If some node in a secure schema, e  Si
with classification eSL ,
has children nodes e1 and e2 , then the classification e1,SL and e2,SL must be equal to
or higher than the classification eSL . That is, eSL < e1,SL or eSL  e1,SL and eSL < e2,SL
or eSL  e2,SL . This definition means that the least secure levels migrate towards the
top of the tree of the schema while the more secure level migratetowards the bottom
leaf nodes.
XMLSecurity-45
Examples
CSE
5810
XMLSecurity-46
LBAC in CDA Instance
CSE
5810
XMLSecurity-47
LBAC in CCR Instance
CSE
5810
XMLSecurity-48
Model: DAC Delegations
CSE
5810
There exists a set of original users that have assigned roles and the ability to delegate those
roles.
There is a set of delegable users that have the ability to receive roles from original users.
Pass-on delegation is an ability given to original users that allows an individual the authority
to delegate the role even further. This means that an original user can delegate a role to a
delegable user with pass -on delegation, resulting in the permission of that delegable user to
pass the role on one step further to another user.
Delegation of roles is only allowed to delegable users. This means that original users can
delegate the role to a user in the delegable users set, and in the case that pass-on delegation is
authorized, the receiving delegable user can delegate the role to ano ther user in the delegable
users set.
XMLSecurity-49
Model: DAC Delegations
CSE
5810
Defn. 35: Let DelRoles  R , where DelRoles  {r1 , r2 ,..., ry } and ry  R , be defined as
the subset of all roles that are eligible for delegation.
Defn. 36: The set of Original Users, OU  U  DelRoles , OU  U  DelRoles , where
DU  { u1 , r1 ,...,  u x , ry } , is the set of original users with their assigned roles.
That is, the members of OU have the form  u x , ry  OU , which means that the
user with identifier uID is allowed to delegate the role with identifier ry .
Defn. 37: The set of
Delegable Users ,
DU  U  DelRoles , where





DU { u1 , r1 ,..., u x , ry } , is the set of delegable users w ith the roles they are
allowed to receive as part of a delegation. The members of DU have the form of
 u x , ry  DU , which means that the user u x can receive the role with identifier
ry when delegated by another user.
Defn. 38: Pass-On Delegation, or PoD, is a Boolean {0,1} that indicates whether a
user and role pair  u x , rx  DU can delegate the role rx , originally received by a
user and role pair  u y , rx  OU , one further step to another user u z that is set as
 u z , rx  DU . In this case, a PoD value of 0 means that the delegation has
no
pass-on authority. A value of 1 means that the delegation has a pass-on authority.
Defn. 39: Delegable, or Del, is a Boolean {0,1} that indicate whether a user and role
pair  u y , ry OU or a user and role pair  u x , rx  DU can execute the
permission of delegation to another user and role pair u z , rz  DU , where rz  ry
or rz  rx .
Defn. 6 (RBAC with Delegation):
A user that has been authorized to RBAC
(but not LBAC) redefines the user u as a tuple  u ID , u NAME , rID , Del , PoD  , where
Del true means that the role can be delegated and when PoD true means that the
authority to delegate that role can be passed on when the role is delegated. If Del
is false, PoD must be false; if Del is true, PoD can be either true or false.
XMLSecurity-50
Model: User Authorizations
CSE
5810
Defn. 40: The set of authorized schemas, AS  { uID1 , rID1 , sID1 ,...,  uIDx , rIDy , sIDz }
,
is defined as the schemas from the application A that have been assigned to a
 uID , rID , sID  AS represents an
user/role combination. That i s, the tuple
authorized schema to a user/role combination, where uID is the unique identifier for
a user u U , rID is the unique identifier for a role r  R , and s ID is the unique
identifier for a schema S  A , where S is a role -secured schema or an LBAC
decorated schema.
Defn. 41: The set of authorized instances ( AI) is defined as the instances from the
application A that have been assigned to a user/role combination. That is, the tuple
 uID , rID , iID  AI represents an authorized instance to a user/role combination,
where uID is the unique identifier for a user u U , rID is the unique identifier for
a role r  R , and iID is the unique identifier for an instance i  A .
Defn. 6 (LBAC + RBAC):
A user that has been authorized to both RBAC and
LBAC redefines the
user u
as a tuple
rID
rID
 u ID , u NAME , u CLR , u LBAC  R , u LBAC W , rID , SoD , ME , Del , PoD  , where u ID is the
unique identifier for the user, u NAME is the tag for the user u, uCLR is the clearance
level assigned to the user (per LBAC components),
u LBAC R / W are either SS, SI,
LS, SSR, or SSW , rID is the unique identifier for the assigned role r  R , SoD rID is
r
the resulting set of roles that have a separation of duty for role
rID , ME ID is the
resulting set of roles that have a mutual exclusion with rID , Del means that the role
with the identifier u rID can be delegated (Boolean value), and PoD means that passon delegation is allowed or not (Boolean value).
XMLSecurity-51
Delegation and Users
CSE
5810
UserID, Name, RoleID, DA, PODA
CLR, Dom, RoleID, SoD, ME, DA, PODA
XMLSecurity-52
Example Process
Original Schema
CSE
5810
S
r
Original
tree-structured
schema
D
SL = {x1, x2, ….}
c
L = (SL, <)
~
~
S
~
S
r
3
r
2
3
2
3
P
2
2
3
3
2
2
R
LBAC
Decorated
2
1
1
1
2
2
1
RBAC
projected
for role R
1
1
1
XMLSecurity-53
Security Framework

CSE
5810
Security Schema and Policy Generation
 Schema Modeling via Seven Security Extensions
to UML








Document Schema Class Diagram (DSCD)
Document Role Slice Diagram (DRSD)
Secure Information Diagram (SID)
LBAC Secure Information Diagram (LSID)
User Diagram (UD)
Delegation Diagram (DD)
Authorization Diagram (AD)
XACML Policy Generation
 Mapping Process from Diagrams to Enforcement
XACML Instances
XMLSecurity-54
Securing Schemas with our Framework

CSE
5810
UML provides diagrams to model applications
 Lack of diagrams for Security
 Pavlich-Mariscal defined new UML diagrams for
RBAC in the Metamodel layer




Document Schema Class Diagram (DSCD)
 UML Representation of the schema
For RBAC, Document Role Slice Diagram (DRSD)
 Security Augmented Representation of schema
Elements, Roles and Permissions
For LBAC, LBAC Secure Information Diagram
(LSID)
 Security Augmented Representation of schema
with classification levels
For DAC and Authorizations, the Delegation and
Authorization Diagrams (DD and AD)
XMLSecurity-55
Document Schema Class Diagram (DSCD)

CSE
5810

An artifact that holds all the characteristics of an
schema
 Structure, Data Type, Value Constraints
Hierarchical nature of schemas is modeled via a UML
Profile
 xs:complexType, xs:element, xs:sequence
 Child Relations (xs:element, xs:sequene,
xs:simpleType)
 xs:extension
 Data-type Cardinality Requirements and
Constraints; type
XMLSecurity-56
UML Profile for DSCD
CSE
5810
XMLSecurity-57
CDA Schema Segment
CSE
5810
XMLSecurity-58
CCR Schema Segment
CSE
5810
XMLSecurity-59
CCR Schema Segment
CSE
5810
XMLSecurity-60
Example DSCD for the HL7 CDA XML Schema
CSE
5810
XMLSecurity-61
Example DSCD for the HL7 CDA XML Schema
CSE
5810
XMLSecurity-62
Example DSCD for the CCR XML Schema
CSE
5810
XMLSecurity-63
Example DSCD for the CCR XML Schema
CSE
5810
XMLSecurity-64
Secure Information Diagram (SID)

CSE
5810

Represents those elements from the DSCD that require
some type of security
 RBAC permissions
 LBAC classification
Results from the projection operation over the original
schema diagram
 Truncates the original schema by some criteria
 Elements, Roles, Classification
XMLSecurity-65
Secure Information Diagram (SID)
CSE
5810
XMLSecurity-66
Document Role Slice Diagram (DRSD)

CSE
5810
Represents Access Control Definitions on DSCD
Attributes for RBAC
 Fine Grained Control through Security Policies and
Definitions to the DSCD
 Permissions on Documents with operations
– Read, Aggregate, Insert, Update, Delete

Represented in the DRSD with Stereotypes:
 On a access() method for the class





«read» (non-destructive)
«aggregate» (non-destructive)
«insert» (destructive)
«update» (destructive)
«delete» (destructive)
XMLSecurity-67
Document Role Slice Diagram (DRSD)
CSE
5810
XMLSecurity-68
Document Role Slice Diagram (DRSD)
CSE
5810
XMLSecurity-69
LBAC Secure Information Diagram (LSID)
CSE
5810
XMLSecurity-70
LBAC Secure Information Diagram (LSID)

CSE
5810

Similar to SID
 Represents those elements of the DSCD that
require LBAC Sensitivities
UML package with the stereotype
«SecureInformation» that decorates the
 Contains all of the respective classes of elements
from the schema to be secured
 Access modes (ams)
 Classifications (cls)
«SecureInformation»
ClinicalDocumentArchitectureSystem
«SecureInformation»
ContinuityOfCareRecordSystem
«element»
«ref» name=“legal_authenticator”
{ am=read, cls=c }
«element»
«ref» name=“patient”
{ am=read, cls=u }
{ am=write, cls=c }
«element»
«name» “Assessment”
{ am=read, cls=c }
«element»
«ref» name=“Vital Signs”
{ am=read, cls=c }
{ am=write, cls=c }
«element» Patient
«constraint» maxOccurs=“2”
{ am=read, cls=c }
«element»
«ref» name=“originating_organization”
{ am=read, cls=c }
«element»
«name» “Allergies”
{ am=read, cls=c }
«element»
«name» “Past Medical History”
{ am=read, cls=c }
{ am=write, cls=s }
«element» Body
{ am=read, cls=c }
«element» Problems
«constraint» minOccurs=“0”
{ am=read, cls=c }
«element» FamilyHistory
«constraint» minOccurs=“0”
{ am=read, cls=c }
XMLSecurity-71
User Diagram (UD)

CSE
5810
Fulfills the need to quantify different users of the
system
 Their requirements and constraints
 Define the users of the system whose information is to
be secured.

The interplay of users, roles and delegation
permissions, clearance levels, and authorization
permissions
 Jaime proposed a UML extension for users via a
User Diagram.
 We build upon it for information security
XMLSecurity-72
User Diagram (UD)
CSE
5810
XMLSecurity-73
Delegation Diagram (DD)

CSE
5810

Captures the information of the security model’s
delegation
 Mechanisms as a new UML diagram extension
Meant to capture the concepts
 Original user
 Role assigned
 Delegable users
 Role delegation
XMLSecurity-74
Authorization Diagram (DD)

CSE
5810

Illustrates a particular user/role combination
 Connected to authorizations to particular schemas
and/or their instances
Authorizations are used to augment security by
providing another layer of verification.
 If a user has permissions defined over a specific
schema, but is not authorized to it, then that user
cannot perform any of the permissions.
 A user may have permission to access a particular
schema but have no assigned instances.
XMLSecurity-75
Authorization Diagram (DD)
CSE
5810
XMLSecurity-76
UML Metamodel
CSE
5810
XMLSecurity-77
Generating Enforcement Policies

CSE
5810


UML has a long history for the automatic generation of code in
varied languages
 Our usage of our new UML diagrams to generate a security
policy is consistent with this
Define a set of mapping statements (MSs)
 Utilized to define the conditions under which the
combination of the various diagrams (DSCD, SID, DRSD,
LSID, UD, DD, and AD)
 Utilized to support the creation of respective policies for
RBAC, LBAC, DAC, and authorization
A mapping rule (MR) is defined to take the security model
concepts and capabilities and the new the UML diagrams to
yield a portion of the security policy
 For example, an XACML Policy’s <Target> Subject is the
role and role identifier set as a <role> subtree with
<roleName> and <roleID> children that corresponds to the
DRSD package name.
XMLSecurity-78
Generating Enforcement Policies
RBAC
Mappings
Users, Roles &
Permissions
LBAC
Mappings
Users, CLRs,
Elements, CLSs &
Operations
DAC
Delegations
Mappings
Users & Roles
Authorizations
Mappings
Users, Schemas
& Instances
Secure Information
Diagram
(SID)
LBAC Secure
Information
Diagram (LSID)
Document Role
Slice Diagram
(DRSD)
User Diagram
(UD)
Authorization
Diagram
(AD)
AOP
Delegation Diagram
(DD)
Generated Policy
XACML
Policies
Document Schema
Class Diagram
(DSCD)
Policy Components
SQL
Database
Access Control Model
Automatic Policy Generation
CSE
5810
XMLSecurity-79
Mapping Process
CSE
5810
XMLSecurity-80
XACML
CSE
5810
XMLSecurity-81
RBAC Mapping Statements
Mapping
Statement
Type
Involved
UML
Diagram(s)
CSE
5810
R-MS
(Role
Mapping
Statements)
DRSD, UD
P-MS
(Permission
Mapping
Statements)
DRSD, SID
E-MS
(Element
Mapping
Statements)
DRSD,
DSCD, SID
Mapping Statements
R-MS1. XACML Policy’s <Target>Subject is the role and
role identifier set as a <role> subtree with
<roleName> and <roleID> children that corresponds
to the DRSD package name.
R-MS2. XACML Policy’s <Target>Subject is the user
name and user identifier set as a <user> subtree with
<name> and <id> children that corresponds to the
UD.
R-MS3. SubjectMatch’s MatchId uses the function “stringequal” to evaluate the user’s role as modeled in the
DRSD.
R-MS4. AttributeValue of the Subject is a string, and the
value is the «DRSD» Role.
R-MS5. SubjectAttributeDesignator’s AttributeId is the role
attribute.
R-MS6. As many Rule per role Policy as permission
combinations.
R-MS7. Subject in Rule is set as the Subject in the higherlevel <Target> (role).
P-MS1. XACML Policy’s <Target>Action set to
<AnyAction /> to ensure that the higher-level policy
applies to the role.
P-MS2. ActionMatch’s MatchId uses the function “stringequal”.
P-MS3. ActionAttributeDesignator’s AttributeId set to the
operation’s tag (e.g. read, aggregate, insert, update,
delete).
P-MS4. Rule’s <Actions> children are <Operation> with
the operation name (<operationName>) and access
mode (<opAccessMode>) that correspond to the
stereotypes of the +access() method in the
«element» classes in the DRSD package.
E-MS1. XACML Policy’s <Target>Resource set to
<AnyResource /> to ensure that the higher-level
policies applies to the role.
E-MS2. Each Resource’s ResourceMatch has a MatchId
that determines the usage of the function “stringequal”.
E-MS3. Rule’s <Resources> children are <element> with
the element identifier (<elementID>) and element
name (<elementName>) that correspond to the
«element» classes in the DRSD, DSCD and SID
packages.
XMLSecurity-82
Mapping Process
CSE
5810
XMLSecurity-83
Mapping Process
CSE
5810
XMLSecurity-84
Mapping Process
CSE
5810
XMLSecurity-85
LBAC Mapping Statements
CSE
5810
Mapping
Statement
Type
Involved
UML
Diagram(s)
SU-MS
(Subject
User
Mapping
Statements)
UD
AO-MS
(Action
Operation
Mapping
Statements)
UD, SID,
LSID
RE-MS
(Resource
Element
Mapping
Statements)
DSCD, SID,
LSID
Mapping Statements
SU-MS1.
XACML Policy’s <Target> Subject is the
user and user identifier set as a <user> subtree with
<name> and <id> children that corresponds to the
«User» package of the UD.
SU-MS2.
SubjectMatch’s MatchId uses the function
“string-equal” to evaluate the user’s name and id as
modeled in the UD and the security model.
SU-MS3.
Subject in Rule is set as the Subject in the
higher-level <Target> (user).
SU-MS4.
Subject in Rule is extended with a
<clearance> element that corresp onds to the LBAC
clearance from the UD.
AO-MS1.
XACML Policy’s <Target> Action set to
<AnyAction /> to ensure that the higher-level policy
applies to the user.
AO-MS2.
ActionMatch’s MatchId uses the function
“string-equal”.
AO-MS3.
ActionAttributeDesignator’s AttributeId set
to the operation’s tag (e.g. read, aggregate, insert,
update, delete).
AO-MS4.
Rule’s <Actions> children are <Operation>
with the operation name (<operationName>) and access
mode (<opAc cessMode>) that corresponds to the
members of the stereotyped «element» classes of the
LSID.
RE-MS1.
XACML Policy’s <Target> Resource set to
<AnyResource /> to ensure that thehigher-level policies
applies to the user.
RE-MS2.
Each Resource’s ResourceMatch has a
MatchId that determines the usage of the function
“string-equal”.
RE-MS3.
Rule’s <Resources> children are <element>
with the element identifier (<elementID>), element
name (<elementName>), LBAC cla
ssification
(<classification>), and access mode (<accessMode>)
that corresponds to the stereotyped «element» class of
the LSID.
XMLSecurity-86
Mapping Process
CSE
5810
XMLSecurity-87
Mapping Process
CSE
5810
XMLSecurity-88
DAC Delegation Mapping Statements
CSE
5810
Mapping
Statement
Type
Involved
UML
Diagram(s)
UD, DD
DSOU-MS1. XACML Policy’s <Target> Subject is the
user and user identifier set as a < user> subtree with
<name> and <id> children that corresponds to the
«User» package of the DD.
DSOU-MS2. SubjectMatch’s MatchId uses the function
“string-equal” to evaluate the user’s name and id as
modeled in the DD and the security model.
DSOU-MS3. Subject in the Delegation Rule is set as the
Subject in the higher-level <Target> (user), the «User»
package from the DD.
DRSD, DD
DRR-MS1.
XACML Policy’s <Target> Resource set to
<AnyResource /> to ensure that thehigher-level policies
applies to the user.
DRR-MS2.
Rule’s <Resources> children are <role>
elements with the role identifier (<roleID>) and role
name (<roleName>) that corresponds to the«DRSD» of
the DD.
UD, DRSD,
DD
DTDU-MS1. Rule’s <DelegationTargets> children are
<User> with the user identifier (<id>) and user name
(<name>) that corresponds to the «User» classes of the
«DelegationDiagram» package in the DD.
DSOU-MS
(Delegation
Subject
Original
User
Mapping
Statements)
DRR-MS
(Delegation
Resources
Role
Mapping
Statements)
DTDU-MS
(Delegation
Targets
Delegable
User
Element
Mapping
Statements)
Mapping Statements
XMLSecurity-89
Mapping Process
CSE
5810
XMLSecurity-90
Mapping Process
CSE
5810
XMLSecurity-91
Authorizations Mapping Statements
CSE
5810
Mapping
Statement
Type
Involved
UML
Diagram(s)
Mapping Statements
UD, DRSD,
AD
SUA-MS1.
XACML Policy’s <Target> Subject is the
user and user identifier set as a <user> subtree with
<name> and <id> children that corresponds to the
«User» package of the AD.
SUA-MS2.
XACML Policy’s <Target>Subject is the
role and role identifier set as a <role> subtree with
<roleName> and <roleID> children that corresponds to
the DRSD package name.
SUA-MS3.
SubjectMatch’s MatchId uses the function
“string-equal” to evaluate the user’s name and id as
modeled in the AD and the security model.
SUA-MS4.
Subject in the Authorization Rule is set as
the Subject in the higher-level <Target> (user), the
«User» package from the AD.
AD, DSCD
RSI-MS1.
XACML Policy’s <Target> Resource set to
<AnyResource /> to ensure that thehigher-level policies
applies to the user.
RSI-MS2.
Rule’s <Resources> children are
<Schemas> and <Instances> elements that correspond to
the with the «DSCD» and «Instance» components of the
«AuthorizationDiagram» package.
SUA-MS
Subject
(User)
Mapping
Statements
RSI-MS
Resources
(Schemas
and
Instances)
Mapping
Statements
XMLSecurity-92
Mapping Process
CSE
5810
XMLSecurity-93
Mapping Process
CSE
5810
XMLSecurity-94
High-level Mapping Algorithm
CSE
5810
XMLSecurity-95
Mapping Algorithm Pseudo-code
CSE
5810
XMLSecurity-96
Resulting XACML Policy
CSE
5810
<Policy PolicyId="ada-policy" RuleCombiningAlgId="deny-overrides">
<Description>Omitted due to length.</Description>
<Target>
<Subjects>
<user><id>6</id><name>Elisa</name></user>
</Subjects>
<Resources><AnyResource/></Resources>
<Actions><AnyAction/></Actions>
</Target>
<Rule RuleId="simple-RBAC+LBAC-rule" Effect="Permit">
<Target>
<Subjects>
<role><roleID>5</roleID><roleName>Physician</roleName></role>
</Subjects>
<Resources><element>
<elementID>el-3</elementID>
<elementName>Past Medical History</elementName>
</element></Resources>
<Actions><operation>
<operationName>insert</operationName>
<opAccessMode>write</opAccessMode>
</operation></Actions>
</Target>
<Condition>
<Apply FunctionId="…:integer-greater-than-or-equal">
<Apply FunctionId="…:integer-one-and-only">
<AttributeValue DataType="…#integer">Secret</AttributeValue>
</Apply>
<AttributeValue DataType="…#integer">Secret</AttributeValue>
</Apply>
</Condition>
</Rule>
<Rule RuleId="simple-delegation-rule" Effect="Permit">
<Target>
<Subjects>
<user><id>6</id><name>Elisa</name></user>
</Subjects>
<Resources>
<Roles><role>
<roleID>2</roleID><roleName>Physician</roleName>
</role></Roles>
</Resources>
<DelegationTargets>
<user><id>30</id><name>Samantha</name></user>
</DelegationTargets>
</Target>
</Rule>
<Rule RuleId="simple-authorization-rule" Effect="Permit">
<Target>
<Subjects>
<user><id>6</id><name>Elisa</name></user>
</Subjects>
<Resources><Schemas><schema>
<schemaID>4</schemaID>
<schemaName>Schema 4</schemaName>
</schema></Schemas>
<Instances><instance>
<instanceID>4,2</instaneID>
<instanceName>Carol Smith Health Record</instanceName>
</instance></Instances></Resources>
</Target>
</Rule>
</Policy>
XMLSecurity-97
Secure Information Engineering

CSE
5810



Over the past five years, major focus has been on
extending UML with new diagrams
 Supports secure software engineering for RBAC,
MAC, and DAC
From a functional perspective
 A framework of composable security features was
defined (Jaime)
From a collaboration perspective
 A framework for secure, obligated, coordinated,
and dynamic collaboration was developed
(Solomon)
From an information perspective
 A framework for tree-structured document security
was developed (Alberto)
XMLSecurity-98
Secure Software Engineering
CSE
5810
XMLSecurity-99
Secure Information Engineering Process
CSE
5810
XMLSecurity-100
Secure Information Engineering Process
CSE
5810
XMLSecurity-101
Secure Information Engineering Process
CSE
5810
(1) Main Security Design of the Application
(2) Initial Information Security Design
(2.1) Define
Document Schema
Class Diagram (DSCD)
A
(2.2) Define Information
Security
Requirements
and User Diagram (UD)
B
«element»
ContinuityOfCareRecord
«complexType»
«RoleAssignment»
«User»
Elisa
«DRSD»
Physician
«sequence»
«User»
Brock
«CLRAssignment»
«CLRAssignment»
«LBAC»
S
«RoleAssignment»
«element» CCRDocumentObjectID
«element» Patient
«LBAC»
TS
«CLRAssignment»
«element» Body
«constraint» maxOccurs=“2”
«element» Language
«User»
Leroy
«complexType»
«DRSD»
Psychiatrist
«LBAC»
C
«complexType»
«element» Version
«sequence»
«SOD»
«sequence»
«element» DateTime
«RoleAssignment»
«element» ActorID
«ME»
«RoleAssignment»
«DRSD»
Nurse
«element» Payers
«element» AdvanceDirectives
«element» Support
«User»
Jenkins
«LBAC»
S
«constraint» minOccurs=“0”
«constraint» minOccurs=“0”
«complexType»
«complexType»
«sequence»
«sequence»
«element» Payer
«constraint» minOccurs=“unbounded”
«element» FunctionalStatus
«constraint» minOccurs=“0”
«element» AdvanceDirective
«constraint» minOccurs=“unbounded”
«element» Problems
«constraint» minOccurs=“0”
«constraint» minOccurs=“0”
«sequence»
«element» SupportProvider
«constraint» minOccurs=“unbounded”
«constraint» minOccurs=“0”
«complexType»
«sequence»
«sequence»
«sequence»
«element» Function
«element» Problem
«element» FamilyProblemHistory
«constraint» minOccurs=“unbounded”
UD
«element» FamilyHistory
«complexType»
«constraint» minOccurs=“unbounded”
«CLRAssignment»
«complexType»
«complexType»
«constraint» minOccurs=“unbounded”
B
DSCD
A
XMLSecurity-102
Secure Information Engineering Process
«element»
ContinuityOfCareReco
rd
«SecureInformation»
ContinuityOfCareRecordSystem
«complexType»
CSE
5810
«RoleAssignment»
«User»
Elisa
«sequence»
«element» Patient
«constraint»
maxOccurs=“2”
«element»
Language
«element»
Body
«complexType»
«complexType»
«element»
Version
«sequence»
«User»
Brock
«LBAC»
S
«element» Body
«constraint» maxOccurs=“2”
«RoleAssignment»
«LBAC»
TS
«CLRAssignment»
«element» Problems
«User»
Leroy
«DRSD»
Psychiatrist
«LBAC»
C
«sequence»
«constraint» minOccurs=“0”
«SOD»
«element» ActorID
«element» DateTime
«element» Patient
«CLRAssignment»
«CLRAssignment»
«element»
CCRDocumentObjectID
«DRSD»
Physician
«element» FamilyHistory
«RoleAssignment»
«ME»
«RoleAssignment»
«element»
AdvanceDirectives
«constraint»
minOccurs=“0”
«element» Payers
«constraint»
minOccurs=“0”
«element» Support
«constraint»
minOccurs=“0”
«complexType»
«complexType»
«complexType»
«sequence»
«sequence»
«sequence»
«element» AdvanceDirective
«constraint»
minOccurs=“unbounded”
«element» Payer
«constraint»
minOccurs=“unbounded”
«element»
FunctionalStatus
«constraint»
minOccurs=“0”
UD
C
«complexType»
«sequence»
«sequence»
SID
«LBAC»
S
«CLRAssignment»
«element» FamilyHistory
«constraint»
minOccurs=“0”
«complexType»
«complexType»
«sequence»
«element»
FamilyProblemHistory
«constraint»
minOccurs=“unbounded”
«element» Problem
«constraint»
minOccurs=“unbounded”
«element» Function
«constraint»
minOccurs=“unbounded”
«User»
Jenkins
«element» SupportProvider
«constraint»
minOccurs=“unbounded”
«element» Problems
«constraint»
minOccurs=“0”
«constraint» minOccurs=“0”
«DRSD»
Nurse
B
DSCD
«User»
Elisa
A
«Delegation»
«RoleAssignment»
«DelegationDiagram»
Delegations
«User»
Samantha
«User»
Emily
«DRSD»
Physician
«DRSD»
MedicalProv
ider
«elemen
t»
«read»
access()
DD
«SecureInformation»
ContinuityOfCareRecordSystem
«element»
caption : string = {“Allergies, Assessment,
ref:patient
«element» Patient
«constraint»
maxOccurs=“2”
Past
Medical History”}
«read» + access()
+
«element»
«element»
ref:legal_authenticat
or
ref:originating_organizatio
n
«read» + access()
«read» + access()
«element» Body
{ am=read, cls=c }
{ am=read, cls=c }
F
«element»
caption : string = {“Vital Signs”}
«read»«aggregate»«insert»«update» + access()
«element» Problems
«constraint» minOccurs=“0”
«DRSD»
Physician
«DRSD»
Nurse
«elemen
t»
{ am=read, cls=c }
«element»
«element»
«element»
ref:prescription
ref:laboratytest
ref:prescription
ref:laboratytest
«read»
access()
«read» + access()
«rwrite» + access()
«rwrite» + access()
+
«element» FamilyHistory
«constraint» minOccurs=“0”
{ am=read, cls=c }
«element»
«element»
ref:prescription
ref:laboratytest
«rwrite» + access()
«rwrite» + access()
«elemen
t»
ref:patient
«read»
access()
«element»
ref:pyschhistory
«rwrite» + access()
D
+
«element»
«element»
ref:legal_authenticat
or
ref:originating_organizatio
n
«read» + access()
«read» + access()
DRSD
«AuthorizationDiagram»
Authorizations
«User»
Elisa
«DRSD»
Staff
«DRSD»
Psychiatrist
LSID
E
«Authorization»
«DSCD»
CCR
«RoleAssignment»
«DRSD»
Physicia
n
«has»
«Instance»
Carol Smith
«Instance»
John Jones
AD
G
XMLSecurity-103
Secure Information Engineering Process
(1) Main Security Design of the Application
(2) Initial Information Security Design
CSE
5810
(2.2) Define Information
Security
Requirements
and User Diagram (UD)
(2.1) Define
Document Schema
Class Diagram (DSCD)
A
B
(3) Information Security Design
C
Define Secure
Information
Diagram (SID)
[NOT DONE]
[DONE]
[NEEDS DAC]
[NEEDS LBAC]
[NEEDS RBAC]
Define Roles and
Permissions
Define User/Role Delegations
and Authorizations
Define Sensitivity Levels
[NOT DONE]
[NOT DONE]
[NOT DONE]
[DONE]
E
[DONE]
Create Document Role
Slice Diagrams
Create Authorization and
Delegation Diagrams
Create SID with LBAC
[NOT DONE]
[DONE]
[DONE]
[NOT DONE]
[NOT DONE]
[DONE]
[NOT DONE]
D
B
F, G
Security Refinement
Process and UD
[DONE]
[NEEDS REVISION]
(4) Mapping to Enforcement Code and XACML Policies
Generated Information Secure System
XMLSecurity-104
Prototype for Enforcing Generated Policies
Microsoft HealthVault - Patient’s
Account
CSE
5810
HV Objects +
XACML
Write-back: HV
Objects
• Medications
• Procedures
• Allergies
• Demographics
Reading: CCR
Instance + XACML
XACML Policies
Microsoft HealthVault Middle-Layer Server
Patient Layer (Data Transfer)
• Set Security Policies
• Save Medications
• Save Allergies
• Save Procedures
• Save Demographic Info
• Get Patient Information
• Write-back Information
• Enforce XACML Policies
Provider List
JSON
JSON
Provider Layer (Enforcement)
Patient List
JSON
PHA - Patient
PHA - Provider
• Medications
• Allergies
• Procedures
• Demographics
Patient List
Provider List
Reading: JSON
(from filtered
CCR instance)
Writing: JSON
(with update payload)
• Medications
• Allergies
• Procedures
• Demographics
XACML Policies
XMLSecurity-105
Enforcing RBAC read access modes
Initial Request:
Patient Selection
CSE
5810
Retrieval of CCR XML instance
and XACML policies
Is user/role
authorized?
YES
Evaluate policy reading rules
to requester’s role
NO
Drop Request:
Deny access
Filter CCR XML
instance
Package as equivalent
JSON for PHA
Respond Request:
JSON
XMLSecurity-106
Enforcing RBAC write access modes
CSE
5810
Initial Request:
Information Update
JSON Data
Payload
Evaluation of target and policy
writing rules
Is user/role
authorized and
allowed?
YES
Write-back to CCR XML
instance
NO
Drop Request:
Deny access
Validation of updated
CCR with schema
Validation passed?
YES
Save data in
HealthVault
NO
Drop Request:
Invalid
Respond Request:
Success
XMLSecurity-107
Enforcing LBAC read and write
CSE
5810
Initial Request:
Information Update
JSON Data Payload
(if write)
Evaluation of target, policy rules
and LBAC features
YES
Is User authorized and
clearance proper?
NO
Read XML instance and output
or
Write-back to CCR XML
instance
IF READ
IF WRITE
Drop Request:
Deny access
Validation of updated
CCR with schema
YES
Validation passed?
Save data in
HealthVault
Respond Request:
Success
NO
Drop Request:
Invalid
XMLSecurity-108
Enforcing Delegations
CSE
5810
Initial Request:
Information Update
Delegate Role and
Respond Request:
Success
Evaluate the Initiating User and the
Receiving User
Is the Initiating User
an Original user?
YES
YES
Is the receiving user a
delegable user allowed to
perform the sent role?
NO
Is the Initiating User a
Delegable User
NO
Drop Request:
Invalid
Is there Pass-On
Delegation?
NO
NO
XMLSecurity-109
What about Authorizations?

CSE
5810
Authorizations over schemas and instances are
verified before permissions
 For RBAC, this is part of the process that
determines if the role is authorized
 If the user/role is not authorized, then the permission is
not performed

For LBAC, this is part of the process that
determines if the user is authorized
 If the user/role is not authorized, the operation is not
performed
XMLSecurity-110
Conclusion and Contributions

CSE
5810
Presented a Security Framework
 Addressed the Issue of Providing Information
Security in Systems with Tree-Structured
Documents
 Utilize Security Policies defined after the different
Access control models
 Support for RBAC, LBAC and DAC

Not enough to utilize the security requirements of the
newly developed system
 Security Definitions and Requirements of
Constituent Systems must be Considered
XMLSecurity-111
Ongoing Research and Future Directions

CSE
5810




Non-orthogonal RBAC and LBAC
 Clearance assigned to both users and roles
Support of other access control models
 ABAC (Attribute-Based Access Control)
 Support of Compartments for RBAC
UML Profile for other specialized document formats
 JSON
 RDF serializations
 OWL
 Automatic Creation of DSCD
Policy generation in other languages and more efficient algorithm
 Deployable to databases
 Development Framework Policies
 Decoupled systems from a security architecture
Generate XACML directly from the model
 Skip UML altogether
XMLSecurity-112
Conclusion and Contributions

CSE
5810


Security Model
 RBAC (roles, permissions)
 LBAC (sensitivities, read/write features)
 DAC (delegations) and Authorizations
UML Security Extensions for UML
 DSCD, DRSD (for RBAC), SID, LSID (for
LBAC), UD, DD (delegations), AD
(authorizations)
Schema targeting XACML Policy Generation
 Automatic Policy Generation
 Mapping Statements
 Generation Algorithm

Secure Information Engineering
 Development Cycle
XMLSecurity-113
Publications to Date

Published / Accepted

CSE
5810










Demurjian, S., De la Rosa Algarín, A., Bi, J., Berhe, S., Agresta, T., Wang, W., Blechner, M. (2014). A Viewpoint of
Security for Digital Health Care: What's There? What Works? What's Needed? (Accepted) To appear in International
Journal of Privacy and Health Information Management.
Pavlich-Mariscal, J. A., Berhe, S., De la Rosa Algarín, A. and Demurjian, S. A. (2014). An Integrated Secure Software
Engineering Approach for Functional, Collaborative, and Information Concerns. (Accepted) To appear in Handbook of
Research on Emerging Advancements and Technologies in Software Engineering, IGI Global.
Saripalle, R., Demurjian, S. A., De la Rosa Algarín, A. and Blechner, M. (2013). A Software Engineering Process for
Ontology Design and Development through Extensions to OMD and OWL. (Accepted) To appear in International Journal of
Web Semantics and Information Systems.
De la Rosa Algarín, A., Ziminski, T. B., Demurjian, S. A., Rivera Sánchez, Y. K. and Kuykendall, R. (2013). Generating
XACML Enforcement Policies for Role-Based Access Control of XML Documents. (WEBIST 2013 Selected Papers)
(Accepted) To appear in Lecture Notes in Business Information Processing (LNBIP), Springer-Verlag.
De la Rosa Algarín, A. and Demurjian, S. A. (2013). An Approach to Facilitate Security Assurance for Information Sharing
and Exchange in Big Data Applications. Emerging Trends in Information and Communication Technologies Security, pp.
65-83. Elsevier (Kaufman). Editors: Babak Akhgar and Hamid R. Arabnia.
Demurjian, S., De la Rosa Algarín, A. and Saripalle, R. K. (2013). Information Models for Granular Computing.
Encyclopedia of Complexity and Systems Science, Springer. Editor-in-Chief: R. Meyers, Granular Computing Section, T.
Y. Lin (ed.); revision and substantial update of June 2009 article Springer, submitted April 2013, see here for Encyclopedia
and here for article.
De la Rosa Algarín, A., Demurjian, S. A., Ziminski, T. B., Rivera Sánchez, Y. K. and Kuykendall, R. (2013). Securing
XML with Role-Based Access Control: Case Study in Health Care. Architectures and Protocols for Secure Information
Technology (APSIT), pp. 334-365, IGI Global. Editors: Antonio Ruiz Martínez, Fernando Pereñíguez García, and Rafael
Marín López.
De la Rosa Algarín, A., Ziminski, T. B., Demurjian, S. A., Kuykendall, R. and Rivera Sánchez, Y. (2013). Defining and
Enforcing XACML Role-Based Security Policies within an XML Security Framework. Proceedings of 9th International
Conference on Web Information Systems and Technologies (WEBIST 2013) (pp. 16-25), doi:10.5220/0004366200160025
De la Rosa Algarín, A., Demurjian, S. A., Berhe, S. and Pavlich-Mariscal, J. (2012). A Security Framework for XML
Schemas and Documents for Healthcare. Proceedings of 2012 International Workshop on Biomedical and Health
Informatics (BHI 2012) (pp. 782-789), doi:10.1109/BIBMW.2012.6470239
Ziminski, T. B., De la Rosa Algarín, A., Saripalle, R., Demurjian, S. A. and Jackson, E. (2012). SMARTSync: Towards
Patient-Driven Medication Reconciliation Using the SMART Framework. Proceedings of 2012 International Workshop on
Biomedical and Health Informatics (BHI 2012) (pp. 806-813), doi:10.1109/BIBMW.2012.6470243
In Review

De la Rosa Algarín, A. and Demurjian, S. (2014). UML Extensions to Model and Enforce LBAC and RBAC on XML
Documents. Submitted to PST 2014.
XMLSecurity-114