Security-1 CSE 300Security Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box.

Security-1

CSE 300

Security Security

Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department

The University of Connecticut371 Fairfield Road, Box U-1155

Storrs, CT [email protected]

http://www.engr.uconn.edu/~steve(860) 486 - 4818

The majority of these slides represent material that has been accumulated from various The majority of these slides represent material that has been accumulated from various sources over the years. sources over the years.

A portion these slides are being used with the permission of Dr. Ling Lui, Associate A portion these slides are being used with the permission of Dr. Ling Lui, Associate Professor, College of Computing, Georgia Tech. Professor, College of Computing, Georgia Tech.

Security-2

CSE 300

Patients

Providers

Clinical Researchers

Motivation: Security Issues?Motivation: Security Issues?

Web Server

Appl Server

DB Server

Firewall

https Encryptionhttps

Encryption

Encryption

Secure Communication

XML

html

Web Content

GUI Look and Feel

Patient GUI for RN vs. MD

Web - Control Services

Appl. – Control Methods

Security-3

CSE 300

Security Issues for PatientsSecurity Issues for Patients

HIPPA Overriding ConcernHIPPA Overriding Concern All Patient Interfaces Web-BasedAll Patient Interfaces Web-Based Secure CommunicationSecure Communication

To/From Web Server (https) Among Discussion Group Members

Is this https or Peer-to-Peer? Role-Based Access Control to AuthorizeRole-Based Access Control to Authorize

Providers to Interact PHR Data to Individual Providers

Patients Providers


Web-BasedPortal(XML + HL7)Open Source XML DB

Security-4

CSE 300

Security Issues for ProvidersSecurity Issues for Providers

Patients Providers


EMR

HIPPA Concerns for any EMR Data HIPPA Concerns for any EMR Data Transmitted into PortalTransmitted into Portal

Need to Consider DelegationNeed to Consider Delegation Provider P Access to Portal for

Patient X Provider Q on Call Can P Delegate his Permission to

Access Portal to Q? Will Q’s Role (e.g., EMT) Limit

Access Even with Delegation?


Security-5

CSE 300

Security Issues forSecurity Issues for Clinical ResearchersClinical Researchers


Patients Providers

Feedback Repository

Is Role-Based Access Control Needed to Is Role-Based Access Control Needed to Authorized Providers to Portal Features?Authorized Providers to Portal Features?

Security for Discussion Forums? Security for Discussion Forums? Collaborative Interactions Among

Providers and Clinical Researchers Is Security Required?

Collect Results from Providers (HIPPA)Collect Results from Providers (HIPPA) Store in Feedback Repository Transfer to Permanent Warehouse


Security-6

CSE 300

OverviewOverview Explore Wide Range of Security Topics in this and Explore Wide Range of Security Topics in this and

Associated PPTs:Associated PPTs: Security for Collaborative Web Portals Secure Information Exchange via XML Object-Oriented/Programmatic Security Secure Software Engineering Security for Services-Based Computing

Objective – Understand the Wide Range and Location Objective – Understand the Wide Range and Location of Security Across Macro-Architectureof Security Across Macro-Architecture

Note: All of these Security Approaches Must work Note: All of these Security Approaches Must work with the Security Discussed in Background PPTswith the Security Discussed in Background PPTs

Security-7

CSE 300

Object-Oriented and Programmatic

Security in C++/Java

Collaborative Portals

Look-and-FeelApplication Content

Document Access

Secure Software Design To Design and Write Secure

Software Programs

Our Five-Pronged Security EmphasisOur Five-Pronged Security Emphasis

Secure Information Exchange via XMLwith MAC/RBAC

Secure MAC/RBAC Interactions via Middleware in

Distributed Setting

AssuranceConsistencyIntegrity

RBAC, DAC, MACSeparation of Duty

Mutual Excl.Safety

Liveness

Security-8

CSE 300

Security for Collaborative Web PortalsSecurity for Collaborative Web Portals Collaborative Portals Rapidly Emerging as Means for Collaborative Portals Rapidly Emerging as Means for

Communication, Interaction, and Problem Solving Communication, Interaction, and Problem Solving over Distancesover Distances SourceForge MediaWiki Microsoft Sharepoint phpBB

Security Model and Enforcement Often LackingSecurity Model and Enforcement Often Lacking Consider WIKIs

Anonymous Users (Read Only) Registered Users (Full Write Access) Result: No Guarantee of Data Correctness

Need to Transcend Simplistic Approach for Need to Transcend Simplistic Approach for Application Level, Document Level (Author/View), Application Level, Document Level (Author/View), and Look-and-Feel of Portal Itselfand Look-and-Feel of Portal Itself

Security-9

CSE 300

What is a WIKI?What is a WIKI?

Repository for Information that Accessible to AllRepository for Information that Accessible to All Collaborative PlatformCollaborative Platform Content Contribution/Creation/ModificationContent Contribution/Creation/Modification Document AuthoringDocument Authoring Historical Tracking of ActionsHistorical Tracking of Actions Shared Platform to Facilitate Information Exchange, Joint Shared Platform to Facilitate Information Exchange, Joint

Efforts, etc.Efforts, etc. Runs in Web Environment (Browser) – No Software to Runs in Web Environment (Browser) – No Software to

InstallInstall Limited Security: User Accounts/PasswordsLimited Security: User Accounts/Passwords

Security-10

CSE 300

Security-11

CSE 300

Security-12

CSE 300

Security-13

CSE 300

Security-14

CSE 300

http://www.mediawiki.org/wiki/MediaWiki

MediaWiki underlies WikiPediaMediaWiki underlies WikiPedia

Security-15

CSE 300

MediaWiki from SourceForgeMediaWiki from SourceForge

Security-16

CSE 300

A Wiki for AccreditationA Wiki for Accreditation

Security-17

CSE 300

Creating an AccountCreating an Account

Security-18

CSE 300

Viewing the Main PageViewing the Main Page

Security-19

CSE 300

Uploading DocumentsUploading Documents

Security-20

CSE 300

Creating and Modifying ContentCreating and Modifying Content

Security-21

CSE 300

Viewing the Historical RecordViewing the Historical Record

Security-22

CSE 300

Customized SearchingCustomized Searching

Security-23

CSE 300

Uploading ImagesUploading Images

Security-24

CSE 300

Problems with MediaWiki and OthersProblems with MediaWiki and Others Not Very User Friendly, Particularly for Non-Not Very User Friendly, Particularly for Non-

Computer Savvy PopulationComputer Savvy Population Difficult to Customize with Specialized Features and Difficult to Customize with Specialized Features and

Capabilities beyond Basic Look and Feel ChangesCapabilities beyond Basic Look and Feel Changes Security Limited to User/Password CombinationsSecurity Limited to User/Password Combinations

Everyone can do Anything Set up as Shared and Collaborative for All No Control on Incorrect Content Being Uploaded

Addition of Security Violates General WIKI Concept Addition of Security Violates General WIKI Concept of Open and Available to Allof Open and Available to All

Security-25

CSE 300

Current R&D on WIKIsCurrent R&D on WIKIs Led by Serebrum (Led by Serebrum (www.serebrum.comwww.serebrum.com)) Developing AXON WIKI with Capabilities that Developing AXON WIKI with Capabilities that

include:include: Content Creating Editing (WYSISYG) Document Publishing (Web, PDF, RTF) Document Distribution (Email, Print, Fax) Mobile Access (Limited with BlackBerry) Security

Role-Based Access Control to Define Privileges For Example, Physician, Provider, Patient, Clinical

Researcher, etc. Full Collaborative Environment

Security-26

CSE 300

A First Snapshot of AXONA First Snapshot of AXON

Security-27

CSE 300

A First Snapshot of AXONA First Snapshot of AXONInfolet – Piece of Information that can be Easily Created, Edited, Classified, etc.

Infolets organized into Accordions (US Travel, Project Brainstorm, etc.)

For Our Purposes – HIT Related Topics

Security-28

CSE 300

A First Snapshot of AXONA First Snapshot of AXON

Accordions Contain a Topic Topics Accordions Contain a Topic Topics Parent Topics, Child Topics, GrandChild Topics Customizable Based on Domain PHR: Parent Topics of: History, Meds, Visits, etc. Each Topic has Document (Editable) and Attached

Documents The Topic Tree is Customizable by User/Role so thatThe Topic Tree is Customizable by User/Role so that

Different Information visible to Different UsersDifferent Information visible to Different Users

This is an editable document associated with the Selected Topic

Docs can be Images, Word, PDF, anything…

Security-29

CSE 300

Other AXON FeaturesOther AXON Features Intended to be Fully Fledged Collaborative ToolIntended to be Fully Fledged Collaborative Tool Work Over DistanceWork Over Distance

Full-textsearch

Easy Content Creation

Hierarchical topic tree

IntegratedCMS + DMS

History + Audit Trail

Security-30

CSE 300

Editing Topic DocumentsEditing Topic Documents

For Each Topic,Associated Document can be For Each Topic,Associated Document can be Created/Edited with Full WYSISYG editorCreated/Edited with Full WYSISYG editor Other WIKIs Don’t have this Capability Extending this to Spreadsheet Creation

Word-like Interface for Document Creation and Word-like Interface for Document Creation and ModificationModification

Security-31

CSE 300

Other AXON FeaturesOther AXON Features

This allows Documents to This allows Documents to be Assembledbe Assembled From Topic Down Combines Docs Creates New Doc

This is the WIKIBerry This is the WIKIBerry InterfaceInterface Limited Access View and Edit Content Synchs with Server

Security-32

CSE 300

Channels

Laptop

Workstation

VPN

Web

Any DB

Data Layer

BrainStorm

Application Layer

FIREWALL

ElicitationToolkit

DITAPublishing

LDAPRBAC

Presentation Layer

WebSphere

Struts(JSP / Servlets)

Hibernate

Ajax

Requirements Ontology

Axon(Wiki + CMS

+ DMS + Search)

Ajax Engine

Grayed Boxes (Elicitation Toolkit and Ontology) are Grayed Boxes (Elicitation Toolkit and Ontology) are Application Dependent/CustomizableApplication Dependent/Customizable

Architecture Promotes CustomizabilityArchitecture Promotes Customizability

Security-33

CSE 300

Security Concepts and Permissions in AxonSecurity Concepts and Permissions in Axon A user is identified by:A user is identified by:

Username (unique), userid (unique), User duration (userstarttime and userendtime that

the user is active). A role can be defined for any capabilityA role can be defined for any capability

Standard roles: guest, author, manager, admin For each role, there is a list of allowable topics

A user associated with one or more roles in axon A user associated with one or more roles in axon User authenticated (user name, password) User selects from list of authorized roles a set of Axon customizes itself based on the chosen role

using the permissions stored in the database Able to change roles during a session. Multiple separate sessions each with its own role.

Security-34

CSE 300

Security Concepts and Permissions in AxonSecurity Concepts and Permissions in Axon To isolate user from role: group abstractionTo isolate user from role: group abstraction

Each User is the member of one or more Groups Group is identified by: GroupName (unique),

