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

Security-1 CSE 300Security Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-1155 Storrs, CT 06269-1155 steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818  The majority of these slides represent material that has been accumulated from various sources over the years.  A portion these slides are being used with the permission of Dr. Ling Lui, Associate Professor, College of Computing, Georgia Tech.

Security-2 CSE 300 Patients Providers Clinical Researchers Motivation: Security Issues? Web Server Appl Server DB Server Firewall https Encryption https 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 Patients  HIPPA Overriding Concern  All Patient Interfaces Web-Based  Secure Communication  To/From Web Server (https)  Among Discussion Group Members Is this https or Peer-to-Peer?  Role-Based Access Control to Authorize  Providers to Interact  PHR Data to Individual Providers Patients Providers Clinical Researchers Web-Based Portal(XML + HL7) Open Source XML DB

Security-4 CSE 300 Security Issues for Providers Patients Providers Clinical Researchers EMR  HIPPA Concerns for any EMR Data Transmitted into Portal  Need 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? Web-Based Portal(XML + HL7) Open Source XML DB

Security-5 CSE 300 Security Issues for Clinical Researchers Clinical Researchers PatientsProviders Feedback Repository  Is Role-Based Access Control Needed to Authorized Providers to Portal Features?  Security for Discussion Forums?  Collaborative Interactions Among Providers and Clinical Researchers  Is Security Required?  Collect Results from Providers (HIPPA)  Store in Feedback Repository  Transfer to Permanent Warehouse Web-Based Portal(XML + HL7) Open Source XML DB

Security-6 CSE 300Overview  Explore Wide Range of Security Topics in this and 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 of Security Across Macro-Architecture  Note: All of these Security Approaches Must work with the Security Discussed in Background PPTs

Security-7 CSE 300 Object-Oriented and Programmatic Security in C++/Java Collaborative Portals Look-and-Feel Application Content Document Access Secure Software Design To Design and Write Secure Software Programs Our Five-Pronged Security Emphasis Secure Information Exchange via XML with MAC/RBAC Secure MAC/RBAC Interactions via Middleware in Distributed Setting Assurance Consistency Integrity RBAC, DAC, MAC Separation of Duty Mutual Excl. Safety Liveness

Security-8 CSE 300 Security for Collaborative Web Portals  Collaborative Portals Rapidly Emerging as Means for Communication, Interaction, and Problem Solving over Distances  SourceForge MediaWiki  Microsoft Sharepoint  phpBB  Security 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 Application Level, Document Level (Author/View), and Look-and-Feel of Portal Itself

Security-9 CSE 300 What is a WIKI?  Repository for Information that Accessible to All  Collaborative Platform  Content Contribution/Creation/Modification  Document Authoring  Historical Tracking of Actions  Shared Platform to Facilitate Information Exchange, Joint Efforts, etc.  Runs in Web Environment (Browser) – No Software to Install  Limited 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 WikiPedia

Security-15 CSE 300 MediaWiki from SourceForge

Security-16 CSE 300 A Wiki for Accreditation

Security-17 CSE 300 Creating an Account

Security-18 CSE 300 Viewing the Main Page

Security-19 CSE 300 Uploading Documents

Security-20 CSE 300 Creating and Modifying Content

Security-21 CSE 300 Viewing the Historical Record

Security-22 CSE 300 Customized Searching

Security-23 CSE 300 Uploading Images

Security-24 CSE 300 Problems with MediaWiki and Others  Not Very User Friendly, Particularly for Non- Computer Savvy Population  Difficult to Customize with Specialized Features and Capabilities beyond Basic Look and Feel Changes  Security 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 of Open and Available to All

Security-25 CSE 300 Current R&D on WIKIs  Led by Serebrum (www.serebrum.com) www.serebrum.com  Developing AXON WIKI with Capabilities that 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 AXON

Security-27 CSE 300 A First Snapshot of AXON Infolet – 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 AXON  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 that Different 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 Features  Intended to be Fully Fledged Collaborative Tool  Work Over Distance Full-text search Easy Content Creation Hierarchical topic tree Integrated CMS + DMS History + Audit Trail

Security-30 CSE 300 Editing Topic Documents  For Each Topic,Associated Document can be Created/Edited with Full WYSISYG editor  Other WIKIs Don’t have this Capability  Extending this to Spreadsheet Creation  Word-like Interface for Document Creation and Modification

Security-31 CSE 300 Other AXON Features  This allows Documents to be Assembled  From Topic Down  Combines Docs  Creates New Doc  This is the WIKIBerry Interface  Limited Access  View and Edit Content  Synchs with Server

Security-32 CSE 300  Grayed Boxes (Elicitation Toolkit and Ontology) are Application Dependent/Customizable Architecture Promotes Customizability

Security-33 CSE 300 Security Concepts and Permissions in Axon  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 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  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 Axon  To 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 particular Group  Active Session for a User limits the User to a particular Group  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 Scren

Security-37 CSE 300 Other Important Concepts  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 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:  Patient History, Education Materials, Appointments, etc.

Security-38 CSE 300 Other Important Concepts  The Topic Tree contains three levels of parent, child, 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 Permissions  Basic 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 Group with a Role are Displayed  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 Permissions  Edit/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:  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 Permissions Axon Permissions  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 Permissions  Document 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 Axon  Combination 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 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 Enforcement Built into Axon

Security-44 CSE 300 UML ER Diagram

Security-45 CSE 300 Relational Database Tables for RBAC  Top Level Tables: ProjectInfo AccordionInfo ProjectAccordions  Top Level Tables: ProjectInfo AccordionInfo ProjectAccordions  Master Tables: All Projects, Accordions, and P-A  Topic/Subtopic Tables: Topic SubTopic1 SubTopic2  Topic/Subtopic Tables: Topic SubTopic1 SubTopic2  Master Tables for All Parent, Child, and Grandchild Topics

Security-46 CSE 300 Relational Database Tables for RBAC  Versions: TopicVersion  Versions: TopicVersion  Different Versions of xhtml Page for Each Tree Entry  Attachments: Attachment AttachmentVersion  Attachments: Attachment AttachmentVersion  Various Attachments (Documents –Word, PPT, etc.) Associate with Each Topic + Versions

Security-47 CSE 300 Relational Database Tables for RBAC  Permissions: UserInfo PermissionInfo GroupInfo RoleInfo UserGroupAuthorization UserRoleAuthorization  Permissions: UserInfo PermissionInfo GroupInfo RoleInfo UserGroupAuthorization UserRoleAuthorization  The User, Roles, Groups, and their Permissions

Security-48 CSE 300 Relational Database Tables for RBAC  Authorizing Topics to Users, Groups, and Roles  Authorization – Option A: TopicUserAuth TopicGroupAuth TopicRoleAuth  Authorization – Option A: TopicUserAuth TopicGroupAuth TopicRoleAuth  Authorization – Option B: TopicAuth  Authorization – Option B: TopicAuth

Security-49 CSE 300 Relational Database Tables for RBAC  Wiki Look and Feel Authorization: WikiLookandFeelAuthorization Widget WidgetPrivilegeType  Wiki Look and Feel Authorization: WikiLookandFeelAuthorization Widget WidgetPrivilegeType  Tracking the Different Widgets and their Availability based on Role

Security-50 CSE 300 Sample Table Entries

Security-51 CSE 300 Usage of Axon in Safety.Net  Used by Project Team (PIs, Co-PIs, Providers, etc.)  Repository for Planning Effort  Upload, Create, Review, Modify Documents  Allows Safety.Net Team to Familiarize Themselves with WIKI Technology/Web Portals  No Software to Install  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.Net  Another Alternative – Use AXON Product  Still Web Solution (No Software to Download)  Professional Developers  Customize AXON for Use on Project  Multi-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 Customization  Work Currently Funded

Security-53 CSE 300 Potential Usage of WIKIs in CTSA  Use 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

Security-54 CSE 300 Concluding Remarks: Portal Security  Expand WIKI Security Beyond Coarse Grained  Transition and Generalize to Web Portals  Security for:  Application Level  Document Level  Portal Look-and-Feel  Truly Collaborative and Secure  Other Work  Extending Axon with MAC (Navy SBIR)  Dealing with Delegation, Separation of Duty, etc.  Leveraging the Concepts for Team Project

Security-56 CSE 300 Secure Information Exchange via XML  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 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 Documents  Extend 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 DTDs  Role DTD  User DTD  Constraint DTD Application Application DTDs Application XML Files Appl_Role.xml Appl _User.xml Appl_Constraint.xml Security Officer Generates Security XML files for the Application DTDs and XML User’s Role Determines the Scope of Access to Each XML Document

Security-58 CSE 300 What is an XML Schema?

Security-59 CSE 300 What is an XML Schema?

Security-60 CSE 300 What is an Associated XML Instance?

Security-61 CSE 300 Attaining Security in XML  Given an XML Application of Schemas and Associated Instances, can we:  Define Schemas/Instances for Clearances, Roles, Users, User-Role Authorizations, and Delegation  Augment Application’s Schemas/Instances with MAC Security Classifications (if Needed)  Then, as XML Instances are Dynamically Identified to 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 Delivered Content and not Just Application Look-and-Feel and Usage!  Work is Ongoing at this Point …

Security-63 CSE 300 Motivating Security for OO Paradigm  OO Paradigm Provides Minimal Support via Public Interface and Private Implementation  Public Interface Represents UNION of all Possible Privileges Needed by All Potential Users  A Method in the Public Interface for One Specific User 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?  Many Situations When OT Library Designer (SWE) Could Utilize More Fine-Grained Control to Access of Public Interface  Tradeoff 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?  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?  Collects User Role, User Type, and User Class into User-Role Definition Hierarchies for Application  To Establish Privileges: Assign Different Methods of PIs to Different UCs, UTs, and URs  Defined Security Must be Enforced:  For SWEs - by Supporting Environment  For End-Users - by Application and Its Tools  RBAC Approach Intentionally Obscures Information and Its Access  Consistent with OO Principles on Hiding  Force SWEs to Focus on Abstract Concepts  Incorporate RBAC into OO in a Manner Consistent with OO Principles and Philosophy

Security-67 CSE 300 The Health Care Application - OTs

Security-70 CSE 300 The Health Care Application - RTs

Security-71 CSE 300 User Role Definition Hierarchy (URDH)  Characterize Individual/Group Application Access via Hierarchy in Three Abstraction Levels :  User-Roles (URs) for Fine-Grained Activities  grade-recorder (changes and corrections)  transcript-issuer (fill transcript request)  User-Types (UTs) for Similarities that are Shared Among Set of URs  registrar-staff is common responsibilities (access student records) among URs  User-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 HCA Users UC:Medical_Staff UT:Nurse UT:Physcian UR:Manager UR:Staff_RN UR:Education UR:Discharge_Plng UR:PrivateUR:Attending UC:Support_Staff Etc. UT:Technician UR:Director UR:LabUR:Pharmacy UR:Radiology

