1. SecBG-1 CSE 333 Security Concepts and Capabilities 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.

2. SecBG-2 CSE 333Overview  Concepts and Issues  Glossary of Security Terms  Security Policy, Authentication, and Authorization  Security in Java  Database Security  Access Control  Mandatory Access Control (MAC)  Discretionary Access Control (DAC)  Role-Based Access Control (RBAC)  Cryptography  Security in Statistical DB  Emerging Security Trends

3. SecBG-3 CSE 333 Introduction: General Concepts  Authentication  Proving you are who you are  Signing a Message  Is the Client who S/he Says they are?  Authorization  Granting/Denying Access  Revoking Access  Does the Client have Permission to do what S/he Wants?  Encryption  Establishing Communications Such that No One but Receiver will Get the Content of the Message  Symmetric Encryption  Public Key Encryption

4. SecBG-4 CSE 333 Type of Security Issues  Legal and Ethical Issues  Information that Must be Protected (e.g., SSN)  Information that Must be Accessible (e.g., SSN)  Policy Issues  Who Can See What Information When?  Applications Limits w.r.t. Data vs. Users?  System Level Enforcement  What is Provided by the DBMS? Programming Language? OS? Application?  How Do All of the Pieces Interact?  Multiple Security Levels/Organizational Enforcement  Mapping Security to Organizational Hierarchy  Protecting Information in Organization

5. SecBG-5 CSE 333 Glossary of Protection and Security Terms  Principal  Entity (Person/Process/etc.) to Which Authorizations are Granted  Can be a User, User Group, Program, Client, etc.  Also Known as Subject  Protected Object  Known Object whose Internal Structure is Inaccessible Except by Protection System  The Unit of Protection  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.

6. SecBG-6 CSE 333 Glossary of Protection and Security Terms  Access Control List  List of Principals (User, User Group, Process, …) Authorized to have Access to Some Object  For Every Object, Maintain Authorized Principals  Easily Implemented in Algorithm/Typically in OS  Authenticate  Verify Identity of Principal Making Request  In OS - Equivalent to Logging on (ID, Password)  May be More Complicated Based on Security Needs  Authorize  Grant Principal Access to Objects  Granularity Ranges from Fine to Coarse  Application Directed

7. SecBG-7 CSE 333 Glossary of Protection and Security Terms  Capability  Unforgeable Ticket as Proof of Authorization of Presenter (Principal) to Access Named Object  Ticket or Certificate Must be Presented at Each Access  Capability List  List of Protected Objects which Likewise List Authorized Principles  Used in Conjunction with Tickets for Authorization  Certify  Verify Accuracy, Correctness, & Completeness of Security/Protection Mechanism  Critical for Select Domains (DoD, Banking, etc.)

8. SecBG-8 CSE 333 Glossary of Protection and Security Terms  Confinement  Restricting What a Process Can Do to with Authorized Objects  Similar in Concept to Sandbox of Java  Domain  Objects Currently Accessed by Principal  (De)Encryption  De(Encoding) of Data According to Transformation Key for Transmission/Storage  Reciprocal Activity - Many Different Options  Grant  Authorize Access to Objects by Principals  Who Can do What When

9. SecBG-9 CSE 333 Glossary of Protection and Security Terms  Password  Encrypted Character String to Authenticate Identity of Individual  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  Permission  Form of Allowed Access to Object (R, W, RW)  Level of Access is System Dependent  Unix File System has:  r, w, x for User, Group, and Other

10. SecBG-10 CSE 333 Glossary of Protection and Security Terms  Privacy  Ability to Decide Whether, When, and to Whom Information is Released  Is Anyone Intercepting Client/Server Communications?  Propagation  Principal Passing on Authorization to Object to Another Principal  Current Term Today is “Delegation”  Principal Must be Authorized to Delegate Privileges to Another Principal  Enforcement Mechanism  Centralized and Distributed “Code”  Enforces Security Policy at Runtime

11. SecBG-11 CSE 333 Glossary of Protection and Security Terms  Protection & Security  Mechanisms and Techniques to Control Access to Information by Executing Programs  Enforcement Mechanism, Cryptography Algorithms, Database Security, etc.  Revoke  Remove Previously Authorized Access from Principals  Security Tools Must Promote Grant, Revoke, and Authorize in a Dynamic Setting  Ticket-Oriented  Each Principal Maintains List of Unforgeable Tickets Denoting Objects have been Authorized  Works with Capability Lists

