Security Concepts and Capabilities CSE 2102 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 m m 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_BG-1
Motivation: Recall Project Architecture Providers Patients EMR CSE 2102 Where are the Security Web-Based Portal(XML + Issues. Open Source HL 7) and Concerns? DB (XML or My. SQL) Consider Components of Architecture… Feedback Repository Clinical Researchers Education Materials Security_BG-2
Motivation: Security Issues? Patients CSE 2102 Patient GUI Providers for RN vs. MD XML https html Web Server Encryption Firewall Appl Server Web - Control Services Clinical Researchers Appl. – Control Methods Encryption Secure Communication Web Content DB Server Encryption GUI Look and Feel Security_BG-3
Overview m CSE 2102 m m m m Objective: Cover the wide range of Background Concepts and Security Ideas Motivation: Importance, Concepts, and Issues Glossary of Security Terms Security Policy, Authentication, and Authorization Security in Java Access Control q Mandatory Access Control (MAC) q Discretionary Access Control (DAC) q Role-Based Access Control (RBAC) DB Security, Cryptography, Security in Statistical DB Web Based Security Concluding Remarks Security_BG-4
Motivation: General Concepts m CSE 2102 m m Authentication q Proving you are who you are q Signing a Message q Is Client who s/he Says they are? Authorization q Granting/Denying Access q Revoking Access q Does Client have Permission to do what s/he Wants? Encryption q Establishing Communications Such that No One but Receiver will Get the Content of the Message q Symmetric Encryption and Public Key Encryption Security_BG-5
Motivation: Type of Security Issues m CSE 2102 m m m Legal and Ethical Issues q Information that Must be Protected q Information that Must be Accessible q HIPPA vs. Emergent Health Situations Policy Issues q Who Can See What Information When? q Applications Limits w. r. t. Data vs. Users? System Level Enforcement q What is Provided by the DBMS? Programming Language? OS? Application? Web Server? Client? q How Do All of the Pieces Interact? Multiple Security Levels/Organizational Enforcement q Mapping Security to Organizational Hierarchy q Protecting Information in Organization Security_BG-6
Glossary of Protection and Security Terms m CSE 2102 m Principal q Entity (Person/Process/etc. ) to Which Authorizations are Granted q Can be a User, User Group, Program, Client, etc. q Also Known as Subject Protected Object q Known Object whose Internal Structure is Inaccessible Except by Protection System q The Unit of Protection q For Our Purposes: Ø Table, Column, Tuple Ø Data and Meta-Data Glossary from: Saltzer and Schroeder, “The Protection of Information in Computer Systems”, Proc. of IEEE, Vol. 63, No. 9, September 1975. Security_BG-7
Glossary of Protection and Security Terms m CSE 2102 m m Access Control List q List of Principals (User, User Group, Process, …) Authorized to have Access to Some Object q For Every Object, Maintain Authorized Principals q Easily Implemented in Algorithm/Typically in OS Authenticate q Verify Identity of Principal Making Request q In OS - Equivalent to Logging on (ID, Password) q May be More Complicated Based on Security Needs Authorize q Grant Principal Access to Objects q Granularity Ranges from Fine to Coarse q Application Directed Security_BG-8
Glossary of Protection and Security Terms m CSE 2102 m m Capability q Unforgeable Ticket as Proof of Authorization of Presenter (Principal) to Access Named Object q Ticket or Certificate Must be Presented at Each Access Capability List q List of Protected Objects which Likewise List Authorized Principles q Used in Conjunction with Tickets for Authorization Certify q Verify Accuracy, Correctness, & Completeness of Security/Protection Mechanism q Critical for Select Domains (Do. D, Banking, etc. ) Security_BG-9
Glossary of Protection and Security Terms m CSE 2102 m m m Confinement q Restricting What a Process Can Do to with Authorized Objects q Similar in Concept to Sandbox of Java Domain q Objects Currently Accessed by Principal (De)Encryption q De(Encoding) of Data According to Transformation Key for Transmission/Storage q Reciprocal Activity - Many Different Options Grant q Authorize Access to Objects by Principals q Who Can do What When Security_BG-10
Glossary of Protection and Security Terms m CSE 2102 Password q Encrypted Character String to Authenticate Identity of Individual q Critical to Encrypt Also from Client to Login Server Ø Client Types in Plain Text that is Encrypted Ø Encrypted login Travels of Network Ø Decrypted at Login Server and Verified m Permission q Form of Allowed Access to Object (R, W, RW) q Level of Access is System Dependent q Unix File System has: Ø r, w, x for User, Group, and Other Security_BG-11
Glossary of Protection and Security Terms m CSE 2102 m m Privacy q Ability to Decide Whether, When, and to Whom Information is Released q Is Anyone Intercepting Client/Server Communications? Propagation q Principal Passing on Authorization to Object to Another Principal q Current Term Today is “Delegation” q Principal Must be Authorized to Delegate Privileges to Another Principal Enforcement Mechanism q Centralized and Distributed “Code” q Enforces Security Policy at Runtime Security_BG-12
Glossary of Protection and Security Terms m CSE 2102 m m Protection & Security q Mechanisms and Techniques to Control Access to Information by Executing Programs q Enforcement Mechanism, Cryptography Algorithms, Database Security, etc. Revoke q Remove Previously Authorized Access from Principals q Security Tools Must Promote Grant, Revoke, and Authorize in a Dynamic Setting Ticket-Oriented q Each Principal Maintains List of Unforgeable Tickets Denoting Objects have been Authorized q Works with Capability Lists Security_BG-13
Policy & Mechanism m CSE 2102 m m m Security Policy Defines Rules for Authorizing Access to Computer and Resources q Who are Users? What are DB Items? What DB Items are Available to Each User? Etc… q For PHR – Patient Defines Policy Protection Mechanisms Authenticate q Access to DB Items, File and Memory Protection q What is the Granularity of Access? A Security Policy is an Organizations Strategy to Authorize Access to the DBMS DB Items q Each Policy is Application Dependent q Range from Full to Limited Access Security Transcends DB as a Separate Research and Realization for All Types of Systems/Applications Security_BG-14
Authentication m CSE 2102 User/Process Authentication q Is this User/Client Who It Claims to Be? Ø Passwords Ø More Sophisticated Mechanisms Ø Need for Re-authentication m Authentication in Networks q Is this Computer Who It Claims to Be? Ø File Downloading and Transferring Ø Obtaining Network Services Ø What is Java Promise? What Does Java Guarantee re. Applets? What can Application do that Applet Can’t? m DB Authentication q Uncontrolled Access (Select, Modify, etc. ) Can be Limited (Authorized) requiring Authentication Security_BG-15
Authorization m CSE 2102 m m m Ability of Principals to Use Machines, Objects, Resources, etc. Security Policy Defines Capabilities of Each Principal Against Objects, Resources, etc. Authorization Mechanism Enforces Policy at Runtime External Authorization q User Attempts to Access Computer q Authenticate Identify and Verify Authorizations Internal Authorization q Can Process Access a Specific Resource? Database Authorization q What Can Each User Do Against the DB? Select, Insert, Update, Delete? q Are Users Limited to Subsets of Tuples by Value? Security_BG-16
User Authentication m CSE 2102 m Combination of User ID and Password Universal for Access to Computers However, Cannot Prevent … q Guessing of Passwords q Stolen and Decrypted Passwords q Masquerading of Intended User Ø Is User Who they are Supposed to be? Ø What Extra Information Can User be Asked to Supply? Ø What About Life Critical Situations – EMR’s Treating Accident Victim? m Past Invasion of Engineering Computing q yppasswd File Stolen/Decrypted q S. Demurjian’s Sun Workstation Corrupted Security_BG-17
Network Authentication m CSE 2102 Computers Must Interact with One Another q Classic Example, Transmitting E-Mail Msgs. q Does Transferring Computer have Right to Store a File on Another Computer? q What About PHR Data Routed from Web to Application to DB to EMR? Ø Where is the Control? https? Encryption? Ø Guarantee Unencrypted Data not Stored on the Way? m m Viruses: Passive Penetrating Entity q Software Module Hidden in Another Module q When Container Executed, Virus Can Penetrate and Wreak Havoc Worms: Active Penetrating Entity q Actively Seeks to Invade Machine Security_BG-18
Core Security Capabilities of Java m CSE 2102 m m Sandbox and Applet Level Security q Downloaded Applets are Confined in a Targeted Portion of System During Execution q Execution of Untrusted Code in Trusted Way What is Sandbox? q Area of Web-Browser Dedicated to Applet q Applet Limited to Sandbox to Prohibit Access to Local Machine/Environment q Utilizes Class Loader, Bytecode Verifier, and Security Manager q Three Components Maintain System Integrity q How Does this Occur? Why is this Relevant for BMI Applications? q Pervasive Usage of Applets and Client Java Code Security_BG-19
Core Security Capabilities of Java m CSE 2102 m m m Class Loader - Only Load Correct Classes Bytecode Verifier - Classes in Correct Format q Both Don’t care Where the Code is from (compiled from Java or another PL – just is it correct) Security Manager - Untrusted Classes Can’t Execute Dangerous Instructions nor Access Protected System Resources Role of Security Managers q Enforces Boundaries of Sandbox q All Java Classes ask Manager for Permission to Perform Certain Operations q Implements/Imposes Appl. Security Policy q Java Interface Class Implementable by Users q Integrated with Exception Handling of Java Security_BG-20
Recall Java Bytecode Verification: CSE 2102 Security_BG-21
Digital Signatures and JAR Files m CSE 2102 m m When Can Applets Become Applications? q Trusted Publisher (Originator of Applet) q Signed Applet is Authenticated q Java Security Manager May Allow Applet out of Sandbox to be Application How is Information Transmitted and Exchanged? q JAR: Archived (Compressed) Files q Bundling of Code/Data into Java Archive q Associated Digital Signature for Verification q Transmission via Object Serialization Again, for BMI q Web Applications to PCs, PDAs, and Cells q Pervasiveness of Technology and Potential for Misuse and Information Release Security_BG-22
Available Access Control Approaches m CSE 2102 m m Mandatory Access Control (MAC) q Bell/Lapadula Security Model q Security Classification Levels for Data Items q Access Based on Security Clearance of User Role Based Access Control (RBAC) q Govern Access to Information based on Role q Users can Play Different Roles at Different Times Responsibilities of Users Guiding Factor q Facilitate User Interactions while Simultaneously Protecting Sensitive Data Discretionary Access Control (DAC) q Richer Set of Access Modes - Govern Access to Information based on User Id q Discretionary Rules on Access Privileges q Focused on Application Needs/Requirements Security_BG-23
What are Key Access Control Concepts? m CSE 2102 m Assurance q Are the Security Privileges for Each User Adequate to Support their Activities? q Do the Security Privileges for Each User Meet but Not Exceed their Capabilities? Consistency q Are the Defined Security Privileges for Each User Internally Consistent? Ø Least-Privilege Principle: Just Enough Access q Are the Defined Security Privileges for Related Users Globally Consistent? Ø Mutual-Exclusion: Read for Some-Write for Others Security_BG-24
![Mandatory Access Control m CSE 2102 Bell-Lapadula Model [1976] q An Extension of the](https://present5.com/presentation/db7349c54f72e03f2499569007d7dd00/image-25.jpg "Mandatory Access Control m CSE 2102 Bell-Lapadula Model [1976] q An Extension of the")
Mandatory Access Control m CSE 2102 Bell-Lapadula Model [1976] q An Extension of the Access Matrix Model q The Model is Based on Subject-Object Paradigm Ø Subjects: Active Elements Ø Objects: Passive Elements q Four Access Modes/Categories Ø Executable by Subjects on Objects Ø Read-only or Read Ø Append (Write without Read) Ø Execute (Executes an Object/program) Ø Read-Write or Write Security_BG-25
Mandatory Security Mechanism m CSE 2102 m Typical Security Classification Levels for Subjects/programs and Objects/resources q Top Secret (TS) and Secret (S) q Confidential (C) and Unclassified (U) Rules: q TS is the Highest and U is the Lowest Level q TS > C > U q Security Levels: Ø C 1 is Security Clearance Given to User U 1 Ø C 2 is Security Classification Given to Object O 1 Ø U 1 can Access O 1 iff C 1 C 2 Ø This is Referred to as the Domination of U 1 Over O 1 Security_BG-26
Operations m CSE 2102 m m m m Get access q Initiate access to object in the given mode Release access q Terminate access previously started by get Given access q grant an access mode on an object to a subject Rescind access q Revoke access previously granted with the “give” operation Create object q An object may be inactive or active; this takes an inactive object and adds to the object hierarchy Delete object q Deactivates an active object Change subject security level Change object security level Security_BG-27
Mandatory Security Mechanism m CSE 2102 Restriction (Axiom 1): q No Subject S Can Read an Object O if the Object’s Security Classification is Higher Than the Subject’s Security Clearance Ø S Can Read O iff Clearance(S) Classification(O) q No Subject May Write an Object that has Lower Security Class than the Subject’s Security Clearance Ø S Can Write O iff Clearance(S) Classification(O) Ø This Prevents Information Flow from Higher Classification to Lower Classification Levels m Depending on the Desired MAC, Different Axioms Can be Employed that Satisfy Different Criteria of Clearance Dominating Classification Security_BG-28
Other Axioms CSE 2102 m m m Simple Security (SS) Property q Subject S may have Read(Write) Access to Object O iff Clearance of S Dominates the Classification of O Star (*) Property q A Subject Can Only Read Objects at or Above their Level q A Subject Can Only Write Objects at or Below their Level Tranquility Principle q No Subject Can Modify Classification of Active Object Security_BG-29
Mandatory Security Mechanism m CSE 2102 m m There are Numerous Security Properties Regarding the Ability of a Subject S to Read (Write) an Object O These Properties Control the flow of Information from Users to the Objects that they are allowed to Access Simple Security Property (Read Down – No Read Up) q No Subject S Can Read an Object O if the Object’s Security Classification is Higher Than the Subject’s Security Clearance q S Can Read O iff Clearance(S) Classification(O) q This Insures that a Subject S cannot Read Information Above his/her Security Level TS S User (S) C U Read Down Security_BG-30
Mandatory Security Mechanism m CSE 2102 m Simple Integrity Property (Write Down–No Write Up) q A Subject May Write an Object only if that Object is at or Below the Subject’s Security Clearance q S Can Write O iff Clearance(S) ≥ Classification(O) q This Allows the Potential of Information Flow from Higher Classification to Lower Classification Levels q This Prevents the Ability of a Subject S to Corrupt Data above its Security Level Security Designer Must Choose their Poison! TS S User (S) C U Write Down Security_BG-31
Mandatory Security Mechanism m CSE 2102 m Liberal * Property (Write Up–No Write Down) q No Subject May Write an Object that has Lower Security Class than the Subject’s Security Clearance q S Can Write O iff Clearance(S) Classification(O) q This Prevents Information Flow from Higher Classification to Lower Classification Levels q Such an Attempt can be Overt or Unintentional Likewise, this Allows a Subject to Corrupt Information above its Level TS S C U Write Up User (S) Security_BG-32
Mandatory Security Mechanism m CSE 2102 Strict * Property (Read/Write Equal) q A Subject May Only Read/Write an Object that has the Exact Same Security Class than the Subject’s Security Clearance q S Can Read/Write O iff Clearance(S) = Classification(O) q This Limits Information Flow to within a Level TS S C U Read Equal Write Equal User (S) Security_BG-33
Using the Properties m CSE 2102 m Security Policy is Typically a Combination of one Read and one Write Property q Simple Security + Simple Integrity q Simple Security + Strict * (Write) q Simple Security + Liberal * q Strict * (Read) + Simple Integrity q Strict * (Read) + Strict * (Write) q Strict * (Read) + Liberal * Objective: Security Engineer Must Choose the Most Appropriate Combination for their Application Security_BG-34
A Classic Example m CSE 2102 m Simple Security for Reads q See Information at User Clearance Level and Lower (Less Secure) q No Chance of Viewing TS Information Liberal * for Writes q Write Information at User Clearance Level and Above (More Secure) q No Chance of Releasing “S” Data to Lower Levels User (S) TS S Read Down C U Write Up Security_BG-35
Other Axioms m CSE 2102 m m Discretionary Property (DS-property) q Every Current Access Must Be Present in the Access Matrix q For All Subjects S, Objects O, and the Access Mode M: <S, o, m> B M M[s, o] Non-Accessibility of Inactive Objects q A Subject Cannot Read the Contents of an Inactive Object Rewriting of Inactive Objects q A Newly Activated Object is Assigned to an Initial State Independent of the Previous Activation of the Object Security_BG-36
Illustrating MAC m CSE 2102 m Consider the EMPLOYEE Table Below with Two Instances q Notice Classifications on Each Tuple (TC) q Notice Classifications on Each Attribute Value Interpretation: q Limit Who Can See Each Tuple and Values q Focus on User Clearance w. r. t. Classifications Security_BG-37
Illustrating MAC m CSE 2102 Whenever a User Attempts to Access a Table, the Table is Filtered According to U’s Clearance q First Set are for a User at Confidential Level q Second Set is For a User at Unclassified Level Security_BG-38
Security in Software Applications m CSE 2102 m m m Extensive Published Research (Demurjian, et al) in Last Ten Years for DAC/RBAC for OO Efforts in q Automatically Generatable and Reusable Enforcement Mechanisms q MAC/DAC/RBAC within Distributed Setting Premise: q Customizable Public Interface of Class q Access to Public Interface is Variable and Based on User Needs and Responsibilities q Only Give Exactly What’s Needed and No More Please see: www. engr. uconn. edu/~steve/DSEC/desc. html Security_BG-39
What is Role Based Access Control (RBAC)? m CSE 2102 m m Most OO Programming and Database Languages have a Single Public Interface that is Shared by All Users of OT/Class Consequently, Public Interface Often Union of all Possible Methods Required by All Likely Users Discretionary Access Control: q Occurs at Type-Level q Different Portions of Public Interface Available to Different Users at Different Times Depending on User-Roles q Promote Potential Public Interface Security_BG-40
Motivating Security for OO Paradigm m CSE 2102 m m 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 q Can Access to Public Interface be Customized? q Can Individuals have Particular Access to Specific Subsets of Public Interface? q Can Access be Based on (Potentially) Dynamic User Roles? q Can Code be Automatically Generated to Implement an Enforcement Mechanism? q Role of OO Paradigm in Support a Generic, Evolvable, Reusable Enforcement Mechanism? Security_BG-41
Why is RBAC Needed? CSE 2102 m m In Health Care, different professionals (e. g. , Nurses vs. Physicians vs. Administrators, etc. ) Require Select Access to Sensitive Patient Data Suppose we have a Patient Access Client q Lois playing the Nurse Role would be Allowed to Enter Patient History, Record Vital Signs, etc. q Steve playing M. D. Role would be Allowed to do all of a Nurse plus Write Orders, Enter Scripts, etc. q Vicky playing Admin Role would be Allowed to Enter Demographic/Insurance Info. q Role Dictates Client Behavior Security_BG-42
Why is RBAC Needed? m CSE 2102 m Many Situations When Application Library Designer (SWE) Could Utilize More Fine-Grained Control to Access of Public Interface Tradeoff Between Developers and End-Users q SWEs Have Different Roles Based on Their Responsibilities Related to Cooperative Design on an Application q SWEs Should Only See Those Portions of the Application That They Need to See or That They Will Be Responsible for Implementing q End-users Must Be Limited in Their Interactions and Access Depending on Their Roles Security_BG-43
Examples of Why RBAC is Needed m CSE 2102 m In HTSS, the public interface for Items has methods that read (for Scanner, I-Controller) and modify instances (only for I-Controller) q Read Methods Targeted for Certain System Functions (e. g. , Scan Item) q Update Methods Targeted for Others (e. g. , as Item is Scanned, Decrement Inventory Amount) In HCA, different health care professionals (e. g. , Nurses vs. Physicians vs. Administrators, etc. ) require select access to sensitive patient data q Physician’s Write Scripts q Nurses Enter Patient Data (Vitals + History) q All Access Shared Medical Record q Access is Limited Based on Role Security_BG-44
RBAC for OO m CSE 2102 m m m Public Interface is Union of All Privileges for All Potential Users No Explicit way to Prohibit Access Customizable Public Interface of Class Access to Public Interface is Variable and Based on User Needs and Responsibilities Only Give Exactly What’s Needed and No More public class Patient. Record { private: Data/Methods as Needed; public: write_medical_history(); write_prescription(); For MDs get_medical_history(); and Nurses get_diagnosis(); set_payment_mode(); etc… For MDs Only For Admitting Security_BG-45
Sample RBAC Hierarchy for HCA CSE 2102 Users Medical_Staff Support_Staff Etc. Nurse Physcian Technician UR: Lab UR: Pharmacy UR: Radiology UR: Staff_RN UR: Education UR: Private UR: Attending UR: Director UR: Manager UR: Discharge_Plng Security_BG-46
Sample RBAC Hierarchy for University CSE 2102 Users / +---+ +-----+ / non-academic-staff / purchasing campus-police. . academic-staff / . . / dept-staff registrar-staff. . . / grade-recording transcript-issuing Security_BG-47
Sample RBAC Hierarchy for Portal CSE 2102 Users Medical_Staff Patients Etc. Clinical Researcher Basic User Provider UR: Nurse UR: Occ. Ther UR: Physician UR: etc… UR: Forum. Leader UR: Basic. PHR UR: Poster UR: Data. Analyst UR: Ed. Materials Security_BG-48
NIST RBAC Standard m CSE 2102 m m http: //csrc. nist. gov/groups/SNS/rbac/ Formalized in 1992 (Ferraiolo and Kuhn) Based on Work by Sandhu, et al. Lot’s of Health Care Related Case Studies: http: //csrc. nist. gov/groups/SNS/rbac/case_studies. html q Please Visit the Site … q May be Applicable Applications …. Briefly, Let’s Review … Security_BG-49
RBAC Model Variants m CSE 2102 http: //csrc. nist. gov/groups/SNS/rbac/documents/towards-std. pdf m Transition from Essential Features to Complex Model Security_BG-50
Level 1 and Level 2 m CSE 2102 m Level 1: Three States and UA/PA Level 2: Add in Role Hierarchy Look on R State Security_BG-51
Example Role Hierarchies CSE 2102 Security_BG-52
Constrained RBAC – with SOD CSE 2102 Security_BG-53
Constrained RBAC – with SOD CSE 2102 Security_BG-54
Discretionary Access Control m CSE 2102 m m Discretionary q Grant Privileges to Users, Including the Capabilities to Access Specific Data Items in a Specific Mode q Available in Most Commercial DBMSs Aspects of DAC q User’s Identity q Predefined Discretionary “Rules” Defined by the Security Administrator Focus on Two Variants of this Model q Access Matrix Model q Lampson’s Protection System Role Delegation and Delegation Authority Detail DAC in SQL 2 Security_BG-55
What is Role Delegation? m CSE 2102 m m m Role Delegation, a User-to-User Relationship, Allows an Original User (OU) to Transfer Responsibility for a Particular Role to a Delegated User (DU) Two Major Types of Delegation q Administratively-directed Delegation has an Administrative Infrastructure Outside the Direct Control of a User Mediates Delegation q 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 Vital in Health Care: q Provider on-Call, Emergent Situations, DCP … Security_BG-56
Why is Role Delegation Important? m CSE 2102 Many Different Scenarios Under Which Privileges May Want to be Passed to Other Individuals q Large organizations often require delegation to meet demands on individuals in specific roles for certain periods of time q True in Many Different Sectors Ø Health Care Ø Financial Services Ø Engineering Ø Academic Setting m Key Issues: q Who Controls Delegation to Whom? q How are Delegation Requirements Enforced? Security_BG-57
What Can be Delegated? m CSE 2102 m m m 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 Security_BG-58
Delegation/Pass on Delegation Authorities m CSE 2102 When Establishing Privileges (by the Security Officer) there must be the Ability to Define: q 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 q 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 Security_BG-59
Example - Role Delegation m CSE 2102 m General Do. Best Delegates his Role CDR_CR 1 (Commander, Crisis 1) to Colonel Do. Good with DA, where Do. Best, CDR_CR 1, and Do. Good defined as: OU: [Do. Best, [ct, ], T] UR: [CDR_CR 1, [01 dec 00, 01 dec 01], T] UA: [Do. Best, CDR_CR 1, [01 dec 00, 01 dec 01]] DA: Yes PODA: Yes After Delegation: DU: [Do. Good, [01 dec 00, 01 jun 01], T] UA: [Do. Good, CDR_CR 1, [01 dec 00, 01 jun 01]] Security_BG-60
Example - Role Delegation m CSE 2102 Now, Colonel Do. Good wishes to re-delegate CDR_CR 1 to Major Can. Do. Right, which can be defined as: DU: [Do. Good, [01 dec 00, 01 jun 01], T] UR: [CDR_CR 1, [01 dec 00, 01 dec 01], T] UA: [Do. Good, CDR_CR 1, [01 dec 00, 01 jun 01]] DA: Yes PODA: No m After Delegation: DU: [Can. Do. Right, [01 jan 01, 01 feb 01], T] UA: [Can. Do. Right, CDR_CR 1, [01 dec 00, 01 jun 01]] Security_BG-61
Role Delegation Revocation Rules m CSE 2102 User-to-User Delegation Authority Rule q 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). Security_BG-62
Role Delegation Revocation Rules m CSE 2102 m Delegation Revocation Authorization Rule: q An Original User Can Revoke Any Delegated User From a User Role in Which the OU Executed the Delegation. q This is a Stricter Interpretation than [Zhan 01], Which Allows Any OU of a Role Revocation Authority Over a DU in the Delegation Path. q In Addition, a Security Administrator Can Revoke Any Delegation. Cascading Revocation Rule: q Whenever an OU or DU in the delegation path is revoked, all DUs in the path are revoked. Security_BG-63
Monotonicity and Permanence CSE 2102 m m Definition: Monotonicity Refers to the State of Control the OU Possesses After Role Delegation q Monotonic Delegation Means That the OU Maintains Control of the Delegated Role q Non-monotonic Means That the OU Passes the Control of the Role to DU Definition: Permanence Refers to Delegation in Terms of Time Duration q Permanent Delegation is When a DU Permanently Replaces the OU q Temporary Delegation Has an Associated Time Limit With Each Role Security_BG-64
Totality and Administration CSE 2102 m m Definition: Totality Refers to How Completely the Permissions Assigned to the Role Are Delegated q Partial Delegation Refers to the Delegation of a Subset of the Permissions of the Role q Total Delegation Refers to the Situation All of the Permissions of the Role Are Delegated Definition: Administration Refers to how Delegation will be Administered q User Directed is when the User Controls all Aspects of Delegation q Administrator-Directed (Third party, Agentdirected) is when Control is with the Security Officer Security_BG-65
Revocation CSE 2102 m m Definition: Cascading Revocation Refers to the Indirect Revocation of All DUs When the OU Revokes Delegation or Administration Revokes the OU’s Delegated Role Definition: Grant-Dependency Revocation Refers to Who Has Authority to Revoke a DU q Grant-Dependent Revocation Only Allow the OU to Revoke the Delegated Role q Grant-Independent Revocation Allows Any Original Member of the DUR to Revoke a Delegated Role Security_BG-66
Database Security Approach m CSE 2102 m m m Software Engineers can Write Complex Programs Limited by Intellectual Capabilities DB Designer Must Create Protection Scheme that Can’t be Bypassed by Current and Future Software Users and DB Initiators q Users have Dedicated and Shared DB Items q DB Items Shared by User Groups vs. DB Items Globally Shared q Users Spawn Clients that Access DB Items q Clients May be Local or Remote (on Another Machine Connected via Network) Protection System of DB Must Support Above According to Organization’s Admin. Policy Security_BG-67
Database Security m CSE 2102 Types of Security q Database Security is Mainly Related with Access Rights to the Database q Database Security Involves Issues Such as Ø Governmental or Corporate Level of Policies Ø Privacy and Confidentiality Requirements q For Example - Consider a Medicine Prescription Ø Physician or PA Only One Authorized to Write Drug, Dosage, Refills, Generic vs. Brand, etc. Ø Pharmacist by Law Can Enter Script, Replace Brand with Generic, Alter “Refills” - Can’t Change the Med Ø By Law - Protect the Script per Patient (MD/Insurance) m Access Control is Mechanism to Prevent Unauthorized Access to Databases Security_BG-68
Database Security m CSE 2102 m Database Administrator (DBA) has the Privileged Commands to Perform the Following on Databases q Account Creation q Privilege Granting q Privilege Revocation q Security Level Assignments Elements of the Security Model q Subjects (Principals) q Objects (Data) q Access Methods (How to Use) q Policies (Application Dictated) q Authorizations (Who Can Do What) q Authentication and Enforcement (Runtime) Security_BG-69
DAC in SQL 2 m CSE 2102 m m m SQL 2 Uses the Concept of Authorization Identifier q User Group (could be Single User) q References a Set of User Accounts DBA Must Provide Selective Access by each User to Every Relation in the DB Based on Account Two Levels of Privilege Assignment q Account Level - DBA Manages the Accounts for to Authorize Users to Different DBs q Relation/Table Level - Controlling Access to Each Relation or View in a DB Objective q Manage and Administer q Design/Realize the Security Policy Security_BG-70
Privileges in SQL m CSE 2102 Allocated at a Relation Level q SELECT Privilege Ø Gives Account Retrieval Access q MODIFY Privilege Ø Gives Account Ability to Change the Database Ø Subdivided into Insert, Update, and Delete Ø Insert and Update can be Specialized on Different Attributes of Relation q REFERENCES Privilege Ø Gives Account the Ability re. Integrity Constraints Ø Can be Restricted to Certain Attributes of Relation m Commands to both GRANT and REVOKE are Supported Security_BG-71
Example Schema m CSE 2102 Consider Two Database Tables: q EMPLOYEE Ø (NAME, SNN, BDATE, ADDRESS, SET, SALARY, DNO) q DEPARTMENT Ø (D#, DNAME, MGRSNN) m Consider Four Accounts/Users: q U 1, U 2, U 3 and U 4 q Limit U 1 to be Able to Create Schema q In SQL Ø GRANT CREATETAB TO U 1; q In SQL 2 Ø CREATE SCHEMA EXAMPLE AUTHORIZATION U 1; q U 1 Can Create Tables In Schema EXAMPLE Security_BG-72
SQL Examples m CSE 2102 Suppose U 1 Wants to Grant U 2 the Ability to Insert and Delete into EMPLOYEE and DEPARTMENT q U 1 Wants to Disallow Ability of U 2 to Propagate (Delegate) Insert/Delete to Other Users Ø GRANT INSERT, DELETE ON EMPLOYEE, DEPARTMENT TO U 2; m Suppose U 1 Wants to Grant U 3 the Ability to Select from EMPLOYEE and DEPARTMENT q U 1 Allows U 3 to Propagate to Other Users Ø GRANT SELECT ON EMPLOYEE TO U 3 WITH GRANT OPTION; q Now, U 3 can: Ø GRANT SELECT ON EMPLOYEE TO U 4; Ø U 4 Cannot Propagate/Delegate this Privilege Security_BG-73
SQL Examples m CSE 2102 Suppose U 1 Wants to REVOKE U 3 the Ability to Select from EMPLOYEE and DEPARTMENT Ø REVOKE SELECT ON EMPLOYEE TO U 3; Database Must Also Cascade this Revoke to U 4 Since U 3 No Longer has the Ability to Grant Cascading Revokes Can be Complicated as Privileges are Defined Consider 100 Users and DB with 20 Tables and Ability to Grant/Revoke Becomes Complex Consequently, Propagation/Delegation are Usually Only Given Very Carefully Critical to Document Security Policy for Each Application! q m m Security_BG-74
SQL Examples m CSE 2102 Suppose that U 1 wants to Give Back to U 3 a Limited Capability to SELECT from EMPLOYEE q Also Allow U 3 to be able to Propagate q U 1 First Creates a View create view U 3_EMP as select NAME, BDATE, ADDRESS from EMPLOYEE where DNO = 5; q U 1 Now Grants the View Ø GRANT SELECT ON U 3_EMP TO U 3 WITH GRANT OPTION; q U 1 Can also Grant Limited Update Ø GRANT UPDATE ON EMPLOYEE (SAL) TO U 4; Security_BG-75
Cryptography m CSE 2102 m m m Information can be Encoded Using a Key it is Written (or Transferred) -- Encryption Information is then Decoded Using a Key When it is Read (or Received) -- Decryption Very Widely Used for Secure Network Transmission Mathematical Basis - Prime Number Generation encryption plaintext ciphertext decryption Security_BG-76
More on Cryptography CSE 2102 plaintext Ke Encrypt Side information Kd C = EKe(plaintext) Invader Decrypt plaintext Security_BG-77
Cryptographic Systems CSE 2102 Cryptographic Systems Modern Systems Conventional or Symmetric Systems • Ke and Kd are Private Key Public Key essentially the same • Ke and Kd are • Ke is public private • Kd is private Security_BG-78
Statistical Database Security m CSE 2102 m Statistical Databases are used to Produce Statistics on Various Populations q Individual Information is Considered Confidential q Users May be Allowed to Access Statistical Information on the Population, i. e. , Applying Statistic Functions to a Population of Tuples Techniques for Protecting Privacy of Individual Information Solutions are Illustrated by Examples: Person(name, ssn, income, address, city, state, zip, sex, last_degree) m m Suppose we are Allowed to Retrieve Only the Statistical Information Over this Relation by Using SUM, AVG, MIN, MAX, COUNT, Etc. Vital for Epidemiology and other Clinical Research Security_BG-79
Example of Statistical DB m CSE 2102 Consider Q 1 and Q 2: Q 1: find the total number of women Q 1: find the average income of women who have ph. D. and live in Calgary, Alberta. select COUNT(*) from Person where last_degree = “ph. D. ” and sex = “F” and city = “Calgary” and state = “Alberta”; m select AVG(income) from Person where last_degree = “ph. D. ” and sex = “F” and city = “Calgary” and state = “Alberta”; Suppose Mary Black is a Ph. D who Lives in Calgary and we want to know her Income, which is Prohibited q If Query Q 1 Returns One Tuple, then the Result of Q 2 is the Income of Mary q Otherwise we May Issue a Number of Subsequent Queries Using MAX and MIN, we May Easily Obtain a Close Range of Mary’s Income Security_BG-80
Example Two of Statistical DB m CSE 2102 m m The Issue is that Even with Statistical DB Limits, it is Possible to Infer and Discern Confidential Info. Suppose the Query Writer (Connie) also Lives in Calgary and has a Ph. D. Consider Q 3 (left) and Q 4 (right) below: select from where and and m SUM(income) Person last_degree = “ph. D. ” sex = “F” city = “Calgary” state = “Alberta”; name <> “Mary” select from where and and SUM(income) Person last_degree = “ph. D. ” sex = “F” city = “Calgary” state = “Alberta” name <> “Connie”; Since Connie Knows her Own Income, by Calculating Q 4 - (Q 3 - Connie’s Income), She Determinds Mary’s Income Security_BG-81
Statistical Database Security m CSE 2102 m m Thus, having Just Aggregate Operations Can Allow the Confidentiality of DB to be Breached A Number of Restrictions can be used to Reduce the Possibility of Deducing Individual Information from Statistical Queries: q Statistical Queries are not Permitted if the Number of Tuples in the Population Specified by the Selection Condition Falls Below Some Threshold q Restricting the Number of Tuples in the Intersection of Subsequent Query Results q Prohibiting Sequences of Queries that Refer Repeatedly to the Same Population of Tuples While these can help - it may Still Possible to Deduce Information and Breach Confidentiality! Security_BG-82
Web Based Security m CSE 2102 m m What are the Issues and Concerns in Web-Based Security? See: http: //www. w 3. org/Security/Faq/ Partitions Security into: q Client Side Security q Server Side Security q CGI Scripts q Protecting Confidential Documents q Denial of Service Attacks We’ll Briefly Review all, but Concentrate on those Most Apropos to BMI and Associated Web-Based Applications (e. g. , Team Project) Security_BG-83
General Web Security Issues m CSE 2102 m m m Bugs or Configuration Problems in Web Servers that allow Remote users able to: q Steal Confidential Documents, Execute Commands on Servers, Break Into Servers, Launch Do. S Browser-Side: q Active-X or Applets Can Breach Privacy q Misuse of Supplied Personal Info (App Side) Network Eavesdropping: q Network on Browser Side q Network on Server Side q End User ISP, Server ISP What is the Biggest Concern for BMI? Security_BG-84
General Web Security Issues m CSE 2102 m m Impact of OS on Web Security: q Unix and NT – Powerful and Full Featured have Many Potential Holes – most Vulnerable q Special Purpose Web Boxes – less Vulnerable q Bare-Bones Macintosh – least Vulnerable Security of Web Server Software Programs q Dependent on Services Offered q Simple Server (Static files) Safer than Complex Server (CGI scripts, Server-Side Processing, etc. ) q All Security Servers have Holes! Common Gateway Interface (CGI) Scripts are Major Source of Security Problems q Issue Traced to Diligence in Writing Code as Opposed to Technology Itself Security_BG-85
General Web Security Issues m CSE 2102 General Security Precautions – Laundry List q Who is allowed to use the system q When they are allowed to use it q What they are allowed to do (different groups may be granted different levels of access) q Procedures for granting access to the system q Procedures for revoking access (e. G. When an employee leaves) q What constitutes acceptable use of the system q Remote and local login methods q System monitoring procedures q Protocols for responding to suspected security breaches Security_BG-86
Benefits for Written Security Policy m CSE 2102 m m m You yourself will understand what is and is not permitted on the system. If you don't have a clear picture of what is permitted, you can never be sure when a violation has occurred. Others in your organization will understand what the security policy is. The written policy raises the level of security consciousness, and provides a focal point for discussion. The security policy serves as a requirements document against which technical solutions can be judged. This helps guard against the "buy first, ask questions later" syndrome. The policy may help bolster your legal case should you ever need to prosecute for a security violation. Security_BG-87
Issues of Client Side Security CSE 2102 Q 1 How do I turn off the "You are submitting the contents of a form insecurely" message in Netscape? Should I worry about it? Q 2 How secure is the encryption used by SSL? Q 3 When I try to view a secure page, the browser complains that the site certificate doesn't match the server and asks me if I wish to continue. Should I? Q 4 When I try to view a secure page, the browser complains that it doesn't recognize the authority that signed its certificate and asks me if I want to continue. Should I? Q 5 How private are my requests for Web documents? Q 6 What's the difference between Java and Java. Script? Q 7 Are there any known security holes in Java? Q 8 Are there any known security holes in Java. Script? Security_BG-88
Issues of Client Side Security CSE 2102 Q 9 What is Active. X? Does it pose any risks? Q 10 Do "Cookies" Pose any Security Risks? Q 11 I hear there's an e-mail message making the rounds that can trash my hard disk when I open it. Is this true? Q 12 Can one Web site hijack another's content? Q 13 Can my web browser reveal my LAN login name and password? Q 14 Are there any known problems with Microsoft IE? Q 15 Are there any known problems with Netscape Com. ? Q 16 Are there any known problems with Lynx for Unix? Q 17 Is it a good idea to configure /bin/csh as a viewer for documents of type application/x-csh. Q 18 Is there anything else I should keep in mind regarding external viewers? Security_BG-89
Issues of Protecting Confidential Documents CSE 2102 Q 1 What types of access restrictions are available? Q 2 How safe is restriction by IP address or domain name? Q 3 How safe is restriction by user name and password? Q 4 What is user verification? Q 5 How do I restrict access to documents by the IP address or domain name of the remote browser? Q 6 How do I add new users and passwords? Q 7 Isn't there a CGI script to allow users to change their passwords online? Q 9 How does encryption work? Q 10 What are: SSL, SHTTP, Shen? Q 11 Are there any "freeware" secure servers? Security_BG-90
Web Services Security m CSE 2102 m m m Predominately Achieved via SOAP Messaging See: http: //www. oasis-open. org/specs/index. php#wssv 1. 0 Enhancements to SOAP Messaging for: q Message Integrity q Message Confidentiality q Single Message Authentication General Purpose Mechanism for Associating Security Token with messages This is a Good Topic for Project 2 – Web Services Security… See also: http: //www. ibm. com/developerworks/library/specification/ws-secure/ Security_BG-91
Concluding Remarks m CSE 2102 m Security is Multi-Step, Multi-Discipline Process q Definition of Security Requirements q Realization of Security at Web, Application, and Database Levels q Integration of Security from Client to Web to Application to DB q Rigorous Definition of Security Policy q Dynamic Nature of Security Privileges q Enforcement of Defined Privileges Across and within Multiple Tiers Overall, Security in Today’s World Integral Part of Everyday Life - Some Key Concerns q Confidentiality of an Individuals Data – PHR/EMR q Identity Theft q Protecting National Infrastructure Security_BG-92
Скачать презентацию Security Concepts and Capabilities CSE 2102 Prof Steven
db7349c54f72e03f2499569007d7dd00.ppt