Security Concepts and Capabilities

1
Security Concepts and Capabilities
Prof. Steven A. Demurjian, Sr. Computer Science
Engineering Department The University of
Connecticut 371 Fairfield Road, Box
U-1155 Storrs, CT 06269-1155
steve_at_engr.uconn.edu http//www.engr.uconn.edu/st
eve (860) 486 - 4818

• The majority of these slides represent material
  that has been accumulated from various sources
  over the years.
• A portion these slides are being used with the
  permission of Dr. Ling Lui, Associate Professor,
  College of Computing, Georgia Tech.

2
Overview

• Concepts and Issues
• Glossary of Security Terms
• Security Policy, Authentication, and
  Authorization
• Security in Java
• Database Security
• Access Control
• Mandatory Access Control (MAC)
• Discretionary Access Control (DAC)
• Role-Based Access Control (RBAC)
• Cryptography
• Security in Statistical DB
• Emerging Security Trends

3
Introduction General Concepts

• Authentication
• Proving you are who you are
• Signing a Message
• Is the Client who S/he Says they are?
• Authorization
• Granting/Denying Access
• Revoking Access
• Does the Client have Permission to do what S/he
  Wants?
• Encryption
• Establishing Communications Such that No One but
  Receiver will Get the Content of the Message
• Symmetric Encryption
• Public Key Encryption

4
Type of Security Issues

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

5
Glossary of Protection and Security Terms

• Principal
• Entity (Person/Process/etc.) to Which
  Authorizations are Granted
• Can be a User, User Group, Program, Client, etc.
• Also Known as Subject
• Protected Object
• Known Object whose Internal Structure is
  Inaccessible Except by Protection System
• The Unit of Protection
• For Our Purposes
• Table, Column, Tuple
• Data and Meta-Data
• Glossary from Saltzer and Schroeder, The
  Protection of Information in Computer Systems,
  Proc. of IEEE, Vol. 63, No. 9, September 1975.

6
Glossary of Protection and Security Terms

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

7
Glossary of Protection and Security Terms

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

8
Glossary of Protection and Security Terms

• Confinement
• Restricting What a Process Can Do to with
  Authorized Objects
• Similar in Concept to Sandbox of Java
• Domain
• Objects Currently Accessed by Principal
• (De)Encryption
• De(Encoding) of Data According to Transformation
  Key for Transmission/Storage
• Reciprocal Activity - Many Different Options
• Grant
• Authorize Access to Objects by Principals
• Who Can do What When

9
Glossary of Protection and Security Terms

• Password
• Encrypted Character String to Authenticate
  Identity of Individual
• Critical to Encrypt Also from Client to Login
  Server
• Client Types in Plain Text that is Encrypted
• Encrypted login Travels of Network
• Decrypted at Login Server and Verified
• Permission
• Form of Allowed Access to Object (R, W, RW)
• Level of Access is System Dependent
• Unix File System has
• r, w, x for User, Group, and Other

10
Glossary of Protection and Security Terms

• Privacy
• Ability to Decide Whether, When, and to Whom
  Information is Released
• Is Anyone Intercepting Client/Server
  Communications?
• Propagation
• Principal Passing on Authorization to Object to
  Another Principal
• Current Term Today is Delegation
• Principal Must be Authorized to Delegate
  Privileges to Another Principal
• Enforcement Mechanism
• Centralized and Distributed Code
• Enforces Security Policy at Runtime

11
Glossary of Protection and Security Terms

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

12
Policy Mechanism

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

13
Authentication

• User/Process Authentication
• Is this User/Client Who It Claims to Be?
• Passwords
• More Sophisticated Mechanisms
• Authentication in Networks
• Is this Computer Who It Claims to Be?
• File Downloading and Transferring
• Obtaining Network Services
• What is Java Promise? What Does Java Guarantee
  re. Applets? What can Application do that Applet
  Cant?
• DB Authentication
• Uncontrolled Access (Select, Modify, etc.) Can be
  Limited (Authorized) requiring Authentication