12. SecBG-12 CSE 333 Policy & Mechanism  Security Policy Defines Rules for Authorizing Access to Computer and Resources  Who are Users? What are DB Items? What DB Items are Available to Each User? Etc…  Protection Mechanisms Authenticate  Access to DB Items  Insure File and Memory Protection  A Security Policy is an Organizations Strategy to Authorize Access to the DBMS DB Items  Each Policy is Application Dependent  Range from Full to Limited Access  Security Transcends DB as a Separate Research and Realization for All Types of Systems/Applications

13. SecBG-13 CSE 333Authentication  User/Process Authentication  Is this User/Client Who It Claims to Be?  Passwords  More Sophisticated Mechanisms  Authentication in Networks  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?  DB Authentication  Uncontrolled Access (Select, Modify, etc.) Can be Limited (Authorized) requiring Authentication

14. SecBG-14 CSE 333Authorization  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  User Attempts to Access Computer  Authenticate Identify and Verify Authorizations  Internal Authorization  Can Process Access a Specific Resource?  Database Authorization  What Can Each User Do Against the DB? Select, Insert, Update, Delete?  Are Users Limited to Subsets of Tuples by Value?

15. SecBG-15 CSE 333 User Authentication  Combination of User ID and Password Universal for Access to Computers  However, Cannot Prevent …  Guessing of Passwords  Stolen and Decrypted Passwords  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 (DCP)?  Past Invasion of Engineering Computing  yppasswd File Stolen/Decrypted  S. Demurjian’s Sun Workstation Corrupted

16. SecBG-16 CSE 333 Network Authentication  Computers Must Interact with One Another  Classic Example, Transmitting E-Mail Msgs.  Does Transferring Computer have Right to Store a File on Another Computer?  Viruses: Passive Penetrating Entity  Software Module Hidden in Another Module  When Container Executed, Virus Can Penetrate and Wreak Havoc  Worms: Active Penetrating Entity  Actively Seeks to Invade Machine  Morris’s Worm Penetrated via Unix Finger  Passed String that Executed Allocated Memory  Destroyed Runtime Stack/Allowed Worm Execute

17. SecBG-17 CSE 333 Core Security Capabilities of Java  Sandbox and Applet Level Security  Downloaded Applets are Confined in a Targeted Portion of System During Execution  Execution of Untrusted Code in Trusted Way  What is Sandbox?  Area of Web-Browser Dedicated to Applet  Applet Limited to Sandbox to Prohibit Access to Local Machine/Environment  Utilizes Class Loader, Bytecode Verifier, and Security Manager  Three Components Maintain System Integrity  How Does this Occur?

18. SecBG-18 CSE 333 Core Security Capabilities of Java  Class Loader - Only Load Correct Classes  Bytecode Verifier - Classes in Correct Format  Security Manager - Untrusted Classes Can’t Execute Dangerous Instructions nor Access Protected System Resources  Role of Security Managers  Enforces Boundaries of Sandbox  All Java Classes ask Manager for Permission to Perform Certain Operations  Implements/Imposes Appl. Security Policy  Java Interface Class Implementable by Users  Integrated with Exception Handling of Java

19. SecBG-19 CSE 333 Recall Java Bytecode Verification:

20. SecBG-20 CSE 333 Digital Signatures and JAR Files  When Can Applets Become Applications?  Trusted Publisher (Originator of Applet)  Signed Applet is Authenticated  Java Security Manager May Allow Applet out of Sandbox to be Application  How is Information Transmitted and Exchanged?  JAR: Archived (Compressed) Files  Bundling of Code/Data into Java Archive  Associated Digital Signature for Verification  Transmission via Object Serialization

21. SecBG-21 CSE 333 Database Security Approach  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  Users have Dedicated and Shared DB Items  DB Items Shared by User Groups vs. DB Items Globally Shared  Users Spawn Clients that Access DB Items  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

22. SecBG-22 CSE 333 Database Security  Types of Security  Database Security is Mainly Related with Access Rights to the Database  Database Security Involves Issues Such as  Governmental or Corporate Level of Policies  Privacy and Confidentiality Requirements  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)  Access Control is Mechanism to Prevent Unauthorized Access to Databases

