1. CS 5950/6030 – Computer Security and Information Assurance Section 6: Database Security
Dr. Leszek Lilien
Department of Computer Science
Western Michigan University
Slides based on Security in Computing. Third Edition by Pfleeger and Pfleeger.
Using some slides courtesy of:
Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke (U. Idaho) — taught at U. Washington
Prof. Csilla Farkas— course taught at U. of South Carolina
Slides not created by the above authors are © 2006 by Leszek T. Lilien
Requests to use original slides for non-profit purposes will be gladly granted upon a written request.

2. 6. Database Security – Outline - 1
6.1. Introduction - a DB refresher –
6.2. Security Requirements
Physical database integrity requirements
Logical database integrity requirements
Element integrity requirements
Auditability requirements
Access control requirements
User authentication requirements
Availability requirements
6.3. Reliability and Integrity
6.4. Sensitive Data

3. 6. Database Security – Outline -2
6.5. Inference (Inference Problems)
Direct attacks / Indirect attacks
Inferences in statistical DBs (incl. small/large query set attacks, tracker attacks, query overlap attacks, insertion/deletion attacks)
Inferences in general-purpose DBs (incl. inferences via queries based on sensitive data, inferences via DB constraints, inferences via updates)
6.6. Multilevel Databases
6.7. Proposals for Multilevel Security

4. - STUDY 6.1 ON YOUR OWN IF NEEDED -
6.1. Introduction – DB „Refresher”
- STUDY 6.1 ON YOUR OWN IF NEEDED -
Terms you know from database courses:
Database
Database management system (front end)
Records
Fields (elements)
Schema (logical design)
Subschema (user view)
Entity
Attributes
Relation
Queries (results in subschema)

5. Management Challenges
Courtesy of: Prof. Barbara Endicott-Popovsky
Traditional data file environment
Creating database environment
Challenges exisiting structure — requires restructure
Large initial costs, delayed benefits
Source: Laudon & Laudonr

6. File Organization BIT: Binary Digit (0,1; Y,N; On,Off)
Courtesy of: Prof. Barbara Endicott-Popovsky
BIT: Binary Digit (0,1; Y,N; On,Off)
BYTE: Combination of BITS representing a CHARACTER
FIELD: Collection of BYTES representing a DATUM or Fact
RECORD: Collection of FIELDS reflecting a TRANSACTION
Source: Laudon & Laudonr

7. File Organization FILE: Collection of similar RECORDS DATABASE:
Courtesy of: Prof. Barbara Endicott-Popovsky
FILE: Collection of similar RECORDS
DATABASE:
Organization’s Electronic Library of FILES
Organized to serve business applications
Source: Laudon & Laudonr

8. File Organization
Courtesy of: Prof. Barbara Endicott-Popovsky
ENTITY: Person, place, thing, event about which data must be kept
ATTRIBUTE: Description of a particular ENTITY
KEY FIELD: Field used to retrieve, update, sort RECORD
Source: Laudon & Laudonr

9. Key Field Field in Each Record Uniquely Identifies THIS Record
Courtesy of: Prof. Barbara Endicott-Popovsky
Field in Each Record
Uniquely Identifies THIS Record
For RETRIEVAL
UPDATING
SORTING
Source: Laudon & Laudonr

10. Problems With Traditional File Environment
Courtesy of: Prof. Barbara Endicott-Popovsky
Data redundancy
Program / data dependency
Lack of flexibility
Poor security
Lack of data sharing & availability
Flat File
Source: Laudon & Laudonr

11. Sequential Vs. Direct File Organization
Courtesy of: Prof. Barbara Endicott-Popovsky
SEQUENTIAL:
Tape-oriented;
One file follows another--physical sequence
DIRECT:
Disk-oriented;
Accessible without regard to physical sequence
Source: Laudon & Laudonr

12. Filing Methods Indexed sequential access method (ISAM) :
Courtesy of: Prof. Barbara Endicott-Popovsky
Indexed sequential access method (ISAM) :
Each record identified by key
Grouped in blocks and cylinders
Keys in index
Virtual storage access method (VSAM) :
Memory divided into areas & intervals
Dynamic file space
VSAM widely used for relational DBs
Direct file access method (next)
Source: Laudon & Laudonr

