XML Security Framework

XML Security Framework
Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-1155 Storrs, CT (860)

An RBAC, LBAC and DAC Security Framework for Tree-Structured Documents
Alberto De la Rosa Algarín Major Advisor: Dr. Steven A. Demurjian Associate Advisors: Dr. Jinbo Bi, Dr. Swapna Gokhale Dr. Xiaoyan Wang,

Introduction 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

Tree-Structured Documents
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

Secure Information Exchange
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.?

Security for Tree-Structured Documents
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 Application Schemas Appl_Role.xml Appl _User.xml Appl_Constraint.xml Application XML Files User’s Role Determines the Scope of Access to Each XML Document

What is a Schema?

What is an Associated Instance?

Attaining Security 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

Main Research Questions
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? 11

Attaining Security Given an Application of Schemas and Associated Instances, can we: Define Schemas for Security Levels, Roles, User-Role Authorizations, and Delegation Augment Application’s Schemas/Instances with MAC Security Classifications (if Needed) 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

What is the Big Picture? 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 13

Why Health Care Domain? 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? 14

Makeup of Health Care Landscape
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)

Interplay of Information in Health Care
PHI Secure PHI Local Security Policy/Control XML Converter MeSH XML DTD SNOMED XML Schema RxNorm RxTerms LOINC Standards Health Information Exchange UMLS Global Security Policy and Control Secure XML-C PHA Patient App Mobile Provider Mobile App SMARTSync App USES MS Health Vault ASP.NET API C# Data Harvard SMART EHR REST API JSON-LD Open mHealth JSON openEHR JAVA APIs PatientOS Java APIs HL7 CDA FreeMED PHP APIs CDA

Proposed Security Framework
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

Why Multiple Access Control Models?
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

What is the Big Picture? Security Framework HIT System Data Sources
PatientOS HIE Server Java APIs HL7 CDA Secure Data HIT System Data Sources Local Security Policies MS Health Vault ASP.NET API C# Data Role-Based Access Control Secure Data and Local Schemas Lattice-Based Access Control Secure Data HIT Application Input Schemas XML-C Open mHealth JSON Application Instances Security Framework Schemas Discretionary Access Control Generate XACML Global Security Policies PHA Enforcement Mechanism XACML Policy Enforcement Filtered Instances Medical Provider SMARTSync 19

Expected Research Contributions
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

Remainder of Presentation
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

Unified Modeling Language
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

Access Control Models 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

eXtensible Markup Language (XML)
Provides a Common, Structured Language Independent of Systems Information Hierarchically Structured and Tagged Tags can Offer Semantics XML schemas Blueprints for new Instances Validation Agents Achieved with XML Schema Definition (XSD) XML Schema Language (XSL)

Sample XML from CCR Standard
25

eXtensible Access Control Markup Language
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 Rule Subject Action Resource Rule Combination Algorithm Policy Combination Algorithm

Introducing Security with our Framework
Security Model and Policy Generation Information Security Extensions to UML Generated Security Policies SECURITY SCHEMA MODELING SECURE INFORMATION ENGINEERING Lattice-Based Access Control Role-Based Access Control Discretionary Access Control Document Schema Class Diagram Document Role Slice Diagram LBAC & DAC Features Roles, Actions, Resources Element Sensitivity User Clearance Delegations and Authorizations SchemaCIS1 SchemaCIS2 SchemaCIS3 SchemaCIS4 SchemaLSIA1 SchemaLSIA2 Schema Modeling Security Definition Policy Generation Access Control Models

Security Model 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 tree-structure 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. 28

Model: Application, Schema, Instances, and Users
29

Model: Application, Schema, Instances, and Users
30

Example of Model

CDA Instance

CCR Instance

Model: Schema Operations for RBAC, LBAC, and DAC
36

Model: Schema Operations for RBAC, LBAC, and DAC
37

Projecting Instances – Define Projection

Projecting Instances – Apply CDAProjection

Projecting Instances – Apply CCR Projection

Model: RBAC Security 41