23. SecBG-23 CSE 333 Database Security  Database Administrator (DBA) has the Privileged Commands to Perform the Following on Databases  Account Creation  Privilege Granting  Privilege Revocation  Security Level Assignments  Elements of the Security Model  Subjects (Principals)  Objects (Data)  Access Methods (How to Use)  Policies (Application Dictated)  Authorizations (Who Can Do What)  Authentication and Enforcement (Runtime)

24. SecBG-24 CSE 333 Available Security Approaches  Mandatory Access Control (MAC)  Bell/Lapadula Security Model  Security Classification Levels for Data Items  Access Based on Security Clearance of User  Role Based Access Control (RBAC)  Govern Access to Information based on Role  Users can Play Different Roles at Different Times Responsibilities of Users Guiding Factor  Facilitate User Interactions while Simultaneously Protecting Sensitive Data  Discretionary Access Control (DAC)  Richer Set of Access Modes - Govern Access to Information based on User Id  Discretionary Rules on Access Privileges  Focused on Application Needs/Requirements

25. SecBG-25 CSE 333 What are Key Access Control Concepts? What are Key Access Control Concepts?  Assurance  Are the Security Privileges for Each User Adequate to Support their Activities?  Do the Security Privileges for Each User Meet but Not Exceed their Capabilities?  Consistency  Are the Defined Security Privileges for Each User Internally Consistent?  Least-Privilege Principle: Just Enough Access  Are the Defined Security Privileges for Related Users Globally Consistent?  Mutual-Exclusion: Read for Some-Write for Others

26. SecBG-26 CSE 333 Mandatory Access Control  Bell-Lapadula Model [1976]  An Extension of the Access Matrix Model  The Model is Based on Subject-Object Paradigm  Subjects: Active Elements  Objects: Passive Elements  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

27. SecBG-27 CSE 333 Mandatory Security Mechanism  Typical Security Classification Levels for Subjects/programs and Objects/resources  Top Secret (TS) and Secret (S)  Confidential (C) and Unclassified (U)  Rules:  TS is the Highest and U is the Lowest Level  TS > S > C > U  Security Levels:  C1 is Security Clearance Given to User U1  C2 is Security Classification Given to Object O1  U1 can Access O1 iff C1  C2  This is Referred to as the Domination of U1 Over O1

28. SecBG-28 CSE 333Operations  Get access  Initiate access to object in the given mode  Release access  Terminate access previously started by get  Given access  grant an access mode on an object to a subject  Rescind access  Revoke access previously granted with the “give” operation  Create object  An object may be inactive or active; this takes an inactive object and adds to the object hierarchy  Delete object  Deactivates an active object  Change subject security level  Change object security level

29. SecBG-29 CSE 333 Mandatory Security Mechanism  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)  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)  This Insures that a Subject S cannot Read Information Above his/her Security Level TSSCU User (S)Read Down

30. SecBG-30 CSE 333 Mandatory Security Mechanism  Simple Integrity Property (Write Down–No Write Up)  A Subject May Write an Object only if that Object is at or Below the Subject’s Security Clearance  S Can Write O iff Clearance(S) ≥ Classification(O)  This Allows the Potential of Information Flow from Higher Classification to Lower Classification Levels  This Prevents the Ability of a Subject S to Corrupt Data above its Security Level  Security Designer Must Choose their Poison! TSSCU User (S)Write Down

31. SecBG-31 CSE 333 Mandatory Security Mechanism  Liberal * Property (Write Up–No Write Down)  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  Such an Attempt can be Overt or Unintentional  Likewise, this Allows a Subject to Corrupt Information above its Level TSSCU User (S)Write Up

32. SecBG-32 CSE 333 Mandatory Security Mechanism  Strict * Property (Read/Write Equal)  A Subject May Only Read/Write an Object that has the Exact Same Security Class than the Subject’s Security Clearance  S Can Read/Write O iff Clearance(S) = Classification(O)  This Limits Information Flow to within a Level TSSCU User (S) Read Equal Write Equal

33. SecBG-33 CSE 333 Using the Properties  Security Policy is Typically a Combination of one Read and one Write Property  Simple Security + Simple Integrity  Simple Security + Strict * (Write)  Simple Security + Liberal *  Strict * (Read) + Simple Integrity  Strict * (Read) + Strict * (Write)  Strict * (Read) + Liberal *  Objective: Security Engineer Must Choose the Most Appropriate Combination for their Application