13. Direct File Access Method
Courtesy of: Prof. Barbara Endicott-Popovsky
Each record has key field
Key field fed into transformation algorithm
Algorithm generates physical storage location of record (record address)
Source: Laudon & Laudonr

14. Database Management System (DBMS)
Courtesy of: Prof. Barbara Endicott-Popovsky
Software to create & maintain data
Enables business apps to extract data
Independent of specific computer programs
DBMS
Source: Laudon & Laudonr

15. Components of DBMSs DBMS DATA DEFINITION LANGUAGE:
Courtesy of: Prof. Barbara Endicott-Popovsky
DATA DEFINITION LANGUAGE:
Defines data elements in database
DATA MANIPULATION LANGUAGE:
Manipulates data for applications
DATA DICTIONARY:
Formal definitions of all variables in database
Controls variety of database contents
Data elements
DBMS
Source: Laudon & Laudonr

16. Structured Query Language (SQL)
Courtesy of: Prof. Barbara Endicott-Popovsky
Emerging standard
Data manipulation language
For relational databases
DBMS
Source: Laudon & Laudonr

17. Elements Of SQL DBMS SELECT: List of columns from tables desired
Courtesy of: Prof. Barbara Endicott-Popovsky
SELECT: List of columns from tables desired
FROM: IDs tables from which columns will be selected
WHERE: Includes conditions for selecting specific rows, conditions for joining multiple tables
Example:
SELECT (name, phone)
FROM employees_table
WHERE employer = ‘MWU’ and city = ‘Kalamazoo’
Source: Laudon & Laudon
DBMS

18. Two Views Of Data DBMS PHYSICAL VIEW: Where is data physically?
Courtesy of: Prof. Barbara Endicott-Popovsky
PHYSICAL VIEW: Where is data physically?
Drive, disk, surface, track, sector (block), record
Tape, block, record number (key)
LOGICAL VIEW: What data is needed by application?
Succession of facts needed by application
Name, type, length of field
DBMS
Source: Laudon & Laudonr

19. Storage Hierarchy BIT BYTE FIELD RECORD FILE DATABASE
Courtesy of: Prof. Barbara Endicott-Popovsky
BIT
BYTE
FIELD
RECORD
FILE
DATABASE
Source: Laudon & Laudonr

20. Relational Data Model Data in table format RELATION: Table
Courtesy of: Prof. Barbara Endicott-Popovsky
Data in table format
RELATION: Table
TUPLE: Row (record) in table
FIELD: Column (attribute) in table
Source: Laudon & Laudonr

21. Types Of Relations ONE-TO-ONE: STUDENT ID ONE-TO-MANY: CLASS STUDENT A
Courtesy of: Prof. Barbara Endicott-Popovsky
ONE-TO-ONE:
STUDENT ID
ONE-TO-MANY:
CLASS
STUDENT A B C
MANY-TO-MANY:
STUDENT A B C
CLASS 1 2
Source: Laudon & Laudonr

22. Hierarchical Data Model
Courtesy of: Prof. Barbara Endicott-Popovsky
ROOT
Employer
1st Child
Job
Compensation
Benefits
Assignments
2nd Child
Ratings
Salary
Pension
Insurance
Health
Source: Laudon & Laudonr

23. Network Data Model Variation of hierarchical model
cf: Prof. Barbara Endicott-Popovsky
Variation of hierarchical model
Best suited for many-to-many relationships
NETWORK A B C 1 2
Source: Laudon & Laudon

24. Other Systems LEGACY SYSTEM: older system
Courtesy of: Prof. Barbara Endicott-Popovsky
LEGACY SYSTEM: older system
OBJECT - ORIENTED DBMS: stores data & procedures as objects
OBJECT - RELATIONAL DBMS: hybrid
Source: Laudon & Laudonr

25. Creating a Database Conceptual Design Physical Design
Courtesy of: Prof. Barbara Endicott-Popovsky
Conceptual Design
Physical Design
Source: Laudon & Laudonr

26. Creating a Database — Conceptual Design
Courtesy of: Prof. Barbara Endicott-Popovsky
Abstract model, business perspective
How will data be grouped?
Relationships among elements
Establish end-user needs
Source: Laudon & Laudonr

27. Creating a Database — Physical Design
Courtesy of: Prof. Barbara Endicott-Popovsky
Detailed model by database specialists
Entity-relationship diagram
Normalization
Hardware / software specific
Source: Laudon & Laudonr