14
Authorization

• Ability of Principals to Use Machines, Objects,
  Resources, etc.
• Security Policy Defines Capabilities of Each
  Principal Against Objects, Resources, etc.
• Authorization Mechanism Enforces Policy at
  Runtime
• External Authorization
• User Attempts to Access Computer
• Authenticate Identify and Verify Authorizations
• Internal Authorization
• Can Process Access a Specific Resource?
• Database Authorization
• What Can Each User Do Against the DB? Select,
  Insert, Update, Delete?
• Are Users Limited to Subsets of Tuples by Value?

15
User Authentication

• Combination of User ID and Password Universal for
  Access to Computers
• However, Cannot Prevent
• Guessing of Passwords
• Stolen and Decrypted Passwords
• Masquerading of Intended User
• Is User Who they are Supposed to be?
• What Extra Information Can User be Asked to
  Supply?
• What About Life Critical Situations (DCP)?
• Past Invasion of Engineering Computing
• yppasswd File Stolen/Decrypted
• S. Demurjians Sun Workstation Corrupted

16
Network Authentication

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

17
Core Security Capabilities of Java

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

18
Core Security Capabilities of Java

• Class Loader - Only Load Correct Classes
• Bytecode Verifier - Classes in Correct Format
• Security Manager - Untrusted Classes Cant
  Execute Dangerous Instructions nor Access
  Protected System Resources
• Role of Security Managers
• Enforces Boundaries of Sandbox
• All Java Classes ask Manager for Permission to
  Perform Certain Operations
• Implements/Imposes Appl. Security Policy
• Java Interface Class Implementable by Users
• Integrated with Exception Handling of Java

19
Recall Java Bytecode Verification
20
Digital Signatures and JAR Files

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

21
Database Security Approach

• Software Engineers can Write Complex Programs
  Limited by Intellectual Capabilities
• DB Designer Must Create Protection Scheme that
  Cant 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 Organizations Admin. Policy

22
Database Security

• Types of Security
• Database Security is Mainly Related with Access
  Rights to the Database
• Database Security Involves Issues Such as
• Governmental or Corporate Level of Policies
• Privacy and Confidentiality Requirements
• For Example - Consider a Medicine Prescription
• Physician or PA Only One Authorized to Write
  Drug, Dosage, Refills, Generic vs. Brand, etc.
• Pharmacist by Law Can Enter Script, Replace Brand
  with Generic, Alter Refills - Cant Change the
  Med
• By Law - Protect the Script per Patient
  (MD/Insurance)
• Access Control is Mechanism to Prevent
  Unauthorized Access to Databases

23
Database Security

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

24
Available Security Approaches

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

25
What are Key Access Control Concepts?

• Assurance
• Are the Security Privileges for Each User
  Adequate to Support their Activities?
• Do the Security Privileges for Each User Meet but
  Not Exceed their Capabilities?
• Consistency
• Are the Defined Security Privileges for Each User
  Internally Consistent?
• Least-Privilege Principle Just Enough Access
• Are the Defined Security Privileges for Related
  Users Globally Consistent?
• Mutual-Exclusion Read for Some-Write for Others

26
Mandatory Access Control

• Bell-Lapadula Model 1976
• An Extension of the Access Matrix Model
• The Model is Based on Subject-Object Paradigm
• Subjects Active Elements
• Objects Passive Elements
• Four Access Modes/Categories
• Executable by Subjects on Objects
• Read-only or Read
• Append (Write without Read)
• Execute (Executes an Object/program)
• Read-Write or Write

27
Mandatory Security Mechanism

• Typical Security Classification Levels for
  Subjects/programs and Objects/resources
• Top Secret (TS) and Secret (S)
• Confidential (C) and Unclassified (U)
• Rules
• TS is the Highest and U is the Lowest Level
• TS gt S gt C gt U
• Security Levels
• C1 is Security Clearance Given to User U1
• C2 is Security Classification Given to Object O1
• U1 can Access O1 iff C1 ? C2
• This is Referred to as the Domination of U1 Over
  O1