34. SecBG-34 CSE 333 A Classic Example  Simple Security for Reads  See Information at User Clearance Level and Lower (Less Secure)  No Chance of Viewing TS Information  Liberal * for Writes  Write Information at User Clearance Level and Above (More Secure)  No Chance of Releasing “S” Data to Lower Levels TSSCU User (S) Write Up Read Down

35. SecBG-35 CSE 333 Illustrating MAC  Consider the EMPLOYEE Table Below with Two Instances  Notice Classifications on Each Tuple (TC)  Notice Classifications on Each Attribute Value  Interpretation:  Limit Who Can See Each Tuple and Values  Focus on User Clearance w.r.t. Classifications

36. SecBG-36 CSE 333 Illustrating MAC  Whenever a User Attempts to Access a Table, the Table is Filtered According to U’s Clearance  First Set are for a User at Confidential Level  Second Set is For a User at Unclassified Level

37. SecBG-37 CSE 333 Security in Software Applications  Extensive Published Research (Demurjian, et al) in Last Ten Years for DAC/RBAC for OO  Efforts in  Automatically Generatable and Reusable Enforcement Mechanisms  MAC/DAC/RBAC within Distributed Setting  Premise:  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  Please see: www.engr.uconn.edu/~steve/DSEC/desc.html

38. SecBG-38 CSE 333 What is Role Based Access Control (RBAC)?  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:  Occurs at Type-Level  Different Portions of Public Interface Available to Different Users at Different Times Depending on User-Roles  Promote Potential Public Interface

39. SecBG-39 CSE 333 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?

40. SecBG-40 CSE 333 Why is RBAC Needed?  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  Lois playing the Nurse Role would be Allowed to Enter Patient History, Record Vital Signs, etc.  Steve playing M.D. Role would be Allowed to do all of a Nurse plus Write Orders, Enter Scripts, etc.  Vicky playing Admin Role would be Allowed to Enter Demographic/Insurance Info.  Role Dictates Client Behavior

41. SecBG-41 CSE 333 Why is RBAC Needed?  Many Situations When Application 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

42. SecBG-42 CSE 333 Examples of Why RBAC is Needed  In HTSS, the public interface for Items has methods that read (for Scanner, I-Controller) and modify instances (only for I-Controller)  Read Methods Targeted for Certain System Functions (e.g., Scan Item)  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  Physician’s Write Scripts  Nurses Enter Patient Data (Vitals + History)  All Access Shared Medical Record  Access is Limited Based on Role

43. SecBG-43 CSE 333 public class PatientRecord { private: Data/Methods as Needed; public: write_medical_history(); write_prescription(); get_medical_history(); get_diagnosis(); set_payment_mode(); etc… For MDs and Nurses For MDs Only For Admitting RBAC for OO RBAC for OO  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

44. SecBG-44 CSE 333 Sample RBAC Hierarchy for HCA Users Medical_Staff NursePhyscian UR:Manager UR:Staff_RN UR:Education UR:Discharge_Plng UR:PrivateUR:Attending Support_Staff Etc. Technician UR:Director UR:LabUR:Pharmacy UR:Radiology

45. SecBG-45 CSE 333 Sample RBAC Hierarchy for University Users / \ +---+ +-----+ / \ non-academic-staff academic-staff / \ \ / \ \.... / \ \ / \ purchasing campus-police... dept-staff registrar-staff... / \...... / \ grade-recording transcript-issuing

46. SecBG-46 CSE 333 Discretionary Access Control  Discretionary  Grant Privileges to Users, Including the Capabilities to Access Specific Data Items in a Specific Mode  Available in Most Commercial DBMSs  Aspects of DAC  User’s Identity  Predefined Discretionary “Rules” Defined by the Security Administrator  Focus on Two Variants of this Model  Access Matrix Model  Lampson’s Protection System  Role Delegation and Delegation Authority  Detail DAC in SQL2

47. SecBG-47 CSE 333 Access Matrix Model  Proposed by Harrison, Ruzzo, and Ullman, 1976  Basic Concepts are  S: Set of Subjects (Principals)  O: Set of Objects (Data Items)  A: The Access Matrix (Who can do What)  Rows Correspond to the Subjects  Columns Correspond to the Objects  We’ll see a Variant of this in Lampson

48. SecBG-48 CSE 333 Access Matrix Model  Conditions Associated with Access Authorization  Data-Dependent  Specifying Constraints on the Value of Accessed Data  Time-Dependent  Specifying Constraints on the Time When an Access can Take Place  Context-Dependent  Specifying Constraints on Combinations of Data Which can be Accessed  History-Dependent:  Specifying Constraints Dependent on Previously Performed Accesses

49. SecBG-49 CSE 333 O1 …. Oi …. Om object subject S1 S2 …. Sn A[S1,O1] A[S1,Oi] A[S1,Om] A[S2,O1] A[S2,Oi] A[S2,Om] A[Sn,O1] A[Sn,Oi] A[Sn,Om] Access Matrix Model  An Example  Object Types:  Relations, Views, Rows (records), Columns, Operations  Subject Types:  Users, Accounts, Programs

50. SecBG-50 CSE 333 Access Modes  Access Modes  Read, Write, Append, and Execute  Authorization  A[S,O] is an Entry in the Access Matrix  A[S,O] can be Authorized to One or More Operations  Mechanisms  - Add a Row  create> - Add a Column  - Remove a Row  - Remove a Column  <operation x into A[Si, Oj]  <operation x from A[Si, Oj]

51. SecBG-51 CSE 333 What is Role Delegation?  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  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

52. SecBG-52 CSE 333 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?

53. SecBG-53 CSE 333 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

54. SecBG-54 CSE 333 Delegation/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

55. SecBG-55 CSE 333 Example - Role Delegation   General DoBest Delegates his Role CDR_CR1 (Commander, Crisis 1) 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]]