Security-73 CSE 300 Privilege Definition Process  Assignment  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)  Prohibition  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?

Security-74 CSE 300 Privilege Acquisition Process  Assignment  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. Privileges  Specialization (UT to URs)  Generalization (URs to UT, UTs to UC)  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 Privileges Node Profiles and Privileges  Profiles Contain Detailed Requirements on the Semantic Contex(n)t for Security Related Aspects of Application  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 HCA

Security-77 CSE 300 Role Security Requirements from HCA

Security-78 CSE 300 Positive Privileges for Nodes  Explicit Access to PPI Methods of OTs  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:  Similar Get Methods  Limited Write: Insert_Med_History

Security-79 CSE 300 Implied Methodology for Assignment  Privileges Associated with URs  Shared Privileges for URs Under Same UT Can be Moved to UT  Shared Privileges for UTs Under Same UC Can be Moved to UC  However, Methods Assigned to:  UC Available to Its UTs/URs  UT Available to Its URs  Observe that:  Commonalities Push Up Tree  Differences Flow Down Tree

Security-80 CSE 300 Two Important Concepts  Methods 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 Concepts  Methods on UC Available to all of its UR  Methods on UR Specific to that Role

Security-81 CSE 300 Prohibited Methods - Negative Privileges  Important To Give Explicitly, Since:  Methods Call Other Methods (MP)  Assigned Methods Map to Larger Set Due to Calls and Inheritance  Staff_RN Prohibited:  Set_Treatment of Visit  Set_Medication of Prescription  Get_All methods from Medical_R  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 Nodes Consistency Criteria Between URDH Nodes  Equivalence - URDH Nodes Must Have Same Capabilities per Assigned/Prohibited Methods  Physical  Respiratory  Respiratory  Occupational  Education  Discharge_Plng  Subsumption - Ordering Among URDH Nodes w.r.t. Capabilities  Staff_RN Discharge_Plng  Manager Staff_RN  Transitive Closure Applies

Security-83 CSE 300 A Complete Node Profile

Security-84 CSE 300 Security Issues for OO Paradigm  MAC/DAC/RBAC - Existing Security Approaches  Must Security for OO Systems Embody an Existing Approach?  Is there a `Better' or `New' Choice to Consider?  Are there Characteristics/Features of OO Paradigm, Systems, and Applications that Should Dictate Approach?  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 Inheritance  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 Public Interface  Hiding: Masks Sensitive Details in Implementation  Inheritance: Controlled Sharing Among OTs Transfers Privileges from Ancestor(s) to Descendant(s)  All Three Embody Security Concepts!

Security-86 CSE 300 What's in an OO Application? What's in an OO Application?  Application Characteristics:  High Volumes of Persistent Data  Varied/Disparate Data  Multiple Individuals/Unique Needs  Distributed: Agencies/Individuals/Systems  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:  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:  Relational Data, Few OTs (10s), Many Instances (1000s)  Control at Instance and Attribute Value Levels

Security-88 CSE 300 Polymorphism, Dispatching, Overloading  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:  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:  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 Claims Object-Oriented Paradigm Claims  Accepted Claims:  Stresses Modularity  Promotes Software Reuse  Facilitates Software Evolution  Difficult-to-Prove Claims:  Controls Data Consistency  Increases Productivity  For OO Security, Reuse and Evolution are Critical!  Both Strongly Linked to Definition and Maintenance of OT/Class Libraries

Security-90 CSE 300 Security Issues and Approaches  Security Defn./Enforcement Consistent with OO Precepts and Principles  Support for Wide-Variety of User-Roles  User Roles - Extensibility/Evolution Critical  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 Mechanism Goals for RBAC Enforcement Mechanism  Extensibility: Application Perspective:  New Classes, Methods, Roles, etc.  Automatic Adjustment by RBAC EM?  Extensibility: RBAC EM Perspective:  New Security Policies/Approaches  Can you go from MAC to DAC?  Flexibility: Application Perspective:  Changes to Roles, Methods, Classes, etc.  How does RBAC EM Adapt?  Flexibility: RBAC EM Perspective:  Change to Security Restrictions/Policy  Reimplementation of RBAC EM?

Security-92 CSE 300 Goals for RBAC Enforcement Mechanism Goals for RBAC Enforcement Mechanism  Hiding & Encapsulation: Application Perspective:  Invisible to Users and Components  Minimize Impact on Actual Software  Hiding & Encapsulation: RBAC EM Perspective:  Representation Independence a Must  Exploit OO Paradigm/Principles  Reusability: Application Perspective:  Reuse of Classes, Methods, Roles  Does RBAC EM Always Need Regeneration?  Reusability: RBAC EM Perspective:  Is RBAC EM Application Specific?  Is there a Generic RBAC EM?

Security-93 CSE 300 Goals for RBAC Enforcement Mechanism Goals for RBAC Enforcement Mechanism  Software 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 Door

Security-94 CSE 300 Quantifying RBAC Approaches  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)  Specify “Subclasses” for Each User Role that Correspond to Each Application Class/OT  Override Prohibited Methods to Return Nulls  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 Approach  Consider HCA Prescription Class:  UR: 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 Approach  Method Implementation:  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 Approach  Consider HCA Prescription Class  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 Approach  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 Approach  Behavior at Runtime: Consider the Call  Type of ptr Determines Which Method is called:  If Staff_RN User Role, the Method  is Called Which Returns Nothing (Overridden) ptr->Set_Prescription_No(); virtual void Set_Prescription_No(...) {return;};

Security-100 CSE 300 User-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 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 Specific  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 Approach  Objectives  Utilize Structure of URDH to Record Privileges  Track all of Methods Assigned to User Roles, User Types, and User Classes  Result  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 URDH Root UsersUC:Medical Staff UT:Nurse UR:Staff RNUR:ManagerUR:Education Turn Off All “Check” Methods at Root Node Turn On Check Methods To Correspond to Assigned Methods Call “Check” Method Prior to Invoking Actual Method

Security-105 CSE 300 URDH Classes  Consider Following URDH Subset:  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 Root class Medical_Staff: public Root class 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 Classes  Introduce “Object” Class to Track Current User and Tie into URDH Class Hierarchy  Note 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 Classes  Focus on Actual Method Implementations  Wrap Check Method Call Around Method Body  Note 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 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:  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 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 Approach  Since Changes aren't Allowed by Unauthorized Individuals the Need to Undo is Eliminated  Extensibility: As new URs are Changed/Added, Only URDH Class Library Must be Recompiled  Hides Security Code Once a User has been Identified  Better Job at Encapsulation of Enforcement Mechanism  Still Difficult to Quantify Entire Mechanism as a Single Unit  Steamlines Application Code  Reusability is Definitely Utilized/Superior

Security-111 CSE 300 Compare/Contrast the Three Approaches  Application Perspective  RBAC Enforcement Mechanism Perspective

Security-112 CSE 300 Advanced RBAC Approaches  Generic Security Classes  Streamline Security Defn. Process  Achieve Uniformity/Promote Reuse  Independent Design/Implementation/Validation  Exception Handling  Hide Security Code with Handlers  Raise Violations when UR Attempts Unauthorized Access  Review Four Approaches  Generic URSA (GURSA)  Basic Exception Approach (BEA)  Generic Exception Approach (GEA)  Advanced Exception Handling  See Papers on Course Web Page…

DSEC--114 CSE300 A Security Model/Enforcement Framework with Assurance for a Distributed Environment C. Phillips, S. Demurjian, and T.C. Ting Computer Science & Engineering Department The University of Connecticut Storrs, Connecticut 06269-3155 Charles.Phillips@usma.edu {steve,ting}@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818

DSEC--115 CSE300Motivation Legacy COTS GOTS Database NETWORK Java Client GOTS Client Legacy Client Database Client COTS Client  Premise: Artifacts - set of  DB, Legacy, COTS, GOTS, Each w/ API  Premise: Users  New and Existing  Utilize Artifact APIs  Distributed Application, DA  Artifacts + Users  Can we Control User Access to Artifact APIs (Methods) by …  Role (who)  Classification (MAC)  Time (when)  Data (what)

DSEC--116 CSE300 Java Client User A Role X Authorize C1, C2 C3, C5 L1, L2 L: Legacy API: Methods L1 L2 L3 C: COTS API: Methods C1 C2 C3 C4 C5 Java Client User B Role Y Authorize C1, C4 L2, L3 Motivation API Access Based on Role/Classification  Can we Control Access Based on Role?  Can we Control Access to Based on Classification? (high T > S > C > U low) Java Client User A Role X Authorize Secret (S) L: Legacy API: Methods T: L1 C: L2 U: L3 C: COTS API: Methods T: C1 S: C2 S: C3 T: C4 C: C5 Java Client User B Role Y Authorize Confidential (C)

DSEC--117 CSE300 Java Client User A Role X Authorize C1: TI a C4: TI b L1: TI c L: Legacy API: Methods L1 L2 L3 C: COTS API: Methods C1 C2 C3 C4 C5 Java Client User B Role Y Authorize C2: TI d L1: TI e Motivation API Access Based on Time/Value  Can we Control Access Based on Time?  Can we Control Access Based on Data Values? Java Client User A Role X Authorize X.C1 (a < 30) X.C4 (d > 40) X.L1 (f = 10) L: Legacy API: Methods L1 (f) L2 (g) L3 (h) C: COTS API: Methods C1 (a) C2 (b) C3 (c) C4 (d) C5 (e) Java Client User B Role Y Authorize Y.C2 (0<b<99) Y. L1 (f = 100)

DSEC--118 CSE300 Overview of Remainder of Talk  Problem Statement  Research Goals and Objectives  Relevance/Importance of Research  Distributed Environment Assumptions  Unified Security Model for RBAC/MAC  Security Enforcement Framework  Security Assurance  Design Time and Run Time Checks  Role Delegation Extensions and Capabilities  Analysis vs. SSE-CMM and Evaluation vs. DCP  Concluding Remarks

DSEC--119 CSE300 Problem Statement - Research Foci Unified RBAC/MAC Security Model Security Policy Definition Run Time Security Assurance Analyses of RBAC/MAC Model/Framework Against SSE-CMM Evaluation of RBAC/MAC Model Using DCP RBAC/MAC Enforcement Framework Security Administrative and Management Tools Design Time Security Assurance

DSEC--120 CSE300 Research Goals and Objectives  Security Model that Unifies RBAC/MAC with  Constraints Based on Method Signature (How), Time (When), and Security Clearances and Classifications  Security Policy and Enforcement Assurance  Design Time (During Security Policy Definition) Security Assurance  Run Time (Executing Application) Security Enforcement  RBAC/MAC Model for a Distributed Setting  Leverage Middleware Capabilities  Flexible, Portable, Platform Independent  Security with Minimal/Controlled Impact

