Download finsecuritybackground - University of Connecticut

Security Concepts and Capabilities
CSE
333
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.
SecBG-1
Overview

CSE
333








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
SecBG-2
Introduction: General Concepts

CSE
333


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
SecBG-3
Type of Security Issues

CSE
333



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
SecBG-4
Glossary of Protection and Security Terms

CSE
333

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.
SecBG-5
Glossary of Protection and Security Terms

CSE
333


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
SecBG-6
Glossary of Protection and Security Terms

CSE
333


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.)
SecBG-7
Glossary of Protection and Security Terms

CSE
333



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
SecBG-8
Glossary of Protection and Security Terms

CSE
333
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
SecBG-9
Glossary of Protection and Security Terms

CSE
333


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
SecBG-10
Glossary of Protection and Security Terms

CSE
333


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
SecBG-11
Policy & Mechanism

CSE
333



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
SecBG-12
Authentication

CSE
333
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
SecBG-13
Authorization

CSE
333





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?
SecBG-14
User Authentication

CSE
333

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
SecBG-15
Network Authentication

CSE
333


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
SecBG-16
Core Security Capabilities of Java

CSE
333

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?
SecBG-17
Core Security Capabilities of Java

CSE
333



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
SecBG-18
Recall Java Bytecode Verification:
CSE
333
SecBG-19
Digital Signatures and JAR Files

CSE
333

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
SecBG-20
Database Security Approach

CSE
333



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
SecBG-21
Database Security

CSE
333
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
SecBG-22
Database Security

CSE
333

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)
SecBG-23
Available Security Approaches

CSE
333


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
SecBG-24
What are Key Access Control Concepts?

CSE
333

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
SecBG-25
Mandatory Access Control

CSE
333
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
SecBG-26
Mandatory Security Mechanism

CSE
333

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
SecBG-27
Operations

CSE
333







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
SecBG-28
Mandatory Security Mechanism

CSE
333


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
SecBG-29
Mandatory Security Mechanism

CSE
333

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
SecBG-30
Mandatory Security Mechanism

CSE
333

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)
SecBG-31
Mandatory Security Mechanism

CSE
333
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)
SecBG-32
Using the Properties

CSE
333

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
SecBG-33
A Classic Example

CSE
333

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
SecBG-34
Illustrating MAC

CSE
333

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
SecBG-35
Illustrating MAC

CSE
333
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
SecBG-36
Security in Software Applications

CSE
333



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
SecBG-37
What is Role Based Access Control (RBAC)?

CSE
333


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
SecBG-38
Motivating Security for OO Paradigm

CSE
333


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?
SecBG-39
Why is RBAC Needed?

CSE
333

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
SecBG-40
Why is RBAC Needed?

CSE
333

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
SecBG-41
Examples of Why RBAC is Needed

CSE
333

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
SecBG-42
RBAC for OO

CSE
333



Public Interface is Union of All Privileges for All
Potential Users No Explicit way to Prohibit Access
Customizable Public Interface of Class
Access to Public Interface is Variable and Based on
User Needs and Responsibilities
Only Give Exactly What’s Needed and No More
public class PatientRecord
{ private: Data/Methods as Needed;
public:
write_medical_history();
write_prescription();
For MDs
get_medical_history();
and Nurses
get_diagnosis();
set_payment_mode();
etc…
For MDs Only
For Admitting
SecBG-43
Sample RBAC Hierarchy for HCA
CSE
333
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
SecBG-44
Sample RBAC Hierarchy for University
CSE
333
Users
/ \
+---+
+-----+
/
\
non-academic-staff
academic-staff
/
\
\
/
\
\....
/
\
\
/
\
purchasing
campus-police
...
dept-staff registrar-staff
...
/
\
...
...
/
\
grade-recording transcript-issuing
SecBG-45
Discretionary Access Control

CSE
333




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
SecBG-46
Access Matrix Model

CSE
333

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
SecBG-47
Access Matrix Model

CSE
333
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
SecBG-48
Access Matrix Model

CSE
333
An Example
 Object Types:
 Relations, Views, Rows (records), Columns,
Operations

Subject Types:
 Users, Accounts, Programs
object
subject
S1
S2
….
Sn
O1
….
Oi
….
Om
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]
SecBG-49
Access Modes