28. Elements Of Database Environment
Courtesy of: Prof. Barbara Endicott-Popovsky
DATA
ADMINISTRATION
DATABASE TECHNOLOGY & MANAGEMENT
DATABASE MANAGEMENT SYSTEM
DATA PLANNING & MODELING METHODOLOGY
USERS
Source: Laudon & Laudonr

29. Entity- Relationship Diagram
Courtesy of: Prof. Barbara Endicott-Popovsky 1 M
ORDER
CAN HAVE
PART
SUPPLIER
ORDER: #, DATE, PART #, QUANTITY
PART: #, DESCRIPTION, UNIT PRICE, SUPPLIER #
SUPPLIER: #, NAME, ADDRESS
Source: Laudon & Laudonr

30. Normalization
Courtesy of: Prof. Barbara Endicott-Popovsky
= Process of creating small data structures from complex groups of data
EXAMPLES:
Accounts Receivable
Personnel Records
Payroll
Source: Laudon & Laudonr

31. Distributed Databases
Courtesy of: Prof. Barbara Endicott-Popovsky
PARTITIONED: remote CPUs (connected to host) have files unique to that site, e.g., records on local customers
REPLICATED (DUPLICATED as a special case) ea. remote CPU has copies of common files e.g., layouts for standard reports and forms
Source: Laudon & Laudonr

32. Database Administration
cf: Prof. Barbara Endicott-Popovsky
A person or a group of people
Defines / organizes database structure and content
Develops security procedures
Develops database documentation
Maintains DBMS
E.g., software patches and updates
Source: Laudon & Laudonr

33. Database Trends - 1
Courtesy of: Prof. Barbara Endicott-Popovsky
Multidimensional Data Analysis: 3D (or higher dimension) groupings to store complex data
Hypermedia:
Nodes contain text, graphics, sound, video, programs
Organizes data as nodes
Source: Laudon & Laudonr

34. Database Trends - 2
Courtesy of: Prof. Barbara Endicott-Popovsky
Data Warehouse: Organization’s electronic library stores consolidated current & historic data for management reporting & analysis
On-Line Analytical Processing (OLAP): Tools for multi-dimensional data analysis
Source: Laudon & Laudonr

35. Components of Data Warehouse
Courtesy of: Prof. Barbara Endicott-Popovsky
Source: Laudon & Laudonr

36. Database Trends -3
cf: Prof. Barbara Endicott-Popovsky
DATA MART: Small data warehouse for special function
E.g., focused marketing based on customer info
DATA MINING: Tools for finding hidden patterns, relationships, for predicting trends, etc.
Source: Laudon & Laudonr

37. Database Trends - 4 Linking Databases to The Web:
Courtesy of: Prof. Barbara Endicott-Popovsky
Linking Databases to The Web:
Web user connects to vendor database
Special software converts users query ‘in’ html to SQL
SQL finds data, server converts result to HTML
Source: Laudon & Laudonr

38. 6.2. Security Requirements
Security requirements for databases and DBMSs:
Physical database integrity requirements
DB immune to physical problems (e.g., power failure, flood)
Logical database integrity requirements
DB structure preserved (e.g., update of a field doen’t affect another)
Element integrity requirements
Accuracy of values of elements
Auditability requirements
Able to track who accessed (read, wrote) what
Access control requirements
Restricts DB access (read, write) to legitinmate users
User authentication requirements
Only authorized users can access DB
Availability requirements
DB info available to all authorized users 24/7
cf: Prof. Barbara Endicott-Popovsky
Source: Pfleeger & Pfleeger

39. --OPTIONAL– Confident. / Integrity / Availability
Requirements can be rephrased / sumarized as follows:
Data must be trusted
DBMS designed to manage trust
DBMS must reconstruct reality
Data must be accurate
Field checks
Access control (CRUD)
CRUD = Create, Read, Update, and Delete
Change log
Trade-offs
Audit vs. performance
Access vs. performance
Self-authentication
High availability
Courtesy of: Prof. Barbara Endicott-Popovsky
Source: Pfleeger & Pfleeger