DSEC--121 CSE300 Research Goals and Objectives  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  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 Research  Shrinking Military More Reliant on the Civilian Sector for Operational Support and Internet Usage  Legacy Software Systems  COTS and GOTS  Shared Databases  Flexible Security Policy Realization and Enforcement in Support of Coalition Warfare  Classified and Non-Classified Information  Rapid Deployment and Easy to Use  Platform Independence  Growing Need for Multi-level Security Solutions  Currently Government Systems Avoid MAC  Difficult to Realize and Manage

DSEC--123 CSE300 Distributed Environment Assumptions  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:  Middleware that Provides Means for Software Artifacts (Resource) and Clients to Interact  A Resource is a Software Artifact Accessible via API (e.g., C++, Java, etc.) Consisting of Services  A Service is a Logical Grouping of Public Methods that are Registered with Lookup Service  A Method has a Signature Consisting of a Possible Null Return Type and Zero or More Parameters

DSEC--124 CSE300 Global Command and Control System (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 Software Architecture Wrapped Resource for Legacy Application Wrapped Resource for Database Application Lookup Service General Resource Wrapped Resource for COTS Application Java Client Legacy Client Database Client Software Agent COTS Client Lookup Service Security Authorization Client (SAC) Security Policy Client (SPC) Security Registration Services Unified Security Resource (USR) Security Policy Services Security Delegation Client (SDC) Security Analysis and Tracking (SAT) Security Authorization Services

DSEC--126 CSE300 Security Enforcement Framework  Unified Security Resource Services to:  Manage URs and Privileges  Authorize URs to Us  Identify Users and Track Security Behavior  Associated 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 Definitions Lifetimes Concept

DSEC--128 CSE300 Concept of Containment of Lifetimes

DSEC--129 CSE300 Usage of Lifetimes  Lifetimes are Important Concepts since they Delineate “When” an Action or Usage Can Occur  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 Behavior for Security

DSEC--130 CSE300 Examples of Lifetimes

DSEC--131 CSE300 Related Work: Lifetimes  Leasing [Wald99]  Temporal Constraints [Bert96, Bert01, Ahn00]  DBMS Constraints [Bark01, Nota95]  User Constraints [Sand98, Zurk96]  Similarities 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:  We Utilize 4 Levels of Sensitivity  Approach Will Work for n Levels Unified Security Model Definitions MAC Concept

DSEC--133 CSE300 Unified Security Model Definitions Distributed Application  Definition 3: A Distributed Application, DAPPL, is Composed of a Set of Software/system Resources (e.g., a Legacy, COTS, DB, Etc.), Each Composed of a Set of Services, Which in Turn Are Each Composed of a Set of Methods, Namely:  Uniquely Identifies Each Method

DSEC--134 CSE300 Unified Security Model Definitions Methods  Every Method of Service of Resource Must be Registered from a Security Perspective  Registration of Signature and Security Information  Lifetime of Method (When Available for Use)  Classification of Method (Level of Use)  Definition 4: Every method is registered as:  Default CLS is U  Default LT = [ct,  ]  Resource by Registering Sets CLS and LT

DSEC--135 CSE300 Unified Security Model Definitions Services  Definition 5: Every service is registered as: where  Note that LT and CLS are Inferred from LT and CLS of Methods that Comprise Service

DSEC--136 CSE300 Unified Security Model Definitions Resource  Definition 6: Every resource is registered as: where  Note that LT and CLS are Inferred from LT and CLS of Services that Comprise Resource

DSEC--137 CSE300 Clearances/Classifications Example (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: Clearances/Classifications  Lattice Based Access Control [Sand93]  MAC and RBAC [Nyan95, Osbo97, Osbo00]  DAC with Roles [Sand98]  Orange Book [DoD96]  MAC with Objects [Thur89]  Similarities 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 Definitions User Roles and UR List  Definition 7: A user role, UR, representing a set of responsibilities for an application, is defined as:  Notes  LT and CLS is Set by Security Officer  Defaults are [ct,  ] and U Respectively  Examples: Commander /Joint Planner - Crisis 1 [CDR_CR1, UR LT, T] [JPlannerCR1, [01dec00, 01jun01], S] [CDR_CR1, UR LT, T] [JPlannerCR1, [01dec00, 01jun01], S]  Definition 8: A user-role list,, URL is the set of r unique roles that have been defined for DAPPL.

DSEC--140 CSE300 Unified Security Model Definitions Users and User List  Definition 9: A user, U, who will be accessing the DAPPL via a client application, is defined as:  Notes  LT and CLS is Set by Security Officer  Defaults are [ct,  ] and U Respectively  Example Users: General DoBest: [DoBest, 1 year, T] Colonel DoGood: [DoGood, 6 mo., S]  Definition 10: A user list, UL is the set of u users that have been defined for DAPPL.

DSEC--141 CSE300 Examples: Users, User-Roles, and URA

DSEC--142 CSE300 Related Work: RBAC  Benefits of RBAC  Flexible, Ease of Use, Policy Realization  [Bert97, Demu95, Ferr92, Nyan93, Sand96, Ting87]  Main 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 Signature Constraint  Definition 11: A Signature Constraint, SC, Boolean Expression Defined on the Signature of Method, M ijk of Service S ij of resource R i 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: CrisisPicture (Token, CrisisNum, Grid1, Grid2); SC: Grid1 < NA20 and Grid2 < NC40

DSEC--144 CSE300 Unified Security Model Definitions Time Constraint  Definition 12: A time constraint, TC, is a lifetime that represents when a method can be assigned to a user role (or invoked by a user) or when a user is allowed to play a role. A TC has the default of [ct,  ]. 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: ArmyBattleCommandSys (Token, CrisisNum); TC = [ 10dec00, 16feb01]

DSEC--145 CSE300 Related Work: Signature and Time Constraints  Temporal Constraints [Ahn00, Bert96, Bert01]  User Constraints [Sand98, Zurk96]  Similarities 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 Mandatory Access Control Constraint  Definition 13: A mandatory access control constraint, MACC, is the domination of the 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 Definitions User Role Authorizations  Definition 14: A user-role authorization, URA, signifies a UR authorized to invoke a method under optional TC and/or SC, and is defined as: where  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

DSEC--148 CSE300 Unified Security Model Definitions User Role Authorizations  Definition 15a : UR authorization matrix, URAM, is a matrix indexed by roles and methods: 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

DSEC--149 CSE300 Example Users, User Roles, and URAs ],

DSEC--150 CSE300 Unified Security Model Definitions Remaining Definitions  Definition 15b : A valid user-role authorization list, where  Definition 15b : A valid user-role authorization list, where is the set of all VURAs with URAM(UR,M) = 1.  Definition 16: A user authorization, UA, is a user authorized to play a role: where  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

DSEC--151 CSE300 Unified Security Model Definitions Remaining Definitions  Definition 17a : User authorization matrix, UAM:  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

DSEC--152 CSE300 Example UAM and URAM Matrices User\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1 DoBest 0 0 0 0 1 DoGood 0 0 1 1 0 DoRight 1 0 0 0 0 CanDoRight 0 1 0 0 0 Method\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1 ArmyBattleCommamdSys 1 1 1 1 1 CrisisPicture 1 1 1 1 1 MarineCombatOpnsSys 0 0 1 1 1 LogPlanningTool 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 Unified Security Model Definitions Remaining Definitions  Definition 17b: A valid user authorization list, where is the set of all VUAs with UAM(UR,U) = 1  Definition 18: A client, C, is authorized user U, uniquely identified via a client token C = [U, UR, IP-Address, Client-Creation-Time] where Creation Time is Clock at Creation

DSEC--154 CSE300 Security Enforcement Framework Software Architecture Wrapped Resource for Legacy Application Wrapped Resource for Database Application Lookup Service General Resource Wrapped Resource for COTS Application Java Client Legacy Client Database Client Software Agent COTS Client Lookup Service Security Authorization Client (SAC) Security Policy Client (SPC) Global Clock Resource (GCR) Security Registration Services Unified Security Resource (USR) Security Policy Services Security Authorization Services Security Analysis and Tracking (SAT)

DSEC--155 CSE300 Security Enforcement Framework  Unified Security Resource Services to:  Manage URs and Privileges  Authorize URs to Us  Identify Users and Track Security Behavior  Associated 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 Prototype (JINI and CORBA) Java GUI PDB Client JINI Lookup Service USR All Services Common Resource (Global Clock) CORBA Lookup Service Patient DB Resource (PDB) University DB Resource (UDB) Java GUI UDB Client Security Policy Client Security Authorization Client

DSEC--157 CSE300 Security Enforcement Framework USR Services Security Policy Services Register Service Query Privileges Service User Role Service Constraint Service Grant-Revoke Service Grant_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 Services Authorize Role Service Client Profile Service Security Registration Services Register Client Service Security 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 Policy Services Register Service Register_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 Service Query_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 Service Create_New_Role(UR_Name, UR_Disc, UR_Id); Delete_Role(UR_Id);

DSEC--159 CSE300 Security Enforcement Framework Security Policy Services Constraint Service DefineTC(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 Service Grant_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 Services Register Client Service Create_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 Services Tracking Service: Logfile(Log String) Analysis Service: Analyze (Java Class File) SECURITY REGISTRATION SERVICES Authorize Role Service Grant_Role(UR_Id, User_Id); Revoke_Role(UR_Id, User_Id); Client Profile Service Verify_UR(User_Id, UR_Id); Erase_Client(User_Id); Find_Client(User_Id); Find_All_Clients(); SECURITY AUTHORIZATION SERVICES

DSEC--161 CSE300 Security Enforcement Framework Client, Resource, Service Invocations Security Authorization Services Security Registration Services Lookup Service GCCS Client 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) Security Policy Services GCCS Resource 8 Return Result of IsClient_Registered(…) USR

DSEC--162 CSE300 Security Prototype Global Clock Server/Client Logon

DSEC--163 CSE300 The Security Policy Client  Manages Privileges for Roles and Resources  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:  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 Client Registering a Resource

DSEC--165 CSE300 Security Policy Client Registering a Service

DSEC--166 CSE300 Security Policy Client Registering Methods for Resource

DSEC--167 CSE300 Security Policy Client Registering Methods for Resource

DSEC--168 CSE300 Security Policy Client Adding Methods to Service

DSEC--169 CSE300 Security Policy Client Adding Methods to Service

DSEC--170 CSE300 Security Policy Client Confirmation of Registered Methods

DSEC--171 CSE300 Security Policy Client Tracking Defined Resources

DSEC--172 CSE300 Security Policy Client Creating User Role

DSEC--173 CSE300 Security Policy Client Creating User Role

DSEC--174 CSE300 Security Policy Client Granting Resource to UR

DSEC--175 CSE300 Security Policy Client Granting Service to UR

DSEC--176 CSE300 Security Policy Client Granting Method to UR

DSEC--177 CSE300 Security Policy Client Confirmation of Method to Role

DSEC--178 CSE300 Security Policy Client Reviewing Access of Resources to Roles

DSEC--179 CSE300 Security Policy Client Defining a Signature Constraint

DSEC--180 CSE300 Security Policy Client Defining a Signature Constraint

DSEC--181 CSE300 The Security Authorization Client  Intended for Authorization Capabilities  Main Objectives  Define New User with CLR and LT  Authorize URs to End Users  Define Clients  Authorization 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 Creating a User

DSEC--183 CSE300 Security Authorization Client Granting Roles to User

DSEC--184 CSE300 Security Prototype Tracking Logins and Actions

DSEC--185 CSE300 Security Prototype Tracking Methods of Resources

DSEC--186 CSE300 Security 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  Enumerated and Defined to  Security Assurance is Enumerated and Defined to:  Insure Policy Consistency (A & M Tools)  Check Conditions as Users Access Resources

DSEC--187 CSE300 Assurance Guarantees  Available Time : Maximum Amount of Time Derived from the Intersections of LTs and TCs  Simple Security Property: A Subject Can Read at the Same or Lower Level. (Read Down/No Read Up)  Simple Integrity Property: A Subject Can Write to the Same or Lower Level  Safety: No Bad Things Can Happen During Execution  Liveness: All Good Things Can Happen

DSEC--188 CSE300 Available Time  Available Time Represents “When” Construct is Available for Usage  Comparison of Lifetimes Including  Role  Method  Current Time  Sets a Limit on When an Action can Occur

DSEC--189 CSE300 The Compare Function for Two LTs

DSEC--190 CSE300 Time-Based Guarantees

DSEC--192 CSE300 Lemma 1 Conceptually

DSEC--197 CSE300 MAC-Based Guarantees  Verify the Behavior of Method Invocation  Differentiate 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 MAC-Based Guarantees

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 Guarantees

DSEC--204 CSE300 Security 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:  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 Time Rule I: Authorizing Method to UR

DSEC--206 CSE300  LTs and TCs must be Contrasted Security Assurance - Design Time Rule I Conceptually ct A.LTM.LTTC A.LT M.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 Time Rule II: Authorizing UR to User

DSEC--208 CSE300  LTs and TCs Again Constrained Security Assurance - Design Time Rule II Conceptually ct A.LT X.LT TC A.LT X.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 - Runtime Rule III: Authorizing UR to User

DSEC--210 CSE300  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 - Runtime Rule III Conceptually ct TC 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 - Runtime Rule IV: Invoking a Method

DSEC--212 CSE300 Security Assurance - Runtime Rule IV Conceptually  Same issues as Rule III (Rule I and TC vs. ct)  Additionally, There is a Constraint Checker Defn: CrisisPicture (Token, CrisisNum, Grid1, Grid2); SC: Grid1 < NA20 and Grid2 < NC40 Call: CrisisPicture (123, 111, NA18, NC45); Compare Call Against SC to Determine if Can Invoke

DSEC--213 CSE300 Safety and Liveness Theorems

DSEC--217 CSE300 Related Work 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?   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  Rensselaer at Hartford)  Work of M. Liebrand ( Rensselaer at Hartford)