CSE
333


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]
SecBG-50
What is Role Delegation?

CSE
333


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
SecBG-51
Why is Role Delegation Important?

CSE
333
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?
SecBG-52
What Can be Delegated?

CSE
333



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
SecBG-53
Delegation/Pass on Delegation Authorities

CSE
333
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
SecBG-54
Example - Role Delegation

CSE
333

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]]
SecBG-55
Example - Role Delegation

CSE
333
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]]
SecBG-56
Role Delegation Revocation Rules

CSE
333
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).
SecBG-57
Role Delegation Revocation Rules

CSE
333

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.
SecBG-58
Monotonicity and Permanence

CSE
333

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
SecBG-59
Totality and Administration

CSE
333

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, Agentdirected) is when Control is with the Security
Officer
SecBG-60
Revocation

CSE
333

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
SecBG-61
DAC in SQL2

CSE
333



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
SecBG-62
Privileges in SQL

CSE
333
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
SecBG-63
Example Schema

CSE
333
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
SecBG-64
SQL Examples

CSE
333
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
SecBG-65
SQL Examples

CSE
333
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!





SecBG-66
SQL Examples

CSE
333
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;
SecBG-67
Cryptography

CSE
333



Information can be Encoded Using a Key it is Written
(or Transferred) -- Encryption
Information is then Decoded Using a Key When it is
Read (or Received) -- Decryption
Very Widely Used for Secure Network Transmission
Mathematical Basis - Prime Number Generation
encryption
plaintext
ciphertext
decryption
SecBG-68
More on Cryptography
CSE
333
plaintext
plaintext
Ke
Encrypt
Side information
Kd
C = EKe(plaintext)
Invader
Decrypt
plaintext
SecBG-69
Cryptographic Systems
CSE
333
Cryptographic Systems
Modern Systems
Conventional or
Symmetric Systems
•Ke and Kd are
Private Key
Public Key
essentially the
same
•Ke and Kd are
•Ke is public
private
•Kd is private
SecBG-70
Statistical Database Security

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:
Person(name, ssn, income, address,city,
state, zip, sex, last_degree)

Suppose we are Allowed to Retrieve Only the
Statistical Information Over this Relation by Using
SUM, AVG, MIN, MAX, COUNT, Etc.
SecBG-71
Example of Statistical DB

CSE
333
Consider Q1 and Q2:
Q1: find the total number of women
who have ph.D. and live in Calgary,
Alberta.
select COUNT(*)
from Person
where last_degree = “ph.D.”
and
sex = “F”
and
city = “Calgary”
and
state = “Alberta”;

Q1: find the average income of women
who have ph.D. and live in Calgary,
Alberta.
select AVG(income)
from Person
where last_degree = “ph.D.”
and
sex = “F”
and
city = “Calgary”
and
state = “Alberta”;
Suppose Mary Black is a Ph.D who Lives in Calgary and we
want to know her Income, which is Prohibited
 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
SecBG-72
Example Two of Statistical DB

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:
select
from
where
and
and
and
and

SUM(income)
Person
last_degree = “ph.D.”
sex = “F”
city = “Calgary”
state = “Alberta”;
name <> “Mary”
select
from
where
and
and
and
and
SUM(income)
Person
last_degree = “ph.D.”
sex = “F”
city = “Calgary”
state = “Alberta”
name <> “Connie”;
Since Connie Knows her Own Income, by Calculating
Q4 - (Q3 - Connie’s Income), She Determinds Mary’s
Income
SecBG-73
Statistical Database Security

CSE
333


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!
SecBG-74
Public Policy on Security

CSE
333


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
SecBG-75
Security Solutions for Systems/Databases
CSE
333
Pfizer
UConn
Health
Center
UConn
Storrs
Johns
Yale
Hopkins
Bayer
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?
NIH
FDA
NSF
Balancing Cooperation with Propriety
SecBG-76
Concluding Remarks

CSE
333

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
SecBG-77