40. 6.3. Reliability and Integrity
Reliable software runs long time without failures
Reliable DBMS preserves:
DB Integrity / Element Integrity / Element Accuracy
Basic protection provided by OS underlying DBMS
File back ups
Access controls
Integrity checks
DBMS needs more CIA controls
E.g. two-phase commit protocols for updates
Redundancy/internal consistency controls
DB recovery
Concurrency/consistency control
Monitors to enforce DB constraints
Range, state, transition constraints
Control structural DB integrity
Courtesy of: Prof. Barbara Endicott-Popovsky
Source: Pfleeger & Pfleeger

41. --SKIP-- a) Two-Phase Update (2PC)
Courtesy of: Prof. Barbara Endicott-Popovsky
Intent Phase
Check value of COMMIT-FLAG
Gathers resources
Data
Dummy records
Open files
Lock out others
Calculate final answers
Write COMMIT-FLAG
Permanent Change Phase
Update made
Rollback ability at each phase
Source: Pfleeger & Pfleeger

42. --SKIP-- b)-e) Detecting Inconsistencies
b) Redundancy/internal consistency controls
Error detection / error correction
Hamming codes
Parity bits
Cyclic redundancy check
Shadow fields
c) DB recovery
Uses DBMS access log
d) Concurrency control
Checks/enforcement
e) Monitors for DB constraints
Range comparisons
State constraints
Transition constraints
Courtesy of: Prof. Barbara Endicott-Popovsky
More sophisticated
Source: Pfleeger & Pfleeger

43. --OPTIONAL-- 6.4. Sensitive Data
Managing access
Hiding existence
Sharing vs. confidentiality
Security vs. precision
Perfect confidentiality
Maximum precision
Courtesy of: Prof. Barbara Endicott-Popovsky
Source: Pfleeger & Pfleeger

44. 6.5. Inference (Inference Problems)
Inference attack - inferring sensitive data
from nonsensitive data
Types of inference attacks:
1) Direct attack
Infer sens. data from results of queries run by attacker
n-item k-percent rule:
Data withheld if n items represent > k percent of the result reported
Most obvious case: 1-item 100-percent case: 1 person represents 100 % of results reported
2) Indirect attack
Infer sens. info from statistics (Sum, Count, Median) also from info external to the attacked DB
Tracker attacks (intersection of sets)
Linear system vulnerability
Use algebra of multiple equations to infer
cf: Prof. Barbara Endicott-Popovsky
Source: Pfleeger & Pfleeger

45. Indirect Information Flow Channels
1) Covert channels
Discussed earlier –
in the general context of program security
Recall:
Overt Channel: designed into a system and documented
Covert Channel: not documented
Covert channels may be deliberately inserted into a system, but most are accidents of the system design.
2) Inference channels
Discussed next–
in the context of DBMS
cf: Prof. Csilla Farkas

46. Inference Controls - Outline
1) Query controls — applied to queries
Primarily against direct attacks
Query analysis to prevent inferences
Query inventory (history) per person
2) Data item controls —applied to individual DB items
Useful for indirect attacks
Two types:
a) Suppression — data not provided to querying user
Suppress combinations of rows and columns
Combine results (to hide actual answers)
b) Concealing — close answers, not exact given to querying user
Rounding
Present range of results
Present random sample results
Perturb random data (generate small + and – error)
Courtesy of: Prof. Barbara Endicott-Popovsky
Source: Pfleeger & Pfleeger

47. Database Inference Problem & Types
DB inference problem:
where meta-data:
Working knowledge about the attributes
Supplementary knowledge (not stored in database)
DB inference types:
1) Statistical database inferences
2) General-purpose database inferences
cf: Prof. Csilla Farkas +
Meta-data
Sensitive
information
Non-sensitive =

48. 1) Statistical Database Inference
Statistical database goal: provide aggregate information about groups of individuals
E.g., average grade point of students
Security risk in statistical database:
disclosure of specific information about a particular individual
E.g., grade point of student John Smith
cf: Prof. Csilla Farkas

49. --OPTIONAL-- Types of Statistics
Macro-statistics: collections of related statistics presented in 2-dimensional tables
Micro-statistics: Individual data records used for statistics after identifying information is removed
cf: Prof. Csilla Farkas
Sex\Year
1997
1998
Sum
Female 4 1 5
Male 6 13 19 10 14 24
Sex
Course
GPA
Year F
CSCE 590
3.5
2000 M
3.0
CSCE 790
4.0
2001