DSEC--219 CSE300 Why is Role Delegation Important?  Many Different Scenarios Under Which Privileges May 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:  Who Controls Delegation to Whom?  How are Delegation Requirements Enforced?

DSEC--220 CSE300 What Can be Delegated?  Authority to Do the Task, Carries the Least Responsibility Necessary to Execute the Task, but Does Mean the Delegated User Can Execute the Delegated Task or Role.  Responsibility to Do a Task Implies Accountability and a Vested Interest that a Task or Role Can Be Executed Properly.  Duty to Perform a Task Implies that the Delegated User is Obligated to Execute the Given Task.  Our Focus: Delegate Authority Only

DSEC--221 CSE300 Our Focus for Delegation  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 Concepts  Analysis of Role Delegation Capabilities  Investigation of SPC, SAC, and SDC in Support of Delegation  Security Assurance for Delegation

DSEC--222 CSE300 Role Delegation Extensions  Definition 19: A delegatable UR, DUR, is a UR that is eligible for delegation.  Definition 20: The delegatable UR vector, DURV, is defined for all r as:  Delegatable URs (from Slide 33) [CDR_CR1, [01dec00,01dec01], T] [JPlannerCR1, [01dec00, 01jun01], S] [JPlannerCR2, [01jul01, 01sep01], C]  Delegatable URs (from Slide 33) [CDR_CR1, [01dec00,01dec01], T] [JPlannerCR1, [01dec00, 01jun01], S] [JPlannerCR2, [01jul01, 01sep01], C] DURV(A) = 1 for A = CDR_CR1, JPlannerCR1 and JPlannerCR2 DURV(A) = 0 for A = ArmyLogCR1 and ArmyLogCR2

DSEC--223 CSE300 Role Delegation Extensions  Definition 21: An original user, OU  UL, is authorized to the UR such that there exists a VUA for the OU/UR, i.e., UAM(UR,OU) = 1  OU: Authorized to the UR via Regular Process  Implies Not Eligible for Delegation  Definition 22: A delegated user, DU  UL, is a user eligible to be delegated a UR by an OU or a DU (there is not a VUA i.e., UAM(UR,DU)  1).  DU of a UR cannot be an OU for same UR

DSEC--224 CSE300 Examples of OUs DUs Examples of OUs DUs  ArmyLogCR1  DoRight  ArmyLogCR2  CanDoRight  JPlannerCR1  DoGood  JPlannerCR2  DoGood  CRC_CR1  CDR_CR1  ArmyLogCR1  DoBest, DoGood, CanDoRight  ArmyLogCR2  DoBest, DoGood, DoRight  JPlannerCR1/JPlannerCR2  DoBest, DoRight, CanDoRight  CRC_CR1  DoGood, DoRight, CanDoRight

DSEC--225 CSE300 Role Delegation Extensions  Definition 23: User delegation/authorization matrix, UDAM: Represents who is a DU, OU, or Neither  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 = 1

DSEC--226 CSE300 Delegation and Pass on Delegation Authorities  When Establishing Privileges (by the Security 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 Extensions  Definition 24: Delegation authority, DA, is given to the OU to allow delegation of a DUR.  Definition 25: Pass-on delegation authority, PODA, allows an OU (DU) to pass on DA for a DUR to another user (OU or DU).  Definition 26: Delegation authority matrix, DAM: DU has Neither DA Nor PODA DU has Just DA DU has Both DA and PODA

DSEC--228 CSE300 Example of DA and PODA  JPlanner1: DoGood has DA  JPlanner2: DoGood has DA  CDR_CR1: DoBest has both DA and PODA  All Other Entries have Neither DA Nor PODA User\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1 DoBest 0 0 0 0 2 DoGood 0 0 1 1 0 DoRight 0 0 0 0 0 CanDoRight 0 0 0 0 0 Delegation Authority Matrix (DAM): 2 = has DA and PODA, 1 = has DA, 0 = neither

DSEC--229 CSE300 Recall UAM and URAM Matrices User\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1 DoBest 0 0 0 0 1 DoGood 0 0 1 1 0 DoRight 1 0 0 0 0 CanDoRight 0 1 0 0 0 Method\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1 ArmyBattleCommamdSys 1 1 1 1 1 CrisisPicture 1 1 1 1 1 MarineCombatOpnsSys 0 0 1 1 1 LogPlanningTool 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 with DAM and UDAM Matrices User\User-Role ArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1 DoBest 0 0 0 0 2 DoGood 0 0 1 1 0 DoRight 0 0 0 0 0 CanDoRight 0 0 0 0 0 Delegation Authority Matrix (DAM): 2 = has DA and PODA, 1 = has DA, 0 = neither User\User-RoleArmyLogCR1 ArmyLogCR2 JPlannerCR1 JPlannerCR2 CDR_CR1 DoBest 0 0 0 0 1 DoGood 0 0 1 1 0 DoRight 1 0 0 0 0 CanDoRight 0 1 0 0 0 User Delegation/Authorization Matrix (UDAM): 2 = U is a DU, 1 = U is a OU, and 0 = not authorized

DSEC--231 CSE300 Example - 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: Yes PODA: Yes   After Delegation: DU: [DoGood, [01dec00, 01jun01], T] UA: [DoGood, CDR_CR1, [01dec00, 01jun01]]

DSEC--232 CSE300 Example - Role Delegation  Now, Colonel DoGood wishes to re-delegate CDR_CR1 to Major CanDoRight, which can be defined as:  Now, Colonel DoGood wishes to re-delegate CDR_CR1 to Major CanDoRight, which can be defined as: DU: [DoGood, [01dec00, 01jun01], T] UR: [CDR_CR1, [01dec00, 01dec01], T] UA: [DoGood, CDR_CR1, [01dec00, 01jun01]] DA: Yes PODA: No   After Delegation: DU: [CanDoRight, [01jan01, 01feb01], T] UA: [CanDoRight, CDR_CR1, [01dec00, 01jun01]]

DSEC--233 CSE300 Related Work: Role Delegation  Role Administration [Awis97]  Delegation with RBAC [Bark00, Na00]  Delegation Principals [Zhang01]  Similarities 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 and Role Delegation Revocation Rules  User-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 and Role Delegation Revocation Rules  Delegation 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 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 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 Delegation Monotonicity   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 Delegation Permanence  Definition: Permanence Refers to Delegation in Terms 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 Delegation Totality  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 Delegation Administration  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 Delegation Levels 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 Delegation Multiple 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 Delegation Agreements  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 Delegation Cascading 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 Delegation Grant 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 Security Management Tools  Examine the Process of Delegation  Utilize the Military Application  Explore  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 Administration  Screen Bit Maps are Ordered to Illustrate a Process

DSEC--247 CSE300 Security Policy Client Registration of Resources

DSEC--248 CSE300 Security Policy Client Creation of Administration Role

DSEC--249 CSE300 Security Authorization Client Granting of Role(s) to User(s)

DSEC--250 CSE300 Security Policy Client Cdr. Crisis 1 Role/Conflicting Role List

DSEC--251 CSE300 Security Policy Client Granting of Resource(s) to Role(s)

DSEC--252 CSE300 Security Policy Client Granting of Service (s) to Role(s)

DSEC--253 CSE300 Security Policy Client Granting of Methods(s) to Role(s)

DSEC--254 CSE300 Security Policy Client Query Privileges

DSEC--255 CSE300 Security Authorization Client Create a User

DSEC--256 CSE300 Security Authorization Client Create a User

DSEC--257 CSE300 Security Authorization Client Granting a Role

DSEC--258 CSE300 Security Authorization Client Granting a Role with DA/PODA

DSEC--259 CSE300 Security Authorization Client Granting a Role with DA/PODA

DSEC--260 CSE300 Security Authorization Client Query Privileges

DSEC--261 CSE300 Security Authorization Client Query Privileges - Results

DSEC--262 CSE300 The Security Delegation Client

DSEC--263 CSE300 Security Delegation Client Log on to the Security Delegation Client

DSEC--264 CSE300 Security Delegation Client Attempt to Perform a Delegation

DSEC--265 CSE300 Security Delegation Client Attempt to Perform a Delegation

DSEC--266 CSE300 Security Delegation Client Query a User’s Role

DSEC--267 CSE300 Security Delegation Client Revocation of Delegation

DSEC--268 CSE300 Security Delegation Client Revocation of Delegation

DSEC--269 CSE300 Security Delegation Client Denying Log in if UR not Available

DSEC--270 CSE300 Security Delegation Client Denying Delegation if MAC Violated

DSEC--271 CSE300 Security Delegation Client Denying Delegation if TC Violated

DSEC--272 CSE300 Security Delegation Client Denying Delegation if no Delegatable Roles

DSEC--273 CSE300 Security Delegation Client Pass on Delegation Restriction

DSEC--274 CSE300 Security Delegation Client Example 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 Client Delegation Matrix within SDC Dobest(T): ArmyLogCR1(c) Chip(T): ArmyLogCR1(c) Dogood(S): ArmyLogCR1 ( C) Doright(c ): ArmyLogCR1 ( C) When Original user revoke This role, the role matrix is revoked within SDC

DSEC--276 CSE300 Security Delegation Client Example Dobest delegate a role to dogood Dogood delegate this role to other users

DSEC--277 CSE300 Security Delegation Client Example 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 for Delegation  Design 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 SDC

DSEC--279 CSE300 Run Time Security Assurance for Delegation  Executed 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 as 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 time Rule V: Assigning Delegation Authority

DSEC--281 CSE300 Theorem 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 time Rule 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 time Rule 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 time Rule VIII: Delegation of DA/PODA

DSEC--285 CSE300 Theorem VI, VII, and VIII

DSEC--286 CSE300 Assessment of RBAC/MAC Model/Framework  Intent is to Assess the Capabilities of RBAC/MAC Model and Security Framework  Analysis 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)  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 What is SSE-CMM?  An ISO Standard Model For Capturing the Essential Characteristics of an Organization’s Security Engineering Process  The Model is a Standard for Security Engineering 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 Why was SSE-CMM Developed?  Objective:  Advance Security Engineering As a Defined, Mature, and Measurable Discipline  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 SSE-CMM Engineering Process Areas  Administer Security Controls  Assess Impact  Assess Security Risk  Assess Threat  Assess Vulnerability  Build Assurance Argument  Coordinate Security  Monitor Security Posture  Provide Security Input  Specify Security Needs  Verify and Validate Security