28
Operations

• Get access
• Initiate access to object in the given mode
• Release access
• Terminate access previously started by get
• Given access
• grant an access mode on an object to a subject
• Rescind access
• Revoke access previously granted with the give
  operation
• Create object
• An object may be inactive or active this takes
  an inactive object and adds to the object
  hierarchy
• Delete object
• Deactivates an active object
• Change subject security level
• Change object security level

29
Mandatory Security Mechanism

• Restriction (Axiom 1)
• No Subject S Can Read an Object O if the Objects
  Security Classification Is Higher Than the
  Subjects Security Clearance
• S Can Read O iff Clearance(S) ? Classification(O)
• No Subject May Write an Object that has Lower
  Security Class than the Subjects 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

30
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

31
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 Objects
  Security Classification is Higher Than the
  Subjects Security Clearance
• S Can Read O iff Clearance(S) ? Classification(O)
• This Insures that a Subject S cannot Read
  Information Above his/her Security Level

User (S)
Read Down
32
Mandatory Security Mechanism

• Simple Integrity Property (Write DownNo Write
  Up)
• A Subject May Write an Object only if that Object
  is at or Below the Subjects Security Clearance
• S Can Write O iff Clearance(S)
  Classification(O)
• This Allows the Potential of Information Flow
  from Higher Classification to Lower
  Classification Levels
• This Prevents the Ability of a Subject S to
  Corrupt Data above its Security Level
• Security Designer Must Choose their Poison!

User (S)
Write Down
33
Mandatory Security Mechanism

• Liberal Property (Write UpNo Write Down)
• No Subject May Write an Object that has Lower
  Security Class than the Subjects 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

User (S)
Write Up
34
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 Subjects
  Security Clearance
• S Can Read/Write O iff Clearance(S)
  Classification(O)
• This Limits Information Flow to within a Level

Read Equal Write Equal
User (S)
35
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

36
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

Read Down
User (S)
Write Up
37
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 ltS,o,mgt ? B ? M ? Ms,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

38
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

39
Illustrating MAC

• Whenever a User Attempts to Access a Table, the
  Table is Filtered According to Us Clearance
• First Set are for a User at Confidential Level
• Second Set is For a User at Unclassified Level

40
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 Whats Needed and No More
• Please seewww.engr.uconn.edu/steve/DSEC/desc.ht
  ml

41
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

42
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?

43
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

44
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

45
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
• Physicians Write Scripts
• Nurses Enter Patient Data (Vitals History)
• All Access Shared Medical Record
• Access is Limited Based on Role

46
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 Whats Needed and No More

47
Sample RBAC Hierarchy for HCA
Users
Medical_Staff
Support_Staff
Etc.
Nurse
Physcian
Technician
URLab
URPharmacy
URRadiology
URPrivate
URAttending
UREducation
URStaff_RN
URDirector
URDischarge_Plng
URManager
48
Sample RBAC Hierarchy for University
Users
/ \
--- -----
/ \
non-academic-staff
academic-staff / \ \
/ \ \.... /
\ \ / \
purchasing campus-police ... dept-staff
registrar-staff ...
/ \ ...
... / \

grade-recording transcript-issuing
49
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
• Users Identity
• Predefined Discretionary Rules Defined by the
  Security Administrator
• Focus on Two Variants of this Model
• Access Matrix Model
• Lampsons Protection System
• Role Delegation and Delegation Authority
• Detail DAC in SQL2

50
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
• Well see a Variant of this in Lampson

51
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

52
Access Matrix Model

• An Example
• Object Types
• Relations, Views, Rows (records), Columns,
  Operations
• Subject Types
• Users, Accounts, Programs

53
Access Modes

• Access Modes
• Read, Write, Append, and Execute
• Authorization
• AS,O is an Entry in the Access Matrix
• AS,O can be Authorized to One or More
  Operations