GroupID (unique), and Group duration (GroupStartTime and GroupEndTime

Users in multiple groups and have multiple roles Each group can have zero or more users

Active Session for a User limits the User to a Active Session for a User limits the User to a particular Group <UserID, GroupID> particular Group <UserID, GroupID>

From a security perspective (see next slide):From a security perspective (see next slide): Permissions will be assigned to Roles Roles will be assigned to Users/Groups Users/Groups will be assigned to Accordions.

Security-35

CSE 300

Security-36

CSE 300

Current AXON Main ScrenCurrent AXON Main Scren

Security-37

CSE 300

Other Important ConceptsOther Important Concepts A Project contains multiple Accordions A Project contains multiple Accordions

E.g. US Travel, Brainstorm, EGuru, and Report For Each Accordions, a Topic Tree, a Document

List, and an Index is maintained Each Accordion can have one or more Users, Each Accordion can have zero or more Groups

University Accordions: Just like PeoplesoftUniversity Accordions: Just like Peoplesoft Faculty, Student, Grad Program Director Faculty Accordion (corresponding to the Faculty

Role) would have Record Grade, Permission Numbers, Advisee List, and other Child Topics

PHR Accordions:PHR Accordions: Patient History, Education Materials,

Appointments, etc.

Security-38

CSE 300

Other Important ConceptsOther Important Concepts The Topic Tree contains three levels of parent, child, The Topic Tree contains three levels of parent, child,

and grandchild topics: and grandchild topics: Each topic in this tree is associated with exactly

one xhtml page. Each topic in this tree is associated with zero or

more documents of all types (Word, PPT, PDF, GIF, etc.).

The DOCS tab contains a list of documents. specifically, for the selected topic - all documents for the topic and its descendants are shown.

Security-39

CSE 300

Axon PermissionsAxon Permissions Basic Topic Tree PermissionsBasic Topic Tree Permissions

Each Role can have one or more topics Each Group can have zero or more topics Each Accordion can have zero or more topics

Upon Successful Login, the Accordions for a User in a Upon Successful Login, the Accordions for a User in a Group with a Role are DisplayedGroup with a Role are Displayed

Advanced Topic Tree Permissions:Advanced Topic Tree Permissions: View Means that the User has permission to View

the xhtml page associated with that topic Edit Means that the User has permission to modify,

delete, update, etc., the xhtml page associated with that topic

Security-40

CSE 300

Axon PermissionsAxon Permissions Edit/History PermissionsEdit/History Permissions

Edit having a value of Yes means the Edit button is enabled If the Topic Tree has a Permission of Edit for a Topic,

then the permission for the Topic Button Edit should be set to Yes.

History View and History Rollback are assigned on a Yes/No basis to each Role.

Button Permissions:Button Permissions: Buttons: Global Menu for Hide, History, Import,

Export, Email, Fax, and Print. Permissions are Yes/No on a role-by-role basis.

No means that the associated ICON doesn’t appear

Security-41

CSE 300

Axon PermissionsAxon Permissions Topic Icon Permissions: Five Icons are:Topic Icon Permissions: Five Icons are:

New Topic to Create a new Topic Copy to Make a Copy of an Existing Topic Paste to Paste a Copy of an Existing Topic Rename to Change the Name of a Topic Archive to Store a new Version of the xhtml page

associated with the topic Permissions are Yes/No on a role-by-role basis.

No means that the associated ICON doesn’t appear

Security-42

CSE 300

Axon PermissionsAxon Permissions Document PermissionsDocument Permissions

View: Open Document (word, PPT, etc.) with associated desktop viewer but do not save changes.

Add: Be able to Import a Document Replace: Be able to Substitute a new Document for

an Existing Document Replace is really "Substitute this new document while

saving all versions of the old one." Archive: Transition a document to being "logically

offline" as it exists at that point in time and remove it from the list of active documents Users will not be able to view the archived documents. An Administrator has the authority to restore archived

documents if required

Security-43

CSE 300

Realizing RBAC in AxonRealizing RBAC in Axon Combination of LDAP and Custom RBACCombination of LDAP and Custom RBAC

Lightweight Directory Access Protocol Tracks Directory Info on Users/Sessions

Customize via RBAC Look and Feel (prior slides) Other Technologies PossibleOther Technologies Possible

XACML – Web Services Policy Constraint Lang. Different Implementations Available Not Mature as yet

Bandit Role Engine RBAC based on NIST and Sun’s XACML Limited Functionality

Our Approach – Custom, Relational DB Solution with Our Approach – Custom, Relational DB Solution with Enforcement Built into AxonEnforcement Built into Axon

Security-44

CSE 300

UML ER DiagramUML ER Diagram

Security-45

CSE 300

Relational Database Tables for RBACRelational Database Tables for RBAC Top Level Tables:Top Level Tables:

ProjectInfo <ProjectID, ProjectName>ProjectInfo <ProjectID, ProjectName>AccordionInfo <AccordionID, AccordionName>AccordionInfo <AccordionID, AccordionName>ProjectAccordions <ProjectID, AccordionID,ProjectAccordions <ProjectID, AccordionID,

AccStartTime, AccEndTime>AccStartTime, AccEndTime> Master Tables: All Projects, Accordions, and P-A

Topic/Subtopic Tables:Topic/Subtopic Tables:Topic <TopicID, TopicName, ProjectID, Topic <TopicID, TopicName, ProjectID,

AccordionID>AccordionID>SubTopic1 <SubtopicID1, SubTopic1Name, SubTopic1 <SubtopicID1, SubTopic1Name,

TopicID>TopicID>SubTopic2 <SubTopicID2, SubTopicID1, TopicID,SubTopic2 <SubTopicID2, SubTopicID1, TopicID,

SubTopic2Name>SubTopic2Name> Master Tables for All Parent, Child, and

Grandchild Topics

Security-46

CSE 300

Relational Database Tables for RBACRelational Database Tables for RBAC Versions:Versions:

TopicVersion <VersionPK, VersionID, TopicID, TopicVersion <VersionPK, VersionID, TopicID, SubTopicID1, SubTopicID2, Author,SubTopicID1, SubTopicID2, Author,Description, VersionDate, Attachment>Description, VersionDate, Attachment>

Different Versions of xhtml Page for Each Tree Entry

Attachments:Attachments:Attachment <AttachmentPK, TopicID, LevelID>Attachment <AttachmentPK, TopicID, LevelID>AttachmentVersion <VersionPK, VersionID, AttachmentVersion <VersionPK, VersionID,

AttachID, FileName, DocType, AttachID, FileName, DocType, Author, Size, Author, Size,

AttachmentDate, Comments, AttachmentDate, Comments, RandomName>RandomName> Various Attachments (Documents –Word, PPT,

etc.) Associate with Each Topic + Versions

Security-47

CSE 300

Relational Database Tables for RBACRelational Database Tables for RBAC Permissions:Permissions:

UserInfo <UserID, LastName, FirstName, UserInfo <UserID, LastName, FirstName, UserStartTime, UserEndTime>UserStartTime, UserEndTime>

PermissionInfo <PermissionID, PermissionName>PermissionInfo <PermissionID, PermissionName>GroupInfo <GroupID, GroupName, GroupStartTime,GroupInfo <GroupID, GroupName, GroupStartTime,

GroupEndTime>GroupEndTime>RoleInfo <RoleID, RoleName, RoleStartTime, RoleInfo <RoleID, RoleName, RoleStartTime,

RoleEndTime>RoleEndTime>UserGroupAuthorization <UserID, GroupID, UserGroupAuthorization <UserID, GroupID,

UGStartTime, UGEndTime>UGStartTime, UGEndTime>UserRoleAuthorization <UserID, RoleID, UserRoleAuthorization <UserID, RoleID,

URStartTime, UREndTime>URStartTime, UREndTime> The User, Roles, Groups, and their Permissions

Security-48

CSE 300

Relational Database Tables for RBACRelational Database Tables for RBAC Authorizing Topics to Users, Groups, and RolesAuthorizing Topics to Users, Groups, and Roles Authorization – Option A:Authorization – Option A:

TopicUserAuth <UserID, PermissionID, TopicUserAuth <UserID, PermissionID, ProjectID, AccordionID, ProjectID, AccordionID, TopicID, SubTopicID1, SubTopicID2>TopicID, SubTopicID1, SubTopicID2>

TopicGroupAuth <GroupID, PermissionID, TopicGroupAuth <GroupID, PermissionID, ProjectID, AccordionID, ProjectID, AccordionID,

TopicID, SubTopicID1, TopicID, SubTopicID1, SubTopicID2>SubTopicID2>TopicRoleAuth <RoleID, PermissionID, TopicRoleAuth <RoleID, PermissionID,

ProjectID, AccordionID, ProjectID, AccordionID, TopicID, SubTopicID1, TopicID, SubTopicID1,

SubTopicID2>SubTopicID2> Authorization – Option B:Authorization – Option B:

TopicAuth <ProjectID, AccordionID, GroupID, TopicAuth <ProjectID, AccordionID, GroupID, UserID, RoleID, PermissionID, UserID, RoleID, PermissionID, TopicID, SubTopicID1, SubTopicID2>TopicID, SubTopicID1, SubTopicID2>

Security-49

CSE 300

Relational Database Tables for RBACRelational Database Tables for RBAC Wiki Look and Feel Authorization:Wiki Look and Feel Authorization:

WikiLookandFeelAuthorization <RoleID, widgetID, WikiLookandFeelAuthorization <RoleID, widgetID, widgetprivilegeID>widgetprivilegeID>Widget <widgetID, widgettype, widgetcategory, Widget <widgetID, widgettype, widgetcategory,

widgetname>widgetname>WidgetPrivilegeType <widgetprivilegeID, WidgetPrivilegeType <widgetprivilegeID, widgetprivilegename>widgetprivilegename> Tracking the Different Widgets and their

Availability based on Role

Security-50

CSE 300

Sample Table EntriesSample Table Entries

Security-51

CSE 300

Usage of Axon in Safety.NetUsage of Axon in Safety.Net Used by Project Team (PIs, Co-PIs, Providers, etc.)Used by Project Team (PIs, Co-PIs, Providers, etc.) Repository for Planning EffortRepository for Planning Effort Upload, Create, Review, Modify DocumentsUpload, Create, Review, Modify Documents Allows Safety.Net Team to Familiarize Themselves Allows Safety.Net Team to Familiarize Themselves

with WIKI Technology/Web Portalswith WIKI Technology/Web Portals No Software to InstallNo Software to Install Problems with Off-the-Shelf Product (MediaWiki)Problems with Off-the-Shelf Product (MediaWiki)

Customization Time Consuming (and Limited) Security Minimal – but Acceptable for this Use

(Can’t store any Patient Related Information) Limited User Friendliness May Result in Poor

Opinion of Web Technology

Security-52

CSE 300

Usage of WIKIs in Safety.NetUsage of WIKIs in Safety.Net Another Alternative – Use AXON ProductAnother Alternative – Use AXON Product

Still Web Solution (No Software to Download) Professional Developers Customize AXON for Use on Project

Multi-Pronged ApproachMulti-Pronged Approach Start with AXON for PIs, Co-PIs, Providers as

Means to Support the Grant Explore the Potential Usage/Extensions of AXON

to Support Patient Access to Health Care Data Synergistic Teams (Serebrum, UCHC, UConn

CSE) Submit Phase I Grants for Funding In-Kind Software Contribution/Pay for CustomizationIn-Kind Software Contribution/Pay for Customization Work Currently FundedWork Currently Funded

Security-53

CSE 300

Potential Usage of WIKIs in CTSAPotential Usage of WIKIs in CTSA Use of AXON as Enabling Technology for the GrantUse of AXON as Enabling Technology for the Grant

Web-Based and Hand-Held Interfaces Customization for Biomedical Informatics Platform for

Clinical Research (Recruit Patients, Providers, etc.) Information Dissemination (Newsletters, etc.)

Architectures and Solutions for Integration with Healthcare Systems (EMR, EHR) Security and HIPPA Compliance XML Standards for Health Data

Document Extensions (Medical Images) Visualization Extensions (Data Mining)

Going Independent Route for Team Project Going Independent Route for Team Project

Security-54

CSE 300

Concluding Remarks: Portal SecurityConcluding Remarks: Portal Security Expand WIKI Security Beyond Coarse Grained Expand WIKI Security Beyond Coarse Grained Transition and Generalize to Web PortalsTransition and Generalize to Web Portals Security for:Security for:

Application Level Document Level Portal Look-and-Feel

Truly Collaborative and SecureTruly Collaborative and Secure Other WorkOther Work

Extending Axon with MAC (Navy SBIR) Dealing with Delegation, Separation of Duty, etc.

Leveraging the Concepts for Team ProjectLeveraging the Concepts for Team Project

Security-55

CSE 300





Document Access


Software Programs




Distributed Setting



Mutual Excl.Safety

Liveness

Security-56

CSE 300

Secure Information Exchange via XMLSecure Information Exchange via XML XML Quickly Emerging as Standard of Choice for: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 XML Document RepositoryOur Perspective, Given a XML Document Repository Each Document has DTD or XML Schema Multiple Documents per DTD/Schema Users with Particular Roles in Application Can We Customize the Displayed XML Instance

Based on Role? How Can we Incorporate RBAC, MAC, etc.?

Security-57

CSE 300

Security for XML DocumentsSecurity for XML Documents Extend RBAC/MAC to XMLExtend RBAC/MAC to XML

Collection of Security DTDs (or XML Schema) DTDs (Schemas) for Roles,

Users, and Constraints Capture RBAC and MAC

Apply Security DTDs (Schemas) to XML Documents An XML Document Appears

Differently Based on Role, MAC, Time, Value

Security DTD (Schema) Filters Document

Different DTDs (Schemas) for Roles, Users, MAC, DAC

Security DTDsRole DTDUser DTDConstraint DTD

Application

Application DTDs

Application XML Files

Appl_Role.xmlAppl _User.xmlAppl_Constraint.xml

Security Officer Generates Security XML files for the Application

ApplicationDTDs and XML

User’s Role Determines

the Scope of Access

to Each XML Document

Security-58

CSE 300

What is an XML Schema?What is an XML Schema?

Security-59

CSE 300

What is an XML Schema?What is an XML Schema?

Security-60

CSE 300

What is an Associated XML Instance?What is an Associated XML Instance?

Security-61

CSE 300

Attaining Security in XMLAttaining Security in XML Given an XML Application of Schemas and Given an XML Application of Schemas and

Associated Instances, can we:Associated Instances, can we: Define Schemas/Instances for Clearances, Roles,

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

MAC Security Classifications (if Needed) Then, as XML Instances are Dynamically Identified to Then, as XML Instances are Dynamically Identified to

Suit a User’s Needs for an Application, can we:Suit a User’s Needs for an Application, can we: Retrieve and Filter those XML Instance(s) Based

on User’s Role, MAC, and/or Delegation Deliver Filtered Instances(s) to User

For AXON – Customized For AXON – Customized Delivered ContentDelivered Content and not and not Just Application Look-and-Feel and Usage!Just Application Look-and-Feel and Usage!

Work is Ongoing at this Point …Work is Ongoing at this Point …

Security-62

CSE 300





Document Access


Software Programs




Distributed Setting



Mutual Excl.Safety

Liveness

Security-63

CSE 300

Motivating Security for OO ParadigmMotivating Security for OO Paradigm OO Paradigm Provides Minimal Support via Public OO Paradigm Provides Minimal Support via Public

Interface and Private ImplementationInterface and Private Implementation Public Interface Represents UNION of all Possible Public Interface Represents UNION of all Possible

Privileges Needed by All Potential UsersPrivileges Needed by All Potential Users A Method in the Public Interface for One Specific A Method in the Public Interface for One Specific

User Available to ALL UsersUser Available to ALL Users Can Access to Public Interface be Customized? Can Individuals have Particular Access to Specific

Subsets of Public Interface? Can Access be Based on (Potentially) Dynamic User

Roles? Can Code be Automatically Generated to Implement an

Enforcement Mechanism? Role of OO Paradigm in Support a Generic, Evolvable,

Reusable Enforcement Mechanism?

Security-64

CSE 300

Why is RBAC Needed?Why is RBAC Needed? Many Situations When OT Library Designer (SWE) Many Situations When OT Library Designer (SWE)

Could Utilize More Fine-Grained Control to Access of Could Utilize More Fine-Grained Control to Access of Public InterfacePublic Interface

Tradeoff Between Developers and End-UsersTradeoff Between Developers and End-Users SWEs Have Different Roles Based on Their

Responsibilities Related to Cooperative Design on an Application

SWEs Should Only See Those Portions of the Application That They Need to See or That They Will Be Responsible for Implementing

End-users Must Be Limited in Their Interactions and Access Depending on Their Roles

Security-65

CSE 300

Why is RBAC Needed?Why is RBAC Needed? For Example:For Example:

In SDEs, the public interface for Modules has methods that read (for SWEs and Managers) and modify instances (only for SWEs)

In HTSS, the public interface for Items has methods that read (for Scanner, I-Controller) and modify instances (only for I-Controller)

In HCA, different health care professionals (e.g., Nurses vs. Physicians vs. Administrators, etc.) require select access to sensitive patient data

Security-66

CSE 300

What is RBAC Approach?What is RBAC Approach? Collects User Role, User Type, and User Class into Collects User Role, User Type, and User Class into

User-Role Definition Hierarchies for ApplicationUser-Role Definition Hierarchies for Application To Establish Privileges: Assign Different Methods of To Establish Privileges: Assign Different Methods of

PIs to Different UCs, UTs, and URsPIs to Different UCs, UTs, and URs Defined Security Must be Enforced:Defined Security Must be Enforced:

For SWEs - by Supporting Environment For End-Users - by Application and Its Tools

RBAC Approach Intentionally Obscures Information RBAC Approach Intentionally Obscures Information and Its Accessand Its Access Consistent with OO Principles on Hiding Force SWEs to Focus on Abstract Concepts

Incorporate RBAC into OO in a Manner Consistent Incorporate RBAC into OO in a Manner Consistent with OO Principles and Philosophywith OO Principles and Philosophy

Security-67

CSE 300

The Health Care Application - OTsThe Health Care Application - OTs

Security-68

CSE 300


Security-69

CSE 300


Security-70

CSE 300

The Health Care Application - RTsThe Health Care Application - RTs

Security-71

CSE 300

User Role Definition Hierarchy (URDH)User Role Definition Hierarchy (URDH) Characterize Individual/Group Application Access via Characterize Individual/Group Application Access via

Hierarchy in Three Abstraction Levels :Hierarchy in Three Abstraction Levels : User-Roles (URs) for Fine-Grained ActivitiesUser-Roles (URs) for Fine-Grained Activities

grade-recorder (changes and corrections) transcript-issuer (fill transcript request)

User-Types (UTs) for Similarities that are Shared User-Types (UTs) for Similarities that are Shared Among Set of URsAmong Set of URs registrar-staff is common responsibilities (access

student records) among URs User-Classes (UCs) for Commonalities Across UTsUser-Classes (UCs) for Commonalities Across UTs

non-academic-staff (UTs: purchasing-staff, campus-police, maintenance-staff, etc.)

academic-staff (UTs: dept-staff, registrar-staff, presidents-office, etc.)

Security-72

CSE 300

URDH for HCAURDH for HCA

Users

UC:Medical_Staff

UT:Nurse UT:Physcian

UR:Manager

UR:Staff_RN UR:Education

UR:Discharge_Plng

UR:Private UR:Attending

UC:Support_Staff

Etc.

UT:Technician

UR:Director

UR:Lab UR:Pharmacy

UR:Radiology

Security-73

CSE 300

Privilege Definition ProcessPrivilege Definition Process AssignmentAssignment

Assign Methods to Various Nodes of URDH Methods that are Assigned are Positive Privileges Indicate they can be Invoked by User (via a

Software Application/Client) ProhibitionProhibition

Indicate the Methods which Can’t be Called These represent the Negative Privileges Attempt to Invoke by User (via a Software

Application/Client) Results in Exception Why are Prohibited Methods Necessary?Why are Prohibited Methods Necessary?

Security-74

CSE 300

Privilege Acquisition ProcessPrivilege Acquisition Process AssignmentAssignment

Assigned to UR for Its Use Only Assigned to UT and Passed to Its URs Assigned to UC and Passed to Its UTs

Employ OO Concepts: Inheritance w.r.t. PrivilegesEmploy OO Concepts: Inheritance w.r.t. Privileges Specialization (UT to URs) Generalization (URs to UT, UTs to UC)

Notes:Notes: A UR Under 2 UTs May Have Diff. Meaning URs Cannot be Further Specialized Granularity of UR: Designer Definable! Vitals, SetIV, etc., in HCA OrderItem, TakeInventory, etc., in HTSS

Security-75

CSE 300

Node Profiles and PrivilegesNode Profiles and Privileges Profiles Contain Detailed Requirements on the Profiles Contain Detailed Requirements on the

Semantic Contex(n)t for Security Related Aspects of Semantic Contex(n)t for Security Related Aspects of ApplicationApplication

Each Node in the URDH Represented by:Each Node in the URDH Represented by: Name Prose Description of Responsibility Prose Security Requirement Assigned Methods (Positive Privileges) Prohibited Methods (Negative Privileges) Consistency Criteria (Relations Among Nodes)

Security-76

CSE 300

Node Descriptions - Examples from HCANode Descriptions - Examples from HCA

Security-77

CSE 300

Role Security Requirements from HCARole Security Requirements from HCA

Security-78

CSE 300

Positive Privileges for NodesPositive Privileges for Nodes Explicit Access to PPI Methods of OTsExplicit Access to PPI Methods of OTs Staff_RN Assigned: Staff_RN Assigned:

Get_Symptom of Visit and Get_Medication of Prescription

Get_Patient_Name of Record and Get_Test of Medical_R

Set_Symptom (record symptoms on patients) Set_Test_Code (record test to be conducted) Set_Patient_Name and Insert_Med_History

Discharge_Plng and Education Assigned:Discharge_Plng and Education Assigned: Similar Get Methods Limited Write: Insert_Med_History

Security-79

CSE 300

Implied Methodology for AssignmentImplied Methodology for Assignment Privileges Associated with URsPrivileges Associated with URs Shared Privileges for URs Under Same UT Can be Shared Privileges for URs Under Same UT Can be

Moved to UTMoved to UT Shared Privileges for UTs Under Same UC Can be Shared Privileges for UTs Under Same UC Can be

Moved to UCMoved to UC However, Methods Assigned to:However, Methods Assigned to:

UC Available to Its UTs/URs UT Available to Its URs

Observe that:Observe that: Commonalities Push Up Tree Differences Flow Down Tree

Security-80

CSE 300

Two Important ConceptsTwo Important Concepts Methods Call Other MethodsMethods Call Other Methods

“8” Methods Assigned to Staff_RN Direct Methods/Explicitly Assigned

“n” Indirect Methods Assigned to Staff_RN “8” Methods Assigned Call Other Methods In Turn, Other Methods Call Still Other Methods Hence, Chaining Effect of Implied (Actual) Calls

Methods on URDH Mirror Inheritance ConceptsMethods on URDH Mirror Inheritance Concepts Methods on UC Available to all of its UR Methods on UR Specific to that Role

Security-81

CSE 300

Prohibited Methods - Negative PrivilegesProhibited Methods - Negative Privileges Important To Give Explicitly, Since:Important To Give Explicitly, Since:

Methods Call Other Methods (MP) Assigned Methods Map to Larger Set Due to Calls

and Inheritance Staff_RN Prohibited: Staff_RN Prohibited:

Set_Treatment of Visit Set_Medication of Prescription Get_All methods from Medical_R

Prohibition w.r.t. Hierarchy:Prohibition w.r.t. Hierarchy: On a UR Implies on Its UT/UC On a UT(UC) Implies on Its URs(UTs)

Security-82

CSE 300

Consistency Criteria Between URDH NodesConsistency Criteria Between URDH Nodes Equivalence - URDH Nodes Must Have Same Equivalence - URDH Nodes Must Have Same

Capabilities per Assigned/Prohibited MethodsCapabilities per Assigned/Prohibited Methods Physical Respiratory Respiratory Occupational Education Discharge_Plng

Subsumption - Ordering Among URDH Nodes w.r.t. Subsumption - Ordering Among URDH Nodes w.r.t. CapabilitiesCapabilities Staff_RN Discharge_Plng Manager Staff_RN

Transitive Closure AppliesTransitive Closure Applies

Security-83

CSE 300

A Complete Node ProfileA Complete Node Profile

Security-84

CSE 300

Security Issues for OO ParadigmSecurity Issues for OO Paradigm MAC/DAC/RBAC - Existing Security ApproachesMAC/DAC/RBAC - Existing Security Approaches Must Security for OO Systems Embody an Existing Must Security for OO Systems Embody an Existing

Approach?Approach? Is there a `Better' or `New' Choice to Consider?Is there a `Better' or `New' Choice to Consider? Are there Characteristics/Features of OO Paradigm, Are there Characteristics/Features of OO Paradigm,

Systems, and Applications that Should Dictate Systems, and Applications that Should Dictate Approach?Approach?

Focus on Impact/Influence of:Focus on Impact/Influence of: Encapsulation, Hiding, and Inheritance OO Application Characteristics Polymorphism, Dispatching, Overloading Object-Oriented Paradigm Claim

Security-85

CSE 300

Encapsulation, Hiding, and InheritanceEncapsulation, Hiding, and Inheritance Object Types (OTs)/Classes Involve:Object Types (OTs)/Classes Involve:

Encapsulated: Data and Methods Public Interface to Access OT Hidden Implementation Fosters Representation

Independence Encapsulation: Reduces Allowable Actions via the Encapsulation: Reduces Allowable Actions via the

Public Interface Public Interface Hiding: Masks Sensitive Details in ImplementationHiding: Masks Sensitive Details in Implementation Inheritance: Controlled Sharing Among OTs Transfers Inheritance: Controlled Sharing Among OTs Transfers

Privileges from Ancestor(s) to Descendant(s)Privileges from Ancestor(s) to Descendant(s) All Three Embody Security Concepts!All Three Embody Security Concepts!

Security-86

CSE 300

What's in an OO Application?What's in an OO Application? Application Characteristics:Application Characteristics:

High Volumes of Persistent Data Varied/Disparate Data Multiple Individuals/Unique Needs Distributed: Agencies/Individuals/Systems

Public Interface of OT Provides:Public Interface of OT Provides: Methods, Parameters, Return Type One Interface for All Users Can't Control/Limit Access to Public Methods Need: Selective/Customizable Control of Public

Interface Based on an Individual's Role

Security-87

CSE 300

What's in an OO Application?What's in an OO Application? OT/Class Libraries Contain:OT/Class Libraries Contain:

Hundreds (or More) OTs Instances/OT Range from Very Few (10s or Less)

to Very Many (1000s or More) Instances Can Change Types Instances/OT Can Change Radically Over Time

Conflicts with MAC: Conflicts with MAC: Relational Data, Few OTs (10s), Many Instances

(1000s) Control at Instance and Attribute Value Levels

Security-88

CSE 300

Polymorphism, Dispatching, OverloadingPolymorphism, Dispatching, Overloading Polymorphism:Polymorphism:

Type-Independent Software Promotes Reuse Realized via Generics or Parameterized Types Can Polymorphism be Used in a Role Independent Security

Library for Authentication and Enforcement? Dispatching:Dispatching:

Run-Time Method Invocation Based on Type Strong Ties to Inheritance, Reuse, and Extensibility Can Dispatching Support Execution of Security Code by

Invoking Different Methods Based on User Roles? Overloading:Overloading:

Methods with Same Name and Different Signatures Ada, C++, SML, etc., Support User-Defined Overloading Overloading Supports Polymorphism and Dispatching

Security-89

CSE 300

Object-Oriented Paradigm ClaimsObject-Oriented Paradigm Claims Accepted Claims:Accepted Claims:

Stresses Modularity Promotes Software Reuse Facilitates Software Evolution

Difficult-to-Prove Claims:Difficult-to-Prove Claims: Controls Data Consistency Increases Productivity

For OO Security, Reuse and Evolution are Critical!For OO Security, Reuse and Evolution are Critical! Both Strongly Linked to Definition and Maintenance Both Strongly Linked to Definition and Maintenance

of OT/Class Librariesof OT/Class Libraries

Security-90

CSE 300

Security Issues and ApproachesSecurity Issues and Approaches Security Defn./Enforcement Consistent with OO Security Defn./Enforcement Consistent with OO

Precepts and PrinciplesPrecepts and Principles Support for Wide-Variety of User-Roles Support for Wide-Variety of User-Roles User Roles - Extensibility/Evolution CriticalUser Roles - Extensibility/Evolution Critical Target OO Applications and Systems:Target OO Applications and Systems:

Programming, SW Engineering, Databases, Security RBAC within Joint Object-Oriented Framework Framework Facilitates Development of Application Code

Against Persistent Class Library (and its Underlying DB) Role-Based Enforcement Mechanism is Part of Executable

Image After Compilation During Runtime, Role of Logged In Individual Utilized to

Enforce Security

Security-91

CSE 300

Goals for RBAC Enforcement MechanismGoals for RBAC Enforcement Mechanism Extensibility: Application Perspective:Extensibility: Application Perspective:

New Classes, Methods, Roles, etc. Automatic Adjustment by RBAC EM?

Extensibility: RBAC EM Perspective:Extensibility: RBAC EM Perspective: New Security Policies/Approaches Can you go from MAC to DAC?

Flexibility: Application Perspective:Flexibility: Application Perspective: Changes to Roles, Methods, Classes, etc. How does RBAC EM Adapt?

Flexibility: RBAC EM Perspective:Flexibility: RBAC EM Perspective: Change to Security Restrictions/Policy Reimplementation of RBAC EM?

Security-92

CSE 300

Goals for RBAC Enforcement MechanismGoals for RBAC Enforcement Mechanism Hiding & Encapsulation: Application Perspective:Hiding & Encapsulation: Application Perspective:

Invisible to Users and Components Minimize Impact on Actual Software

Hiding & Encapsulation: RBAC EM Perspective:Hiding & Encapsulation: RBAC EM Perspective: Representation Independence a Must Exploit OO Paradigm/Principles

Reusability: Application Perspective:Reusability: Application Perspective: Reuse of Classes, Methods, Roles Does RBAC EM Always Need Regeneration?

Reusability: RBAC EM Perspective:Reusability: RBAC EM Perspective: Is RBAC EM Application Specific? Is there a Generic RBAC EM?

Security-93

CSE 300

Goals for RBAC Enforcement MechanismGoals for RBAC Enforcement Mechanism Software Engineering RelatedSoftware Engineering Related

Software Itself How Pervasive are the Security Additions? Easy to Change/Modify as Privileges Change? Adheres to Existing OOPL Capabilities

Software Engineer How Much Does the Software Engineer Need to Know

about Security? What can be Hidden from Software Engineering? Can we Prevent Software Engineer from Getting at

Restricted Software? For Example, Putting in Trap DoorFor Example, Putting in Trap Door

Security-94

CSE 300

Quantifying RBAC Approaches Quantifying RBAC Approaches Brute-Force (BFA)Brute-Force (BFA)

Focus on Code Level Changes Include “Conditionals” for Each UR Allowed to

Access a Method in Each Methods Code User-Role Subclass (URSA)User-Role Subclass (URSA)

Specify “Subclasses” for Each User Role that Correspond to Each Application Class/OT

Override Prohibited Methods to Return Nulls URDH Class Library (UCLA)URDH Class Library (UCLA)

Employ a Separate Class Library that Mirrors the URDH and Contains Privileges

Requires Casting to Insure Correct Behavior

Security-95

CSE 300

Brute Force ApproachBrute Force Approach Consider HCA Prescription Class:Consider HCA Prescription Class:

UR: Staff_RN Assigned Following MethodsUR: Staff_RN Assigned Following Methods

class Prescription { Public: Set_Prescription_No(....); Get_Prescription_No(....); Set_Pharmacist_Name(....); Get_Pharmacist_Name(....); Set_Medication(....); Get_Medication(....); Protected: char* patient_name, address, ..... }

Get_Prescription_No(....);Get_Pharmacist_Name(....);Get_Medication(....);

Security-96

CSE 300

Brute Force ApproachBrute Force Approach Method Implementation:Method Implementation:

Comments on BFA:Comments on BFA: Code for IFs Easily Generated Any Changes Have Significant Impact Encapsulation is Poor - Spread Across OTs No Identifiable Enforcement Mechanism

char* Prescription::Get_Prescription_No (....) { /* Check if a valid user is accessing the method */ if (User.User_Role == Staff_RN) || (User.User_Role == Physician) || (etc.) { // .... method code for the access ..... } else return (NULL);

Security-97

CSE 300

User-Role Subclassing ApproachUser-Role Subclassing Approach Consider HCA Prescription ClassConsider HCA Prescription Class

Associated Privileges:Associated Privileges:

class Prescription { public: virtual Get_Prescription_No(....); virtual Set_Prescription_No(....); virtual Get_Pharmacist_Name(....); virtual Set_Pharmacist_Name(....); virtual Get_Medication(....); virtual Set_Medication(....); private: char* prescription_no, pharmacist_name, ...}

UR: Attending_MD PM: Set_Pharmacist_Name AMs: All of the Rest

UR: Staff_RN AMs: Get_Pharmacist_Name Get_Prescription_No Get_Medication PMs: Set_Prescription_No Set_Pharmacist_Name Set_Medication

Security-98

CSE 300

User-Role Subclassing ApproachUser-Role Subclassing Approach Generate User-Role Subclasses:Generate User-Role Subclasses:

class Staff_RN_Prescription: public Prescription{ public: virtual void Set_Prescription_No(...) {return;}; virtual void Set_Pharmacist_Name(...) {return;}; virtual void Set_Medication(...) {return;}; };

class Attending_MD_Prescription: public Prescription{ public: virtual void Set_Pharmacist_Name(...) {return;};};

Security-99

CSE 300

User-Role Subclassing ApproachUser-Role Subclassing Approach Behavior at Runtime: Consider the CallBehavior at Runtime: Consider the Call

Type of ptr Determines Which Method is called:Type of ptr Determines Which Method is called:

If Staff_RN User Role, the MethodIf Staff_RN User Role, the Method

is Called Which Returns Nothing (Overridden)is Called Which Returns Nothing (Overridden)

ptr->Set_Prescription_No();

virtual void Set_Prescription_No(...) {return;};

Security-100

CSE 300

User-Role Subclassing ApproachUser-Role Subclassing Approach

main() { char user_name[20], user_role[20]; Prescription* P; Staff_RN_Prescription* SP; int Number; char* Medication; cout << "Please input your name:"; cin >> user_name; cout << "Please input your role:"; cin >> user_role; // Simulates a URDH and Authorization List Current_User=new User(user_name, user_role); P = new Prescription("Jessica", "3-9-95", 100, "Kitty", "Cold");

Security-101

CSE 300

User-Role Subclassing ApproachUser-Role Subclassing Approach

// This is a portion of application code if (strcmp(user_role, "Staff_RN")==0) { // Create a Instance to Hold “Staff_RM” SP = new Staff_RN_Prescription("", "", 0, "", ""); // Copy from the Parent Prescription Object SP->copy_object(P); //copy attributes from parent // Attempt to Invoke a Method as Staff_RN SP->Set_Prescription_No(200); // Set No to 200 //Get the Result of Invocation Number=SP->Get_Prescription_No(); // Staff_RN Doesn’t have Privileges - output 100 cout << "Number==" << Number << "\n"; P->copy_object(SP); //copy attributes from child delete SP; } }

Security-102

CSE 300

Application Code Still UR SpecificApplication Code Still UR Specific

Comments on URSA:Comments on URSA: Extensible via New User-Role Subclasses Hindered by Switch/Recompilation Encapsulation of Security at Method Level Enforcement Mechanism Still Vague

void Fill_Patient_Prescription(..., Prescription* p_rec){ // Determine the role of the user currently switch (User.User_Role()) { case Staff_RN: ((Staff_RN_Prescription *) p_rec)->Set_Prescription_No(...); break; case Attending_MD: ((Attending_MD_Prescription *) p_rec)->Set_Prescription_No(...); break; }}

Security-103

CSE 300

URDH Class Library ApproachURDH Class Library Approach ObjectivesObjectives

Utilize Structure of URDH to Record Privileges Track all of Methods Assigned to User Roles, User

Types, and User Classes ResultResult

Class Hierarchy Corresponding to URDH Contains all Permissions Turn Off Permissions at Root Node Turn On Permissions to Correspond to Assigned

Methods Invocation only if Method “Turned On”

Security-104

CSE 300

Partial Class Hierarchy for URDHPartial Class Hierarchy for URDH

Root

Users UC:Medical Staff

UT:Nurse

UR:Staff RNUR:Manager UR:Education

Turn Off All “Check” Methods at Root Node

Turn On Check MethodsTo Correspond toAssigned Methods

Call “Check” Method Prior to Invoking Actual Method

Security-105

CSE 300

URDH ClassesURDH Classes Consider Following URDH Subset:Consider Following URDH Subset:

and its Corresponding Class Library:and its Corresponding Class Library:

UR: Staff_RN Assigned methods: Get_Prescription_No() (to Staff_RN) Get_Pharmacist_Name() (to Staff_RN) Get_Medication() (to Nurse)

class Root: all methods return False;class Users: public Rootclass Medical_Staff: public Rootclass Nurse: public Users, public Medical_Staff {int Check_Prescription_Get_Medication(){return True;}};class Staff_RN: public Nurse {int Check_Prescription_Get_Prescription_No(){return True;}int Check_Prescription_Get_Pharmacist_Name(){return True;}};

Security-106

CSE 300

Impact on Application ClassesImpact on Application Classes Introduce “Object” Class to Track Current User and Introduce “Object” Class to Track Current User and

Tie into URDH Class HierarchyTie into URDH Class Hierarchy

Note User Part of Prescription ConstructorNote User Part of Prescription Constructor

class Object { protected: Root* current_user; ... }

class Item: public Object{ ... }

class Prescription: public Item { public : Prescription(Root* u, char* Name, ...); int Get_Prescription_No(); ... };

Security-107

CSE 300

Impact on Application ClassesImpact on Application Classes Focus on Actual Method ImplementationsFocus on Actual Method Implementations Wrap Check Method Call Around Method BodyWrap Check Method Call Around Method Body

Note Other Gets and Sets are SimilarNote Other Gets and Sets are Similar

int Prescription::Get_Prescription_No(){ if(current_user-> Check_Prescription_Get_Prescription_No()) return(Prescription_No); else return(NULL);}void Prescription::Set_Prescription_No(int No){ if(current_user-> Check_Prescription_Set_Prescription_No()) {Prescription_No=No;}}

Security-108

CSE 300

URDH Class Library ApproachURDH Class Library Approach

main() { Prescription* P; char user_name[64]; char user_role[64]; int Number; Root* current_user;

cout << "Please input your name:"; cin >> user_name; cout << "Please input your role:"; cin >> user_role; // Create and Simulate a New User if (strcmp(user_role, "Staff_RN") == 0) { current_user = new Staff_RN(user_name); } else current_user = new Root(user_name);

Security-109

CSE 300

Key Issues:Key Issues: Create User to Coincide with Entry in URDH

Class Hierarchy and Set Current User Change Each Method Code to Invoke Check

Method Prior to Actual Invocation (Body)

URDH Class Library ApproachURDH Class Library Approach

P = new Prescription(current_user,"Jim", "3-9-95", 1, "Ron", "Flu"); // FOLLOWING Set HAS NO EFFECT IF A STAFF_RN // IS ATTEMPTING TO MAKE THE CHANGE P->Set_Prescription_No(100); Number=P->Get_Prescription_No(); cout << "Number==" << Number << "\n"; }

Security-110

CSE 300

Comments: URDH Class Library ApproachComments: URDH Class Library Approach Since Changes aren't Allowed by Unauthorized Since Changes aren't Allowed by Unauthorized

Individuals the Need to Undo is EliminatedIndividuals the Need to Undo is Eliminated Extensibility: As new URs are Changed/Added, Only Extensibility: As new URs are Changed/Added, Only

URDH Class Library Must be RecompiledURDH Class Library Must be Recompiled Hides Security Code Once a User has been IdentifiedHides Security Code Once a User has been Identified Better Job at Encapsulation of Enforcement Better Job at Encapsulation of Enforcement

MechanismMechanism Still Difficult to Quantify Entire Mechanism as a Still Difficult to Quantify Entire Mechanism as a

Single UnitSingle Unit Steamlines Application CodeSteamlines Application Code Reusability is Definitely Utilized/SuperiorReusability is Definitely Utilized/Superior

Security-111

CSE 300

Compare/Contrast the Three ApproachesCompare/Contrast the Three Approaches Application PerspectiveApplication Perspective

RBAC Enforcement Mechanism PerspectiveRBAC Enforcement Mechanism Perspective

Security-112

CSE 300

Advanced RBAC Approaches Advanced RBAC Approaches Generic Security ClassesGeneric Security Classes

Streamline Security Defn. Process Achieve Uniformity/Promote Reuse Independent Design/Implementation/Validation

Exception HandlingException Handling Hide Security Code with Handlers Raise Violations when UR Attempts Unauthorized

Access Review Four ApproachesReview Four Approaches

Generic URSA (GURSA) Basic Exception Approach (BEA) Generic Exception Approach (GEA) Advanced Exception Handling See Papers on Course Web Page…

Security-113

CSE 300





Document Access


Software Programs




Distributed Setting



Mutual Excl.Safety

Liveness

DSEC--114

CSE300

A Security Model/Enforcement Framework with A Security Model/Enforcement Framework with Assurance for a Distributed EnvironmentAssurance for a Distributed Environment

C. Phillips, S. Demurjian, and T.C. TingComputer Science & Engineering Department

The University of ConnecticutStorrs, Connecticut 06269-3155

[email protected]{steve,ting}@engr.uconn.edu

http://www.engr.uconn.edu/~steve(860) 486 - 4818

DSEC--115

CSE300

Motivation Motivation

Legacy

Legacy

COTS

GOTS

Database

Database

NETWORK

JavaClient

GOTSClient

LegacyClient

DatabaseClient

COTSClient

Premise: Premise: ArtifactsArtifacts - set of - set of DB, Legacy, COTS,

GOTS, Each w/ API Premise: Premise: UsersUsers

New and Existing Utilize Artifact APIs

Distributed Application, DADistributed Application, DA Artifacts + Users

Can we Control Can we Control UserUser Access to Access to Artifact Artifact APIs APIs (Methods) by … (Methods) by … Role (who) Classification (MAC) Time (when) Data (what)

DSEC--116

CSE300

JavaClientUser ARole X

AuthorizeC1, C2C3, C5L1, L2

L: Legacy API:

MethodsL1L2L3

C: COTSAPI:

MethodsC1C2C3C4C5

JavaClientUser BRole Y

AuthorizeC1, C4L2, L3

Motivation Motivation API Access Based on Role/ClassificationAPI Access Based on Role/Classification Can we Control AccessCan we Control Access

Based on Based on RoleRole??

Can we Control Access to Based on Can we Control Access to Based on ClassificationClassification??(high T > S > C > U low)(high T > S > C > U low)


AuthorizeSecret

(S)

L: Legacy API:

MethodsT: L1C: L2U: L3

C: COTSAPI:

MethodsT: C1S: C2S: C3T: C4C: C5


AuthorizeConfidential

(C)

DSEC--117

CSE300Java

ClientUser ARole X

AuthorizeC1: TI aC4: TI bL1: TI c

L: Legacy API:

MethodsL1L2L3

C: COTSAPI:

MethodsC1C2C3C4C5


AuthorizeC2: TI dL1: TI e

Motivation Motivation API Access Based on Time/ValueAPI Access Based on Time/Value

Can we Control Access Can we Control Access Based on Based on TimeTime??

Can we Control Access Can we Control Access Based on Based on Data ValuesData Values??


AuthorizeX.C1 (a < 30)X.C4 (d > 40)X.L1 (f = 10)

L: Legacy API:

MethodsL1 (f)L2 (g)L3 (h)

C: COTSAPI:

MethodsC1 (a)C2 (b)C3 (c)C4 (d)C5 (e)


AuthorizeY.C2 (0<b<99)Y. L1 (f = 100)

DSEC--118

CSE300

Overview of Remainder of TalkOverview of Remainder of Talk

Problem StatementProblem Statement Research Goals and ObjectivesResearch Goals and Objectives Relevance/Importance of ResearchRelevance/Importance of Research Distributed Environment AssumptionsDistributed Environment Assumptions Unified Security Model for RBAC/MACUnified Security Model for RBAC/MAC Security Enforcement FrameworkSecurity Enforcement Framework Security AssuranceSecurity Assurance

Design Time and Run Time Checks Role Delegation Extensions and Capabilities Role Delegation Extensions and Capabilities Analysis vs. SSE-CMM and Evaluation vs. DCPAnalysis vs. SSE-CMM and Evaluation vs. DCP Concluding RemarksConcluding Remarks

DSEC--119

CSE300

Problem Statement - Research FociProblem Statement - Research Foci

UnifiedRBAC/MAC

Security Model

Security Policy Definition

Run TimeSecurity

Assurance

Analyses of RBAC/MACModel/Framework Against SSE-CMM

Evaluation of RBAC/MAC Model

Using DCP

RBAC/MACEnforcementFramework

Security Administrative

and Management Tools

Design Time Security

Assurance

DSEC--120

CSE300

Research Goals and ObjectivesResearch Goals and Objectives

Security Model that Unifies RBAC/MAC withSecurity Model that Unifies RBAC/MAC with Constraints Based on Method Signature (How),

Time (When), and Security Clearances and Classifications

Security Policy and Enforcement AssuranceSecurity Policy and Enforcement Assurance Design Time (During Security Policy

Definition) Security Assurance Run Time (Executing Application) Security

Enforcement RBAC/MAC Model for a Distributed SettingRBAC/MAC Model for a Distributed Setting

Leverage Middleware Capabilities Flexible, Portable, Platform Independent Security with Minimal/Controlled Impact

DSEC--121

CSE300

Research Goals and ObjectivesResearch Goals and Objectives

Method-Level Approach Method-Level Approach Constraints using: Role, MAC, Time, and Data Customized Access to APIs of Artifacts Contrast with Object Level Approach

Assessment: Security Model/Enforcement Assessment: Security Model/Enforcement Analysis Versus CMU’s Security Engineering

Capability Maturity Model (SSE-CMM) Evaluation of Utility of Approach for

Supporting Dynamic Coalition Problem Prototype

Administrative and Management Tools - Assurance Security Resources/Middleware - Enforcement

DSEC--122

CSE300

Relevance/Importance of ResearchRelevance/Importance of Research

Shrinking Military More Reliant on the Civilian Shrinking Military More Reliant on the Civilian Sector for Operational Support and Internet UsageSector for Operational Support and Internet Usage Legacy Software Systems COTS and GOTS Shared Databases

Flexible Security Policy Realization and Flexible Security Policy Realization and Enforcement in Support of Coalition WarfareEnforcement in Support of Coalition Warfare Classified and Non-Classified Information Rapid Deployment and Easy to Use Platform Independence

Growing Need for Multi-level Security SolutionsGrowing Need for Multi-level Security Solutions Currently Government Systems Avoid MAC Difficult to Realize and Manage

DSEC--123

CSE300

Distributed Environment Assumptions Distributed Environment Assumptions

Assume Presence of Middleware (JINI, CORBA):Assume Presence of Middleware (JINI, CORBA): Provides Bridge Between Software Artifacts Allows Software Artifacts to Register/Publish

their APIs for use by Clients/Other Resources Lookup Service: Lookup Service:

Middleware that Provides Means for Software Artifacts (Resource) and Clients to Interact

A Resource is a Software Artifact Accessible via A Resource is a Software Artifact Accessible via API (e.g., C++, Java, etc.) Consisting of ServicesAPI (e.g., C++, Java, etc.) Consisting of Services

A Service is a Logical Grouping of Public A Service is a Logical Grouping of Public Methods that are Registered with Lookup ServiceMethods that are Registered with Lookup Service

A Method has a Signature Consisting of a Possible A Method has a Signature Consisting of a Possible Null Return Type and Zero or More ParametersNull Return Type and Zero or More Parameters

DSEC--124

CSE300

Global Command and Control System Global Command and Control System (GCCS) Resource/Service/Methods(GCCS) Resource/Service/Methods

GCCS Resource with Two Services

Joint Service with Methods: a.k.a Weather (Token); METOC VideoTeleconference (Token, fromOrg, toOrg);TLCF JointOperationsPlannning (Token, CrisisNum); JOPES CrisisPicture (Token, CrisisNum, Grid1, Grid2); COP TransportationFlow (Token); JFAST LogisticsPlanningTool (Token, CrisisNum); LOGSAFE DefenseMessageSystem (Token); DMS NATOMessageSystem (Token); CRONOS

Component Service with Methods: ArmyBattleCommandSys (Token, CrisisNum); ABCS AirForceBattleManagementSys (Token, CrisisNum); TBMCS MarineCombatOpnsSys (Token, CrisisNum); TCO NavyCommandSystem (Token, CrisisNum); JMCIS

DSEC--125

CSE300

Security Enforcement Framework Security Enforcement Framework Software ArchitectureSoftware Architecture

WrappedResource for LegacyApplication

WrappedResource

for DatabaseApplication

LookupService

General Resource

WrappedResource

for COTSApplication

JavaClient

LegacyClient

DatabaseClient

SoftwareAgent

COTSClient

Lookup

Service

Security AuthorizationClient (SAC)

Security Policy Client (SPC)

SecurityRegistration

Services

Unified Security Resource (USR)Security Policy

Services

Security DelegationClient (SDC)

SecurityAnalysis and

Tracking (SAT)

SecurityAuthorization

Services

DSEC--126

CSE300

Security Enforcement FrameworkSecurity Enforcement Framework

Unified Security Resource Services to:Unified Security Resource Services to: Manage URs and Privileges Authorize URs to Us Identify Users and Track Security Behavior

Associated Administrative/Management ToolsAssociated Administrative/Management Tools Security Policy Client to Grant/Revoke Privileges (TCs, methods, SCs)/set CLS/CLR Security Authorization Client to Assign CLRs and Authorize URs to End Users Security Analysis Tool (SAT) to Track all Client Activity (Logons/Method Invocations)

DSEC--127

CSE300

Definition 1: A lifetime, LT, is a Discrete Time Interval [LT.st, LT.et] with LT.et > LT.st LT.st (start time) or LT.et (end time) is a tuple

(day, month, year, hour, minute, second) where x y means x.LT.st y.LT.st and

x.LT.et y.LT.et X Y is equivalent to Y X Let

LT = [ct, ] means current time (ct) onward

Unified Security Model DefinitionsUnified Security Model DefinitionsLifetimes ConceptLifetimes Concept

}.,.min{}.,.max{ etYetXETandstYstXST

)2.1(],[

)1.1(Ø

STETifETST

STETifYX

DSEC--128

CSE300

Concept of Containment of LifetimesConcept of Containment of Lifetimes

DSEC--129

CSE300

Usage of LifetimesUsage of Lifetimes

Lifetimes are Important Concepts since they Lifetimes are Important Concepts since they Delineate “When” an Action or Usage Can OccurDelineate “When” an Action or Usage Can Occur

For Example:For Example: “When” is a User Role Authorized to invoke a

Method? “When” is a User Authorized to a User Role? “When” Does a Resource Allow its Services

Available in the Distributed Environment? Overall - LTs Control the Time Constrained Overall - LTs Control the Time Constrained

Behavior for SecurityBehavior for Security

DSEC--130

CSE300

Examples of LifetimesExamples of Lifetimes

DSEC--131

CSE300

Related Work: LifetimesRelated Work: Lifetimes

Leasing [Wald99]Leasing [Wald99] Temporal Constraints [Bert96, Bert01, Ahn00]Temporal Constraints [Bert96, Bert01, Ahn00] DBMS Constraints [Bark01, Nota95]DBMS Constraints [Bark01, Nota95] User Constraints [Sand98, Zurk96]User Constraints [Sand98, Zurk96] Similarities and DifferencesSimilarities and Differences::

Extend Leasing Concept from Resources, Services, and Methods to LTs of URs/ Users

Temporal Constraints used on Objects and Work Flow are applied to Resources, URs, and Users Which Allows for Less Code Modification and Dynamic Changes

LTs in Conjunction with Method Time Constraints Improve Granularity and Provide Increased Flexibility for Security Policy

DSEC--132

CSE300

Definition 2: Relevant MAC Concepts are: A sensitivity level, SLEVEL, SLEVEL =

{U,C,S,T} unclassified (U) - no impact; confidential (C) causes some damage; secret (S), causes serious damage; top secret (T) causes exceptionally grave damage

SLEVELs form a hierarchy: U < C < S < T Clearance (CLR) is SLEVEL given to users Classification (CLS) is the SLEVEL given to

entities (roles, objects, methods, etc.) Note:Note:

We Utilize 4 Levels of Sensitivity Approach Will Work for n Levels

Unified Security Model DefinitionsUnified Security Model DefinitionsMAC ConceptMAC Concept

DSEC--133

CSE300

Unified Security Model DefinitionsUnified Security Model DefinitionsDistributed ApplicationDistributed Application

Definition 3:Definition 3: A A Distributed ApplicationDistributed Application, , DAPPL,DAPPL, is Composed of a Set of is Composed of a Set of Software/systemSoftware/system Resources Resources (e.g., a Legacy, COTS, DB, Etc.), Each (e.g., a Legacy, COTS, DB, Etc.), Each Composed of a Set of Composed of a Set of Services, Services, Which in Turn Are Which in Turn Are Each Composed of a Set of Each Composed of a Set of MethodsMethods, Namely:, Namely:

Uniquely Identifies Each MethodUniquely Identifies Each Method

}1|{ miRR i

}1|{ iiji njSS

}1|{ ijijkij qkMM

ijkiji MSR ..

DSEC--134

CSE300

Unified Security Model DefinitionsUnified Security Model DefinitionsMethodsMethods

Every Method of Service of ResourceEvery Method of Service of ResourceMust be Registered from a Security PerspectiveMust be Registered from a Security Perspective

Registration of Signature and Security InformationRegistration of Signature and Security Information Lifetime of Method (When Available for Use) Classification of Method (Level of Use)

Definition 4:Definition 4: Every Every methodmethod is registered as: is registered as:

Default CLS is UDefault CLS is U Default LT = [ct, Default LT = [ct, ] ] Resource by Registering Sets CLS and LTResource by Registering Sets CLS and LT

],,,[ Paramsijk

CLSijk

LTijk

Nameijkijk MMMMM

ijkiji MSR ..

DSEC--135

CSE300

Unified Security Model DefinitionsUnified Security Model DefinitionsServicesServices

Definition 5Definition 5: Every : Every service service is registered as:is registered as:

wherewhere

Note that LT and CLS are Inferred from LT and Note that LT and CLS are Inferred from LT and CLS of Methods that Comprise ServiceCLS of Methods that Comprise Service

],,[ CLSij

LTij

Nameijij SSSS

}...1|min{ ..ij

stLTijk

stLTij qkMS

}...1|max{ ..ij

etLTijk

etLTij qkMS

}1|min{ ijCLSijk

CLSij qkMS

DSEC--136

CSE300

Unified Security Model DefinitionsUnified Security Model DefinitionsResourceResource

Definition 6:Definition 6: Every Every resourceresource is registered as: is registered as:

wherewhere

Note that LT and CLS are Inferred from LT and Note that LT and CLS are Inferred from LT and CLS of Services that Comprise ResourceCLS of Services that Comprise Resource

],,[ CLSi

LTi

Nameii RRRR

}...1|min{ ..i

stLTij

stLTi njSR

}...1|max{ ..i

etLTij

etLTi njSR

}1|min{ iCLSij

CLSi njSR

DSEC--137

CSE300

Clearances/ClassificationsClearances/ClassificationsExampleExample

(C) GCCS Resource C= min {Service CLSs}(S) Joint Service with Methods S = min{Method CLSs} a.k.a (S)Weather (Token); METOC (S)VideoTeleconference (Token, fromOrg, toOrg); TLCF (S)JointOperationsPlannning (Token, CrisisNum); JOPES (S)CrisisPicture (Token, CrisisNum, Grid1, Grid2); COP (S)TransportationFlow (Token);JFAST (S)LogisticsPlanningTool (Token, CrisisNum); LOGSAFE (S)DefenseMessageSystem (Token); DMS (T)NATOMessageSystem (Token); CRONOS

(C) Component Service with Methods: C = min{Method CLSs} (S)ArmyBattleCommandSys (Token, CrisisNum); ABCS (S)AirForceBattleManagementSys (Token, CrisisNum); TBMCS (S)MarineCombatOpnsSys (Token, CrisisNum); TCO (C)NavyCommandSystem (Token, CrisisNum); JMCIS

Note: Access Classification Precedes Each Entry.

DSEC--138

CSE300

Related Work: Related Work: Clearances/ClassificationsClearances/Classifications

Lattice Based Access Control [Sand93]Lattice Based Access Control [Sand93] MAC and RBAC [Nyan95, Osbo97, Osbo00]MAC and RBAC [Nyan95, Osbo97, Osbo00] DAC with Roles [Sand98]DAC with Roles [Sand98] Orange Book [DoD96]Orange Book [DoD96] MAC with Objects [Thur89]MAC with Objects [Thur89] Similarities and DifferencesSimilarities and Differences

Our Approach Opposite in that we Take Minimum and Standard would Take Maximum

Our Security Approach is at the Method Level Our Approach is Dynamic in That CLRs and

CLSs Can Be Changed During Runtime MAC Check at Invocation Eliminates Need for

Object Access or Change

DSEC--139

CSE300

Unified Security Model DefinitionsUnified Security Model DefinitionsUser Roles and UR ListUser Roles and UR List

Definition 7: Definition 7: A A user roleuser role, , URUR, representing a set of , representing a set of responsibilities for an application, is defined as: responsibilities for an application, is defined as:

Notes Notes LT and CLS is Set by Security Officer Defaults are [ct, ] and U Respectively

Examples: Commander /Joint Planner - Crisis 1Examples: Commander /Joint Planner - Crisis 1 [[CDR_CR1CDR_CR1, , URURLTLT, , TT]]

[ [JPlannerCR1JPlannerCR1, [, [01dec00, 01jun0101dec00, 01jun01], ], SS]] Definition 8:Definition 8: A A user-role list, user-role list, ,, URL URL is the set of is the set of rr

unique roles that have been defined for DAPPL. unique roles that have been defined for DAPPL.

],,[ CLSLTName URURURUR

DSEC--140

CSE300

Unified Security Model DefinitionsUnified Security Model DefinitionsUsers and User ListUsers and User List

Definition 9:Definition 9: A A user, U,user, U, who will be accessing the who will be accessing the DAPPL via a client application, is defined as: DAPPL via a client application, is defined as:

Notes Notes LT and CLS is Set by Security Officer Defaults are [ct, ] and U Respectively

Example Users:Example Users:General DoBest: [General DoBest: [DoBestDoBest, , 1 year1 year, , TT]]Colonel DoGood: [Colonel DoGood: [DoGoodDoGood, , 6 mo.,6 mo., SS]]

Definition 10:Definition 10: A A user list, UL user list, UL is the set of is the set of uu users users that have been defined for DAPPL.that have been defined for DAPPL.

],,[ CLRLTUserId UUUU

DSEC--141

CSE300

Users: Users:

(T)General DoBest: [DoBest, [ct, ], T](T)Colonel DoGood: [DoGood, [01dec00,01jun01], T](S)Major DoRight: [DoRight, [01dec00,01jan01], S](T)Major CanDoRight: [CanDoRight,[01jan01,01feb01, T]

],,[ CLRLTUserId UUUU

],,[ CLSLTName URURURUR UserUser--Roles: Roles:

[CDR_CR1, [01dec00, ], T][JPlannerCR1, [01dec00, 01jun01], S][JPlannerCR2, [01jul01, 01sep01], C][ArmyLogCR1, [10dec00, 01mar01], S][ArmyLogCR2, [01jul01, 01aug01], C]

User Role Authorizations: User Role Authorizations: [JPlannerCR1, CrisisPicture, [ct, ],true][JPlannerCR1, ArmyBattleCommandSys, [10dec00,16feb01], true][ArmyLogCR1, CrisisPicture, [10dec00,16feb01],

Grid1 NA20 AND Grid2 NC40],[ArmyLogCR1, LogPlanningTool, [10dec00,16feb01],CrisisNum=CR1]

],,,[ SCTCMURURA

Examples: Users, User-Roles, and URAExamples: Users, User-Roles, and URA

DSEC--142

CSE300

Related Work: RBACRelated Work: RBAC

Benefits of RBACBenefits of RBAC Flexible, Ease of Use, Policy Realization [Bert97, Demu95, Ferr92, Nyan93, Sand96, Ting87]

Main ApproachesMain Approaches UConn - [Demu94…01, Hu94, Ting87] GMU -RBAC96 - [Ahn99…, Osbo96…, Sand96...] NIST - [Bark97, Ferr99…, Gavr98, Jeag97…]

Similarities and Differences: Our Approach Does Not Rely on a Role Hierarchy Administrative Duties are Separated for Ease of Use

and Least Privilege Our Approach Can Realize Multiple Policies

Simultaneously on Multiple Federated Resources

DSEC--143

CSE300

Unified Security Model Definitions Unified Security Model Definitions Signature ConstraintSignature Constraint

Definition 11Definition 11: A : A Signature ConstraintSignature Constraint, , SCSC,, Boolean Expression Defined on the Signature of Boolean Expression Defined on the Signature of Method, Method, MMijkijk of Service of Service SSijij of resource of resource RRii that that Limits the Allowable Values on the Parameters Boolean Expression is:

(return-type constraint) and (parameters constraint) where either/both could be null

Parameters Constraint uses AND, OR, NOT

Example:Example:CrisisPicture (Token, CrisisNum, Grid1, Grid2);CrisisPicture (Token, CrisisNum, Grid1, Grid2);

SC: SC: Grid1 < NA20 and Grid2 < NC40Grid1 < NA20 and Grid2 < NC40

DSEC--144

CSE300

Unified Security Model Definitions Unified Security Model Definitions Time ConstraintTime Constraint

Definition 12:Definition 12: A A time constraint, TC, time constraint, TC, is a lifetime is a lifetime that represents when a method can be assigned to a that represents when a method can be assigned to a user role (or invoked by a user) or when a user is user role (or invoked by a user) or when a user is allowed to play a role. A TC has the default of [ct, allowed to play a role. A TC has the default of [ct, ]. TC utilized at design and run time to:]. TC utilized at design and run time to: user role and method LTs constraining when the

method can be assigned user role, method, and user LTs constraining

when the method can be invoked user role and user LT constraining when the user

can be authorized to the role Example:Example:

ArmyBattleCommandSys (Token, CrisisNum);ArmyBattleCommandSys (Token, CrisisNum);TC =TC = [[10dec00, 16feb01]10dec00, 16feb01]

DSEC--145

CSE300

Related Work: Related Work: Signature and Time ConstraintsSignature and Time Constraints

Temporal Constraints [Ahn00, Bert96, Bert01]Temporal Constraints [Ahn00, Bert96, Bert01] User Constraints [Sand98, Zurk96]User Constraints [Sand98, Zurk96] Similarities and DifferencesSimilarities and Differences::

Temporal Constraints used on Objects for Work Flow are applied to Methods as Time Constraints to Create an Operational Time Window for Valid Invocations

Time Constraints are Role Dependent so Same Method in a Different Role, Can Have a Different Time Constraint

Lifetimes in Conjunction with Separate, Method Time Constraints Improve Granularity and Provide Increased Flexibility for Security Policy

Use of Flexible, Run-Time, Signature Constraints is Unique for Role Based Access Control, but Similar to Other Programming Parameter/Argument Techniques

DSEC--146

CSE300

Unified Security Model Definitions Unified Security Model Definitions Mandatory Access Control ConstraintMandatory Access Control Constraint Definition 13:Definition 13: A A mandatory access control mandatory access control

constraint, MACC, constraint, MACC, is the is the dominationdomination of the of the SLEVEL of one entity over another entity:SLEVEL of one entity over another entity: CLS of Role Dominate () CLS of Resource,

Service, or Method CLR of User Dominate () CLS of Role

Example MACC: Design Time

CLS of Role vs. CLS of Resource, Service, or Method

Check for CLR of User vs. CLS of Role Run Time: CLR of User vs. CLS of Resource,

Service, or Method

DSEC--147

CSE300

Unified Security Model DefinitionsUnified Security Model DefinitionsUser Role AuthorizationsUser Role Authorizations

Definition 14Definition 14: A : A user-role authorization, URA,user-role authorization, URA, signifies a UR authorized to invoke a method signifies a UR authorized to invoke a method under optional TC and/or SC, and is defined as: under optional TC and/or SC, and is defined as:

wherewhere UR is as given in Definition 7 M is as given in Definition 4 TC is as given in Definition 12 and is an LT

that represents when the method is available to UR for invocation with default [ct, ]

SC is empty (true) or as given in Definition 11 and represents values that invocation can occur

],,,[ SCTCMURURA

DSEC--148

CSE300

Unified Security Model DefinitionsUnified Security Model DefinitionsUser Role AuthorizationsUser Role Authorizations

Definition 15aDefinition 15a:: UR authorization matrix, URAM,UR authorization matrix, URAM,is ais a matrix indexed by roles and methods:matrix indexed by roles and methods:

Notes:Notes: Initially, URAM, contains all 0 entries When equal to 1 for some

authorization is a Valid URA (VURA) At Design, UR CLS must dominate M CLS

and there must be Overlap of LT/TC

otherwise

MinvoketoauthorizedisURMURURAM ji

ji 0

1),(

qr

],,,[ SCTCMAURA

DSEC--149

CSE300

Example Users, User Roles, and URAsExample Users, User Roles, and URAs

],

DSEC--150

CSE300

Unified Security Model DefinitionsUnified Security Model DefinitionsRemaining DefinitionsRemaining Definitions

Definition 15bDefinition 15b:: A A valid user-role authorization valid user-role authorization list, list, where where is the set of all VURAs with URAM(UR,M) = 1.

Definition 16: Definition 16: A A user authorization, UA,user authorization, UA, is a user is a user authorized to play a role: authorized to play a role: wherewhere U is as given in Definition 9 UR is as given in Definition 7 TC is as given in Definition 12 and

represents the LT of authorization

],,[ TCURUUA

}1{ viVURAVURAL i qrv

DSEC--151

CSE300


Definition 17aDefinition 17a:: User authorization matrix, UAMUser authorization matrix, UAM::

Notes: Notes: Initially, UAM, contains all 0 entries When equal to 1 for some

Authorization is a Valid UA (VUA) At Design Time, a U’s CLR must dominate a

Role’s CLS with overlap of TC and LT

otherwise

URtoauthorizedisUUURUAM ij

ji 0

1),(

DSEC--152

CSE300

Example UAM and URAM MatricesExample UAM and URAM Matrices

User\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1DoBest 0 0 0 0 1DoGood 0 0 1 1 0DoRight 1 0 0 0 0CanDoRight 0 1 0 0 0

Method\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1ArmyBattleCommamdSys 1 1 1 1 1CrisisPicture 1 1 1 1 1MarineCombatOpnsSys 0 0 1 1 1LogPlanningTool 1 1 0 0 1

User Authorization Matrix (UAM)1 = authorized, 0 = not

User-Role Authorization Matrix (URAM): 1 = UR authorized to invoke Method, 0 = otherwise

DSEC--153

CSE300


Definition 17bDefinition 17b: A : A valid user authorization list, valid user authorization list,

where where is the set of all VUAs with UAM(UR,U) = 1is the set of all VUAs with UAM(UR,U) = 1

Definition 18Definition 18: A : A client, C, client, C, is authorized user is authorized user UU, , uniquely identified via a uniquely identified via a client tokenclient token C = [U, UR, IP-Address, Client-Creation-Time]C = [U, UR, IP-Address, Client-Creation-Time]where Creation Time is Clock at Creation where Creation Time is Clock at Creation

}1|{ wiVUAVUAL i

urw

DSEC--154

CSE300

Security Enforcement Framework Security Enforcement Framework Software ArchitectureSoftware Architecture

WrappedResource for LegacyApplication

WrappedResource

for DatabaseApplication

LookupService

General Resource

WrappedResource

for COTSApplication

JavaClient

LegacyClient

DatabaseClient

SoftwareAgent

COTSClient

Lookup

Service

Security AuthorizationClient (SAC)

Security Policy Client (SPC)

Global ClockResource (GCR)

SecurityRegistration

Services

Unified Security Resource (USR)

Security Policy

Services


Services

SecurityAnalysis and

Tracking (SAT)

DSEC--155

CSE300

Security Enforcement FrameworkSecurity Enforcement Framework

Unified Security Resource Services to:Unified Security Resource Services to: Manage URs and Privileges Authorize URs to Us Identify Users and Track Security Behavior

Associated Administrative/Management ToolsAssociated Administrative/Management Tools Security Policy Client to Grant/Revoke

Privileges (TCs, methods, SCs)/set CLS/CLR Security Authorization Client to Assign CLRs

and Authorize URs to End Users Security Analysis Tool (SAT) to Track all

Client Activity (Logons/Method Invocations)

DSEC--156

CSE300

Security Enforcement Framework Security Enforcement Framework Security Prototype (JINI and CORBA)Security Prototype (JINI and CORBA)

JavaGUI

PDB Client

JINILookupService

USR All

Services

CommonResource

(Global Clock)

CORBALookupService

Patient DBResource (PDB)

University DBResource (UDB)

JavaGUI

UDB Client

SecurityPolicyClient


Client

DSEC--157

CSE300

Security Enforcement Framework Security Enforcement Framework USR ServicesUSR Services

Security Policy ServicesRegister ServiceQuery Privileges ServiceUser Role ServiceConstraint ServiceGrant-Revoke ServiceGrant_Resource(UR_Id, R_Id);Grant_Service(UR_Id, R_Id, S_Id);Grant_Method(UR_Id, R_Id, S_Id, M_Id);Grant_SC(UR_Id, R_Id, S_Id, M_Id, SC);Grant_TC(UR_Id, R_Id, S_Id, M_Id, TC);

Security Authorization ServicesAuthorize Role ServiceClient Profile Service

Security Registration ServicesRegister Client ServiceSecurity Tracking and Analysis Services

Revoke_Resource(UR_Id, R_Id);Revoke _Service(UR_Id, R_Id, S_Id);Revoke _Method(UR_Id, R_Id, S_Id, M_Id);Revoke _SC(UR_Id, R_Id, S_Id, M_Id, SC);Revoke _TC(UR_Id, R_Id, S_Id, M_Id, TC);

DSEC--158

CSE300

Security Enforcement Framework Security Enforcement Framework Security Policy ServicesSecurity Policy Services

Register ServiceRegister_Resource(R_Id); Register_Service(R_Id, S_Id);Register_Method(R_Id, S_Id, M_Id);Register_Signature(R_Id, S_Id, M_Id, Signat);UnRegister_Resource(R_Id);UnRegister_Service(R_Id, S_Id);UnRegister_Method(R_Id, S_Id, M_Id);Unregister_Token(Token)

Query Privileges ServiceQuery_AvailResource();Query_AvailMethod(R_Id);Query_Method(Token, R_Id, S_Id, M_Id);Check_Privileges(Token, R_Id, S_Id, M_Id, ParamValueList);

User Role ServiceCreate_New_Role(UR_Name, UR_Disc, UR_Id);Delete_Role(UR_Id);

DSEC--159

CSE300

Security Enforcement Framework Security Enforcement Framework Security Policy ServicesSecurity Policy Services

Constraint ServiceDefineTC(R_Id, S_Id, M_Id, SC);DefineSC(R_Id, S_Id, M_Id, SC);CheckTC(Token, R_Id, S_Id, M_ID); CheckSC(Token, R_Id, S_Id, M_ID, ParamValueList);

Grant-Revoke ServiceGrant_Resource(UR_Id, R_Id);Grant_Service(UR_Id, R_Id, S_Id);Grant_Method(UR_Id, R_Id, S_Id, M_Id);Grant_SC(UR_Id, R_Id, S_Id, M_Id, SC);Grant_TC(UR_Id, R_Id, S_Id, M_Id, TC);Revoke_Resource(UR_Id, R_Id);Revoke_Service(UR_Id, R_Id, S_Id);Revoke_Method(UR_Id, R_Id, S_Id, M_Id);Revoke_SC(UR_Id, R_Id, S_Id, M_Id, SC);Revoke_TC(UR_Id, R_Id, S_Id, M_Id, TC);

DSEC--160

CSE300

Security Authorization and Registration Security Authorization and Registration ServicesServices

Register Client ServiceCreate_Token(User_Id, UR_Id, Token); Register_Client(User_Id, IP_Addr, UR_Id);UnRegister_Client(User_Id, IP_Addr, UR_Id);IsClient_Registered(Token);Find_Client(User_Id, IP_Addr);

Security Tracking and Analysis ServicesTracking Service: Logfile(Log String)Analysis Service: Analyze (Java Class File)

SECURITY REGISTRATION SERVICES

Authorize Role ServiceGrant_Role(UR_Id, User_Id);Revoke_Role(UR_Id, User_Id);

Client Profile ServiceVerify_UR(User_Id, UR_Id);Erase_Client(User_Id);Find_Client(User_Id);Find_All_Clients();

SECURITY AUTHORIZATIONSERVICES

DSEC--161

CSE300

Security Enforcement Framework Security Enforcement Framework Client, Resource, Service InvocationsClient, Resource, Service Invocations


Services

Security Registration

Services

LookupService

GCCSClient

1 Register_Client(DoRight,100.150.200.250, ArmyLogCR1)

10 Return Result of Check_Privileges(…)

4 Return Result,Create_Token(DoRight,ArmyLogCR1,Token)

6 CrisisPicture(Token,CR1, NA20, NC40)

3 Client OK?

11 Return Result,CrisisPicture(…)

5. Discover/Lookup(GCCS,Joint,CrisisPicture) Returns Proxy to Course Client

7 IsClient_Registered(Token)

9 Check_Privileges(Token, GCCS, Joint, CrisisPicture, [NA20,NC40])

2 Verify_UR(DoRight,ArmyLogCR1)

SecurityPolicy

ServicesGCCS

Resource8 Return Result of IsClient_Registered(…)

USR

DSEC--162

CSE300

Security PrototypeSecurity PrototypeGlobal Clock Server/Client LogonGlobal Clock Server/Client Logon

DSEC--163

CSE300

The Security Policy ClientThe Security Policy Client

Manages Privileges for Roles and ResourcesManages Privileges for Roles and Resources For Roles:For Roles:

Define/Delete Roles including LTs and CLSs Grant/Revoke Privileges in Terms of Methods

Grant Methods to Roles Limit Grant based on Time Constraint Limit Grant based on Signature Constraint

For Resources:For Resources: Register Resource, its Services, their Methods Establish LTs and CLSs Resources can Also Register themselves

Programmatically via the USR Services

DSEC--164

CSE300

Security Policy ClientSecurity Policy ClientRegistering a ResourceRegistering a Resource

DSEC--165

CSE300

Security Policy ClientSecurity Policy ClientRegistering a ServiceRegistering a Service

DSEC--166

CSE300

Security Policy ClientSecurity Policy ClientRegistering Methods for ResourceRegistering Methods for Resource

DSEC--167

CSE300

Security Policy Client Security Policy Client Registering Methods for ResourceRegistering Methods for Resource

DSEC--168

CSE300

Security Policy ClientSecurity Policy ClientAdding Methods to ServiceAdding Methods to Service

DSEC--169

CSE300

Security Policy ClientSecurity Policy ClientAdding Methods to ServiceAdding Methods to Service

DSEC--170

CSE300

Security Policy Client Confirmation of Security Policy Client Confirmation of Registered MethodsRegistered Methods

DSEC--171

CSE300

Security Policy Client Security Policy Client Tracking Defined Resources Tracking Defined Resources

DSEC--172

CSE300

Security Policy Client Security Policy Client Creating User Role Creating User Role

DSEC--173

CSE300

Security Policy Client Security Policy Client Creating User RoleCreating User Role

DSEC--174

CSE300

Security Policy Client Security Policy Client Granting Resource to URGranting Resource to UR

DSEC--175

CSE300

Security Policy Client Security Policy Client Granting Service to URGranting Service to UR

DSEC--176

CSE300

Security Policy Client Security Policy Client Granting Method to URGranting Method to UR

DSEC--177

CSE300

Security Policy ClientSecurity Policy ClientConfirmation of Method to RoleConfirmation of Method to Role

DSEC--178

CSE300

Security Policy ClientSecurity Policy ClientReviewing Access of Resources to RolesReviewing Access of Resources to Roles

DSEC--179

CSE300

Security Policy Client Security Policy Client Defining a Signature ConstraintDefining a Signature Constraint

DSEC--180

CSE300

Security Policy Client Security Policy Client Defining a Signature ConstraintDefining a Signature Constraint

DSEC--181

CSE300

The Security Authorization ClientThe Security Authorization Client

Intended for Authorization CapabilitiesIntended for Authorization Capabilities Main ObjectivesMain Objectives

Define New User with CLR and LT Authorize URs to End Users Define Clients

Authorization of Roles to Users Must SatisfyAuthorization of Roles to Users Must Satisfy User.CLR Dominates Role.CLS Overlap of LTs w.r.t. Current Time

DSEC--182

CSE300

Security Authorization Client Security Authorization Client Creating a UserCreating a User

DSEC--183

CSE300

Security Authorization Client Security Authorization Client Granting Roles to UserGranting Roles to User

DSEC--184

CSE300

Security PrototypeSecurity PrototypeTracking Logins and Actions Tracking Logins and Actions

DSEC--185

CSE300

Security PrototypeSecurity PrototypeTracking Methods of ResourcesTracking Methods of Resources

DSEC--186

CSE300

Security AssuranceSecurity Assurance

Security Assurance Represents a Confidence Level of the Security Capabilities to Insure Sensitive Information is Protected From Access and Misuse

Assurance is Needed at: Design Time (DT) - as Security Policy is

Defined Using our Security Model Run Time (RT) - via Enforcement as

Users/Clients Access Resources in Secure Manner

Security Assurance is Enumerated and Defined toEnumerated and Defined to: Insure Policy Consistency (A & M Tools) Check Conditions as Users Access Resources

DSEC--187

CSE300

Assurance GuaranteesAssurance Guarantees

Available Time : Maximum Amount of Time Available Time : Maximum Amount of Time Derived from the Intersections of LTs and TCs Derived from the Intersections of LTs and TCs

Simple Security Property: A Subject Can Read at Simple Security Property: A Subject Can Read at the Same or Lower Level. (Read Down/No Read the Same or Lower Level. (Read Down/No Read Up)Up)

Simple Integrity Property: A Subject Can Write to Simple Integrity Property: A Subject Can Write to the Same or Lower Level the Same or Lower Level

Safety: No Bad Things Can Happen During Safety: No Bad Things Can Happen During ExecutionExecution

Liveness: All Good Things Can HappenLiveness: All Good Things Can Happen

DSEC--188

CSE300

Available TimeAvailable Time

Available Time Represents “When” Construct is Available Time Represents “When” Construct is Available for UsageAvailable for Usage

Comparison of Lifetimes IncludingComparison of Lifetimes Including Role Method Current Time

Sets a Limit on When an Action can OccurSets a Limit on When an Action can Occur

DSEC--189

CSE300

The Compare Function for Two LTsThe Compare Function for Two LTs

DSEC--190

CSE300

Time-Based GuaranteesTime-Based Guarantees

DSEC--191

CSE300


DSEC--192

CSE300

Lemma 1 ConceptuallyLemma 1 Conceptually

DSEC--193

CSE300


DSEC--194

CSE300


DSEC--195

CSE300


DSEC--196

CSE300


DSEC--197

CSE300

MAC-Based GuaranteesMAC-Based Guarantees

Verify the Behavior of Method InvocationVerify the Behavior of Method Invocation Differentiate Between Method TypesDifferentiate Between Method Types

Read-Only Method - Do not Change the State of an Object Satisfies Simple Security (Read up/No Read

Down) Read-Write method

May Change the State of an Object Satisfies Simple Security (Read up/No Read

Down) and Simple Integrity (Write Down/No Write Up)

Assume: Values are Not Returned Through Method Parameters (only Value Parameters)

DSEC--198

CSE300


DSEC--199

CSE300


DSEC--200

CSE300


DSEC--201

CSE300


DSEC--202

CSE300


DSEC--203

CSE300

Safety: Nothing bad happens during execution

Liveness: All good things can happen during execution

GOAL: Maximize Safety and Liveness Disconnecting from a network increases

Safety, but decreases Liveness Allowing unlimited access increases Liveness,

but decreases Safety

Safety and Liveness GuaranteesSafety and Liveness Guarantees

DSEC--204

CSE300

Security Assurance RulesSecurity Assurance Rules

A Security Assurance Rule Must hold True for the Security Policy DT: Privilege Definition/Modification RT: As Users Perform Actions

Categories of Checks are:Categories of Checks are: MACC Domination Lifetime Time Constraint Signature Constraint Authorization and Authentication

DSEC--205

CSE300

Create a VURA and if the Creation is Successful, then the entry of URAM = 1.

For Authorization to Occur CLS of A must Dominate CLS of M LTs of A, M, and TC must Overlap (reset as

TC), and reset TC has an end time after ct

Security Assurance - Design TimeSecurity Assurance - Design TimeRule I: Authorizing Method to URRule I: Authorizing Method to UR

DSEC--206

CSE300

LTs and TCs must be ContrastedLTs and TCs must be Contrasted

Security Assurance - Design TimeSecurity Assurance - Design TimeRule I ConceptuallyRule I Conceptually

ctA.LT M.LT TC

A.LTM.LT

TC

DSEC--207

CSE300

Create a VUA and if the Creation is Successful, the Entries of UAM and UDAM are set to 1

For Authorization to Occur CLR of X must Dominate CLS of A LTs of A, X, and TC must Overlap (reset as

TC), and reset TC has an end time after ct

Security Assurance - Design TimeSecurity Assurance - Design TimeRule II: Authorizing UR to UserRule II: Authorizing UR to User

DSEC--208

CSE300

LTs and TCs Again ConstrainedLTs and TCs Again Constrained

Security Assurance - Design TimeSecurity Assurance - Design TimeRule II ConceptuallyRule II Conceptually

ct

A.LT X.LT TC

A.LTX.LT

TC

DSEC--209

CSE300

Runtime Authorization (of user to role).

For Authorization to Occur at Runtime Rule II must be rechecked (since privileges can

dynamically change). Recheck involves the Overlap of the LTs of X,

A, and TC with Respect to Current Time.

Security Assurance - RuntimeSecurity Assurance - RuntimeRule III: Authorizing UR to UserRule III: Authorizing UR to User

DSEC--210

CSE300

What is the Time Issue in This Case?What is the Time Issue in This Case? Must Compare Against Rule II Must Also Look at TC vs. ct TC.et After ct TC.st Before ct

Security Assurance - RuntimeSecurity Assurance - RuntimeRule III ConceptuallyRule III Conceptually

ctTC

ct

TC

DSEC--211

CSE300

N(Name), P(Params), APV(Actual Param Values) SCOracle is a Constraint Checker that Compares

Parameter Values of M’s Invocation against SC returns true if M.parametervalues satisfy SC returns false otherwise.

Security Assurance - RuntimeSecurity Assurance - RuntimeRule IV: Invoking a MethodRule IV: Invoking a Method

DSEC--212

CSE300

Security Assurance - RuntimeSecurity Assurance - RuntimeRule IV ConceptuallyRule IV Conceptually

Same issues as Rule III (Rule I and TC vs. ct)Same issues as Rule III (Rule I and TC vs. ct) Additionally, There is a Constraint CheckerAdditionally, There is a Constraint Checker

Defn: CrisisPicture (Token, CrisisNum, Grid1, Grid2);SC: Grid1 < NA20 and Grid2 < NC40Call: CrisisPicture (123, 111, NA18, NC45);

Compare Call Against SC to Determine if Can Invoke

DSEC--213

CSE300

Safety and Liveness TheoremsSafety and Liveness Theorems

DSEC--214

CSE300


DSEC--215

CSE300


DSEC--216

CSE300


DSEC--217

CSE300

Related WorkRelated WorkSecurity Assurance Security Assurance

Motivation and Need within DoD

[C4I99, DARP00, DoD88, Tete99] Abstract Study of Assurance

[Alfo01, Garv98,McCu91, Maco01] Role Administration Participates in Assurance

Separation of Duty [Ahn99, Both01,Garv98, Glig98, Nyan93, Osob00, Simo97]

Mutual Exclusion [Bert97, Kand01, Khun97] Role Hierarchies [Demu95, Ferr97, Hu95,

Jans98, Moff99, Sand96, Spoo89 ] Administration Mechanisms [Awis97, Murl01,

Nyan94, Sand99]

DSEC--218

CSE300

What is Role Delegation?What is Role Delegation?

Role Delegation is a User-to-User Relationship that Allows One User to Transfer Responsibility for a Particular Role to Another Individual

Two Major Types of Delegation Administratively-directed Delegation has an

Administrative Infrastructure Outside the Direct Control of a User Mediates Delegation

User-directed Delegation has an User (Playing a Role) Determining If and When to Delegate a Role to Another User

In Both, Security Administrators Still Oversee Who Can Do What When w.r.t. Delegation

Work of M. Liebrand (Rensselaer at Hartford)Rensselaer at Hartford)

DSEC--219

CSE300

Why is Role Delegation Important?Why is Role Delegation Important?

Many Different Scenarios Under Which Privileges Many Different Scenarios Under Which Privileges May Want to be Passed to Other IndividualsMay Want to be Passed to Other Individuals Large organizations often require delegation to

meet demands on individuals in specific roles for certain periods of time

True in Many Different Sectors Financial Services Engineering Academic Setting

Key Issues:Key Issues: Who Controls Delegation to Whom? How are Delegation Requirements Enforced?

DSEC--220

CSE300

What Can be Delegated?What Can be Delegated?

Authority Authority to Do the Task, Carries the Least to Do the Task, Carries the Least Responsibility Necessary to Execute the Task, but Responsibility Necessary to Execute the Task, but Does Mean the Delegated User Can Execute the Does Mean the Delegated User Can Execute the Delegated Task or Role. Delegated Task or Role.

ResponsibilityResponsibility to Do a Task Implies Accountability to Do a Task Implies Accountability and a Vested Interest that a Task or Role Can Be and a Vested Interest that a Task or Role Can Be Executed Properly. Executed Properly.

DutyDuty to Perform a Task Implies that the Delegated to Perform a Task Implies that the Delegated User is Obligated to Execute the Given Task. User is Obligated to Execute the Given Task.

Our Focus: Delegate Authority OnlyOur Focus: Delegate Authority Only

DSEC--221

CSE300

Our Focus for DelegationOur Focus for Delegation

Extensions to the Unified Security Model Extensions to the Unified Security Model Identify Roles that are Delegatable Distinguish: Original and Delegated Users Delegation Authority and Delegated Role

Detailed Example to Illustrate ConceptsDetailed Example to Illustrate Concepts Analysis of Role Delegation CapabilitiesAnalysis of Role Delegation Capabilities Investigation of SPC, SAC, and SDC in Support of Investigation of SPC, SAC, and SDC in Support of

DelegationDelegation Security Assurance for DelegationSecurity Assurance for Delegation

DSEC--222

CSE300

Role Delegation Extensions Role Delegation Extensions

Definition 19:Definition 19: A A delegatable UR, DURdelegatable UR, DUR, is a UR , is a UR that is eligible for delegation. that is eligible for delegation.

Definition 20:Definition 20: The The delegatable UR vector, DURV,delegatable UR vector, DURV, is defined for all is defined for all r r as: as:

Delegatable URs (from Slide 33)Delegatable URs (from Slide 33) [CDR_CR1, [01dec00,01dec01], T][CDR_CR1, [01dec00,01dec01], T][JPlannerCR1, [01dec00, 01jun01], S][JPlannerCR1, [01dec00, 01jun01], S][JPlannerCR2, [01jul01, 01sep01], C][JPlannerCR2, [01jul01, 01sep01], C]DURV(A) = 1 for A = CDR_CR1, JPlannerCR1 and JPlannerCR2DURV(A) = 0 for A = ArmyLogCR1 and ArmyLogCR2

DURanotisUR

DURaisURURDURV

i

ii 0

1)(

DSEC--223

CSE300


Definition 21:Definition 21: An An original user, OUoriginal user, OU UL, UL, is is authorized to the UR such that there exists a VUA authorized to the UR such that there exists a VUA for the OU/UR, i.e., UAM(UR,OU) = 1for the OU/UR, i.e., UAM(UR,OU) = 1 OU: Authorized to the UR via Regular Process Implies Not Eligible for Delegation

Definition 22:Definition 22: A A delegated user, DUdelegated user, DU UL, UL, is a is a user eligible to be delegated a UR by an OU or a user eligible to be delegated a UR by an OU or a DU (there is not a VUA i.e., UAM(UR,DU) DU (there is not a VUA i.e., UAM(UR,DU) 1). 1). DU of a UR cannot be an OU for same UR

DSEC--224

CSE300

Examples of Examples of OUs DUs OUs DUs ArmyLogCR1ArmyLogCR1

DoRight ArmyLogCR2ArmyLogCR2

CanDoRight JPlannerCR1JPlannerCR1

DoGood JPlannerCR2JPlannerCR2

DoGood CRC_CR1CRC_CR1

CDR_CR1

ArmyLogCR1ArmyLogCR1 DoBest, DoGood,

CanDoRight ArmyLogCR2ArmyLogCR2

DoBest, DoGood, DoRight

JPlannerCR1/JPlannerCR2 JPlannerCR1/JPlannerCR2

DoBest, DoRight, CanDoRight

CRC_CR1CRC_CR1 DoGood, DoRight,

CanDoRight

DSEC--225

CSE300


Definition 23:Definition 23: User delegation/authorization User delegation/authorization matrix,matrix, UDAMUDAM::

Represents who is a DU, OU, or NeitherRepresents who is a DU, OU, or Neither UDAM Entries are UDAM Entries are

Initially All Set to False Set to 1 Whenever a User is an OU Set to 2 Whenever a User is an DU

Recall Rule II Set UDAM = 1Recall Rule II Set UDAM = 1

ij

ij

ij

ji

URtoauthorizednotisU0

URofOUanisU1

URofDUaisU2

UURUDAM ),(

DSEC--226

CSE300

Delegation and Pass on Delegation Delegation and Pass on Delegation AuthoritiesAuthorities

When Establishing Privileges (by the Security When Establishing Privileges (by the Security Officer) there must be the Ability to Define:Officer) there must be the Ability to Define: Delegation Authority (DA)

Recall:Security Officer can Delegate a Role to User DA Means that the Security Officer Can Delegate

the Authority to Delegate to another User Role Can be Delegated by one User to Another However, Delegation Authority Cannot

Pass-on Delegation Authority (PODA) PODA Augments DA to Allow the Delegation

Authority to Also be Delegated as Part of the Delegation of a Role to a User

DSEC--227

CSE300

Role Delegation ExtensionsRole Delegation Extensions

Definition 24:Definition 24: Delegation authority, DA, Delegation authority, DA, is given is given to the OU to allow delegation of a DUR.to the OU to allow delegation of a DUR.

Definition 25:Definition 25: Pass-on delegation authority, Pass-on delegation authority, PODA, PODA, allows an OU (DU) to pass on DA for a allows an OU (DU) to pass on DA for a DUR to another user (OU or DU). DUR to another user (OU or DU).

Definition 26:Definition 26: Delegation authority matrix,Delegation authority matrix, DAMDAM::

DU has Neither DA Nor PODADU has Neither DA Nor PODADU has Just DADU has Just DADU has Both DA and PODADU has Both DA and PODA

ij

ij

ij

ji

URforPODAnorDAneitherhasU0

URforDAonlyhasU1

URforPODAandDAhasU2

UURDAM ),(

DSEC--228

CSE300

Example of DA and PODAExample of DA and PODA

JPlanner1: DoGood has DAJPlanner1: DoGood has DA JPlanner2: DoGood has DAJPlanner2: DoGood has DA CDR_CR1: DoBest has both DA and PODACDR_CR1: DoBest has both DA and PODA All Other Entries have Neither DA Nor PODAAll Other Entries have Neither DA Nor PODA


Delegation Authority Matrix (DAM): 2 = has DA and PODA, 1 = has DA, 0 = neither

DSEC--229

CSE300

Recall UAM and URAM MatricesRecall UAM and URAM Matrices


Method\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1ArmyBattleCommamdSys 1 1 1 1 1CrisisPicture 1 1 1 1 1MarineCombatOpnsSys 0 0 1 1 1LogPlanningTool 1 1 0 0 1

User Authorization Matrix (UAM)1 = authorized, 0 = not

User-Role Authorization Matrix (URAM): 1 = UR authorized to invoke Method, 0 = otherwise

DSEC--230

CSE300

Augment withAugment with DAM and UDAM Matrices DAM and UDAM Matrices


Delegation Authority Matrix (DAM): 2 = has DA and PODA, 1 = has DA, 0 = neither


User Delegation/Authorization Matrix (UDAM): 2 = U is a DU, 1 = U is a OU, and 0 = not authorized

DSEC--231

CSE300

Example - Role DelegationExample - Role Delegation

General DoBest Delegates his Role to Colonel DoGood with DA, where DoBest, CDR_CR1, and DoGood defined as:

OU: [DoBest, [ct, ], T]UR: [CDR_CR1, [01dec00, 01dec01], T]UA: [DoBest, CDR_CR1, [01dec00, 01dec01]]DA: YesPODA: Yes

After Delegation:

DU: [DoGood, [01dec00, 01jun01], T]UA: [DoGood, CDR_CR1, [01dec00, 01jun01]]

DSEC--232

CSE300

Example - Role DelegationExample - Role Delegation

Now,Now, Colonel DoGood wishes to re-delegate Colonel DoGood wishes to re-delegate CDR_CR1 to Major CanDoRight, which can be CDR_CR1 to Major CanDoRight, which can be defined as:defined as:

DU: [DoGood, [01dec00, 01jun01], T]UR: [CDR_CR1, [01dec00, 01dec01], T]UA: [DoGood, CDR_CR1, [01dec00, 01jun01]]DA: YesPODA: No

After Delegation:

DU: [CanDoRight, [01jan01, 01feb01], T]UA: [CanDoRight, CDR_CR1, [01dec00, 01jun01]]

DSEC--233

CSE300

Related Work: Role DelegationRelated Work: Role Delegation

Role Administration [Awis97]Role Administration [Awis97] Delegation with RBAC [Bark00, Na00]Delegation with RBAC [Bark00, Na00] Delegation Principals [Zhang01]Delegation Principals [Zhang01] Similarities and DifferencesSimilarities and Differences

In Our Approach, OU Maintains Control of Delegation DU Cannot Give Delegation Authority

Our Approach is Dynamic, in that, Delegations have LTs Changeable During Runtime

Our Delegation Incorporates MACC We extend Zhang’s Definitions to Include

Delegation Authority, Revocation Authority, Delegated Role, and Delegatable Role

DSEC--234

CSE300

Enforcement Framework andEnforcement Framework andRole Delegation Revocation RulesRole Delegation Revocation Rules

User-to-User Delegation Authority RuleUser-to-User Delegation Authority Rule A User (OU or DU) Who is a Current Member

of a Delegatable Role (DUR), Can Delegate that User Role to Any User that Meets the Prerequisite Conditions of the Role: DU Receiving the Role is Not a Member of the

Role; OU or DU is Identified As Having Delegation

Authority for the Role; DU Meets the Mandatory Access Control

Constraints (MACC).

DSEC--235

CSE300

Enforcement Framework andEnforcement Framework andRole Delegation Revocation RulesRole Delegation Revocation Rules

Delegation Revocation Authorization RuleDelegation Revocation Authorization Rule:: An Original User Can Revoke Any Delegated

User From a User Role in Which the OU Executed the Delegation.

This is a Stricter Interpretation than [Zhan01], Which Allows Any OU of a Role Revocation Authority Over a DU in the Delegation Path.

In Addition, a Security Administrator Can Revoke Any Delegation.

Cascading Revocation RuleCascading Revocation Rule:: Whenever an OU or DU in the delegation path

is revoked, all DUs in the path are revoked.

DSEC--236

CSE300

Analysis of Role DelegationAnalysis of Role Delegation

Analysis of Role Delegation Against Set of Common Criteria Monotonicity Permanence Totality Administration Levels of Delegation Multiple Delegation Agreements Cascading Revocation Grant-dependency Revocation

We’ll Define and Discuss Each

DSEC--237

CSE300

Analysis of Role DelegationAnalysis of Role DelegationMonotonicityMonotonicity

Definition: Monotonicity Refers to the State of Control the OU Possesses After Role Delegation Monotonic Delegation Means That the OU

Maintains Control of the Delegated Role Non-monotonic Means That the OU Passes the

Control of the Role to DU Our Approach Utilizes Monotonic Delegation

Since We Believe for Assurance it is Critical to Exercise a Level of Control W.R.T. Delegation

DSEC--238

CSE300

Analysis of Role DelegationAnalysis of Role DelegationPermanencePermanence

Definition: Definition: PermanencePermanence Refers to Delegation in Refers to Delegation in Terms of Time DurationTerms of Time Duration Permanent Delegation is When a DU

Permanently Replaces the OU Temporary Delegation Has an Associated Time

Limit With Each Role Our Approach Utilizes Temporary Delegation

Since Temporal Constraints (LTs/TC) Are an Important Part of Our Unified Security Model

DSEC--239

CSE300

Analysis of Role DelegationAnalysis of Role DelegationTotalityTotality

Definition: Definition: Totality Refers to How Completely the Permissions Assigned to the Role Are Delegated Partial Delegation Refers to the Delegation of

a Subset of the Permissions of the Role Total Delegation Refers to the Situation All of

the Permissions of the Role Are Delegated Our Approach Utilizes Total Delegation Since we

Believe Partial Delegation Defeats Purpose of Urs and Assignment Methods to UR under TCs/SCs

Partial Delegation is Achievable by Defining Special Roles that are Delegatable

DSEC--240

CSE300

Analysis of Role DelegationAnalysis of Role DelegationAdministrationAdministration

Definition: Definition: Administration Refers to how Delegation will be Administered User Directed is when the User Controls all

Aspects of Delegation Administrator-Directed (Third party, Agent-

directed) is when Control is with the Security Officer

Our Approach Utilizes a Combination of Both Allowing the Security Officer to Establish DA/PODA and the User to Determine to “Whom” the Delegation will Occur

DSEC--241

CSE300

Analysis of Role DelegationAnalysis of Role DelegationLevels of DelegationLevels of Delegation

Definition: Definition: Levels of Delegation Refers to the Ability of DU to Further Delegate a Role (PODA) and the Number of Vertical Levels the Delegated Role Can Be Delegated Boolean Control – Roles Can Be Re-delegated

Until a Delegating User Says No Integer Control –Roles can be Re-delegated

until Fixed Number of Re-delegations Occur Our Approach Utilizes Modified Boolean Control

via the DA/PODA If PODA not Given - Delegation Stops Prototype has Limit of either 2 or 3 Levels

DSEC--242

CSE300

Analysis of Role DelegationAnalysis of Role DelegationMultiple DelegationsMultiple Delegations

Definition: Definition: Multiple Delegations Refers to the Number of Delegated Users (DU) (Horizontally) to Whom a Delegatable User Role (DUR) Can Be Delegated to at Any Given Time

Our Approach Includes Unlimited Delegations in Our Security Model Since We Want to Maintain the User’s Flexibility A Limit on the Number of DUs to a Role is

Subjective. Subjective Limits Are Not Often Enforced;

There Are No Hard Bases for Them

DSEC--243

CSE300

Analysis of Role DelegationAnalysis of Role DelegationAgreementsAgreements

Definition: Definition: Agreements Refer to the Delegation Protocol of the OU to the DU Bilateral Agreements: the DU Needs to

Accept the Delegated Role Unilateral Agreements: the OU Delegates the

UR Permissions and the DUs Are Not Required to Accept or Even Acknowledge the Delegation

Our Approach Utilizes Unilateral Agreements

DSEC--244

CSE300

Analysis of Role DelegationAnalysis of Role DelegationCascading RevocationCascading Revocation

Definition: Definition: Cascading Revocation Refers to the Indirect Revocation of All DUs When the OU Revokes Delegation or Administration Revokes the OU’s Delegated Role

Non-cascading Revocation Could Be Useful in the Event a Middle Manager User Is Fired Without Replacement and Subordinates Need to Execute the Vacated Roles

Our Approach Utilizes Cascading Revocation and will Handle Non-Cascading Case via Security Administrative Tools (Changing Privileges)

DSEC--245

CSE300

Analysis of Role DelegationAnalysis of Role DelegationGrant Dependency RevocationGrant Dependency Revocation

Definition: Definition: Grant-Dependency Revocation Refers to Who Has Authority to Revoke a DU Grant-Dependent Revocation Only Allow the

OU to Revoke the Delegated Role Grant-Independent Revocation Allows Any

Original Member of the DUR to Revoke a Delegated Role

Our Approach Utilizes a Limited Form of Grant-independent Revocation Where Only the DU and the Security Administrator Can Revoke a DUR

DSEC--246

CSE300

Role Delegation Process Role Delegation Process Security Management ToolsSecurity Management Tools

Examine the Process of DelegationExamine the Process of Delegation Utilize the Military ApplicationUtilize the Military Application ExploreExplore

Security Policy Client Security Authorization Client Security Delegation Client

SDC is a New Administrative Tool Utilized by Both Security Officer and the End User

Focus on their role in Delegation AdministrationFocus on their role in Delegation Administration Screen Bit Maps are Ordered to Illustrate a ProcessScreen Bit Maps are Ordered to Illustrate a Process

DSEC--247

CSE300

Security Policy ClientSecurity Policy ClientRegistration of ResourcesRegistration of Resources

DSEC--248

CSE300

Security Policy ClientSecurity Policy Client Creation of Administration RoleCreation of Administration Role

DSEC--249

CSE300

Security Authorization ClientSecurity Authorization ClientGranting of Role(s) to User(s)Granting of Role(s) to User(s)

DSEC--250

CSE300

Security Policy ClientSecurity Policy Client Cdr. Crisis 1 Role/Conflicting Role ListCdr. Crisis 1 Role/Conflicting Role List

DSEC--251

CSE300

Security Policy ClientSecurity Policy Client Granting of Resource(s) to Role(s)Granting of Resource(s) to Role(s)

DSEC--252

CSE300

Security Policy ClientSecurity Policy Client Granting of Service (s) to Role(s)Granting of Service (s) to Role(s)

DSEC--253

CSE300

Security Policy ClientSecurity Policy Client Granting of Methods(s) to Role(s)Granting of Methods(s) to Role(s)

DSEC--254

CSE300

Security Policy ClientSecurity Policy Client Query PrivilegesQuery Privileges

DSEC--255

CSE300

Security Authorization ClientSecurity Authorization ClientCreate a UserCreate a User

DSEC--256

CSE300

Security Authorization ClientSecurity Authorization Client Create a UserCreate a User

DSEC--257

CSE300

Security Authorization ClientSecurity Authorization Client Granting a RoleGranting a Role

DSEC--258

CSE300

Security Authorization ClientSecurity Authorization Client Granting a Role with DA/PODAGranting a Role with DA/PODA

DSEC--259

CSE300

Security Authorization ClientSecurity Authorization Client Granting a Role with DA/PODAGranting a Role with DA/PODA

DSEC--260

CSE300

Security Authorization ClientSecurity Authorization Client Query PrivilegesQuery Privileges

DSEC--261

CSE300

Security Authorization ClientSecurity Authorization Client Query Privileges - ResultsQuery Privileges - Results

DSEC--262

CSE300

The Security Delegation ClientThe Security Delegation Client

DSEC--263

CSE300

Security Delegation ClientSecurity Delegation Client Log on to the Security Delegation ClientLog on to the Security Delegation Client

DSEC--264

CSE300

Security Delegation ClientSecurity Delegation ClientAttempt to Perform a DelegationAttempt to Perform a Delegation

DSEC--265

CSE300

Security Delegation ClientSecurity Delegation ClientAttempt to Perform a DelegationAttempt to Perform a Delegation

DSEC--266

CSE300

Security Delegation ClientSecurity Delegation ClientQuery a User’s RoleQuery a User’s Role

DSEC--267

CSE300

Security Delegation ClientSecurity Delegation ClientRevocation of DelegationRevocation of Delegation

DSEC--268

CSE300

Security Delegation ClientSecurity Delegation ClientRevocation of DelegationRevocation of Delegation

DSEC--269

CSE300

Security Delegation ClientSecurity Delegation ClientDenying Log in if UR not AvailableDenying Log in if UR not Available

DSEC--270

CSE300

Security Delegation ClientSecurity Delegation ClientDenying Delegation if MAC ViolatedDenying Delegation if MAC Violated

DSEC--271

CSE300

Security Delegation ClientSecurity Delegation ClientDenying Delegation if TC ViolatedDenying Delegation if TC Violated

DSEC--272

CSE300

Security Delegation ClientSecurity Delegation ClientDenying Delegation if no Delegatable RolesDenying Delegation if no Delegatable Roles

DSEC--273

CSE300

Security Delegation ClientSecurity Delegation ClientPass on Delegation RestrictionPass on Delegation Restriction

DSEC--274

CSE300

Security Delegation ClientSecurity Delegation ClientExampleExample

Dobest delegate a role to dogood without pass-on-delegation, when dogood delegated this role to doright, he can’t delegate it with pass-on-delegation

DSEC--275

CSE300

Security Delegation ClientSecurity Delegation ClientDelegation Matrix within SDCDelegation Matrix within SDC

Dobest(T): ArmyLogCR1(c)

Chip(T): ArmyLogCR1(c)

Dogood(S): ArmyLogCR1 ( C)

Doright(c ): ArmyLogCR1 ( C)

When Original user revokeThis role, the role matrix is revoked within SDC

DSEC--276

CSE300


Dobest delegate a role to dogood

Dogood delegate this role to other users

DSEC--277

CSE300


Dobest revokes the role delegated to dogood

The role delegated by dogood are erased at the same time.

DSEC--278

CSE300

Design Time Security Assurance Design Time Security Assurance for Delegationfor Delegation

Design Time Checks – Policy RealizationDesign Time Checks – Policy Realization MACC Domination CLR Dominates CLS Role Delegation

DU Not Already a Role Member User to User Delegation Authority

Must Check User Delegation Authority Matrix DU Meets MACC Requirements

Lifetime Consistency DU’s LT Must be Within OU’s LT

Modified Boolean Delegation OU can Delegate and Pass on Delegation Authority DU cannot Pass On Delegation Authority

These are Checks in SPC, SAC, and SDCThese are Checks in SPC, SAC, and SDC

DSEC--279

CSE300

Run Time Security Assurance Run Time Security Assurance for Delegationfor Delegation

Executed While Running Distributed ApplicationExecuted While Running Distributed Application MACC Domination Role Delegation User to User Delegation Authority Lifetime Consistency Modified Boolean Delegation

(additional checks) Delegation Revocation Authorization Rule

OU/DU Can Revoke Any Initiated Delegation Cascading Revocation Rule

Whenever OU is Revoked, OU’s Delegations are revoked, Including Passed On Delegations

These are Checks by the Enforcement Framework These are Checks by the Enforcement Framework as supported with USRas supported with USR

DSEC--280

CSE300

UDAM(A, X) =1 implies that UAM(A, X) = 1 by Rule II.

Rules V establishes DA for user X to role A in the case where X is an OU.

Security Assurance - Design timeSecurity Assurance - Design timeRule V: Assigning Delegation AuthorityRule V: Assigning Delegation Authority

DSEC--281

CSE300

Theorem VTheorem V

DSEC--282

CSE300

User must have DA in order to have PODA e.g., a User cannot have PODA without DA

UDAM(A, X) =1 implies that UAM(A, X) = 1 by Rule II.

Rule VI establishes, respectively, DA/PODA for user X to role A in the case where X is an OU.

Security Assurance - Design timeSecurity Assurance - Design timeRule VI: DA and PODARule VI: DA and PODA

DSEC--283

CSE300

The delegation sets UAM and UDAM for the DU and DR.

Y is a DU of A, and X satisfies Rules V or VI Y to be authorized to A, hence UAM(A, Y) = 1

Security Assurance - Design timeSecurity Assurance - Design timeRule VII: Delegation of URRule VII: Delegation of UR

DSEC--284

CSE300

Passing on of DA or DA/PODA from a user (either OU or DU) to another DU

Rule VIII establishes, respectively, DA or DA/PODA for user Y a DU of role A, and assumes Rule VII is satisfied.

Security Assurance - Design timeSecurity Assurance - Design timeRule VIII: Delegation of DA/PODARule VIII: Delegation of DA/PODA

DSEC--285

CSE300

Theorem VI, VII, and VIIITheorem VI, VII, and VIII

DSEC--286

CSE300

Assessment of RBAC/MAC Assessment of RBAC/MAC Model/FrameworkModel/Framework

Intent is to Assess the Capabilities of RBAC/MAC Intent is to Assess the Capabilities of RBAC/MAC Model and Security FrameworkModel and Security Framework

Analysis vs. SSE-CMMAnalysis vs. SSE-CMM SSE-CMM: Standard Security Model Compare/Contrast Model/Framework

(including Assurance) Against SSE-CMM Use SSE-CMM as a Benchmark to Evaluate

the Degree We Meet ISO Requirements Evaluation vs. Dynamic Coalitions (DCs)Evaluation vs. Dynamic Coalitions (DCs)

Represent via the RBAC/MAC Model Security Features/Requirements of DCs

Can RBAC/MAC Model Represent DCs? What Features are Good? Need to be Added?

DSEC--287

CSE300

Analysis vs. SSE-CMM Analysis vs. SSE-CMM What is SSE-CMM?What is SSE-CMM?

An ISO Standard Model For Capturing the An ISO Standard Model For Capturing the Essential Characteristics of an Organization’s Essential Characteristics of an Organization’s Security Engineering ProcessSecurity Engineering Process

The Model is a Standard for Security Engineering The Model is a Standard for Security Engineering Practices Covering:Practices Covering: Life Cycle Management of All Activities Management, Organizational, and Engineering

Activities Concurrent Interactions (Software, Hardware,

Humans, Organizations) Certification, Accreditation, and Evaluation

DSEC--288

CSE300

Analysis vs. SSE-CMM Analysis vs. SSE-CMM Why was SSE-CMM Developed?Why was SSE-CMM Developed?

Objective:Objective: Advance Security Engineering As a Defined,

Mature, and Measurable Discipline Project Goal:Project Goal:

Develop a Mechanism to Enable: Selection of Appropriately Qualified Security

Engineering Providers Focused Investments in Security Engineering

Practices Capability-based Assurance

DSEC--289

CSE300

Analysis vs. SSE-CMM Analysis vs. SSE-CMM SSE-CMM Engineering Process AreasSSE-CMM Engineering Process Areas

Administer Security Administer Security ControlsControls

Assess ImpactAssess Impact Assess Security RiskAssess Security Risk Assess ThreatAssess Threat Assess VulnerabilityAssess Vulnerability Build Assurance Build Assurance

ArgumentArgument

Coordinate Security Coordinate Security Monitor Security Monitor Security

PosturePosture Provide Security Provide Security

InputInput Specify Security Specify Security

NeedsNeeds Verify and Validate Verify and Validate

SecuritySecurity

DSEC--290

CSE300

10/24/96

Domain

ProcessAreas

BasePracticesBase

Practices

ProcessAreas

BasePractices

BasePractices

Analysis vs. SSE-CMM Analysis vs. SSE-CMM SSE-CMM Model ArchitectureSSE-CMM Model Architecture

Process Areas

OrganizationProject

Security Engineering

ProcessAreas • • •

Domain Compare and Contrast Compare and Contrast

RBAC/MAC Model and RBAC/MAC Model and Framework w/StandardFramework w/Standard

SSE-CMM: 11 Process SSE-CMM: 11 Process Areas/61 Base PracticesAreas/61 Base Practices PA01: Administer

Security Controls Base Practice 01:

Establish Responsibilities and Accountability for Security Controls

Base Practice 02: Manage the Configuration of Security System Controls

Work in ProgressWork in Progress

DSEC--291

CSE300

Evaluation vs. DCPEvaluation vs. DCP What is DCP? What is DCP?

Marine Corps

NavyAir Force

Army

GCCS

FADDAFATDS

GCCS-A

MCS

ASAS

CSSCS

Other

ABCS

Battle Management

System

JointCommand

System

Army Battle Command

System

CombatOperations

System

U.N.

U.S.A

NGO/PVO

NATO

Dynamic Coalition

U.S. Global C2 SystemsArmy C2

Dynamic Coalition Problem (DCP) are Inherent Security, Resource, and/or Information Sharing Risks that Occur as a Result of

the Coalition being Formed Quickly

DSEC--292

CSE300

Evaluation vs. DCPEvaluation vs. DCPSuitability of Our Approach for DCPSuitability of Our Approach for DCP

Detailed Evaluation of DCP w.r.t. Security ModelDetailed Evaluation of DCP w.r.t. Security Model Utility of Multiple Roles for Users Relevance of Data Value Constraints and Time

Limitations on Users Examination of API Level Control of Resources Importance of Multi-level Secure Capabilities Security Assurance at Design/Run Times Extrapolating from GCCS to DCP

Evolve from GCCS to DCP What are the Issues and Problems to Solve?

Status: Work in Progress at this TimeStatus: Work in Progress at this Time

DSEC--293

CSE300

Summary: Research InnovationsSummary: Research Innovations

Unification of Mandatory Access Control (MAC) and Role-based Access Control (RBAC) Features Realization of MAC: Bell and LaPadula Model Highly Flexible RBAC Capabilities

Security Policy Realization Change Policy on the fly

Broad Use of Constraints: Fine-Grained Security User Constraints and Role Constraints Time Constraints and Signature Constraints

Security Assurance at Design and Run Times DT Checks as Security Policy is Defined RT Checks for Invocation/Delegation

DSEC--294

CSE300

Summary: Summary: Additional ContributionsAdditional Contributions

Working Prototype that can Administer Multiple Working Prototype that can Administer Multiple Security Policies Against Multiple Resources in a Security Policies Against Multiple Resources in a Distributed Environment Supporting JINI/CORBADistributed Environment Supporting JINI/CORBA

A Well Defined Security Model which Supports A Well Defined Security Model which Supports Security Policy Definition via Administrative and Security Policy Definition via Administrative and Management Tools with Security Assurance:Management Tools with Security Assurance: Security Policy Client (SPC) Security Authorization Client (SAC) Security Analysis Tool (SAT) Security Delegation Client (SDC)

DSEC--295

CSE300

Summary: Remaining ResearchSummary: Remaining Research

Security Model that Unifies RBAC/MACSecurity Model that Unifies RBAC/MAC Finer Grained MAC

Classification Levels on a Method’s Signature Investigate Time-Constrained Classification

User Constraints Role Deconfliction

Security Policy and Enforcement AssuranceSecurity Policy and Enforcement Assurance Detailing all Design and Run Time Checks Defining Security Assurance for Fine Grained

MAC and User Constraints Completion of Analysis/Evaluation:Completion of Analysis/Evaluation:

Model/Framework vs. CMU Security Model Evaluation of Utility in Support of DCP

DSEC--296

CSE300

Summary: Publications to DateSummary: Publications to Date

Initial Security Model S. Demurjian, T. C. Ting, P. Barr, C. Phillips, “Role-

Based Security in a Distributed Resource Environment”, Proc. of 14th IFIP WG 11.3 Working Conf. on Database Security, August 2000.

S. Demurjian, T.C. Ting, C. Phillips, et al., “A User Role-Based Security Model for a Distributed Environment”, in Research Advances in Database and Information Systems Security, J. Therrien (ed.), Kluwer, 2001.

Enhanced Security Model C. Phillips, S. Demurjian, T.C. Ting, “Security

Engineering for Roles and Resources in a Distributed Environment", Proc. of the 3rd Annual Information Systems Security Engineering Conf., March 2002.

DSEC--297

CSE300

Summary: Publications to DateSummary: Publications to Date

Relevance of Work for DCP C. Phillips, T.C. Ting, S. Demurjian, “Information

Sharing in Dynamic Coalitions”, Proc. of the 7th ACM SACMAT 2002, June 2002.

MAC Model Extensions and Security Assurance C. Phillips, S. Demurjian, T.C. Ting, “Towards

Information Assurance for Dynamic Coalitions”, Proc. of the 3rd IEEE Info. Assurance Workshop, June 2002.

C. Phillips, S. Demurjian, T.C. Ting, “Security Assurance for an RBAC/MAC Security Model and Enforcement Framework”, CSE Technical Report.

Role Delegation Extensions with Assurance M. Liebrand, H. Ellis, C. Phillips, S. Demurjian, and

T.C. Ting, “Role Delegation for a Distributed, Unified RBAC/MAC”, Proc. 16th IFIP WG 11.3 Conf. on Data and Application Security, July 2002.

Security-298

CSE 300





Document Access


Software Programs




Distributed Setting



Mutual Excl.Safety

Liveness

Security-299

CSE 300

Security Analysis/Design for UMLSecurity Analysis/Design for UML

Thuong Doan, Jaime Pavlich-Mariscal,Steven A. Demurjian, Laurent D. Michel

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

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

[email protected]@uconn.edu

[email protected]@cse.uconn.edu

Security-300

CSE 300

Motivation: Importance of Security Motivation: Importance of Security Software Engineering Software Engineering

Phases of Requirements, Design, Implementation, Testing, Maintenance. Effort: E.g., 60% for Requirement & Design, 15%

Implementation, and 25% Testing [Boehm 87] Software Applications with Security ConcernsSoftware Applications with Security Concerns

When is Security Incorporated into Software Development? Traditional: Deferred to Latter Stages of the Lifecycle

Problem: Error-Prone, Difficult to Verify, Costly Microsoft Report: >50% Security Problems are Design

Flaws [McGraw 03] Return on Security Investment (ROSI): 21% if

Integrating at Design; 15% Implementation;12% Testing [Hoo 01]

Security-301

CSE 300

Motivation: Importance of SecurityMotivation: Importance of Security Incorporating Security into Design/DevelopmentIncorporating Security into Design/Development

Object-Oriented Software Design: Using the De Facto UML (Unified Modeling

Language) [OMG03], a Language for Specifying, Visualizing, Constructing, and Documenting Software Artifacts

When is Security Incorporated into Software Design/Development Processes? Security Must Be a First Class Citizen - Integrated at

Early and All Stages of the Lifecycle Security Assured, Synchronized, Convenient Provide Automated Transition from Security

Definitions to Security Enforcement Code Integration of Enforcement Code with Application

Security-302

CSE 300

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

the Software Process, its Models, and Toolsthe Software Process, its Models, and Tools Integrated:

Rigid Methodology to Express Security Concerns Seamlessly Capture Security Requirements at Design

Assured: Specific Means to Verify Security Concerns

Easy-To-Use: Intuitive Solution Facilitates Inclusion of Security for

Different Stakeholders Transition: Requirements - Design – Development

Security Code Generation (Authorizations) Run-time Authentication

Security-303

CSE 300

Two Complementary PerspectivesTwo Complementary Perspectives Extend UML Diagrams with SecurityExtend UML Diagrams with Security

Integrate Security into Use Case, Class, and Sequence Diagrams

Align UML Concepts to Security Expand Properties on Use Cases, Actors,

Relations, Classes, Methods, etc. Add New Associations Among Diagrams Design Time Security Assurance

New UML Diagrams for SecurityNew UML Diagrams for Security Role, User, and Delegation Diagrams Support MAC features Across Separate Security from UML Composable Security and Automatic Generate of

Enforcement “Code”

Security-304

CSE 300

Global Objectives Global Objectives Security Features from Design to DevelopmentSecurity Features from Design to Development

Extend UML to Support MAC, DAC, and RBAC Security Properties (Simple Security, Strict *, etc.)

plus Constraint Checking (Mutual Exclusion) New UML Diagrams Collect Security Design into

a Logical, Well-Organized Abstractions Automatic Generation of Security Enforcement

Code Integrated with Application Maintain Security Information in DatabaseMaintain Security Information in Database

Track Design and Security State Provide Single Locale for Security Definitions

(Users, Roles, and their Authorized Privileges) Serve as a Means to Support Run-Time

Authentication

Security-305

CSE 300

Detailed Objectives Detailed Objectives Track Design State that Contains All Actions Related Track Design State that Contains All Actions Related

to Security and Application Definitionto Security and Application Definition Employ Functional Notation that Tracks All Actions Employ Functional Notation that Tracks All Actions

and Maintains Historical Record and Maintains Historical Record Support Security Consistency and Assurance bySupport Security Consistency and Assurance by

Security Checks as Design is Created/Change Overall Security Analysis of Entire Design

Security Abstraction that Collects Security DefinitionsSecurity Abstraction that Collects Security Definitions Cohesive and Coherent UML Diagram Generated from Security Definitions

Security Enforcement Code GenerationSecurity Enforcement Code Generation Aspect-Oriented Programming Approach Security Code Integrated with Application Code

Security-306

CSE 300

Overview of the ProcessOverview of the Process

Non-SecurityRequirementsSpecification

Security RequirementsSpecification

R1 Rn…

Main ApplicationDesign Model

Security Model

…

Main ApplicationCode

SecurityCode…

Requirements Analysis

Design

Implementation

Access Control Requirements

Security Features

Security Component Code

SF1 SFn

SC1 SCn

Iterative Pro

cess

Security-307

CSE 300

Overview of Remainder of TalkOverview of Remainder of Talk Perspective 1: Extending UML Diagrams w/SecurityPerspective 1: Extending UML Diagrams w/Security

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

Perspective 2: New UML Diagrams for SecurityPerspective 2: New UML Diagrams for Security Role Slice, User, and Delegation Diagrams MAC Security Features Composable Security Aspect Oriented Code Generation Prototyping Effort

Conclusions and Ongoing ResearchConclusions and Ongoing Research

Security-308

CSE 300

Extending UML for the Designand Definition of Security Requirements

Address Security in Use-Case Diagrams, Class Diagrams, Sequence Diagrams, etc.

Formal Security Policy Definition that TrackDesign State via a Functional Representation

Iterate, Revise

Bi-Directional Translation – FromSecurity Definitions (Extensions) toUnderlying formal Functional Model

Security Model Generation

RBAC99GMU/NIST

RBAC/MACUConn

(DistributedSecurity)

OracleSecurity

Must Prove GenerationCaptures all Security

Requirements

Perspective 1: Extending UML DiagramsPerspective 1: Extending UML Diagrams

Many AlternativeSecurity

Model Solutions

New UML Diagrams and AOP SecurityEnforcement

Security-309

CSE 300

UML Design Tool

Database Server

Designer’s Input

Internal UML

Structures

UML Diagrams

Customer’s Requirements

UML Diagrams

Triggers

Security Constraints Checking Module

(Algorithm)

Perspective 1: Extending UML DiagramsPerspective 1: Extending UML Diagrams

New UMLSecurity

Diagrams

Aspect-OrientedSecurity

Enforcement Code Generation

Java

Security-310

CSE 300

Principles of Secure DesignPrinciples of Secure Design Principle 1 Principle 1

The Software Design has Multiple Iterative Periods Security Features Should be Incorporated and

Adjusted During Each of and Among Those Periods

Principle 2 Principle 2 TThe Security Assurance is Satisfied Relatively to

the Period of Software Design Principle 3 Principle 3

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

Principle 4Principle 4 Security Definition via a Unified Perspective that

Collects Privileges into a Cohesive Abstraction

Security-311

CSE 300

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

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

Objects

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

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

Signatures) and Relationships Among Classes

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

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

Security-312

CSE 300

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

Period of Software Design Period of Software Design Security Assurance Evaluated Against the

Respective Software Design Phase To Enforce the Security Assurance Rules (SARs)

The Granularity Level of SAR Checks Is Dependent on the Level of Detail in the Software Design Phase

Example:Example: Tiers 1 & 2: Use Case Diagrams, Class Diagrams

Check the Security Levels of Use Cases, Actors, and Classes

Tier 3: Sequence Diagrams Check the Security Levels of Methods

Security-313

CSE 300

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

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

Our Perspective:Our Perspective: (ei, ej.behaviorjk): Whether Element ei Can Employ

Some Behavior behaviorjk of Element ej Security Consideration in UML: “Who Can

Exercise Which Behaviors of the Application (Use Cases) and Class Behaviors (Methods)?”

Answer: Drawing Connections in UML Diagrams Productivity: Incorporating Security Via SARs in

Connections Provides Security Checks During the Normal Activity of Designers

Security-314

CSE 300

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

CounterCounter the Intuition the Intuition nor Decreasenor Decrease the Productivity of the Productivity of the Software Designer the Software Designer Security Consideration in UML: “Who Can

Exercise Which Behaviors of the Application (Use Cases) and Class Behaviors (Methods)?”

Example: The System has Two Usage Modes:Example: The System has Two Usage Modes: Design-Time: Real-Time Check

Drag – Check – “Drop/Pop”: Realization of the Intended Design Element or Pop Up Error Message Depending on the Security Checking Result

Post-Design: On-Demand Check Security Compiler Executed on a Whole Design

Security-315

CSE 300

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

CounterCounter the Intuition the Intuition nor Decreasenor Decrease the Productivity of the Productivity of the Software Designer.the Software Designer. MAC: (Subject, Operation, Object):

Operation = Read|Write|Call Object = A Piece of Atomic Information With Only One Assigned Security Classification

Object-Oriented: Operation = (Read*Write*Call*)* (as Method)Object = An Instance of Class with Many Attributes

Security-316

CSE 300

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

Collects Privileges into a Cohesive AbstractionCollects Privileges into a Cohesive Abstraction Our Perspective:Our Perspective:

Security as Supported via Principles 1, 2, and 3, Spreads Requirements Across Multiple Diagrams

As a Result, Security is “Tangled” and “Scattered” Across Design

Propose a “Role-Slice Diagram” that Collects Definitions into a Central Location

Allows Stakeholders to See the “Big Picture” Provides Basis for Security Enforcement Code

Generation

Security-317

CSE 300

Extending UML for Secure DesignExtending UML for Secure Design Work of Thuong Doan, Ph.D. studentWork of Thuong Doan, Ph.D. student Defining a Framework for Assurance in Secure Defining a Framework for Assurance in Secure

Software Design with UMLSoftware Design with UML Capable of Capturing All of the Critical Security

Requirements Aligning Roles with Actors in Use-Case Diagram Adding Security Properties and Constraints Checking MAC, RBAC, and Lifetimes to Use-Case, Class, and

Sequence Diagrams Simultaneously Tracking All of the States of a

Design from a Security Perspective Maintaining the Security Assurance as

Requirements/Designs are Defined and Changed

Security-318

CSE 300

Extending UML for Secure DesignExtending UML for Secure Design Extend “Most Utilized” UML DiagramsExtend “Most Utilized” UML Diagrams

Use Cases Class Sequence Diagram

Security Extensions for Privileges and AuthorizationSecurity Extensions for Privileges and Authorization MAC – Assignment of Security Levels to UML

Entities (Use Cases, Actors, Class, Methods, etc.) RBAC – Alignment of “Actor” with “Role” Lifetimes –Element or Association (ISA, include,

extend, etc.) Availability w.r.t. Security Real-Time Security AnalysisReal-Time Security Analysis

Maintain Design State As Connections are Made, Check Security

Privileges for their Consistency/Correctness

Security-319

CSE 300

Extending UML for Secure DesignExtending UML for Secure Design

UML + Security

Extensions

Captured inDesign State

Functional Model

DesignAction

Design Time

Checked in

Security Constraints

Checker

AssumptionsAssumptions Utilizing UML Security

Specifications Communicating

with the Customer

Security-320

CSE 300

Use-Case UML ExtensionsUse-Case UML Extensions Security LevelsSecurity Levels

(TS, S, C, U) are Associated with Each Element (Use Case and Actor)

Levels are the Security Sensitivity for the Element LifetimesLifetimes

A Lifetime Represents the Availability of an Element with respect to Security Usage

Start and End Date/Time End Date can be Infinite (no end)

ConnectionsConnections As Use Cases are Connected and Actors are

Connected – Levels and Lifetimes are Checked Consistency of Connections Checked

First – Let’s Consider Extensions Informally … First – Let’s Consider Extensions Informally …

Security-321

CSE 300

Survey Management ExampleSurvey Management Example A Survey Institution Performs and Manages Public A Survey Institution Performs and Manages Public

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

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

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

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

Security-322

CSE 300

Use Case Diagram in UMLUse Case Diagram in UML A Survey Institution Manages Public SurveysA Survey Institution Manages Public Surveys Use Case Diagram for Creating a New Survey EntryUse Case Diagram for Creating a New Survey Entry

Security-323

CSE 300

Use Case Diagram with Security LevelsUse Case Diagram with Security Levels Taking Security ConcernTaking Security Concern

MAC: Security Level (e.g. U<C<S<TS) Assigned for Elements (Use Cases and Actors)

Valid Connection:

Actor with Confidential Level can Utilize Use Case with Confidential Level

Security-324

CSE 300

UML Use Case Diagram with Security LevelsUML Use Case Diagram with Security Levels

Taking Security ConcernTaking Security Concern MAC: Security Level (e.g. U<C<S<TS) Assigned

for Elements

Invalid Connection:

Actor with Confidential Level cannot Utilize Use Case with Secret Level

Security-325

CSE 300

Extensions for Security + LifetimeExtensions for Security + Lifetime Actor Senior Staff is Represented asActor Senior Staff is Represented as

(“Senior Staff”, A, (“Senior Staff”, A, [“01/01/2005”,“12/31/2006”], S, S)[“01/01/2005”,“12/31/2006”], S, S)

Min = Max for ActorsMin = Max for Actors

Security-326

CSE 300

Extensions for Security + LifetimeExtensions for Security + Lifetime Use Case Add Survey Header is Represented AsUse Case Add Survey Header is Represented As

(“Add Survey Header”, UC, [“01/01/2005”, “12/31/2006”], S, S)

Min = Max for Use CasesMin = Max for Use Cases

Security Property of Use Case Add Survey Header

Security-327

CSE 300

UML Class DiagramUML Class Diagram Security LevelsSecurity Levels

(TS, S, C, U) are Associated with Each Element (Class and Method)

Classes have Minimum and Maximum Levels LifetimesLifetimes

Classes and Methods have Start/End Date/Time End Date can be Infinite (no end)

Containment/ConnectionsContainment/Connections All Methods of a Class Must have Security Level

Between its Class’ Minimum and Maximum As Classes are Connected – Levels and Lifetimes

are Checked Consistency of Connections Checked

First – Let’s Consider Extensions Informally … First – Let’s Consider Extensions Informally …

Security-328

CSE 300

Survey Management Class DiagramSurvey Management Class Diagram

Security-329

CSE 300

Extensions for Security + LifetimeExtensions for Security + Lifetime Min = Max for MethodsMin = Max for Methods

Security Property of Class Survey_List

Security Property of Method Add_Survey_Header

Security-330

CSE 300

UML Use-Case ConnectionsUML Use-Case Connections

Relationships Track Dependencies Across DesignsRelationships Track Dependencies Across Designs Two Groups of UML Connection KindsTwo Groups of UML Connection Kinds

Group 1 – Explicitly in UML Use Case/Actor (Role)/Class Inheritance: Child Inherits

(Specializes) Parent Use Case Inclusion/Extension: <<Include / Extend>> Actor-Use Case Association:a Interacts with uc

Group 2 – Result of Tracking Use-Case/Class Interactions – For Each Use Case Track … Classes Utilized to Implement the Use Case (Initial

Phases of Design) Methods of those Classes Utilized to Implement the

Use Case (Later Phases of Design)

Security-331

CSE 300

Group 1 ConnectionsGroup 1 Connections Use Case or Actor (Role) Inheritance: Child Inherits Use Case or Actor (Role) Inheritance: Child Inherits

(Specializes) Parent(Specializes) Parent Child at Level or More Secure than Parent

Use Case Inclusion/Extension: <<Include / Extend>>Use Case Inclusion/Extension: <<Include / Extend>> X Includes Y: Y at Level or Less Secure than X X Extends Y: X at Level or Less Secure than Y

Actor-Use Case Association: Actor-Use Case Association: Actor A Interacts with UC X A at Level or More Secure than X

Connections Cause Detailed ChecksConnections Cause Detailed Checks Not only Source and Destination of Connection Also Must Check Related UCs and/or Actors

Security-332

CSE 300

Use Case Group 1 ConnectionsUse Case Group 1 Connections All Associations (Connections) Must Satisfy MAC All Associations (Connections) Must Satisfy MAC

Constraints on Prior SlideConstraints on Prior Slide Intent – Keep Design in Correct/Consistent StateIntent – Keep Design in Correct/Consistent State

Security-333

CSE 300

Group 2 ConnectionsGroup 2 Connections Secure Design with UML Requires the Ability to Secure Design with UML Requires the Ability to

Establish Associations Between Establish Associations Between UML Use Case Diagrams are Relatively IndependentUML Use Case Diagrams are Relatively Independent In Sequence Diagrams, Actor and UC Can Interact In Sequence Diagrams, Actor and UC Can Interact

with Classes (and Methods) – Not Required with Classes (and Methods) – Not Required Group 2 Connections Provide Ability to TrackGroup 2 Connections Provide Ability to Track

Classes and Methods Utilized to Implement a UC

Security-334

CSE 300

Group 2 Connections: UC to ClassesGroup 2 Connections: UC to Classes Use Case-Class Utilization: Use Case-Class Utilization: uc uc Utilizes Utilizes cc

UC Add Survey Header Utilize Survey_List, Survey_Hdr_Add_Pg, and Survey_Header Classes

Means UC Add Survey Header Will Utilize Portions of those Classes for its Implementation

Again – Consistency Checks From UC to Classes

Security-335

CSE 300


Security-336

CSE 300

Group 2 Connections: UC to MethodsGroup 2 Connections: UC to Methods Use Case-Method Utilizing: Use Case-Method Utilizing: uc uc Directly Utilizes Directly Utilizes mm

UC Add Survey Header Utilizes Methods onSubmit of Class Survey_Hdr_Add_Pg Create_Survey_Header of Class Survey_Header Add_Survey_Header, Survey_Title_Search, and

Update_Survey_List of Class Survey_Header

Security-337

CSE 300

Tracking Design and Security StateTracking Design and Security State Previous Slides Illustrate the Ability to Maintain a Previous Slides Illustrate the Ability to Maintain a

Correct “Security” State as Design Created/ChangedCorrect “Security” State as Design Created/Changed Objective Now is to:Objective Now is to:

Define Design Security State Formalize Prior Definitions of Security Level,

Lifetime, UML Element, UML Connection Introduce Security Constraint Hierarchy and

Checking Define Application’s Security Requirement Formalize Constraint Checking w.r.t.

Disallowed Usage (Negative Permissions) Mutual Exclusion (Excluding Actions by UML

Elements within Time Periods)

Security-338

CSE 300

One Can Consider the Design State As a Set of

Design Elements

Design State SpaceDesign State Space How do we Represent and Keep Track of the Design StatesHow do we Represent and Keep Track of the Design States??

Design Elements Time-Sensitive They have Lifetimes

06/01/2005

Design Time

06/01/2006

Security-339

CSE 300

Design State SpaceDesign State Space Use Functional Model and Track Design InstancesUse Functional Model and Track Design Instances

State is a Function

Design Element ID

State Function i

Design Timei

Design Element Contents

Error Status

Action is a (Meta)Function on States

Design Action

i i+1

Security-340

CSE 300

Security Model for UML DesignSecurity Model for UML Design Extending UML with Security Features (MAC, RBAC Extending UML with Security Features (MAC, RBAC

and Lifetime)and Lifetime) Def. 3.2.1 (Security Level Set)

The Security Level Set (SL): a Partial Ordered Set with Relation < where for SL and SL’ SL, SL < SL’ Means that the Level SL’ has a Higher Security Concern than that of SL

Def. 3.2.2 (Lifetime) Let T be a Set of Discrete Time of the Form “month-

day-year [hour:minute:second]” (As a Subset Cartesian Product of Sets of Integers), a Lifetime lt is a Time Interval [st, et] where et and st T are the Start Time and End Time (lt.st and lt.et), Respectively, with et st (the Point of Time st Occurs Not After et).

Security-341

CSE 300

Extended UML Elements with SecurityExtended UML Elements with Security Augmenting UML Elements withAugmenting UML Elements with Security Levels Security Levels

(SLs) and (SLs) and Lifetimes (LTs)Lifetimes (LTs)

Formal Definition:Formal Definition: Def. 3.2.4 (UML Element)

= IDEKISLSL : the Set of UML Elements A UML element : a Tuple (id, k, lt, slmin, slmax)

where id, k, lt, slmin, and slmax are its Element Identification, Element Kind, Lifetime, Minimum and Maximum Security Levels (Denoted as .id, .k, .lt, .slmin and .slmax)

For a Class c: c.slmin c.slmax;

Other Non-Class Element: e.slmin e.slmax = e.sl

Example:Example: (“Senior Staff”, A, [“01/01/2005”, “12/31/2006”], S, S)

Security-342

CSE 300

Extended UML Connections with SecurityExtended UML Connections with Security UML Connections Have LifetimesUML Connections Have Lifetimes Formal Definition:Formal Definition:

Def. 3.2.6 (UML Connection) = IDCKIIDID: the Set of UML

Connections

A Connection : a Tuple (id, k, lt, ids, idt) where id,

k, lt, ids and idt are the ID of the Connection, the

Connection kind, Connection Lifetime, and the IDs of the Source and Target UML Elements (Denoted as .id, .k, .lt.ids and .idt)

Example:Example: (“”, AU_Asc, [“01/01/2005”, “12/31/2005”],

“Senior Staff ”, “Add Survey Header ”)

Security-343

CSE 300

Security ConstraintSecurity Constraint

Security Constraint

MAC Constraint

RBAC Constraint

LifetimeConstraint

Security as “Enforcing a Policy that Describes Rules Security as “Enforcing a Policy that Describes Rules for Accessing Resources.” (Viega and McGraw 2002)for Accessing Resources.” (Viega and McGraw 2002)

Considering Three Types of Security ConstraintConsidering Three Types of Security Constraint MAC: Checking the Domination of Security

Levels of Connected Elements Lifetime: Checking the Temporal Window of

Activity for Entities and Users. RBAC: Maintaining the Interest Conflict-Free

Working Environment for User Roles

Security-344

CSE 300

Application’s Security RequirementsApplication’s Security Requirements Application’s Security Requirements have LifetimesApplication’s Security Requirements have Lifetimes Formal Definition:Formal Definition:

Def. 3.2.7 (Security Requirement for RBAC) i = IDSRI (ID)i (i= 2, 3,…)

An Application’s Security Requirement (SR) Involved In i elements: a Tuple (id, k, lt, 1, 2,…, i) i

where id, k, lt, 1, 2,…, and i, are the ID Label

(Denoted as .id), the Kind of the Security Requirement (.sk), the Lifetime (.lt), and the i Involved Element’s IDs (Denoting .els = {1, 2,…, i}), Respectively

SRs SRs 22 33, , SRSR = { = {DisUDisU, , MEMESROSRO, , MEMESORSOR}} DisU: Disallowed Usage (Negative Permission) MESRO and MESOR: Mutual Exclusions

Security-345

CSE 300

Application’s Security RequirementsApplication’s Security Requirements Disallowed Usage – DisU: Negative PermissionDisallowed Usage – DisU: Negative Permission

(id, DisU, lt, 1, 2) Element 1 is Not Allowed To Use Element 2 During lt E.g. (“SR1”, DisU, [“01/01/2005”, “12/31/2006”],

“Junior Staff ”, “Add Survey Header”)

[“01/01/2005”, “12/31/2006”]

Security-346

CSE 300

Application’s Security RequirementsApplication’s Security Requirements Static Role-Objects Mutual Exclusion - MEStatic Role-Objects Mutual Exclusion - MESROSRO

(id, MESRO, lt, 1, 2, 3)3: Actor 1 is Not Allowed to Use Both Elements 2 and 3 During lt E.g. (“SR2”, MESRO, [“01/01/2005”, “12/31/2006”],

“Junior Staff ”, “Add Question”, “Approve Question”)

[“01/01/2005”, “12/31/2006”]

Security-347

CSE 300

Application’s Security RequirementsApplication’s Security Requirements

Static Object-Roles Mutual Exclusion - MEStatic Object-Roles Mutual Exclusion - MESORSOR

(id, MESOR, lt, 1, 2, 3) 3: Actors 1 and are Not Allowed to Use Element 3 At the Same Time During lt E.g. (“SR3”, MESOR, [“01/01/2005”, “12/31/2006”],

“Supervisor ”, “Editor”, “Activate/Deactivate Survey”)

Security-348

CSE 300

Together Architect Plug-InTogether Architect Plug-In

The Interface to Enter a Security Requirement

Enter the Static Role-Objects Mutual Exclusion that the Junior Staff Cannot Use Both “Add Question” and “Approve Question” Use Cases from 01/01/2005 to 12/31/2006.

Security-349

CSE 300


The List of Security Requirements The Interface Allows to Add a New Security Requirement,

Edit/Remove a Current Security Requirements, and Generate the Set of Current Security Requirements in Specified Formats.

Security-350

CSE 300

Complete Security Constraint TaxonomyComplete Security Constraint Taxonomy

Security Constraint

MAC Constraint

RBAC Constraint

2-element Constraint

3-element Constraint

DisallowedUsage

Mutual Exclusion

StaticRole-Objects

ME

StaticObject-Roles

ME

LifetimeConstraint

n-element Constraint

Security-351

CSE 300

Design State and TransitioningDesign State and Transitioning State Function Provides the Transition from One State Function Provides the Transition from One

Design State to Next When Given Design ActionDesign State to Next When Given Design Action Adding/Deleting/Modifying a UML Element Adding/Deleting/Modifying a UML Connection

Three Aspects of Design State SpaceThree Aspects of Design State Space UML Elements Application’s Security Requirements UML Connections

State Functions Triggered on Insertion, Deletion, etc.State Functions Triggered on Insertion, Deletion, etc.

Security-352

CSE 300

Three Design State Spaces and Actions Three Design State Spaces and Actions

Security Constraint

UML Element State Space Design

Action

Application’s Security Requirement

State Space

UML Connection Design State Space

Design Time

Design Action

i i+1

Insert/Update/Delete

Security-353

CSE 300

State FunctionsState Functions Extended Sets: Extended Sets: = { = {} } , , = { = {} } , and , and

= {= {} } where where is is the the nullnull Element Element ErrErr ={0, 1, 2,…}: Set of Error Numbers with “0” As ={0, 1, 2,…}: Set of Error Numbers with “0” As

an Initial Value (for Initial State) and “1” As No Error an Initial Value (for Initial State) and “1” As No Error Def. 3.3.1 (State Function Signatures)

For UML Elements: : IDT Err

For UML Connections: : IDT Err For Security Requirements: : IDT Err

UML Element ID

Design Time

iUML Element Contents

Error Status

Design State Design State ii: (: (ii, ,

ii, , ii) )

Security-354

CSE 300

Inserting a UML ElementInserting a UML Element Status FunctionStatus Function for UML Elements for UML Elements the Status of a the Status of a

UML Element UML Element Based on the Current Set of Designed Based on the Current Set of Designed UML Elements UML Elements LL at the Design Time at the Design Time

Def. 3.4.3 (Status Function for UML Element

Space): stat: 2IDT Err stat L =

if L == then (, 0)

else let e L in // Pick an element e in L

if e.id then stat L\{e} else intra_chk e

UML Element IDDesign Time

statUML Element Contents

Error Status

Current UML Element Set

Security-355

CSE 300

Inserting a UML ElementInserting a UML Element intra_chkintra_chk Function for the Intra-element Check on Function for the Intra-element Check on

the Properties (Lifetime and Security Levels) of an the Properties (Lifetime and Security Levels) of an UML Element at a Specific Time UML Element at a Specific Time Def. 3.4.2 (Intra-Element Checking for a UML Element) intra_chk: T Err intra_chk = //: the added UML element; : the design time

if .lt.et then (, 2) // Error: the life time ended before the design time

else if .ek == Cl then // Adding a class

if .slmin .slmax then (, 1) // Return the applicable element without error

else (, 3) // Error: The SL max of a class must dominate its SL min

else // adding a non-class

if .slmin == .slmax then (, 1) // Return the applicable element without error

else (, 4) // Error: The SL max of a non-class must be equal to its SL min

Security-356

CSE 300

State FunctionsState Functions RememberRemember::

Design State Function Signature For UML Elements: : IDT Err


i

UML Element ContentsError Status


statUML Element Contents

Error Status

Current UML Element Set

Status Function for UML Element Space: stat: 2IDT Err

Cast the Form of Cast the Form of ii Function as Function as

i i = (= (statstat LLii) )

Li (=

i.set): The Set of Designed UML Elements in State i. Define L

0 = 0.set =

0= (, 0)

Security-357

CSE 300

Inserting a UML ElementInserting a UML Element Function of Inserting a UML ElementFunction of Inserting a UML Element

Def. 3.4.4 (The Insert Action on UML Element Space): Ins: Ins i e = i+1 where

i+1 = stat (insert e i.set),

i+1 =

i and i+1 =

i ExampleExample: Design From Scratch (From State 0) : Design From Scratch (From State 0) Add Use-Case uc1: Add Survey Header, min SL =

max SL = “S”, and LT = [“01/01/05”, “12/31/06”] State 0: (

0, 0,

0) = ((, 0), (, 0), (, 0))

State 1: 1 stat (insert uc1

0.set)

= stat (insert uc1 ) = stat {uc1};

1 =

0 and 1 =

0

1 uc1 “06/15/05” = (stat {uc1}) uc1 “06/15/05” =

((Add Survey Header, UC, [01/01/05,12/31/06], S, S),1)

Security-358

CSE 300

Status Function for UML ConnectionsStatus Function for UML Connections Status of a UML Element Status of a UML Element Based on the UML Based on the UML

Element State Element State and the Current Set of Designed and the Current Set of Designed UML Connections UML Connections LL at the Design Time at the Design Time Def. 3.4.6 (Status Function for UML Connection

Space): stat: 2IDT Err stat L =

if L == then (, 0)

else let e L in // Pick an element e in L

if e.id then stat L\{e} else intra_chk e

Security-359

CSE 300

Inserting ActionInserting Action Function of Inserting a UML ConnectionFunction of Inserting a UML Connection

Def. 3.4.7 (The Insert Action on UML Connection Space): Ins: Ins i e = i+1 where

i+1 = i,

i+1 = stat

i+1 (insert e i.set), and

i+1 = i

Function of Inserting a Security RequirementFunction of Inserting a Security Requirement Def. 3.4.7 (The Insert Action on SR Space): Ins:

Ins i e = i+1 wherei+1 =

i, i+1 =

i, and

i+1 = stat

i+1 (insert e i.set)

Deletion and Update of UML Elements Also Require Deletion and Update of UML Elements Also Require Analogous Modification to the Design State SpaceAnalogous Modification to the Design State Space

Security-360

CSE 300

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

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

Objects

Recall the three Prior Design TiersRecall the three Prior Design Tiers Tier 1: Use Case Diagrams, Class Diagrams

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

Signatures) and Relationships Among Classes

Recall Design Tiers and Design Process Recall Design Tiers and Design Process

Tiers Represent a Typical Design Process with UMLTiers Represent a Typical Design Process with UML Not Only Process – but One ScenarioNot Only Process – but One Scenario Objective is to Understand Placement of Security in Objective is to Understand Placement of Security in

the Process – Particularly w.r.t. Assurancethe Process – Particularly w.r.t. Assurance

Security-361

CSE 300

Security Constraints CheckingSecurity Constraints Checking Three Security/Software Design Three Security/Software Design TiersTiers for the UML for the UML

Tier 1: Use-Case Diagrams Tier 2: Classes Use-Cases Tier 3: Sequence Diagrams

Intra-Checks Occur within Individual UML ElementsIntra-Checks Occur within Individual UML Elements Inter-Checks for MAC/RBAC/Lifetime ConstraintsInter-Checks for MAC/RBAC/Lifetime Constraints

CstrMAC: T Boolean CstrRBAC: T Boolean CstrLT: T Boolean Lifetime Check at the Design Time: Necessary

Condition Also Checked at Run-Time in the Code Generated

for Security Enforcement

Intra-Checks Inter-Checks

Security-362

CSE 300

Security Constraints CheckingSecurity Constraints Checking

Inter-Element Check for MAC (Simple Sec/Integrity)Inter-Element Check for MAC (Simple Sec/Integrity) The MAC Constraint CstrMAC(i, , t) for a

Connection from x to y For a Connection (Not Use Case-Class and Class-

Method Connection), x Utilizes y : x.SL y.SL

MAC Satisfied Connection:

Actor with Confidential Level can Utilize Use Case with Confidential Level

Security-363

CSE 300

MAC Constraint CheckingMAC Constraint Checking

Enforcing MAC Constraint – Error CaseActor Staff with “C” Cannot

Utilize Add Survey Header with “S”

Security-364

CSE 300


Inter-Element Check for MACInter-Element Check for MAC Use Case-Class Utilization: uc Utilizes c

The Security Level of Use Case uc Dominates the Minimum Security Level of Class c: uc.sl c.slmin

Security-365

CSE 300


Inter-Element Check for MACInter-Element Check for MAC Class-Method Defining: c Defines m

The Security Level of Method m is Between the Minimum and Maximum Security Levels of Class c:

c.slmax m.sl c.slmin

Example: The SL of Method Add_Survey_Header as Secret is Between The Max (Secret) and Min (Confidential) SLs of the Class Survey_List

Security Property of Class Survey_List

Security Property of Method Add_Survey_Header

Security-366

CSE 300


Inter-Element Check for LifetimeInter-Element Check for Lifetime The Lifetime Constraint CstrLT(i, , t) for a

Connection from x to y at t x Utilizes y: Work Time WT = .lt x.lt y.lt

and t < WT.et (= The end time of Work Time)

Lifetime Satisfied Connection at t = “1/15/06” < WT.et = “12/31/07”

[1/1/05, 12/31/07][1/1/05, 12/31/08][1/1/06, 12/31/07]

Security-367

CSE 300

Inter-Element Check for RBACInter-Element Check for RBAC The RBAC Constraint CstrRBAC(i, , t) for a

Security Requirement DisAllowed Usage: (id, DisU, lt, 1, 2)

Path from Element 1 to Element 2 During lt

Static Role-Objects Mutual Exclusion: (id, MESRO, lt, 1,

2, 3)3: The Path Coverage (i.e. All the Paths) from

Actor 1 Cannot Contain Elements 2 and 3 During lt

Static Object-Roles Mutual Exclusion: (id, MESOR, lt, 1,

2, 3)3: Element 3 is NOT in the Intersection of

two Path Coverages from Actor 1 and Actos 2 During

lt


12

1

2

3

1

2

3

Security-368

CSE 300

Towards Security AssuranceTowards Security Assurance When is Design Acceptable with Respect to Security?When is Design Acceptable with Respect to Security?

Define Security Compliance Properties Represents Constraints that Must Hold as Design is

Created and Modified Does the Design have Expected Security Properties?Does the Design have Expected Security Properties?

Security Conformity Support Program Design-Time and Post-Design Modes

Goal:Goal: Each Design Element is Legitimate to Use via

Intra-Checks All Application's Security Requirements Hold via

Inter-Checks at a Design Time t

Security-369

CSE 300

Towards Security AssuranceTowards Security Assurance Design-Time CheckingDesign-Time Checking

As Discussed so Far, Security Checks Occur as Design is Created and Modified

However – Design Can be Too Complicated to Develop without Constant Nagging Error

In Use Case – Perhaps any Remaining Connections will Cause Errors

However – Designer May Intend to Make Changes to Remove Problems in Later Design Iterations

Need the Ability to Turn off Design-Time Checking

Result: Require Checkingof Design Iterations

Security-370

CSE 300

Towards Security AssuranceTowards Security Assurance Post-Design CheckingPost-Design Checking

Turn off Design-Time Security Checking Initiated by Security Designer Allows Design to be in an Inconsistent State w.r.t.

Security Compliance and Conformity Design State is Still Tracked

Represents All Design Actions Can Track All Security Errors Doesn’t Report Errors

At Certain Design Milestones (Iterations) Designer can Initiate Post Design Checking Comprehensive Intra- and Inter- Check Across the

Entire Design Instance

Security-371

CSE 300

Security Compliance PropertiesSecurity Compliance Properties A Design State A Design State ii = ( = (

ii, , ii, ,

ii) is said to Be ) is said to Be Admissible at Design Time t if Every Design

Element in i,

i, and i Evaluates to be

Applicable at t

MAC/LT Constraint-Compliant at Design Time t if i is Admissible and for Every UML Connection in

i, CstrMAC/ CstrLT(i, , t) Yields true at t

RBAC Constraint-Compliant at Design Time t if i is Admissible and for Every Application's Security Constraint in

i, CstrRBAC(i, θ, t) Yields true at t

Security Constraint-Compliant at Design Time t if i is MAC, LT and RBAC Constraint-Compliant

Security-372

CSE 300

Security Conformity Design SupportSecurity Conformity Design Support Security Conformity Design SupportSecurity Conformity Design Support ( (SCDSSCDS) Program) Program For Design-Time Mode For Design-Time Mode PPDTDT

Designer’s Action Event Trigger Security Constraint Check on the Current State & Design Time Materialize Connection | Error Materialize Connection: Update GUI and Design Space

For Post-Design Mode For Post-Design Mode PPDPPD Simulate Designer’s Actions at a Design Time

Connections with Non-Actors (MAC and Lifetime Check Only)

Connections of Actor-Use-Case then Actor Inheritance

Security-373

CSE 300

Design-Time CheckingDesign-Time Checking

Design-Time Checking: MAC Constraint Violation

The Connection is Removed

Security-374

CSE 300


Turning the MAC Design-Time Checking On/Off

Security-375

CSE 300

Post-Design CheckingPost-Design Checking

Post-Design Checking - Error Case

MAC Violation

Security-376

CSE 300

Security Conformity Design SupportSecurity Conformity Design Support SCDSSCDS Program Program for Design-Time Mode for Design-Time Mode PPDTDT

Intended to be Active within the Design Environment PDT(: , t: T){

// is the beginning security constraint-compliant state

// t is the design time specified by the designer

now =

err_no = 0 // No error is defined yet

while designer performs action on e

<temp, err_no> = Response(, e, now, t)

if err_no 1 then ReportError(err_no)

else {Materialize e in the design

now = temp}

end while

}

Security-377

CSE 300

Security Conformity Design SupportSecurity Conformity Design Support Example of a Design State Construction ProcessExample of a Design State Construction Process

Use Case Diagram for Creating a New Survey Entry

Security-378

CSE 300



Security-379

CSE 300



Security-380

CSE 300



Security-381

CSE 300



Security-382

CSE 300

Algorithmic Complexity DiscussionAlgorithmic Complexity Discussion The Design-Time Security Conformity Support The Design-Time Security Conformity Support

Program Program PPDTDT

Check Performed whenever a UML Element, UML Connection or SR is Created/Modified

Checks Occur in the UML Design Tool Reasonable Computational Cost So As to Not Add

Overhead to the Design Process The Post-Design Security Conformity Support The Post-Design Security Conformity Support

Program Program PPPDPD When Designs Become More Complex, or are

Partially Checked (Imported) Employed at Design Iterations to Check the Whole

Design (at Some Milestone/version) A Graph Traverse Problem on UML ConnectionsA Graph Traverse Problem on UML Connections

Security-383

CSE 300

Prototyping EffortPrototyping Effort Together Architect (TA): UML Tool with Open APIs Together Architect (TA): UML Tool with Open APIs

for JAVA and a Modular Plug-in Structurefor JAVA and a Modular Plug-in Structure Thanks to Andy, Phil, Frank, and Vijaya, et al. TA Allows Our Own Custom Code to be Added Custom Code for MAC/RBAC/LT Constraints Provides a Tool for Secure Software Design

On-Going Prototyping Effort SupportsOn-Going Prototyping Effort Supports Definition of SLs and LTs, for Use-cases, Actors,

Classes, and Methods and Constraints into TA Security Level Analyses for UML Designs

Real-Time as Design is Created and Modified Post-Design for Design Iterations/Increments

Generation of Comments that Capture Defined Security - Longer Term to Generate Secure Code

Security-384

CSE 300

Together Architect (TA) Plug-InTogether Architect (TA) Plug-In

The Modified Inspector Panel of TA

Assigning Lifetime and Security Levels to Actor Staff

Security-385

CSE 300


The Interface to Enter a Security Requirement

Enter the Static Role-Objects Mutual Exclusion that the Junior Staff Cannot Use Both “Add Question” and “Approve Question” Use Cases from 01/01/2005 to 12/31/2006.

Security-386

CSE 300


The List of Security Requirements The Interface Allows to Add a New Security Requirement,

Edit/Remove a Current Security Requirements, and Generate the Set of Current Security Requirements in Specified Formats.

Security-387

CSE 300


Turning the MAC Design-Time Checking On/Off

Security-388

CSE 300

Design-Time CheckingDesign-Time Checking

Design-Time Checking: MAC Constraint Violation

The Connection is Removed

Security-389

CSE 300


Post-Design Checking: No Constraint Violation

Security-390

CSE 300


Post-Design Checking - Error Case

MAC Violation

Security-391

CSE 300

Retrospective on Work Retrospective on Work Visual/Non-Visual Modeling Extensions for RBAC, Visual/Non-Visual Modeling Extensions for RBAC,

MAC, & Lifetimes in UML MAC, & Lifetimes in UML Extensions Integrate Security Requirements,

RBAC, MAC, and Lifetimes, into Design Phase Formal Functional Model for Security/Non-Security Formal Functional Model for Security/Non-Security

Design Features/State Design Features/State Formal Functional Model Capturing the Security

& Non-security Features of an Application’s Design

Track the Design State Retaining Design Time As a Parameter

Convenient for Time-Sensitive Applications with Lifetime Constraints

“Design Once, Re-use Many Times” - Advanced Step for the Style “Write Once, Run Anywhere”

Security-392

CSE 300

Retrospective on WorkRetrospective on Work Strong Security Assurance (on Strong Security Assurance (on MAC/LT/RBACMAC/LT/RBAC))

Design-time and Post-design Algorithms Against MAC, Lifetime, and RBAC Constraints

Disallowed Usage and Mutual Exclusions Two Main Important Effects

Immediately Expose Security Flaws of the Design in Design by Discovering the Security Violation

Provide a Degree of Security Assurance for the Design Delivery to be Transferred to the Subsequent Phases

Potential Result: Reducing the Cost of Repairing Errors in the Life Cycle

Security-393

CSE 300

Perspective 2: New UML Diagrams for SecurityPerspective 2: New UML Diagrams for Security

Work of Jaime Pavlich-Mariscal, Ph.D. studentWork of Jaime Pavlich-Mariscal, Ph.D. student Security Privileges in UML Extensions Capture Security Privileges in UML Extensions Capture

Security Across the Entire Design for UML ElementsSecurity Across the Entire Design for UML Elements However, this Information is Scattered and Not However, this Information is Scattered and Not

Captured into a Single, Manageable AbstractionCaptured into a Single, Manageable Abstraction To Transition from Design to Development …To Transition from Design to Development …

Role-Slice, User, and Delegation Diagrams are Combined Privilege Perspective Across Design

Separate,Defined, Abstraction that is Created by Using the UML + Security Design and Supports Automatic Generation of Security Enforcement Code Composable Security Definitions to Customize Security

on Application by Application Basis

Security-394

CSE 300

UML Design Tool

Database Server

Designer’s Input

Internal UML

Structures

UML Diagrams

Customer’s Requirements

UML Diagrams

Triggers

Security Constraints Checking Module

(Algorithm)

Perspective 2: New UML Security DiagramsPerspective 2: New UML Security Diagrams

New UMLSecurity

Diagrams

Aspect-OrientedSecurity

Enforcement Code Generation

Java

Security-395

CSE 300

Motivation of Perspective 2Motivation of Perspective 2 Approach Introduces New UML Security DiagramsApproach Introduces New UML Security Diagrams

Preserve Separation of Security Concerns from Modeling through Implementation Provide the Tools to Integrate them at Every Level Allow a Customized Generation of Secure Code on an

Application-by-Application Basis Four Dimensions to Consider:Four Dimensions to Consider:

Visual Notation Benefits and Advantages Traceability of Security Requirements Customizability of Security Model/Policies Correctness of Specification w.r.t. Design

Let’s Explore Each in TurnLet’s Explore Each in Turn

Security-396

CSE 300

Visual NotationVisual Notation MAC, DAC, RBAC do not Provide a Mechanism to MAC, DAC, RBAC do not Provide a Mechanism to

Incorporate them into a Design ModelIncorporate them into a Design Model Designers need a Notation for SecurityDesigners need a Notation for Security

Facilitate Conceptualization of Security Policies Facilitate Changes Reduce Errors

UML Lacks of Support for SecurityUML Lacks of Support for Security Existing Approaches for UML + SecurityExisting Approaches for UML + Security

They do not address all of the Access Control Models

They do not provide a Notation Separated from the Main Design Models

Security-397

CSE 300

TraceabilityTraceability Ability to Identify which Parts of the Design Models Ability to Identify which Parts of the Design Models

and Code Realize each Requirementand Code Realize each Requirement The Better Traceability, the Easier is to Cope with The Better Traceability, the Easier is to Cope with

Changes in RequirementsChanges in Requirements Separation of Concerns is Instrumental to achieve Separation of Concerns is Instrumental to achieve

better Traceabilitybetter Traceability

Security-398

CSE 300

Example of TraceabilityExample of Traceability

Business Rules of University Business Rules of University Courses traceable to:Courses traceable to: Course Class at the

Design Level Course Class

Implementation at the Code Level

When Business Rules When Business Rules Change for Courses, Change for Courses, Designers/Programmers Designers/Programmers know where to perform know where to perform ChangesChanges

Business Rules of Courses

class Course { …}

Re

qu

ire

men

tsD

es

ign

Co

de

Course

Security-399

CSE 300

Security is Hard to ModularizeSecurity is Hard to Modularize Security is Tangled with other RequirementsSecurity is Tangled with other Requirements

E.g. Course must Implement Access Control in Addition to Business Rules

Security is Spread across the Design/CodeSecurity is Spread across the Design/Code Other Classes in the University Application (e.g.

StudentInformation) must also implement Security Therefore, Traceability of Security is PoorTherefore, Traceability of Security is Poor Designers need a Mechanism to preserve Separation of Designers need a Mechanism to preserve Separation of

Security Concerns Security Concerns Requirements Design Models Code

Security-400

CSE 300

CustomizabilityCustomizability Security Policy of the University ApplicationSecurity Policy of the University Application

Groups of Users (i.e. Teachers, Students, Assistants) can be Modeled using Roles A feature from RBAC

Teachers may Need to delegate into Assistants the Task of Assigning Grades A feature from DAC

Security-401

CSE 300

Customizability (cont.)Customizability (cont.) Applications often Need a Subset of Capabilities of Applications often Need a Subset of Capabilities of

Access Control ModelsAccess Control Models Applications may Need Capabilities from more than Applications may Need Capabilities from more than

One Access Control ModelOne Access Control Model Designers need a Mechanism to:Designers need a Mechanism to:

Select Components from Different Access Control Models

Combine them into a Custom Model Add/Remove Components

Security-402

CSE 300

CorrectnessCorrectness The Code that Implements Security must Enforce the The Code that Implements Security must Enforce the

Policy Specified during DesignPolicy Specified during Design To ensure that an Application is Secure:To ensure that an Application is Secure:

The Code must Correctly Implement the Design Models

A Formal Model for Access Control and Implementation is Required to Prove Correctness

Security-403

CSE 300

Overview of the ProcessOverview of the Process

Security-404

CSE 300

Security DiagramsSecurity Diagrams

Secure Subsystem(Subset of

UML Design)

Role-SliceDiagram

Mandatory Access Control

Features

DelegationDiagram

User Diagram

Security-405

CSE 300

Security FeaturesSecurity Features

Role Slice Diagram

Positive Permissions (PP)

Negative Permissions (NP)

Runtime Permissions (RP)

Selection ofFeatures

MAC Features


Simple Security (SS)

Simple Integrity (SI)

Liberal-Star (LS)

Strict-Star-Read (SSR)

User Diagram

User-Role Assignment (URA)

Separation of Duty (SOD)


Delegation Diagram

Delegation Authority (DA)

Pass-On Delegation Authority (PODA)


Composition

Strict-Star-Write (SSW)

Positive Permissions (PP)

Negative Permissions (NP)

User-Delegation Assignment (UDA)

Custom Access Control Model

Role Hierarchy (RH)

Security-406

CSE 300

Mapping to CodeMapping to Code

Custom Access Control Code

Delegation Diagram-------------


-------------

-------------

-------------

Role Slice Diagram-------------


-------------

-------------

-------------

User Diagram-------------


-------------

-------------

-------------

MAC Features-------------


-------------

-------------

-------------

SecurityComponent

Code

SecurityComponent

Code

SecurityComponent

Code

SecurityComponent

Code

Mappingto Code

Composed AccessControl Model

Preservation of Properties

CompositionCode

Composition

Design Implementation

Security-407

CSE 300

University Application ExampleUniversity Application Example Manages Course and Student InformationManages Course and Student Information Users: Teachers, Students, and AssistantsUsers: Teachers, Students, and Assistants

+getCourses()+getGrades()+getName()+setGrades()

StudentInformation

+getTeacher()+getStudents()+getSyllabus()+getCode()+setSyllabus(in syllabus : String)+setCode(in code : String)

Course

+getCoursesOffered()

Catalog

+getCatalog()+getCourse(in code)+getStudentInformation(in id)-createNewSemester()

UniversityApplication

Security-408

CSE 300

Use Cases of University ApplicationUse Cases of University Application

Security-409

CSE 300

Security Requirements of University Appl.Security Requirements of University Appl. Requirement 1:Requirement 1:

Teachers have assigned a set of courses, they can read and write the syllabus, and read the code of each course.

Teachers can see the enrolled students in each course, access their names, and access grades, but cannot see in which courses students are enrolled.

Assistants can perform the same tasks as teachers, except writing the syllabus.

Students can see their grades, enrolled courses, the teachers of those courses, read the syllabus and code, but cannot see students enrolled in those courses, or modify any information in the system.

Any person external to the university can access catalog information. No access control is required for this information.

Security-410

CSE 300

Security Requirements of University Appl.Security Requirements of University Appl. Requirement 2:Requirement 2:

Security administrators must be able to authorize or deny teachers / assistants / students to perform specific tasks in the system.

Requirement 3:Requirement 3: Every teacher/assistant/student must be able to

perform the same tasks when interacting the system.

E.g., if a security administrator authorizes a teacher to access the grades of his/her own students, then every teacher is automatically authorized to access the grades of their own students.

Security-411

CSE 300

State Diagram for University ApplicationState Diagram for University Application

Security-412

CSE 300

Role-Slice DiagramRole-Slice Diagram

Student<<roleSlice>>

«pos» +getTeacher()«pos» +getSyllabus()«pos» +getCode()

Course

«pos» +getCourses()«pos» +getGrades()«pos» +getName()

StudentInformation

Teacher<<roleSlice>>

Assistant<<roleSlice>>

«pos» +getStudents()«pos» +getTeacher()«pos» +getSyllabus()«pos» +getCode()

Course

UnivApplSecureSubsystem<<SecureSubsystem>>

+getTeacher()+getStudents()+getSyllabus()+getCode()+setSyllabus(in syllabus : String)+setCode(in code : String)

Course

+getCourses()+getGrades()+getName()+setGrades()

StudentInformation

«pos» +getCourses()«pos» +getGrades()«pos» +getName()«pos» +setGrades()

StudentInformation

«pos» +getCourses()«pos» +getGrades()«pos» +getName()

StudentInformation

+getCourse(in code)+getStudentInformation(in id)


«pos» +getStudents()«pos» +setSyllabus(in syllabus : String)«pos» +getTeacher()«pos» +getSyllabus()«pos» +getCode()

Course«pos» +getCourse(in code)«pos» +getStudentInformation(in id)


«pos» +getCourse(in code)«pos» +getStudentInformation(in id)


«pos» +getCourse(in code)«pos» +getStudentInformation(in id)


Security-413

CSE 300

User DiagramUser Diagram

How to create the Infrastructure of Security Diagrams?How to create the Infrastructure of Security Diagrams?

«user»Alice

«user»Bob

«user»Carol

«roleAssignment»

«roleAssignment»

«roleAssignment»

«roleSlice»Student

«roleSlice»Teacher

«roleSlice»Assistant

«user»David

«roleAssignment»

Security-414

CSE 300

Methodology for Secure Software DesignMethodology for Secure Software Design

Security-415

CSE 300

Methodology for Secure Software DesignMethodology for Secure Software Design Multiple Steps in the ProcessMultiple Steps in the Process First IterationFirst Iteration

Identify Security Critical Use Cases Define the Secure Subsystem

Refinement and IterationRefinement and Iteration Incorporate a Security Capability in the Model Specify Concrete Policy Elements

Arriving at a “Final” Security DesignArriving at a “Final” Security Design

Security-416

CSE 300

First IterationFirst Iteration

Security-417

CSE 300

Available Security FeaturesAvailable Security Features

Security-418

CSE 300

Available Security FeaturesAvailable Security Features

Security-419

CSE 300

Security Refinement ProcessSecurity Refinement Process

Security-420

CSE 300

Refinement and IterationRefinement and Iteration

Security-421

CSE 300


Security-422

CSE 300


Security-423

CSE 300


Security-424

CSE 300


Security-425

CSE 300

Composable SecurityComposable Security

Security-426

CSE 300

A Second ExampleA Second Example Recall Survey Management Application:Recall Survey Management Application:

A Survey Institution Performs and Manages Public Surveys

The Senior Staff Person Adds a Survey Header Into the Database

Staff Person (Senior or Junior Staff) Adds Questions Into that Survey, Categorize Questions and Adds a New Question Category If Needed

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

Security-427

CSE 300

Survey Management ExampleSurvey Management Example

Security-428

CSE 300


Security-429

CSE 300

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

}_,_{_

__

,_,___

__,__

,__,___

{}},Re__,_,_{

QuestionsGettisticsGeneralStaGetultsSurvey_ResPublic

QuestionSpecialAdd

QuestionAddHeaderSurveyCreateHeaderSurvey

HeaderSurveyDeleteListSurveyUpdate

SearchTitleSurveyHeaderSurveyAddListSurvey

sultsSurveyPublicHeaderSurveyListSurveynapplicatio

Security-430

CSE 300

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

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

Represents those Classes on Which Privileges will be Defined

{}},_,_{ HeaderSurveyListSurveysubs

SecureSubsystem

Security-431

CSE 300

Integration with Doan’s workIntegration with Doan’s work Each Use Case is Associated to a Set of MethodsEach Use Case is Associated to a Set of Methods Secure SubsystemSecure Subsystem

Defined as the Set of All Classes whose Methods are Associated to at Least One Use Case

Secure Subsystem

Secure MethodsSecure Methods

Security-432

CSE 300

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

Class Diagram that Represents Class Diagram that Represents Permissions for the RBAC ModelPermissions for the RBAC Model Roles are Represented as

Packages Permissions are Represented

as Stereotyped Methods Role Hierarchy is Represented

by a Stereotyped Dependency Relation

Security-433

CSE 300

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

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

ProvidesProvides Definition of Secure Subsystem (Include a Class if

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

Class-Method Link <neg> by Disallowed Usage

Secure Subsystem

Security-434

CSE 300

Recall the Transition Recall the Transition

Secure Subsystem

Security-435

CSE 300

Role-Slice PolicyRole-Slice Policy

falseQuestionSpecialAdd

HeaderSurveyCreateHeaderSurveyAddfSeniorStaf

falseListSurveyUpdatefJuniorStaf

trueQuestionAdd

ListSurveyUpdateSearchTitleSurveyStaff

subsStafffSeniorStaf

StafffJuniorStaf

fSeniorStaf

fJuniorStafStaffpolicy

{},,__

,__,__

},__{{},

{},,_

,__,__

,,

,,,

,,

Security-436

CSE 300

Integration with Doan’s WorkIntegration with Doan’s Work Roles and HierarchiesRoles and Hierarchies

Roles

Role Hierarchy Relation

Security-437

CSE 300

Integration with Doan’s workIntegration with Doan’s work PermissionsPermissions

The Set of Use Cases Allowed to an Actor Defines the Methods Allowed to the Corresponding Role

Authorized Methods

Security-438

CSE 300

Composition of Role SlicesComposition of Role Slices To Obtain the Final Set of PermissionsTo Obtain the Final Set of Permissions

Positive Permissions are Inherited by Child Role Slices from their Parents

Negative Permissions are Used to Override Permissions that are Positive in Parent Role Slices

Security-439

CSE 300

Transitioning to CodeTransitioning to Code Preserving Separation of Security Concerns Preserving Separation of Security Concerns

At the Design Level, Security Concerns are separated from the Main Design Security Diagrams Separated from other UML

Diagrams At the Code Level Security is a Crosscutting

Concern, i.e. not Easy to modularize. Using Aspect Oriented Programming (AOP) to solve Using Aspect Oriented Programming (AOP) to solve

this Problemthis Problem

Security-440

CSE 300

Mapping to CodeMapping to Code

Custom Access Control Code

Delegation Diagram-------------


-------------

-------------

-------------

Role Slice Diagram-------------


-------------

-------------

-------------

User Diagram-------------


-------------

-------------

-------------

MAC Features-------------


-------------

-------------

-------------

SecurityComponent

Code

SecurityComponent

Code

SecurityComponent

Code

SecurityComponent

Code

Mappingto Code

Composed AccessControl Model

Preservation of Properties

CompositionCode

Composition

Design Implementation

Security-441

CSE 300

AOP Security Enforcement Code GenerationAOP Security Enforcement Code Generation Code Generator takes a Role Slice Specification as Code Generator takes a Role Slice Specification as

Input and Outputs: Input and Outputs: An Access Control Aspect A Policy Database

AOP + Policy DB Provides Means for Changing AOP + Policy DB Provides Means for Changing Access Control without Recompiling CodeAccess Control without Recompiling Code

Security-442

CSE 300

Aspect-Oriented DefinitionsAspect-Oriented Definitions To Formalize the Mapping, it is Necessary to Define To Formalize the Mapping, it is Necessary to Define

Basic Aspect-oriented ConceptsBasic Aspect-oriented Concepts Definitions are Simplified Formalizes the Ideas in Companion Presentation

A Point Cut is Represented as a Record <caller,callee>A Point Cut is Represented as a Record <caller,callee> caller is a Method where all Invocations of callee

must be Modified to Include the Aspect Code An Advice is a Record <PC,T>An Advice is a Record <PC,T>

PC: a Point Cut T: Rewriting Function that Modifies the Method

Invocations Specified in PC An Aspect is a Set of AdvicesAn Aspect is a Set of Advices

Security-443

CSE 300

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

Slice from the Information of an ActorSlice from the Information of an Actor Defines whether the Role is Abstract or Not Shows the Role Slice Associated to the Selected

Actor

Security-444

CSE 300

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

Security-445

CSE 300

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

Enforcement Code in AspectJEnforcement Code in AspectJ

Security-446

CSE 300

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

AccessControl.java

Security-447

CSE 300

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

Security-448

CSE 300

Composition of Security FeaturesComposition of Security Features

Security-449

CSE 300

Security DiagramsSecurity Diagrams

Security-450

CSE 300

Code GenerationCode Generation

Security-451

CSE 300

Prototyping Effort – Code GeneratorPrototyping Effort – Code Generator Generated CodeGenerated Code

Obtaining the Active User

public aspect AccessControl { pointcut login():call(User SecurityAdmin.logIn(..)); User around():login() { User u = proceed(); activeUser.set(u); return u; } private ThreadLocal activeUser = new ThreadLocal() { protected Object initialValue() {return null;} }; private User getActiveUser() { return (User)activeUser.get(); } ...}

Security-452

CSE 300

Prototyping Effort – Code GeneratorPrototyping Effort – Code Generator Checking PermissionsChecking Permissions

public aspect AccessControl { ... pointcut externalCall() :

(call(* Survey_List.*(..)) ||call(* Survey_Header.*(..))) &&!within(Survey_List) && !within(Survey_Header);

before() : externalCall() { Role r = getActiveUser().getActiveRole(); if (!r.hasPosPermission(thisJoinPointStaticPart)) {

throw new org.aspectj.lang.SoftException( new PermissionDeniedException());

} }}

Security-453

CSE 300

Retrospective on Role Slices + AOPRetrospective on Role Slices + AOP We Presented an Approach to Preserve Separation of We Presented an Approach to Preserve Separation of

Security ConcernsSecurity Concerns Separation of Concerns at the Model LevelSeparation of Concerns at the Model Level

Role-slice Notation Helps in the Conceptualization of a Method-based Security

Policy Facilitates its Evolution During the Design Process.

Separation of Concerns at the Code LevelSeparation of Concerns at the Code Level Mapping from a Role-slice Diagram to AOP

Enforcement Code Provides a Seamless Transition from Security Specification

to Code Isolates Access Control in an Aspect.

Security-454

CSE 300





Document Access


Software Programs

Concluding RemarksConcluding Remarks



Distributed Setting



Mutual Excl.Safety

Liveness

Security-455

CSE 300

Concluding RemarksConcluding Remarks Security is Part of an Overall Security StrategySecurity is Part of an Overall Security Strategy

Definition of Security Requirements Realization of Security at Application Level Integration of Security from User to OS to DB Rigorous Definition of Security Policy Dynamic Nature of Security Privileges Enforcement of Defined Privileges at Application

and DB Levels Overall, Security in Today’s World Integral Part of Overall, Security in Today’s World Integral Part of

Everyday Life - Some Key ConcernsEveryday Life - Some Key Concerns Confidentiality of an Individuals Data Identity Theft Protecting National Infrastructure

Security-1 CSE 300Security Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box.

Documents

security issues

location of security

security approaches

wide range of security

rolebased access control

access portal

patient interfaces web

providers hippa store