50. Statistical Compromise
Exact compromise:
Find exact value of an attribute of an individual
E.g., finding that John Smith’s GPA is 3.8
Partial compromise:
Find an estimate of an attribute value corresponding to an individual
E.g., finding that John Smith’s GPA is between 3.5 and 4.0)
cf: Prof. Csilla Farkas

51. Methods of Attacks and Protection
Small/Large Query Set Attack
C: characteristic formula that identifies groups of individuals
If C identifies a single individual I, e.g., count(C) = 1
Find out existence of another property D for I
If count(C and D)= 1 means I has property D
If count(C and D)= 0 means I does not have D OR
Find value of property
Sum(C, D), gives value of D
If value of C known already
cf: Prof. Csilla Farkas

52. Prevention Protection from small/large query set attack:
query-set-size control
A query q(C) is permitted only if
N-n  |C|  n
where:
n  0 is a parameter of the database, and
N is the number of records in the database
E.g. a query q(C) in a DB describing 100 individuals is permitted only if
100 – 5 = 95  |C|  5
that is if it can’t give statistics on a group smaller than 5 individuals
(Note: If it gives statistics on C for e.g., 96 people, it gives statistics on not-C for 4 people.)
cf: Prof. Csilla Farkas

53. Tracker Attack 1 (simple)
Query q(C) is disallowed
cf: Prof. Csilla Farkas
T - Tracker C C1 C2
C = C1 and C2
T = C1 and ~C2
Attacker runs instead 2 queries: q(C1) and q(T)
where q(C) = q(C1) – q(T)
=> infers q(C) from q(C1) and q(T)

54. --OPTIONAL-- Tracker Attack 2 (more complex)
Query q(C and D)
is disallowed
Tracker C C1 C2 D
C and D
cf: Prof. Csilla Farkas
C = C1 and C2
T = C1 and ~C2
Attacker runs instead 2 queries: q(T or C and D) and q(T)
where q(C and D) = q(T or C and D) – q(T)
=> infers q(C and D) from q(T or C and D) and q(T)

55. --OPTIONAL-- Query overlap attack
Q(John)=q(C1)-q(C2)
cf: Prof. Csilla Farkas C1 C2
John
Kathy
Max
Fred
Eve
Paul
Mitch
Protection: need query-overlap control

56. --OPTIONAL-- Insertion/Deletion Attack
Observing changes over time
q1=q(C)
Insert(i)
q2=q(C)
q(i) = q2 „-” q1
where „-” means compensation for insertion that permist to infer
Protection: insertion/deletion performed as pairs
cf: Prof. Csilla Farkas

57. Statistical Inference Theory
Given unlimited number of statistics and correct statistical answers, all statistical databases can be compromised
[Ullman]
Fortunately:
Number of statistics can be limited by statistical DB controls
Statistical DB can give approximate rather than ‘correct’ statistical answers
cf: Prof. Csilla Farkas

58. 2) Inferences in General-Purpose Databases
cf: Prof. Csilla Farkas
Inference types:
a) Inference via queries based on sensitive data
b) Inference via DB constraints
c) Inference via updates

59. Inference via Queries Based on Sensitive Data
Sensitive information is used in selection condition but not returned to the user
Example: Salary: secret, Name: public
NameSalary=$25, (- projection,  - selection)
NameSalary=$26,000
• • •
NameSalary=$110,000
Sensitive info (salary) used in selection condition, but not returned to the user
Returns only Name to user
“Infers” (quite mechanically – no intelligence needed) salary for everybody making between $25,000 and $110,000
Protection: apply query of database views at different security levels
cf: Prof. Csilla Farkas

60. b) Inference via DB Constraints
Database constraints:
b-1) Integrity constraints
b-2) DB dependencies
b-3) Key integrity
cf: Prof. Csilla Farkas

61. b-1) Infering via Integrity Constraints
C = A+B
A - public, C - public, and B - secret
B can be calculated from A and C
I.e., secret information can be calculated from public data

62. b-2) Infering via DB Dependencies
DB dependencies (metadata):
Functional dependencies
Multi-valued dependencies
Join dependencies
etc.
cf: Prof. Csilla Farkas