Model: RBAC Security 42 e s Defn. 9: A role r is defined as a two -
pair > =< NAME ID , representation of the responsibilities for a user U u Î to access some portion (entire or further restricted) of a schema . Defn. 10: Let } ,..., { 2 1 j R = be defined as the set of roles for a given application , where and Defn. 6 (RBAC Version): A user that has been authorized to RBAC (but not LBAC) redefines the user as a tuple < where is the role 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. Defn. 11: There exists a schema projection operation P | by role that acts on a schema i S , and yields a filtered version Pr ~ for any given role . This results in what is referred to as a role secured schema. Defn. 12: The set of role secured schemas ) ( is the set of role projections of for role , for any given schema m Defn. 13: delete update insert aggregate read O be the set of operations that can be performed against an element in each schema from either an original or a projected and/or decorated tree. The operation is defined at the schema level to be applied at the instance level. For permissions, each op will be assigned to individual roles. Defn. 14: A permission p is represented by the four tuple e s is the unique identifier of the permission (akin to ), is the identifier of a schema c D the identifier of an element el for some , meaning that operation can be performed on the element (node) identified by constrained to the schema of the application. Defn. 15: z be defined as the set of all granular permissions in a given application A, where a p ermission . That is, is the set of all permissions defined by the security administrator in a given application Defn. 16: The set of all permission the role permission assignments n k RPA is the identifier of a role as defined in Defn. 12 , and is the identifier of a permission 16 contains all the role permissions pairs meaning that role with identifier can perform the permission with identifier Defn. 19: SoD à denotes separation of duty between roles which means that, given x r y , with R Î and , a user with role cannot be assigned and perform any permissions of role where the two tuple >Î < represents the SoD between the two roles . The set contains all the pairs of roles that have a separation of duty relation. Defn. 20: For a given role the set } | { i " > = iterates over all of the roles in R. Defn. 21: ME that is strictly defined as two roles not allowed to have any permissions in common which means that , given the set of RPA does not have pairs with where the ID p are the same This defines a set that contains all the pair of roles that have a mutual exclusion relation. More specifically, Defn. 22: , the set A iterates over all of the roles in Defn. 6 (RBAC with SoD and ME): A user that has been authorized to RBAC with constraints redefines the user u as a tuple NAME u is the resulting set of roles that have a separation of duty for role is the resulting set of roles that have a mutual exclusion with 42

Examples

Model: LBAC Security 44

Model: LBAC Security 45 e l > b a Î g ) ( = Defn. 23: A
partial order relation < is a binary relation that is reflexive, antisymmetric , and transitive. Defn. 24: lattice is a structure with a set S L , a partial order , and two binary operations: infimum and supremum . Defn. 25: Let b a Î (a,b) is called the greatest lower bound of , or meet and, least upper bound join of a and b, such that: a. For any (a, b) b, and for any g , if a and g b then g (a, b). b. , a (a, b ) and (a, b), and for any , if a g and b g, then g. Defn. 26: If for any given , with as the partial order relation, we have that or , then we call chain totally ordered set Defn. 27: We call a lattice ) ( = bounded if there exist elements top (?) bottom such that for any a ? , ? ?. Defn. 28: Define } ,..., { 2 1 q sl SL to be the partially ordered set of consecutive sensitivity levels for the application where represents the least secure and represents the most secure; an individual level is referred to as Defn. 29: Given , the expression denotes that has a higher sensitivity classification or clearance) than , which means that b is more secure. Similarly, the expression have the same sensitivity. Defn. 30: We define a lattice as the lattice of sensitivity levels in an application , ordered by the relation < which has replaced as defined in Defn. 19 Defn. 31: Dc i ~ be the subtree that results from the decoration D c | Defn. 9 . The nodes of are LBAC decorated and in the form of e l I N M E > , where el r P for any As a result, the schema has been extended due to the addition of an element for Defn. 18: If some node in a secure schema, with classification has children nodes then the classification must be equal to or higher than the classification . That is, == This definition means that the least secure levels migrate towards t he top of the tree of the schema while the more secure level migrate towards the bottom leaf nodes. Defn. 33: } , { WRITE AM READ - = is the set of access modes that are used to categorize the multiple read oriented operations into the category and multiple write operations in the that act against the secured tree nodes. Defn. 34: Each O op Î has an access mode assigned based on the operation . F or non destructive operations such as aggregate read have am while delete update insert 45

Examples

LBAC in CDA Instance

LBAC in CCR Instance

Model: DAC Delegations
49

Model: DAC Delegations
Defn. 35: Let R DelRoles Í , where } ,..., , { 2 1 y r = and Î be defined as the subset of all ro les that are eligible for delegation. Defn. 36: The set of Original Users U OU > < ry u DU x is the set of original users with their assigned roles . That is, the members of have the form >Î , which means that the user with identifier ID is allowed to delegate the role with identifier Defn. 37: Delegable Users set of delegable users w ith the roles they are allowed to receive as part of a delegation. The members of have the form of , which means that the user can receive the role with identifier when delegated by anot her user. Defn. 38: Pass - On Delegation, or PoD , is a Boolean {0,1} that indicates whether a user and role pair can delegate t he role , originally received by a one further step to another user z that is set as In this case, a 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 or a user can execute the permission of delegation to another user and role pair or Defn. 6 (RBAC with Delegation): A user that has been authorized to RBAC (but not LBAC) redefines the u as a tuple NAME where true means that the role can be delegated and when true means that the authority to delegate that role can be passed on when the role is delegated. If is false, must be false; if is true, can be either true or false. 50

Model: User Authorizations
51

UserID, Name, RoleID, DA, PODA CLR, Dom, RoleID, SoD, ME, DA, PODA
Delegation and Users UserID, Name, RoleID, DA, PODA CLR, Dom, RoleID, SoD, ME, DA, PODA

Example Process 53

Security Framework 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 54

Securing Schemas with our Framework
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)

