Security Concepts and Capabilities

1. Security Concepts and Capabilities • 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. 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

2. Overview • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Authentication • 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. Authorization • 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. 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. 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. 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. 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. Recall Java Bytecode Verification:

20. 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. 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. 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. 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. 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. 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. 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. 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. Operations • 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. Mandatory Security Mechanism TS S C U • 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 User (S) Read Down

30. Mandatory Security Mechanism TS S C U • 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! User (S) Write Down

31. Mandatory Security Mechanism TS S C U • 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 Write Up User (S)

32. Mandatory Security Mechanism TS S C U • 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 Read Equal Write Equal User (S)

33. 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. A Classic Example TS S C U • 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 Read Down User (S) Write Up

35. 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. 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. 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. 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. 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. 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. 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. 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. RBAC for OO 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 Only For MDs and Nurses For Admitting • 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. Sample RBAC Hierarchy for HCA Users Medical_Staff Support_Staff Etc. Nurse Physcian Technician UR:Lab UR:Pharmacy UR:Radiology UR:Private UR:Attending UR:Education UR:Staff_RN UR:Director UR:Discharge_Plng UR:Manager

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

46. 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. 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. 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. Access Matrix Model object O1 …. Oi …. Om subject A[S1,O1] A[S1,Oi] A[S1,Om] S1 S2 …. Sn A[S2,O1] A[S2,Oi] A[S2,Om] A[Sn,O1] A[Sn,Oi] A[Sn,Om] • An Example • Object Types: • Relations, Views, Rows (records), Columns, Operations • Subject Types: • Users, Accounts, Programs

50. 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 • <create> <subject Si > - Add a Row • create> <object Oj> - Add a Column • <destroy> <subject Si > - Remove a Row • <destroy> <object Oj> - Remove a Column • <enter> <operation x into A[Si, Oj] • <delete> <operation x from A[Si, Oj]