DSEC--290 CSE300 10/24/96 Domain Process Areas Base Practices Base Practices Process Areas Base Practices Base Practices Analysis vs. SSE-CMM SSE-CMM Model Architecture Process Areas Organization Project Security Engineering Process Areas Domain  Compare and Contrast RBAC/MAC Model and Framework w/Standard  SSE-CMM: 11 Process Areas/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 Progress

DSEC--291 CSE300 Evaluation vs. DCP What is DCP? Marine Corps NavyAir Force Army GCCS FADD AFATDS GCCS-A MCS ASAS CSSCS Other ABCS Battle Management System Joint Command System Army Battle Command System Combat Operations System U.N. U.S.A NGO/ PVO NATO Dynamic Coalition U.S. Global C2 Systems Army 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. DCP Suitability of Our Approach for DCP  Detailed 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 Time

DSEC--293 CSE300 Summary: 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: Additional Contributions  Working Prototype that can Administer Multiple Security Policies Against Multiple Resources in a Distributed Environment Supporting JINI/CORBA  A Well Defined Security Model which Supports Security Policy Definition via Administrative and 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 Research  Security 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 Assurance  Detailing all Design and Run Time Checks  Defining Security Assurance for Fine Grained MAC and User Constraints  Completion of Analysis/Evaluation:  Model/Framework vs. CMU Security Model  Evaluation of Utility in Support of DCP

DSEC--296 CSE300 Summary: 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 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-299 CSE 300 Security Analysis/Design for UML Thuong Doan, Jaime Pavlich-Mariscal, Steven A. Demurjian, Laurent D. Michel Computer Science & Engineering Department 371 Fairfield Road, Box U-2155 The University of Connecticut Storrs, Connecticut 06269-2155 http://www.engr.uconn.edu/~steve thuongdoan@yahoo.com jaime.pavlich@uconn.edu steve@cse.uconn.edu ldm@cse.uconn.edu

Security-300 CSE 300 Motivation: Importance of Security  Software Engineering  Phases of Requirements, Design, Implementation, Testing, Maintenance.  Effort: E.g., 60% for Requirement & Design, 15% Implementation, and 25% Testing [Boehm 87]  Software Applications with Security Concerns  When is Security Incorporated into Software Development?  Traditional: Deferred to Latter Stages of the Lifecycle Problem: Error-Prone, Difficult to Verify, Costly  Microsoft Report: >50% Security Problems are Design Flaws [McGraw 03]  Return on Security Investment (ROSI): 21% if Integrating at Design; 15% Implementation;12% Testing [Hoo 01]

Security-301 CSE 300 Motivation: Importance of Security  Incorporating 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 300Objectives  Span from Requirements/Design to Development of the Software Process, its Models, and Tools  Integrated:  Rigid Methodology to Express Security Concerns  Seamlessly Capture Security Requirements at Design  Assured:  Specific Means to Verify Security Concerns  Easy-To-Use:  Intuitive Solution Facilitates Inclusion of Security for Different Stakeholders  Transition: Requirements - Design – Development  Security Code Generation (Authorizations)  Run-time Authentication

Security-303 CSE 300 Two Complementary Perspectives  Extend 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 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  Security Features from Design to Development  Extend UML to Support MAC, DAC, and RBAC  Security Properties (Simple Security, Strict *, etc.) plus Constraint Checking (Mutual Exclusion)  New UML Diagrams Collect Security Design into a Logical, Well-Organized Abstractions  Automatic Generation of Security Enforcement Code Integrated with Application  Maintain Security Information in Database  Track Design and Security State  Provide Single Locale for Security Definitions (Users, Roles, and their Authorized Privileges)  Serve as a Means to Support Run-Time Authentication

Security-305 CSE 300 Detailed Objectives  Track Design State that Contains All Actions Related to Security and Application Definition  Employ Functional Notation that Tracks All Actions and Maintains Historical Record  Support Security Consistency and Assurance by  Security Checks as Design is Created/Change  Overall Security Analysis of Entire Design  Security Abstraction that Collects Security Definitions  Cohesive and Coherent UML Diagram  Generated from Security Definitions  Security Enforcement Code Generation  Aspect-Oriented Programming Approach  Security Code Integrated with Application Code

Security-306 CSE 300 Overview of the Process Non-Security Requirements Specification Security Requirements Specification R1Rn … Main Application Design Model Security Model … Main Application Code Security Code … Requirements Analysis Design Implementation Access Control Requirements Security Features Security Component Code SF1SFn SC1SCn Iterative Process

Security-307 CSE 300 Overview of Remainder of Talk  Perspective 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 Security  Role Slice, User, and Delegation Diagrams  MAC Security Features  Composable Security  Aspect Oriented Code Generation  Prototyping Effort  Conclusions and Ongoing Research

Security-308 CSE 300 Extending UML for the Design and Definition of Security Requirements Address Security in Use-Case Diagrams, Class Diagrams, Sequence Diagrams, etc. Formal Security Policy Definition that Track Design State via a Functional Representation Iterate, Revise Bi-Directional Translation – From Security Definitions (Extensions) to Underlying formal Functional Model Security Model Generation RBAC99 GMU/ NIST RBAC/MAC UConn (Distributed Security) Oracle Security Must Prove Generation Captures all Security Requirements Perspective 1: Extending UML Diagrams Many Alternative Security Model Solutions New UML Diagrams and AOP Security Enforcement

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 Diagrams New UML Security Diagrams Aspect-Oriented Security Enforcement Code Generation Java

Security-310 CSE 300 Principles of Secure Design  Principle 1  The Software Design has Multiple Iterative Periods  Security Features Should be Incorporated and Adjusted During Each of and Among Those Periods  Principle 2  T  The Security Assurance is Satisfied Relatively to the Period of Software Design  Principle 3  The Security Incorporating Process Should Neither Counter the Intuition Nor Decrease the Productivity of the Stakeholders  Principle 4  Security Definition via a Unified Perspective that Collects Privileges into a Cohesive Abstraction

Security-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:  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  The Software Design Has Multiple Iterative Phases and The Security Features Should Be Incorporated and Adjusted During Each of and Among Those Phases

Security-312 CSE 300 Principle 2  The Security Assurance is Satisfied Relatively to the Period of Software Design  Security Assurance Evaluated Against the Respective Software Design Phase To Enforce the Security Assurance Rules (SARs)  The Granularity Level of SAR Checks Is Dependent on the Level of Detail in the Software Design Phase  Example:  Tiers 1 & 2: Use Case Diagrams, Class Diagrams  Check the Security Levels of Use Cases, Actors, and Classes  Tier 3: Sequence Diagrams  Check the Security Levels of Methods

Security-313 CSE 300 Principle 3  The Security Incorporating Process Should Neither Counter the Intuition nor Decrease the Productivity of the Software Designer.  Our Perspective:  (e i, e j.behavior jk ): Whether Element e i Can Employ Some Behavior behavior jk of Element e j  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 3  The Security Incorporating Process Should Neither Counter the Intuition nor Decrease the Productivity of the Software Designer  Security Consideration in UML: “Who Can Exercise Which Behaviors of the Application (Use Cases) and Class Behaviors (Methods)?”  Example: The System has Two Usage Modes:  Design-Time: Real-Time Check  Drag – Check – “Drop/Pop”: Realization of the Intended Design Element or Pop Up Error Message Depending on the Security Checking Result  Post-Design: On-Demand Check  Security Compiler Executed on a Whole Design

Security-315 CSE 300 Principle 3  The Security Incorporating Process Should Neither Counter the Intuition nor Decrease the Productivity of the Software Designer.  MAC: (Subject, Operation, Object): Operation = Read|Write|Call Object = A Piece of Atomic Information With Only One Assigned Security Classification  Object-Oriented: Operation = (Read*Write*Call*)* (as Method) Object = An Instance of Class with Many Attributes