Document Schema Class Diagram (DSCD)
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

UML Profile for DSCD

CDA Schema Segment

CCR Schema Segment

Example DSCD for the HL7 CDA XML Schema

Example DSCD for the CCR XML Schema

Secure Information Diagram (SID)
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

Secure Information Diagram (SID)

Document Role Slice Diagram (DRSD)
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)

Document Role Slice Diagram (DRSD)

LBAC Secure Information Diagram (LSID)

LBAC Secure Information Diagram (LSID)
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)

User Diagram (UD) 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

User Diagram (UD)

Delegation Diagram (DD)
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

Authorization Diagram (DD)
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.

Authorization Diagram (DD)

UML Metamodel

Generating Enforcement Policies
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.

Generating Enforcement Policies

Mapping Process

RBAC Mapping Statements

Mapping Process

LBAC Mapping Statements

Mapping Process

DAC Delegation Mapping Statements

Mapping Process

Authorizations Mapping Statements

Mapping Process

High-level Mapping Algorithm

Mapping Algorithm Pseudo-code

Resulting XACML Policy
<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"> <role><roleID>5</roleID><roleName>Physician</roleName></role> <Resources><element> <elementID>el-3</elementID> <elementName>Past Medical History</elementName> </element></Resources> <Actions><operation> <operationName>insert</operationName> <opAccessMode>write</opAccessMode> </operation></Actions> <Condition> <Apply FunctionId="…:integer-greater-than-or-equal"> <Apply FunctionId="…:integer-one-and-only"> <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"> <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> </Policy>

Secure Information Engineering
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)

Secure Software Engineering

Secure Information Engineering Process

Main Security Design of the Application (2) Initial Information Security Design (2.1) Define Document Schema Class Diagram (DSCD) (2.2) Define Information Security Requirements and User Diagram (UD) A B ContinuityOfCareRecord «element» «complexType» «sequence» «element» Version «element» CCRDocumentObjectID «element» Language «element» DateTime «element» Body «constraint» maxOccurs=“2” «element» Patient «element» ActorID «constraint» minOccurs=“0” «element» Payers «constraint» minOccurs=“unbounded” «element» Payer «element» AdvanceDirectives «element» AdvanceDirective «element» Support «element» SupportProvider «element» FunctionalStatus «element» Function «element» Problems «element» Problem «element» FamilyHistory «element» FamilyProblemHistory DSCD A UD Elisa «User» «RoleAssignment» Physician «DRSD» Leroy Nurse Brock Psychiatrist Jenkins «SOD» «LBAC» C TS S «CLRAssignment» «ME» B

Prototype for Enforcing Generated Policies

Enforcing RBAC read access modes

Enforcing RBAC write access modes

Enforcing LBAC read and write

Enforcing Delegations

What about Authorizations?
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

Conclusion and Contributions
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

Ongoing Research and Future Directions
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

Conclusion and Contributions
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

Publications to Date Published / Accepted In Review
Demurjian, S., De la Rosa Algarí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 Algarí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 Algarí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 Algarí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 Algarí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 Elsevier (Kaufman). Editors: Babak Akhgar and Hamid R. Arabnia. Demurjian, S., De la Rosa Algarí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 Algarí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 , IGI Global. Editors: Antonio Ruiz Martínez, Fernando Pereñíguez García, and Rafael Marín López. De la Rosa Algarí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 ), doi: / De la Rosa Algarí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 ), doi: /BIBMW Ziminski, T. B., De la Rosa Algarí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 ), doi: /BIBMW In Review De la Rosa Algarín, A. and Demurjian, S. (2014). UML Extensions to Model and Enforce LBAC and RBAC on XML Documents. Submitted to PST 2014.

XML Security Framework

Similar presentations

Presentation on theme: "XML Security Framework"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

XML Security Framework

Similar presentations

Presentation on theme: "XML Security Framework"— Presentation transcript:

Similar presentations

About project

Feedback