56. SecBG-56 CSE 333 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]]

57. SecBG-57 CSE 333 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).

58. SecBG-58 CSE 333 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.

59. SecBG-59 CSE 333 Monotonicity and Permanence   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  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

60. SecBG-60 CSE 333 Totality and Administration  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  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

61. SecBG-61 CSE 333Revocation  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  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

62. SecBG-62 CSE 333 DAC in SQL2  SQL2 Uses the Concept of Authorization Identifier  User Group (could be Single User)  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  Account Level - DBA Manages the Accounts for to Authorize Users to Different DBs  Relation/Table Level - Controlling Access to Each Relation or View in a DB  Objective  Manage and Administer  Design/Realize the Security Policy

63. SecBG-63 CSE 333 Privileges in SQL  Allocated at a Relation Level  SELECT Privilege -  Gives Account Retrieval Access  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  REFERENCES Privilege  Gives Account the Ability re. Integrity Constraints  Can be Restricted to Certain Attributes of Relation  Commands to both GRANT and REVOKE are Supported

64. SecBG-64 CSE 333 Example Schema  Consider Two Database Tables:  EMPLOYEE  (NAME, SNN, BDATE, ADDRESS, SET, SALARY, DNO)  DEPARTMENT  (D#, DNAME, MGRSNN)  Consider Four Accounts/Users:  U1, U2, U3 and U4  Limit U1 to be Able to Create Schema  In SQL  GRANT CREATETAB TO U1;  In SQL2  CREATE SCHEMA EXAMPLE AUTHORIZATION U1;  U1 Can Create Tables In Schema EXAMPLE

65. SecBG-65 CSE 333 SQL Examples  Suppose U1 Wants to Grant U2 the Ability to Insert and Delete into EMPLOYEE and DEPARTMENT  U1 Wants to Disallow Ability of U2 to Propagate (Delegate) Insert/Delete to Other Users  GRANT INSERT, DELETE ON EMPLOYEE, DEPARTMENT TO U2;  Suppose U1 Wants to Grant U3 the Ability to Select from EMPLOYEE and DEPARTMENT  U1 Allows U3 to Propagate to Other Users  GRANT SELECT ON EMPLOYEE TO U3 WITH GRANT OPTION;  Now, U3 can:  GRANT SELECT ON EMPLOYEE TO U4;  U4 Cannot Propagate/Delegate this Privilege

66. SecBG-66 CSE 333 SQL Examples  Suppose U1 Wants to REVOKE U3 the Ability to Select from EMPLOYEE and DEPARTMENT  REVOKE SELECT ON EMPLOYEE TO U3;  Database Must Also Cascade this Revoke to U4 Since U3 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!

67. SecBG-67 CSE 333 SQL Examples  Suppose that U1 wants to Give Back to U3 a Limited Capability to SELECT from EMPLOYEE  Also Allow U3 to be able to Propagate  U1 First Creates a View create view U3_EMP as select NAME, BDATE, ADDRESS from EMPLOYEE where DNO = 5;  U1 Now Grants the View  GRANT SELECT ON U3_EMP TO U3 WITH GRANT OPTION;  U1 Can also Grant Limited Update  GRANT UPDATE ON EMPLOYEE (SAL) TO U4;

68. SecBG-68 CSE 333Cryptography  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 plaintextciphertext encryption decryption

69. SecBG-69 CSE 333 plaintext Encrypt Decrypt KeKe KdKd C = E Ke (plaintext) More on Cryptography Invader Side informationplaintext

70. SecBG-70 CSE 333 Cryptographic Systems Conventional or Symmetric Systems Modern Systems Private KeyPublic Key K e and K d are essentially the same K e and K d are private K e is public K d is private Cryptographic Systems

71. SecBG-71 CSE 333  Statistical Databases are used to Produce Statistics on Various Populations  Individual Information is Considered Confidential  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:  Suppose we are Allowed to Retrieve Only the Statistical Information Over this Relation by Using SUM, AVG, MIN, MAX, COUNT, Etc. Person(name, ssn, income, address,city, state, zip, sex, last_degree) Statistical Database Security

72. SecBG-72 CSE 333 select COUNT(*) from Person where last_degree = “ph.D.” and sex = “F” and city = “Calgary” and state = “Alberta”; select AVG(income) from Person where last_degree = “ph.D.” and sex = “F” and city = “Calgary” and state = “Alberta”; Q1: find the total number of women who have ph.D. and live in Calgary, Alberta. Q1: find the average income of women who have ph.D. and live in Calgary, Alberta. Example of Statistical DB  Consider Q1 and Q2:  Suppose Mary Black is a Ph.D who Lives in Calgary and we want to know her Income, which is Prohibited  If Query Q1 Returns One Tuple, then the Result of Q2 is the Income of Mary  Otherwise we May Issue a Number of Subsequent Queries Using MAX and MIN, we May Easily Obtain a Close Range of Mary’s Income

73. SecBG-73 CSE 333  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 Q3 (left) and Q4 (right) below:  Since Connie Knows her Own Income, by Calculating Q4 - (Q3 - Connie’s Income), She Determinds Mary’s Income select SUM(income) from Person where last_degree = “ph.D.” and sex = “F” and city = “Calgary” and state = “Alberta”; and name <> “Mary” select SUM(income) from Person where last_degree = “ph.D.” and sex = “F” and city = “Calgary” and state = “Alberta” and name <> “Connie”; Example Two of Statistical DB

74. SecBG-74 CSE 333 Statistical Database Security  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:  Statistical Queries are not Permitted if the Number of Tuples in the Population Specified by the Selection Condition Falls Below Some Threshold  Restricting the Number of Tuples in the Intersection of Subsequent Query Results  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!

75. SecBG-75 CSE 333 Public Policy on Security  How do we Protect a Person’s DNA?  Who Owns a Person’s DNA?  Who Can Profit from Person’s DNA?  Can Person’s DNA be Used to Deny Insurance? Employment? Etc.  How do you Define Security Limitations/Access?  Can DNA Repositories be Anonymously Available for Medical Research?  Do Societal Needs Trump Individual Rights?  Can DNA be Made Available Anonymously for Medical Research?  International Repository Might Allow Medical Researchers Access to Large Enough Data Set for Rare Conditions (e.g., Orphan Drug Act)  Individual Rights vs. Medical Advances

76. SecBG-76 CSE 333 Security Solutions for Systems/Databases UConn Storrs UConn Health Center Yale Johns Hopkins Pfizer Bayer NIHFDA NSF Info. Sharing - Joint R&D Company and University Partnerships Collaborative Funding Opportunities Retrofit Security Infrastructure Cohesive and Trusted Environment Existing Systems/Databases and New Applications How do you Protect Commercial Interests? Promote Research Advancement? Free Read for Some Data/Limited for Other? Commercialization vs. Intellectual Property? Balancing Cooperation with Propriety

77. SecBG-77 CSE 333 Concluding Remarks  Security in DB 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