Security-316 CSE 300 Principle 4  Security Definition via a Unified Perspective that Collects Privileges into a Cohesive Abstraction  Our Perspective:  Security as Supported via Principles 1, 2, and 3, Spreads Requirements Across Multiple Diagrams  As a Result, Security is “Tangled” and “Scattered” Across Design  Propose a “Role-Slice Diagram” that Collects Definitions into a Central Location  Allows Stakeholders to See the “Big Picture”  Provides Basis for Security Enforcement Code Generation

Security-317 CSE 300 Extending UML for Secure Design  Work of Thuong Doan, Ph.D. student  Defining a Framework for Assurance in Secure Software Design with UML  Capable of Capturing All of the Critical Security Requirements  Aligning Roles with Actors in Use-Case Diagram  Adding Security Properties and Constraints Checking  MAC, RBAC, and Lifetimes to Use-Case, Class, and Sequence Diagrams  Simultaneously Tracking All of the States of a Design from a Security Perspective  Maintaining the Security Assurance as Requirements/Designs are Defined and Changed

Security-318 CSE 300 Extending UML for Secure Design  Extend “Most Utilized” UML Diagrams  Use Cases  Class  Sequence Diagram  Security Extensions for Privileges and Authorization  MAC – Assignment of Security Levels to UML Entities (Use Cases, Actors, Class, Methods, etc.)  RBAC – Alignment of “Actor” with “Role”  Lifetimes –Element or Association (ISA, include, extend, etc.) Availability w.r.t. Security  Real-Time Security Analysis  Maintain Design State  As Connections are Made, Check Security Privileges for their Consistency/Correctness

Security-319 CSE 300 Extending UML for Secure Design UML + Security Extensions Captured in Design State Functional Model Design Action  Design Time Checked in Security Constraints Checker  Assumptions  Utilizing UML  Security Specifications  Communicating with the Customer

Security-320 CSE 300 Use-Case UML Extensions  Security Levels  (TS, S, C, U) are Associated with Each Element (Use Case and Actor)  Levels are the Security Sensitivity for the Element  Lifetimes  A Lifetime Represents the Availability of an Element with respect to Security Usage  Start and End Date/Time  End Date can be Infinite (no end)  Connections  As Use Cases are Connected and Actors are Connected – Levels and Lifetimes are Checked  Consistency of Connections Checked  First – Let’s Consider Extensions Informally …

Security-321 CSE 300 Survey Management Example  A Survey Institution Performs and Manages Public Surveys  The Senior Staff Person Adds a Survey Header Into the Database  Staff Person (Senior or Junior Staff) Adds Questions Into that Survey, Categorize Questions and Adds a New Question Category If Needed  Some Special Questions that have More Sensitive Content - Only Senior Staff Allowed to Process

Security-322 CSE 300 Use Case Diagram in UML  A Survey Institution Manages Public Surveys  Use Case Diagram for Creating a New Survey Entry

Security-323 CSE 300 Use Case Diagram with Security Levels  Taking Security Concern  MAC: Security Level (e.g. U<C<S<TS) Assigned for Elements (Use Cases and Actors) Valid Connection: Actor with Confidential Level can Utilize Use Case with Confidential Level

Security-324 CSE 300 UML Use Case Diagram with Security Levels  Taking Security Concern  MAC: Security Level (e.g. U<C<S<TS) Assigned for Elements Invalid Connection: Actor with Confidential Level cannot Utilize Use Case with Secret Level

Security-325 CSE 300 Extensions for Security + Lifetime  Actor Senior Staff is Represented as (“Senior Staff”, A, [“01/01/2005”,“12/31/2006”], S, S)  Min = Max for Actors

Security-326 CSE 300 Extensions for Security + Lifetime  Use Case Add Survey Header is Represented As  Use Case Add Survey Header is Represented As (“Add Survey Header”, UC, [“01/01/2005”, “12/31/2006”], S, S)  Min = Max for Use Cases Security Property of Use Case Add Survey Header

Security-327 CSE 300 UML Class Diagram  Security Levels  (TS, S, C, U) are Associated with Each Element (Class and Method)  Classes have Minimum and Maximum Levels  Lifetimes  Classes and Methods have Start/End Date/Time  End Date can be Infinite (no end)  Containment/Connections  All Methods of a Class Must have Security Level Between its Class’ Minimum and Maximum  As Classes are Connected – Levels and Lifetimes are Checked  Consistency of Connections Checked  First – Let’s Consider Extensions Informally …

Security-328 CSE 300 Survey Management Class Diagram

Security-329 CSE 300 Extensions for Security + Lifetime  Min = Max for Methods Security Property of Class Survey_List Security Property of Method Add_Survey_Header

Security-330 CSE 300 UML Use-Case Connections  Relationships Track Dependencies Across Designs  Two Groups of UML Connection Kinds  Group 1 – Explicitly in UML  Use Case/Actor (Role)/Class Inheritance: Child Inherits (Specializes) Parent  Use Case Inclusion/Extension: >  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 Connections  Use Case or Actor (Role) Inheritance: Child Inherits (Specializes) Parent  Child at Level or More Secure than Parent  Use Case Inclusion/Extension: >  X Includes Y: Y at Level or Less Secure than X  X Extends Y: X at Level or Less Secure than Y  Actor-Use Case Association:  Actor A Interacts with UC X  A at Level or More Secure than X  Connections Cause Detailed Checks  Not only Source and Destination of Connection  Also Must Check Related UCs and/or Actors

Security-332 CSE 300 Use Case Group 1 Connections  All Associations (Connections) Must Satisfy MAC Constraints on Prior Slide  Intent – Keep Design in Correct/Consistent State

Security-333 CSE 300 Group 2 Connections  Secure Design with UML Requires the Ability to Establish Associations Between  UML Use Case Diagrams are Relatively Independent  In Sequence Diagrams, Actor and UC Can Interact with Classes (and Methods) – Not Required  Group 2 Connections Provide Ability to Track  Classes and Methods Utilized to Implement a UC

Security-334 CSE 300 Group 2 Connections: UC to Classes  Use Case-Class Utilization: uc Utilizes c  UC Add Survey Header Utilize Survey_List, Survey_Hdr_Add_Pg, and Survey_Header Classes  Means UC Add Survey Header Will Utilize Portions of those Classes for its Implementation  Again – Consistency Checks From UC to Classes

Security-336 CSE 300 Group 2 Connections: UC to Methods  Use Case-Method Utilizing: uc Directly Utilizes m  UC Add Survey Header Utilizes Methods  onSubmit of Class Survey_Hdr_Add_Pg  Create_Survey_Header of Class Survey_Header  Add_Survey_Header, Survey_Title_Search, and Update_Survey_List of Class Survey_Header

Security-337 CSE 300 Tracking Design and Security State  Previous Slides Illustrate the Ability to Maintain a Correct “Security” State as Design Created/Changed  Objective Now is to:  Define Design Security State  Formalize Prior Definitions of Security Level, Lifetime, UML Element, UML Connection  Introduce Security Constraint Hierarchy and Checking  Define Application’s Security Requirement  Formalize Constraint Checking w.r.t.  Disallowed Usage (Negative Permissions)  Mutual Exclusion (Excluding Actions by UML Elements within Time Periods)

Security-338 CSE 300 One Can Consider the Design State As a Set of Design Elements Design State Space  How 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 Space  Use Functional Model and Track Design Instances  State is a Function Design Element ID State Function  i Design Time ii Design Element Contents Error Status  Action is a (Meta)Function on States Design Action   ii  i+1

Security-340 CSE 300 Security Model for UML Design  Extending UML with Security Features (MAC, RBAC and Lifetime)  Def. 3.2.1 (Security Level Set)  The Security Level Set (  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 Security  Augmenting UML Elements with Security Levels (SLs) and Lifetimes (LTs)  Formal Definition:  Def. 3.2.4 (UML Element)   =  ID  EK  I  SL  SL : the Set of UML Elements  A UML element  : a Tuple (id, k, lt, sl min, sl max )   where id, k, lt, sl min, and sl max are its Element Identification, Element Kind, Lifetime, Minimum and Maximum Security Levels (Denoted as .id, .k, .lt, .sl min and .sl max )  For a Class c: c.sl min  c.sl max ; Other Non-Class Element: e.sl min  e.sl max = e.sl Example: Example: (“Senior Staff”, A, [“01/01/2005”, “12/31/2006”], S, S)

Security-342 CSE 300 Extended UML Connections with Security  UML Connections Have Lifetimes  Formal Definition:  Def. 3.2.6 (UML Connection)   =  ID  CK  I  ID  ID : the Set of UML Connections  A Connection  : a Tuple (id, k, lt, id s, id t )   where id, k, lt, id s and id t 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 .id s and .id t )  Example:  (“  ”, AU_Asc, [“01/01/2005”, “12/31/2005”], “Senior Staff ”, “Add Survey Header ”)

Security-343 CSE 300 Security Constraint MAC Constraint RBAC Constraint Lifetime Constraint  Security as “Enforcing a Policy that Describes Rules for Accessing Resources.” (Viega and McGraw 2002)  Considering Three Types of Security Constraint  MAC: Checking the Domination of Security Levels of Connected Elements  Lifetime: Checking the Temporal Window of Activity for Entities and Users.  RBAC: Maintaining the Interest Conflict-Free Working Environment for User Roles