63. Functional Dependencies
Functional dependency (FD) for attributes A  B:
For any two tuples in the relation, if they have the same value for A, they must have the same value for B
Example: Exploiting the FD: Rank  Salary to infer secret info
Secret information: Name and Salary together
Query1: Name and Rank
Query2: Rank and Salary
Combined answers for Q1 and Q2 reveal Name and Salary together
Only because we have Rank  Salary
cf: Prof. Csilla Farkas

64. --OPTIONAL--b-3) Infering via Key Integrity
Every tuple in the relation has a unique key
Users at different security levels see different versions of the database
User with ‘top secret’ clearance sees more than one with ‘secret’ clearance
Users might attempt to update data that is not visible for them
cf: Prof. Csilla Farkas

65. --SKIP--Example – Infering via Key Integrity
Secret View
cf: Prof. Csilla Farkas
Name (key)
Salary
Address
Black P
38,000 P
Columbia S
Red S
42,000 S
Irmo S
Public View
Name (key)
Salary
Address
Black P
38,000 P
Null P

66. --SKIP-- Example (ctd) - Updates
Public User:
cf: Prof. Csilla Farkas
Name (key)
Salary
Address
Black P
38,000 P
Null P
Update Black’s address to Orlando
Add new tuple: (Red, 22,000, Manassas) If
Refuse update => covert channel
Allow update =>
Overwrite high data – may be incorrect
Create new tuple – which data it correct
(polyinstantiation) – violate key constraints
polyinstantiation – given record instantiated many times, each time with different security level

67. --SKIP-- Example (ctd) - Updates
Secret user:
cf: Prof. Csilla Farkas
Name (key)
Salary
Address
Black P
38,000 P
Columbia S
Red S
42,000 S
Irmo S
Update Black’s salary to 45,000 If
Refuse update => denial of service
Allow update =>
Overwrite ‘low’ data – covert channel
Create new tuple – which data it corrects
(polyinstantiation) – violate key constraints
polyinstantiation – given record instantiated many times, each time with different security level

68. Conclusions on Inference
cf: Prof. C. Farkas and B. Endicott-Popovsky
No general technique is available to solve the inference problems
Need assurance of protection
Hard to incorporate outside knowledge
Optimal plan:
Suppress obviously sensitive information
Track what user knows (expensive)
Disguise data
--OPTIONAL-- Aggregation—additional problem
Inferences from aggregating data
Data mining increases risks
Source: Pfleeger & Pfleeger

69. 6.6. Multilevel Databases
Multilevel databases - store data with different
sensitivity levels (e.g.: public, confidential, secret, top_secret)
Problems
Polyinstantiation – multiple (“poly”) instantiations of a record, each at a different security level
Example:
[John, Kalamazoo-MI] -- Public level
[John, 19_Main_Ave-Kalamazoo-MI] -- Confidential level …
[John, 19_Main_Ave-Kalamazoo-MI, …, SSN= ] -- Top_Secret level
-- OPTIONAL below --
Global actions (i.e., backup)
Small items controlled
Cost and performance
Consumer resistance to military model
Granularity
Access control policy
Guarantee values not changed by unauthorized person
of: Prof. Barbara Endicott-Popovsky
Source: Pfleeger & Pfleeger

70. --OPTIONAL-- 6.7. Proposals for Multilevel Security - Separation Mechanisms
cf: Prof. Barbara Endicott-Popovsky
1) Partitioning
Redundancy
Accuracy (multiple field update)
2) Encryption per level
Cumbersome decrypting with queries
3) Integrity lock
Data item
Sensitivity level
Checksum (above 2)
Cryptographic checksums
4) Sensitivity lock
Unique identifier
Source: Pfleeger & Pfleeger

71. --OPTIONAL-- Implementations of Separation - 1
1) Integrity lock
Expands size of element
Processing time efficiency
Untrusted DBM subject to Trojan horse
2) Trusted front end
Guard ~ reference monitor
One-way filter—filters out reports
Inefficient—calls, then releases much data
3) Commutative filters
Interface between user and DB
Reformats query
Addresses inefficiencies (above)
Courtesy of: Prof. Barbara Endicott-Popovsky
Source: Pfleeger & Pfleeger

72. --OPTIONAL-- Implementations of Separation - 2
Courtesy of: Prof. Barbara Endicott-Popovsky
4) Distributed DB
Separate DB’s based on sensitivity
Front end sends query to right DB
5) Views
Logical / functional divisions
Source: Pfleeger & Pfleeger

73. End of Section 6 –
Database Security