Chapter 24 6e - 22 5e: Security
CSE
4701
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.
Chapter 24-1
DB Security Approach

CSE
4701



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
Chapter 24-2
Policy & Mechanism

CSE
4701



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 EMR – 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
Chapter 24-3
Authentication

CSE
4701
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
Chapter 24-4
Authorization

CSE
4701





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?
Chapter 24-5
User Authentication

CSE
4701

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
Chapter 24-6
Available Access Control Approaches

CSE
4701


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
Chapter 24-7
What are Key Access Control Concepts?

CSE
4701

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
Chapter 24-8
Mandatory Access Control

CSE
4701
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
Chapter 24-9
Mandatory Security Mechanism

CSE
4701

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
Chapter 24-10
Operations

CSE
4701







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
Chapter 24-11
Mandatory Security Mechanism

CSE
4701
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 of
Clearance Dominating Classification
Chapter 24-12
Other Axioms

CSE
4701


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
Chapter 24-13
Mandatory Security Mechanism

CSE
4701


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
User (S)
C
U
Read Down
Chapter 24-14
Mandatory Security Mechanism

CSE
4701

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
User (S)
C
U
Write Down
Chapter 24-15
Mandatory Security Mechanism

CSE
4701

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
Write Up User (S)
Chapter 24-16
Mandatory Security Mechanism

CSE
4701
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
Read Equal
Write Equal
User (S)
Chapter 24-17
Using the Properties

CSE
4701

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
Chapter 24-18
A Classic Example

CSE
4701

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
User (S)
TS
S
Read Down
C
U
Write Up
Chapter 24-19
Illustrating MAC

CSE
4701

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
Chapter 24-20
Illustrating MAC

CSE
4701
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
Chapter 24-21
What is Role-Based Access Control?

CSE
4701




Define Roles to Capture Job Responsibilities/Tasks
Define Permissions for Each Role
 What Objects are Allowed?
 What Operations (R, W, I, D) are Allowed?
Define a Hierarchy of Roles for an Organization
Users are
 Assigned one or More Roles
 Limited to one Role per Session
Example: John a Professor Could have
 Faculty Role
 Advisor Role
 Dept Head Role
 Etc.
Chapter 24-22
Why is RBAC Needed?

CSE
4701

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
Chapter 24-23
Sample RBAC Hierarchy for HCA
CSE
4701
Users
Medical_Staff
Support_Staff
Etc.
Nurse
Physcian
Technician
UR:Lab
UR:Pharmacy
UR:Radiology
UR:Staff_RN
UR:Education
UR:Private
UR:Attending
UR:Director
UR:Manager
UR:Discharge_Plng
Chapter 24-24
Sample RBAC Hierarchy for University
CSE
4701
Users
/ \
+---+
+-----+
/
\
non-academic-staff
academic-staff
/
\
\
/
\
\....
/
\
\
/
\
purchasing
campus-police
...
dept-staff registrar-staff
...
/
\
...
...
/
\
grade-recording transcript-issuing
Chapter 24-25
NIST RBAC Standard

CSE
4701




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 …
Chapter 24-26
RBAC Model Variants
CSE
4701

http://csrc.nist.gov/groups/SNS/rbac/documents/towards-std.pdf

Transition from Essential Features to Complex Model
Chapter 24-27
Level 1 and Level 2

CSE
4701

Level 1: Three States and UA/PA
Level 2: Add in Role Hierarchy Look on R State
Chapter 24-28
Example Role Hierarchies
CSE
4701
Chapter 24-29
Constrained RBAC – with SOD
CSE
4701
Chapter 24-30
Constrained RBAC – with SOD
CSE
4701
Chapter 24-31
Discretionary Access Control

CSE
4701




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
Chapter 24-32
What is Role Delegation?

CSE
4701



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 …
Chapter 24-33
Why is Role Delegation Important?

CSE
4701
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?
Chapter 24-34
What Can be Delegated?

CSE
4701



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
Chapter 24-35
Delegation/Pass on Delegation Authorities

CSE
4701
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
Chapter 24-36
Database Security Approach

CSE
4701



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
Chapter 24-37
Database Security

CSE
4701
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
Chapter 24-38
Database Security

CSE
4701

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)
Chapter 24-39
Available Security Approaches

CSE
4701


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
Chapter 24-40
Discretionary Access Control

CSE
4701



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
Chapter 24-41
DAC in SQL2

CSE
4701



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
Chapter 24-42
Privileges in SQL

CSE
4701
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
Chapter 24-43
Example Schema

CSE
4701
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
Chapter 24-44
SQL Examples

CSE
4701
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
Chapter 24-45
SQL Examples

CSE
4701
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!





Chapter 24-46
SQL Examples

CSE
4701
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;
Chapter 24-47
Concluding Remarks

CSE
4701

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
Chapter 24-48