Security-344 CSE 300 Application’s Security Requirements  Application’s Security Requirements have Lifetimes  Formal Definition:  Def. 3.2.7 (Security Requirement for RBAC)   i =  ID  SR  I  (  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   2   3,  SR = {DisU, ME SRO, ME SOR }  DisU: Disallowed Usage (Negative Permission)  ME SRO and ME SOR : Mutual Exclusions

Security-345 CSE 300 Application’s Security Requirements  Disallowed 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 Requirements  Static Role-Objects Mutual Exclusion - ME SRO  (id, ME SRO, lt,  1,  2,  3 )  3 : Actor  1 is Not Allowed to Use Both Elements  2 and  3 During lt  E.g. (“SR2”, ME SRO, [“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 Requirements  Static Object-Roles Mutual Exclusion - ME SOR  (id, ME SOR, lt,  1,  2,  3 )   3 : Actors  1 and   are Not Allowed to Use Element  3 At the Same Time During lt  E.g. (“SR3”, ME SOR, [“01/01/2005”, “12/31/2006”], “Supervisor ”, “Editor”, “Activate/Deactivate Survey”) 

Security-348 CSE 300 Together Architect Plug-In The Interface to Enter a Security Requirement Enter the Static Role-Objects Mutual Exclusion that the Junior Staff Cannot Use Both “Add Question” and “Approve Question” Use Cases from 01/01/2005 to 12/31/2006.

Security-349 CSE 300 Together Architect Plug-In The List of Security Requirements The Interface Allows to Add a New Security Requirement, Edit/Remove a Current Security Requirements, and Generate the Set of Current Security Requirements in Specified Formats.

Security-350 CSE 300 Complete Security Constraint Taxonomy Security Constraint MAC Constraint RBAC Constraint 2-element Constraint 3-element Constraint Disallowed Usage Mutual Exclusion Static Role-Objects ME Static Object-Roles ME Lifetime Constraint n-element Constraint

Security-351 CSE 300 Design State and Transitioning  State Function Provides the Transition from One Design State to Next When Given Design Action  Adding/Deleting/Modifying a UML Element  Adding/Deleting/Modifying a UML Connection  Three Aspects of Design State Space  UML Elements  Application’s Security Requirements  UML Connections  State Functions Triggered on Insertion, Deletion, etc.

Security-352 CSE 300 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  i+1 Insert/Update/ Delete

Security-353 CSE 300 State Functions  Extended Sets:   = {  }  ,   = {  }  , and   = {  }   where  is the null Element  Err ={0, 1, 2,…}: Set of Error Numbers with “0” As an Initial Value (for Initial State) and “1” As No Error  Def. 3.3.1 (State Function Signatures)  For UML Elements:   :  ID  T     Err  For UML Connections:   :  ID  T     Err  For Security Requirements:   :  ID  T     Err UML Element ID Design Time ii UML Element Contents Error Status  Design State i: (   i,   i,   i )       

Security-354 CSE 300 Inserting a UML Element  Status Function for UML Elements  the Status of a UML Element  Based on the Current Set of Designed UML Elements L at the Design Time   Def. 3.4.3 (Status Function for UML Element Space): stat  : 2   ID  T     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 ID Design Time stat  UML Element Contents Error Status Current UML Element Set

Security-355 CSE 300 Inserting a UML Element  intra_chk  Function for the Intra-element Check on the Properties (Lifetime and Security Levels) of an UML Element at a Specific Time  Def. 3.4.2 (Intra-Element Checking for a UML Element) intra_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 .sl min  .sl max 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 .sl min == .sl max 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 Functions  Remember:  Design State Function Signature For UML Elements:   :  ID  T     Err UML Element ID Design Time ii UML Element Contents Error Status UML Element ID Design Time stat  UML Element Contents Error Status Current UML Element Set  Status Function for UML Element Space: stat  : 2   ID  T     Err  Cast the Form of   i Function as   i = (stat  L  i )    L  i (=   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 Element  Function 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  Example: Design From Scratch (From State 0)  Add Use-Case uc1: Add Survey Header, min SL = max SL = “S”, and LT = [“01/01/05”, “12/31/06”]  State 0: (   0,   0,   0 ) = (( , 0), ( , 0), ( , 0))  State 1:   1  stat  (insert uc 1   0.set) = stat  (insert uc 1  ) = 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 Connections  Status of a UML Element  Based on the UML Element State   and the Current Set of Designed UML Connections L at the Design Time   Def. 3.4.6 (Status Function for UML Connection Space): stat  :    2   ID  T     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 Action  Function 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 Requirement  Def. 3.4.7 (The Insert Action on SR Space): Ins  :    Ins   i e =  i+1 where   i+1 =   i,   i+1 =   i, and   i+1 = stat    i+1 (insert e   i.set)  Deletion and Update of UML Elements Also Require Analogous 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 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  Tiers Represent a Typical Design Process with UML  Not Only Process – but One Scenario  Objective is to Understand Placement of Security in the Process – Particularly w.r.t. Assurance

Security-361 CSE 300 Security Constraints Checking  Three Security/Software Design Tiers for the UML  Tier 1: Use-Case Diagrams  Tier 2: Classes  Use-Cases  Tier 3: Sequence Diagrams  Intra-Checks Occur within Individual UML Elements  Inter-Checks for MAC/RBAC/Lifetime Constraints  Cstr MAC :  T  Boolean  Cstr RBAC :  T  Boolean  Cstr LT :  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 Checking  Inter-Element Check for MAC (Simple Sec/Integrity)  The MAC Constraint Cstr MAC (  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 Checking Enforcing MAC Constraint – Error Case Actor Staff with “C” Cannot Utilize Add Survey Header with “S”

Security-364 CSE 300 Security Constraints Checking  Inter-Element Check for MAC  Use Case-Class Utilization: uc Utilizes c  The Security Level of Use Case uc Dominates the Minimum Security Level of Class c: uc.sl  c.sl min

Security-365 CSE 300 Security Constraints Checking  Inter-Element Check for MAC  Class-Method Defining: c Defines m  The Security Level of Method m is Between the Minimum and Maximum Security Levels of Class c: c.sl max  m.sl  c.sl min  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 Security Constraints Checking  Inter-Element Check for Lifetime  The Lifetime Constraint Cstr LT (  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 RBAC  The RBAC Constraint Cstr RBAC (  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, ME SRO, 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, ME SOR, lt,  1,  2,  3 )  3 : Element  3 is NOT in the Intersection of two Path Coverages from Actor  1 and Actos  2 During lt Security Constraints Checking 11 22  11 22 33  11 22 33 

Security-368 CSE 300 Towards Security Assurance  When is Design Acceptable with Respect to Security?  Define Security Compliance Properties  Represents Constraints that Must Hold as Design is Created and Modified  Does the Design have Expected Security Properties?  Security Conformity Support Program  Design-Time and Post-Design Modes  Goal:  Each Design Element is Legitimate to Use via Intra-Checks  All Application's Security Requirements Hold via Inter-Checks at a Design Time t

Security-369 CSE 300 Towards Security Assurance  Design-Time Checking  As Discussed so Far, Security Checks Occur as Design is Created and Modified  However – Design Can be Too Complicated to Develop without Constant Nagging Error  In Use Case – Perhaps any Remaining Connections will Cause Errors  However – Designer May Intend to Make Changes to Remove Problems in Later Design Iterations  Need the Ability to Turn off Design-Time Checking  Result: Require Checking of Design Iterations

Security-370 CSE 300 Towards Security Assurance  Post-Design Checking  Turn off Design-Time Security Checking  Initiated by Security Designer  Allows Design to be in an Inconsistent State w.r.t. Security Compliance and Conformity  Design State is Still Tracked  Represents All Design Actions  Can Track All Security Errors  Doesn’t Report Errors  At Certain Design Milestones (Iterations)  Designer can Initiate Post Design Checking  Comprehensive Intra- and Inter- Check Across the Entire Design Instance

Security-371 CSE 300 Security Compliance Properties  A Design State  i = (   i,   i,   i ) 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, Cstr MAC / Cstr LT (  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, Cstr RBAC (  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 Support  Security Conformity Design Support (SCDS) Program  For Design-Time Mode P DT  Designer’s Action  Event Trigger  Security Constraint Check on the Current State & Design Time  Materialize Connection | Error  Materialize Connection: Update GUI and Design Space  For Post-Design Mode PPD  Simulate Designer’s Actions at a Design Time  Connections with Non-Actors (MAC and Lifetime Check Only)  Connections of Actor-Use-Case then Actor Inheritance

Security-373 CSE 300 Design-Time Checking Design-Time Checking: MAC Constraint Violation The Connection is Removed

Security-374 CSE 300 Together Architect Plug-In Turning the MAC Design-Time Checking On/Off

Security-375 CSE 300 Post-Design Checking Post-Design Checking - Error Case MAC Violation

Security-376 CSE 300 Security Conformity Design Support  SCDS Program for Design-Time Mode P DT  Intended to be Active within the Design Environment P DT (  : , 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 = 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 Support  Example of a Design State Construction Process  Use Case Diagram for Creating a New Survey Entry

Security-382 CSE 300 Algorithmic Complexity Discussion  The Design-Time Security Conformity Support Program P DT  Check Performed whenever a UML Element, UML Connection or SR is Created/Modified  Checks Occur in the UML Design Tool  Reasonable Computational Cost So As to Not Add Overhead to the Design Process  The Post-Design Security Conformity Support Program P PD  When Designs Become More Complex, or are Partially Checked (Imported)  Employed at Design Iterations to Check the Whole Design (at Some Milestone/version)  A Graph Traverse Problem on UML Connections

Security-383 CSE 300 Prototyping Effort  Together Architect (TA): UML Tool with Open APIs for JAVA and a Modular Plug-in Structure  Thanks to Andy, Phil, Frank, and Vijaya, et al.  TA Allows Our Own Custom Code to be Added  Custom Code for MAC/RBAC/LT Constraints  Provides a Tool for Secure Software Design  On-Going Prototyping Effort Supports  Definition of SLs and LTs, for Use-cases, Actors, Classes, and Methods and Constraints into TA  Security Level Analyses for UML Designs  Real-Time as Design is Created and Modified  Post-Design for Design Iterations/Increments  Generation of Comments that Capture Defined Security - Longer Term to Generate Secure Code

Security-384 CSE 300 Together Architect (TA) Plug-In The Modified Inspector Panel of TA Assigning Lifetime and Security Levels to Actor Staff

Security-385 CSE 300 Together Architect Plug-In The Interface to Enter a Security Requirement Enter the Static Role-Objects Mutual Exclusion that the Junior Staff Cannot Use Both “Add Question” and “Approve Question” Use Cases from 01/01/2005 to 12/31/2006.

Security-386 CSE 300 Together Architect Plug-In The List of Security Requirements The Interface Allows to Add a New Security Requirement, Edit/Remove a Current Security Requirements, and Generate the Set of Current Security Requirements in Specified Formats.

Security-387 CSE 300 Together Architect Plug-In Turning the MAC Design-Time Checking On/Off

Security-388 CSE 300 Design-Time Checking Design-Time Checking: MAC Constraint Violation The Connection is Removed

Security-389 CSE 300 Post-Design Checking Post-Design Checking: No Constraint Violation

Security-390 CSE 300 Post-Design Checking Post-Design Checking - Error Case MAC Violation

Security-391 CSE 300 Retrospective on Work  Visual/Non-Visual Modeling Extensions for RBAC, MAC, & Lifetimes in UML  Extensions Integrate Security Requirements, RBAC, MAC, and Lifetimes, into Design Phase  Formal Functional Model for Security/Non-Security Design Features/State  Formal Functional Model Capturing the Security & Non-security Features of an Application’s Design  Track the Design State Retaining Design Time As a Parameter  Convenient for Time-Sensitive Applications with Lifetime Constraints  “Design Once, Re-use Many Times” - Advanced Step for the Style “Write Once, Run Anywhere”

Security-392 CSE 300 Retrospective on Work  Strong Security Assurance (on MAC/LT/RBAC)  Design-time and Post-design Algorithms Against MAC, Lifetime, and RBAC Constraints  Disallowed Usage and Mutual Exclusions  Two Main Important Effects  Immediately Expose Security Flaws of the Design in Design by Discovering the Security Violation  Provide a Degree of Security Assurance for the Design Delivery to be Transferred to the Subsequent Phases  Potential Result: Reducing the Cost of Repairing Errors in the Life Cycle

Security-393 CSE 300 Perspective 2: New UML Diagrams for Security  Work of Jaime Pavlich-Mariscal, Ph.D. student  Security Privileges in UML Extensions Capture Security Across the Entire Design for UML Elements  However, this Information is Scattered and Not Captured into a Single, Manageable Abstraction  To Transition from Design to Development …  Role-Slice, 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 Diagrams New UML Security Diagrams Aspect-Oriented Security Enforcement Code Generation Java

Security-395 CSE 300 Motivation of Perspective 2  Approach 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:  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 Turn

Security-396 CSE 300 Visual Notation  MAC, DAC, RBAC do not Provide a Mechanism to Incorporate them into a Design Model  Designers need a Notation for Security  Facilitate Conceptualization of Security Policies  Facilitate Changes  Reduce Errors  UML Lacks of Support for Security  Existing 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 300Traceability  Ability to Identify which Parts of the Design Models and Code Realize each Requirement  The Better Traceability, the Easier is to Cope with Changes in Requirements  Separation of Concerns is Instrumental to achieve better Traceability

Security-398 CSE 300 Example of Traceability  Business Rules of University Courses traceable to:  Course Class at the Design Level  Course Class Implementation at the Code Level  When Business Rules Change for Courses, Designers/Programmers know where to perform Changes Business Rules of Courses class Course { … } Requirements Design Code

Security-399 CSE 300 Security is Hard to Modularize  Security is Tangled with other Requirements  E.g. Course must Implement Access Control in Addition to Business Rules  Security is Spread across the Design/Code  Other Classes in the University Application (e.g. StudentInformation) must also implement Security  Therefore, Traceability of Security is Poor  Designers need a Mechanism to preserve Separation of Security Concerns  Requirements  Design Models  Code

Security-400 CSE 300Customizability  Security 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.)  Applications often Need a Subset of Capabilities of Access Control Models  Applications may Need Capabilities from more than One Access Control Model  Designers need a Mechanism to:  Select Components from Different Access Control Models  Combine them into a Custom Model  Add/Remove Components

Security-402 CSE 300Correctness  The Code that Implements Security must Enforce the Policy Specified during Design  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 Process

Security-404 CSE 300 Security Diagrams Secure Subsystem (Subset of UML Design) Role-Slice Diagram Mandatory Access Control Features Delegation Diagram User Diagram

Security-405 CSE 300 Security Features Role Slice Diagram Positive Permissions (PP) Negative Permissions (NP) Runtime Permissions (RP) Selection of Features MAC Features Selection of Features Simple Security (SS) Simple Integrity (SI) Liberal-Star (LS) Strict-Star-Read (SSR) User Diagram User-Role Assignment (URA) Separation of Duty (SOD) Selection of Features Delegation Diagram Delegation Authority (DA) Pass-On Delegation Authority (PODA) Selection of Features 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 Code Custom Access Control Code Delegation Diagram ------------- Selection of Features ------------- Role Slice Diagram ------------- Selection of Features ------------- User Diagram ------------- Selection of Features ------------- MAC Features ------------- Selection of Features ------------- Security Component Code Security Component Code Security Component Code Security Component Code Mapping to Code Composed Access Control Model Preservation of Properties Composition Code Composition DesignImplementation

Security-407 CSE 300 University Application Example  Manages Course and Student Information  Users: Teachers, Students, and Assistants

Security-408 CSE 300 Use Cases of University Application

Security-409 CSE 300 Security Requirements of University Appl.  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.  Requirement 2:  Security administrators must be able to authorize or deny teachers / assistants / students to perform specific tasks in the system.  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 Application

Security-412 CSE 300 Role-Slice Diagram

Security-413 CSE 300 User Diagram  How to create the Infrastructure of Security Diagrams?

Security-414 CSE 300 Methodology for Secure Software Design

Security-415 CSE 300 Methodology for Secure Software Design  Multiple Steps in the Process  First Iteration  Identify Security Critical Use Cases  Define the Secure Subsystem  Refinement and Iteration  Incorporate a Security Capability in the Model  Specify Concrete Policy Elements  Arriving at a “Final” Security Design

Security-416 CSE 300 First Iteration

Security-417 CSE 300 Available Security Features

Security-418 CSE 300 Available Security Features

Security-419 CSE 300 Security Refinement Process

Security-420 CSE 300 Refinement and Iteration

Security-425 CSE 300 Composable Security

Security-426 CSE 300 A Second Example  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 Example

Security-429 CSE 300 Simplified Class Model of the Survey Application

Security-430 CSE 300 Defining a Secure Subsystem  We do not Want to Define Security over Every Class in the System  Security is Defined over a Secure Subsystem  Represents those Classes on Which Privileges will be Defined Secure Subsystem

Security-431 CSE 300 Integration with Doan’s work  Each Use Case is Associated to a Set of Methods  Secure Subsystem  Defined as the Set of All Classes whose Methods are Associated to at Least One Use Case Secure Subsystem Secure Methods

Security-432 CSE 300 Defining Access Control Policy  A Role Slice is a Specialized Class Diagram that Represents Permissions for the RBAC Model  Roles are Represented as Packages  Permissions are Represented as Stereotyped Methods  Role Hierarchy is Represented by a Stereotyped Dependency Relation

Security-433 CSE 300 Integration is Automatable  Recall the Transition from Use Cases to the:  Classes Utilized to Realize their Functionality  Methods of those Classes (Subset)  Provides  Definition of Secure Subsystem (Include a Class if at Least One Method is Assigned to a Use Case)  Methods Identified via Actor-Use Case- Class-Method Link  by Disallowed Usage Secure Subsystem

Security-434 CSE 300 Recall the Transition Secure Subsystem

Security-435 CSE 300 Role-Slice Policy

Security-436 CSE 300 Integration with Doan’s Work  Roles and Hierarchies Roles Role Hierarchy Relation

Security-437 CSE 300 Integration with Doan’s work  Permissions  The Set of Use Cases Allowed to an Actor Defines the Methods Allowed to the Corresponding Role Authorized Methods

Security-438 CSE 300 Composition of Role Slices  To Obtain the Final Set of Permissions  Positive Permissions are Inherited by Child Role Slices from their Parents  Negative Permissions are Used to Override Permissions that are Positive in Parent Role Slices

Security-439 CSE 300 Transitioning to Code  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 this Problem

Security-440 CSE 300 Mapping to Code Custom Access Control Code Delegation Diagram ------------- Selection of Features ------------- Role Slice Diagram ------------- Selection of Features ------------- User Diagram ------------- Selection of Features ------------- MAC Features ------------- Selection of Features ------------- Security Component Code Security Component Code Security Component Code Security Component Code Mapping to Code Composed Access Control Model Preservation of Properties Composition Code Composition DesignImplementation

Security-441 CSE 300 AOP Security Enforcement Code Generation  Code Generator takes a Role Slice Specification as Input and Outputs:  An Access Control Aspect  A Policy Database  AOP + Policy DB Provides Means for Changing Access Control without Recompiling Code

Security-442 CSE 300 Aspect-Oriented Definitions  To Formalize the Mapping, it is Necessary to Define Basic Aspect-oriented Concepts  Definitions are Simplified  Formalizes the Ideas in Companion Presentation  A Point Cut is Represented as a Record  A Point Cut is Represented as a Record  caller is a Method where all Invocations of callee must be Modified to Include the Aspect Code  An Advice is a Record  An Advice is a Record  PC: a Point Cut  T: Rewriting Function that Modifies the Method Invocations Specified in PC  An Aspect is a Set of Advices

Security-443 CSE 300 Prototyping Effort - Role-slice Inspector  A Plugin for Together Architect that Generates a Role Slice from the Information of an Actor  Defines whether the Role is Abstract or Not  Shows the Role Slice Associated to the Selected Actor

Security-444 CSE 300 Prototyping Effort - Role-slice Inspector  Role-slice View of Actor Staff

Security-445 CSE 300 Prototyping Effort – Code Generator  Uses the Role Slice Information to Generate Enforcement Code in AspectJ

Security-446 CSE 300 Prototyping Effort – Code Generator  Generation of the AspectJ File AccessControl.java

Security-447 CSE 300 Prototyping Effort – Code Generator  Generated AspectJ File

Security-448 CSE 300 Composition of Security Features

Security-449 CSE 300 Security Diagrams

Security-450 CSE 300 Code Generation

Security-451 CSE 300 Prototyping Effort – Code Generator  Generated Code  Obtaining the Active User public aspect AccessControl { pointcut login():call(User SecurityAdmin.logIn(..)); User around():login() { User u = proceed(); activeUser.set(u); return u; } private ThreadLocal activeUser = new ThreadLocal() { protected Object initialValue() {return null;} }; private User getActiveUser() { return (User)activeUser.get(); }... }

Security-452 CSE 300 Prototyping Effort – Code Generator  Checking Permissions public aspect AccessControl {... pointcut externalCall() : (call(* Survey_List.*(..)) || call(* Survey_Header.*(..))) && !within(Survey_List) && !within(Survey_Header); before() : externalCall() { Role r = getActiveUser().getActiveRole(); if (!r.hasPosPermission(thisJoinPointStaticPart)) { throw new org.aspectj.lang.SoftException( new PermissionDeniedException()); }

Security-453 CSE 300 Retrospective on Role Slices + AOP  We Presented an Approach to Preserve Separation of Security Concerns  Separation of Concerns at the Model Level  Role-slice Notation  Helps in the Conceptualization of a Method-based Security Policy  Facilitates its Evolution During the Design Process.  Separation of Concerns at the Code Level  Mapping from a Role-slice Diagram to AOP Enforcement Code  Provides a Seamless Transition from Security Specification to Code  Isolates Access Control in an Aspect.

Security-454 CSE 300 Object-Oriented and Programmatic Security in C++/Java Collaborative Portals Look-and-Feel Application Content Document Access Secure Software Design To Design and Write Secure Software Programs Concluding Remarks Secure Information Exchange via XML with MAC/RBAC Secure MAC/RBAC Interactions via Middleware in Distributed Setting Assurance Consistency Integrity RBAC, DAC, MAC Separation of Duty Mutual Excl. Safety Liveness

Security-455 CSE 300 Concluding Remarks  Security 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 Everyday 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.

Similar presentations

Presentation on theme: "Security-1 CSE 300Security Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

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

Similar presentations

Presentation on theme: "Security-1 CSE 300Security Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box."— Presentation transcript:

Similar presentations

About project

Feedback