• Mechanisms
• ltcreategt ltsubject Si gt - Add a Row
• creategt ltobject Ojgt - Add a Column
• ltdestroygt ltsubject Si gt - Remove a Row
• ltdestroygt ltobject Ojgt - Remove a Column
• ltentergt ltoperation x into ASi, Oj
• ltdeletegt ltoperation x from ASi, Oj

54
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

55
Why is Role Delegation Important?

• Many Different Scenarios Under Which Privileges
  May Want to be Passed to Other Individuals
• Large organizations often require delegation to
  meet demands on individuals in specific roles for
  certain periods of time
• True in Many Different Sectors
• Financial Services
• Engineering
• Academic Setting
• Key Issues
• Who Controls Delegation to Whom?
• How are Delegation Requirements Enforced?

56
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

57
Delegation/Pass on Delegation Authorities

• When Establishing Privileges (by the Security
  Officer) there must be the Ability to Define
• Delegation Authority (DA)
• RecallSecurity 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

58
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
  asOU DoBest, ct, ?, TUR CDR_CR1,
  01dec00, 01dec01, TUA DoBest, CDR_CR1,
  01dec00, 01dec01DA YesPODA Yes
• After DelegationDU DoGood, 01dec00,
  01jun01, TUA DoGood, CDR_CR1, 01dec00,
  01jun01

59
Example - Role Delegation

• Now, Colonel DoGood wishes to re-delegate
  CDR_CR1 to Major CanDoRight, which can be defined
  asDU DoGood, 01dec00, 01jun01, TUR
  CDR_CR1, 01dec00, 01dec01, TUA DoGood,
  CDR_CR1, 01dec00, 01jun01DA YesPODA No
• After DelegationDU CanDoRight, 01jan01,
  01feb01, TUA CanDoRight, CDR_CR1, 01dec00,
  01jun01

60
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).

61
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.

62
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

63
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

64
Revocation

• Definition Cascading Revocation Refers to the
  Indirect Revocation of All DUs When the OU
  Revokes Delegation or Administration Revokes the
  OUs 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

65
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

66
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

67
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

68
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

69
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!

70
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

71
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

encryption
plaintext
ciphertext
decryption
72
More on Cryptography
plaintext
plaintext
Ke
Kd
C EKe(plaintext)
Encrypt
Decrypt
Invader
Side information
plaintext
73
Cryptographic Systems
Cryptographic Systems
Modern Systems
Conventional or Symmetric Systems

• Ke and Kd are essentially the same

Private Key
Public Key

• Ke and Kd are private

• Ke is public
• Kd is private

74
Statistical Database Security

• Statistical Databases are used to Produce
  Statistics on Various Populations
• Individual Information is Considered Confidential
• Users May be Allowed to Access Statistical
  Information on the Population, i.e., Applying
  Statistic Functions to a Population of Tuples
• Techniques for Protecting Privacy of Individual
  Information Solutions are Illustrated by
  Examples
• Suppose we are Allowed to Retrieve Only the
  Statistical Information Over this Relation by
  Using SUM, AVG, MIN, MAX, COUNT, Etc.

Person(name, ssn, income, address,city,
state, zip, sex, last_degree)
75
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 Marys Income

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.
select COUNT() from Person where last_degree
ph.D. and sex F and city
Calgary and state Alberta
select AVG(income) from Person where last_degree
ph.D. and sex F and city
Calgary and state Alberta
76
Example Two of Statistical DB

• 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 - Connies Income), She Determinds
  Marys Income

select SUM(income) from Person where
last_degree ph.D. and sex F and
city Calgary and state Alberta and
name ltgt Mary
select SUM(income) from Person where
last_degree ph.D. and sex F and
city Calgary and state Alberta and
name ltgt Connie
77
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!

78
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 Todays World Integral Part
  of Everyday Life - Some Key Concerns
• Confidentiality of an Individuals Data
• Identity Theft
• Protecting National Infrastructure