Upload
eugenia-bishop
View
234
Download
0
Tags:
Embed Size (px)
Citation preview
Security_BG-1
CSE4701
Chapters 23 6e - 22 5e: Security
Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department
The University of Connecticut371 Fairfield Road, Box U-1155
Storrs, CT [email protected]
http://www.engr.uconn.edu/~steve(860) 486 - 4818
The majority of these slides represent material that has been accumulated from various 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-2
CSE4701
Overview 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
Mandatory Access Control (MAC) Discretionary Access Control (DAC) Role-Based Access Control (RBAC)
DB Security, Cryptography, Security in Statistical DB Middleware Security Web Based Security Concluding Remarks
Security_BG-3
CSE4701
Motivation: General Concepts Authentication
Proving you are who you are Signing a Message Is Client who s/he Says they are?
Authorization Granting/Denying Access Revoking Access Does 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 and Public Key Encryption
Security_BG-4
CSE4701
Motivation: Type of Security Issues Legal and Ethical Issues
Information that Must be Protected Information that Must be Accessible HIPPA vs. Emergent Health Situations
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? Web Server? Client? How Do All of the Pieces Interact?
Multiple Security Levels/Organizational Enforcement Mapping Security to Organizational Hierarchy Protecting Information in Organization
Security_BG-5
CSE4701
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.
Security_BG-6
CSE4701
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
Security_BG-7
CSE4701
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.)
Security_BG-8
CSE4701
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
Security_BG-9
CSE4701
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
Security_BG-10
CSE4701
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
Security_BG-11
CSE4701
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
Security_BG-12
CSE4701
DB 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
Security_BG-13
CSE4701
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… For PHR – Patient Defines Policy
Protection Mechanisms Authenticate Access to DB Items, File and Memory Protection What is the Granularity of Access?
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
Security_BG-14
CSE4701
Authentication User/Process Authentication
Is this User/Client Who It Claims to Be? Passwords More Sophisticated Mechanisms Need for Re-authentication
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
Security_BG-15
CSE4701
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?
Security_BG-16
CSE4701
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 – EMR’s Treating
Accident Victim? Past Invasion of Engineering Computing
yppasswd File Stolen/Decrypted S. Demurjian’s Sun Workstation Corrupted
Security_BG-17
CSE4701
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? 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?
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
Security_BG-18
CSE4701
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?
Why is this Relevant for BMI Applications? Pervasive Usage of Applets and Client Java Code
Security_BG-19
CSE4701
Core Security Capabilities of Java Class Loader - Only Load Correct Classes Bytecode Verifier - Classes in Correct Format
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 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
Security_BG-20
CSE4701
Recall Java Bytecode Verification:
Security_BG-21
CSE4701
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
Again, for BMI Web Applications to PCs, PDAs, and Cells Pervasiveness of Technology and Potential for
Misuse and Information Release
Security_BG-22
CSE4701
Available Access Control 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
Security_BG-23
CSE4701
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
Security_BG-24
CSE4701
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
Security_BG-25
CSE4701
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
Security_BG-26
CSE4701
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
Security_BG-27
CSE4701
Mandatory Security Mechanism Restriction (Axiom 1):
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)
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 Depending on the Desired MAC, Different Axioms
Can be Employed that Satisfy Different Criteria ofClearance Dominating Classification
Security_BG-28
CSE4701
Other Axioms Simple Security (SS) Property
Subject S may have Read(Write) Access to Object O iff Clearance of S Dominates the Classification of O
Star (*) Property A Subject Can Only Read Objects at or Above
their Level A Subject Can Only Write Objects at or Below
their Level Tranquility Principle
No Subject Can Modify Classification of Active Object
Security_BG-29
CSE4701
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
TS S C U
User (S) Read Down
Security_BG-30
CSE4701
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!
TS S C U
User (S) Write Down
Security_BG-31
CSE4701
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
TS S C U
User (S)Write Up
Security_BG-32
CSE4701
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
TS S C U
User (S)
Read EqualWrite Equal
Security_BG-33
CSE4701
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
Security_BG-34
CSE4701
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
TS S C U
User (S)
Write Up
Read Down
Security_BG-35
CSE4701
Other Axioms Discretionary Property (DS-property)
Every Current Access Must Be Present in the Access Matrix
For All Subjects S, Objects O, and the Access Mode M:
<S,o,m> B M M[s,o] Non-Accessibility of Inactive Objects
A Subject Cannot Read the Contents of an Inactive Object
Rewriting of Inactive Objects A Newly Activated Object is Assigned to an Initial
State Independent of the Previous Activation of the Object
Security_BG-36
CSE4701
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
Security_BG-37
CSE4701
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
Security_BG-38
CSE4701
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
Security_BG-39
CSE4701
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
Security_BG-40
CSE4701
Motivating Security for OO Paradigm OO Paradigm Provides Minimal Support via Public
Interface and Private Implementation Public Interface Represents UNION of all Possible
Privileges Needed by All Potential Users A Method in the Public Interface for One Specific
User Available to ALL Users Can Access to Public Interface be Customized? Can Individuals have Particular Access to Specific
Subsets of Public Interface? Can Access be Based on (Potentially) Dynamic
User Roles? Can Code be Automatically Generated to
Implement an Enforcement Mechanism? Role of OO Paradigm in Support a Generic,
Evolvable, Reusable Enforcement Mechanism?
Security_BG-41
CSE4701
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
Security_BG-42
CSE4701
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
Security_BG-43
CSE4701
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
Security_BG-44
CSE4701
public class PatientRecord { private: Data/Methods as Needed; public: write_medical_history(); write_prescription(); get_medical_history(); get_diagnosis(); set_payment_mode(); etc…
For MDsand Nurses
For MDs Only
For Admitting
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
Security_BG-45
CSE4701
Sample RBAC Hierarchy for HCA
Users
Medical_Staff
Nurse Physcian
UR:Manager
UR:Staff_RN UR:Education
UR:Discharge_Plng
UR:Private UR:Attending
Support_Staff
Etc.
Technician
UR:Director
UR:Lab UR:Pharmacy
UR:Radiology
Security_BG-46
CSE4701
Sample RBAC Hierarchy for University
Users / \ +---+ +-----+ / \ non-academic-staff academic-staff / \ \ / \ \.... / \ \ / \ purchasing campus-police ... dept-staff registrar-staff ... / \ ... ... / \ grade-recording transcript-issuing
Security_BG-47
CSE4701
Sample RBAC Hierarchy for Portal
Users
Medical_Staff
Clinical Researcher Basic User
UR: Poster
UR: ForumLeader
UR: DataAnalyst UR: EdMaterials
UR: etc…
Patients
Etc.
Provider
UR: BasicPHR
UR: Nurse UR: OccTher
UR: Physician
Security_BG-48
CSE4701
NIST RBAC Standard 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 Please Visit the Site … May be Applicable Applications ….
Briefly, Let’s Review …
Security_BG-49
CSE4701
RBAC Model Variants http://csrc.nist.gov/groups/SNS/rbac/documents/towards-
std.pdf Transition from Essential Features to Complex Model
Security_BG-50
CSE4701
Level 1 and Level 2 Level 1: Three States and UA/PA Level 2: Add in Role Hierarchy Look on R State
Security_BG-51
CSE4701
Example Role Hierarchies
Security_BG-52
CSE4701
Constrained RBAC – with SOD
Security_BG-53
CSE4701
Constrained RBAC – with SOD
Security_BG-54
CSE4701
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
Security_BG-55
CSE4701
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
Delegation Vital in Health Care: Provider on-Call, Emergent Situations, DCP …
Security_BG-56
CSE4701
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 Health Care Financial Services Engineering Academic Setting
Key Issues: Who Controls Delegation to Whom? How are Delegation Requirements Enforced?
Security_BG-57
CSE4701
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
Security_BG-58
CSE4701
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
Security_BG-59
CSE4701
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: YesPODA: Yes
After Delegation:
DU: [DoGood, [01dec00, 01jun01], T]UA: [DoGood, CDR_CR1, [01dec00, 01jun01]]
Security_BG-60
CSE4701
Example - Role Delegation 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: YesPODA: No
After Delegation:
DU: [CanDoRight, [01jan01, 01feb01], T]UA: [CanDoRight, CDR_CR1, [01dec00, 01jun01]]
Security_BG-61
CSE4701
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).
Security_BG-62
CSE4701
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.
Security_BG-63
CSE4701
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
Security_BG-64
CSE4701
Totality and Administration 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: 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
Security_BG-65
CSE4701
Revocation 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 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
Security_BG-66
CSE4701
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
Security_BG-67
CSE4701
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
Security_BG-68
CSE4701
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)
Security_BG-69
CSE4701
Available Security Approaches Mandatory Access Control (MAC)
Bell/Lapadula Security Model Security Classification Levels for Data Items Access Based on Security Clearance of User
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
User-Role Based Security (URBS) 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
Security_BG-70
CSE4701
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
Detail DAC in SQL2
Security_BG-71
CSE4701
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
Security_BG-72
CSE4701
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
Security_BG-73
CSE4701
O1 …. Oi …. Omobject
subject
S1S2….
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
Security_BG-74
CSE4701
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]
Security_BG-75
CSE4701
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
Security_BG-76
CSE4701
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
Security_BG-77
CSE4701
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
Security_BG-78
CSE4701
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
Security_BG-79
CSE4701
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!
Security_BG-80
CSE4701
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;
Security_BG-81
CSE4701
Cryptography 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
plaintext ciphertext
encryption
decryption
Security_BG-82
CSE4701 plaintext plaintext
EncryptEncrypt DecryptDecrypt
Ke Kd
C = EKe(plaintext)
More on Cryptography
InvaderInvaderSide information plaintext
Security_BG-83
CSE4701
Cryptographic Systems
Conventional orSymmetric Systems
Modern Systems
Private Key Public Key• Ke and Kd are
essentially the same • Ke and Kd are
private• Ke is public• Kd is private
Cryptographic Systems
Security_BG-84
CSE4701
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.
Vital for Epidemiology and other Clinical Research
Person(name, ssn, income, address,city, state, zip, sex, last_degree)
Statistical Database Security
Security_BG-85
CSE4701
select COUNT(*) from Personwhere last_degree = “ph.D.”and sex = “F”and city = “Calgary”and state = “Alberta”;
select AVG(income) from Personwhere 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
Security_BG-86
CSE4701
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 Personwhere last_degree = “ph.D.”and sex = “F”and city = “Calgary”and state = “Alberta”;and name <> “Mary”
select SUM(income) from Personwhere last_degree = “ph.D.”and sex = “F”and city = “Calgary”and state = “Alberta”and name <> “Connie”;
Example Two of Statistical DB
Security_BG-87
CSE4701
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!
Security_BG-88
CSE4701
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