Database Security DAC and MAC in DB(cont'd)
advertisement
Database Security
(DAC and MAC in DB)
2001.7.23
DAC and MAC in DB (cont’d)
!
Discretionary access controls
– users can protect what they own
– the owner may grant access to others
– the owner may define the type of access given to others
» read/write/execute
Commercial DBMS
– use DAC, i.e., users decide who has access to what
» these mechanisms are adequate for most honest users
» but, cannot withstand sophisticated attacks from malicious users
» vulnerable to Trojan Horses
Myoung Ho Kim, KAIST
1
DAC and MAC in DB
!
Access controls in commercial DB systems
– Identification and Authentication
– Security through views
– Grant and Revoke
– Query modification
Myoung Ho Kim, KAIST
DAC and MAC in DB (cont’d)
Identification and Authentication
– (ex) CONNECT <user> IDENTIFIED BY <password>
Security through views
– restrict the users to see only parts of the base table(s)
" limitation of views
» many views cannot be updated
» negative authorization is not possible
» cannot withstand sophisticated attacks
Myoung Ho Kim, KAIST
2
DAC and MAC in DB (cont’d)
Grant and Revoke
– grant or revoke the privileges
" Note on EXECUTE privilege
» Suppose a program is compiled first, and then executed later
» The user1 who compiles a program becomes the owner of the
program. He may give EXECUTE privilege to others
(ex) GRANT EXECUTE ON program1 to James
» Suppose user1 has a privilege to access relation EMP, and program1
needs to access EMP
» James can execute program1 even though he does not have
permission to access EMP
Myoung Ho Kim, KAIST
DAC and MAC in DB (cont’d)
Query modification
– James
» GRANT SELECT ON EMP TO Thomas WHERE SALARY < 5000
– Smith
» SELECT *
FROM EMP
– DBMS
» SELECT *
FROM EMP
WHERE SALARY < 5000
Myoung Ho Kim, KAIST
3
DAC and MAC in DB (cont’d)
!
Trojan Horse example
– we require that all software that run on the system is Trojan
Horse free
» hardly practical
Myoung Ho Kim, KAIST
DAC and MAC in DB (cont’d)
r: A
w: A
User A
File A
Program
Read
r: B
w: A
User B
TH
User B cannot read
File A.
Write
But by using TH,
User B may obtain
the contents of File A
File B
Myoung Ho Kim, KAIST
4
DAC and MAC in DB (cont’d)
!
Mandatory access control
» enforce label-based policy
– assign security levels to all data
– assign security clearance to each users
– DBMS should make sure that all users have access to only those
data for which they have a clearance
Myoung Ho Kim, KAIST
DAC and MAC in DB (cont’d)
Bell-LaPadula restrictions
– The simple security policy
» A subject S is allowed a read access to an object O only if L(S) is
larger than or equal to L(O)
– The *-property
» A subject S is allowed a write access to an object O only if L(S) is less
than or equal to L(O)
" These restrictions together ensure that there is no direct flow of
information from high to low subject
Myoung Ho Kim, KAIST
5
DAC and MAC in DB (cont’d)
User A
File A
Program
User B
TH
Label(A) = Secret
Read
Write
File B
Label(B) = Unclass
Myoung Ho Kim, KAIST
DAC and MAC in DB (cont’d)
Information flow channels
» a secure system should protect
direct revelation of data
indirect violations that produce illegal information flow
– Inference channels
» a user at a low security class uses the low data to infer about high
security class
– Covert channels
» require two active agents, one at a low level and the other at a high
level and some encoding scheme
Myoung Ho Kim, KAIST
6
DAC and MAC in DB (cont’d)
!
Multilevel secure relational model
– Granularity of protection
» in OS, protected objects are files
» in databases, there are several possibilities
relations, attributes, tuples, data elements
– Which one should DBMS implement?
» relation level is easier to implement, but may be too inflexible
» data element level may be too complex
Myoung Ho Kim, KAIST
DAC and MAC in DB (cont’d)
– Assigning security levels to data
» each relation
» each tuple
» each attribute
» each element
Myoung Ho Kim, KAIST
7
Example: granularity of protection
(Ex) Tuple-level granularity
Starship
Objective
Destination
Enterprise
Voyager
Exploration
Spying
Talos
Mars
Objective C
Destination S
Exploration
Spying
Talos
Mars
U
S
(Ex) Attribute-level granularity
Starship
U
Enterprise
Voyager
Myoung Ho Kim, KAIST
Example: granularity of protection
(Ex) Element-level granularity
Starship
Objective
Destination
Enterprise U
Voyager U
Exploration U
Spying
S
Talos
Mars
U
S
Myoung Ho Kim, KAIST
8
Chap. 8 Database Security
(by C.P. Pfleeger, 1997)
2001.7.23
Database Security
!
Security Requirements
!
Reliability and Integrity
!
Sensitive Data
!
Inference Problem
!
Multilevel Database
!
Proposals for Multilevel Security
Myoung Ho Kim, KAIST
9
Security Requirements
!
Integrity of the database
– data must be protected from corruption
» either by mistake or by illegal actions
– updates are performed only by authorized individuals
Integrity constraint
» prevent users from making mistakes
in collecting data, computing results and entering values
access control
audit log
Myoung Ho Kim, KAIST
Security Requirements (cont’d)
!
Auditability
– audit records of all accesses to a database
» helps discover the fact who affected what values and when
!
Access control
– DBA specifies who should be allowed access to which data
– DBMS enforces this policy
– a user or program may have the right
» read, update, insert and delete a field or a record
Myoung Ho Kim, KAIST
10
Security Requirements (cont’d)
!
User authentication
– DBMS enforces authentication in addition to OS
» because DBMS runs as an application program on top of OS
!
Availability
– in order to avoid revealing protected data, unprotected data may
need to be withheld
Myoung Ho Kim, KAIST
Security Requirements (cont’d)
!
Integrity/secrecy/availability
– Integrity
» data must be protected from corruption
– Secrecy
» a problem of inference
» a user can access sensitive data indirectly
– Availability
» an important issue because of the shared access motivation
underlying the development of databases
» it can conflict with secrecy
Myoung Ho Kim, KAIST
11
Reliability and Integrity (cont’d)
!
Integrity and Reliability
– users must be able to trust the accuracy of the data, and
– expect protection of the data from loss or damage
!
Protection features from the OS
– files
» backup, access control facilities
– integrity checks of data during Read/Write for I/O devices
» these provide basic security of database
» DBMS must enhance these controls
Myoung Ho Kim, KAIST
Reliability and Integrity (cont’d)
!
Two-phase update
– 1st phase: Intent phase
» DBMS gathers information and other resources it needs to perform
update, but no changes to the database are made
» writing commit flag to the database at the end of this phase, which
means DBMS begins making permanent changes
– 2nd phase: Commit phase
» DBMS makes permanent changes to the database
" This “Two-phase update” is only one of many update processing
policies
Myoung Ho Kim, KAIST
12
Reliability and Integrity (cont’d)
#
Shadow values
» values maintained for updated data, which are computed and stored
locally during the intent phase, and
» copied to the actual database during the commit phase
#
DBMS writes the commit flag when it begins the commit phase, and
clears the commit flag after completing the commit phase
" In case of system failures before clearing the commit flag
log contains all the changes of database
repeat the commit phase, and clear those flags
Note that the commit phase needs to be idempotent
Myoung Ho Kim, KAIST
Reliability and Integrity (cont’d)
!
Redundancy
» additional information for internal consistencies in data
– error detection and correction codes
» additional information to detect and/or correct the errors
(ex) parity, Hamming codes, cyclic redundancy checks
– duplicated copies of database
» if the database is irreproducible, this second copy can provide an
immediate replacement
Myoung Ho Kim, KAIST
13
Reliability and Integrity (cont’d)
!
Recovery
– DBMS maintains a log of changes
– when failure, the database is reloaded from a backup copy and
all later changes are applied from the log
!
Concurrency
– concurrent accesses to the same data must be constrained
» so that neither interferes with the other
» usually by locking
Myoung Ho Kim, KAIST
Sensitive Data
!
Sensitive data
» data that should not be made public
– nothing sensitive, e.g., public library catalog
– everything sensitive, e.g., the defense database
– some but not all sensitive
» (ex) a student database consisting of name, financial aid, dorm, drug
use, sex, parking fines, and race
name and dorm are probably the least sensitive
financial aid, parking fines, and drug use are the most sensitive
Myoung Ho Kim, KAIST
14
Sensitive Data (cont’d)
!
Sorts of sensitive data
– inherently sensitive
» (ex) locations of defensive missiles
– declared sensitive
» (ex) classified military data
– sensitive in relation to previously disclosed information
» (ex) the longitude coordinate of a secret gold mine in conjunction with
the known latitude coordinate
– sensitive attributes
» (ex) financial aid, fines
Myoung Ho Kim, KAIST
Sensitive Data (cont’d)
!
Access decisions
» DBA decides accessibility of database based on access policy
» DBMS implements the decisions
#
Factors in making access decisions
– acceptability of access
» deciding what is sensitive is not very simple
(ex) FINES is sensitive. But “find NAME for whom FINES is 0”?
(ex) Average salary may not be sensitive. But “average of one
data”?
Myoung Ho Kim, KAIST
15
Sensitive Data (cont’d)
– Assurance of authenticity
» certain properties of users may need to be considered
(ex) access permission based on certain time
(ex) access permission based on the history of queries
Myoung Ho Kim, KAIST
Sensitive Data (cont’d)
!
Types of disclosure
– exact data
– bounds
» bounds on a sensitive value that indicate a sensitive value
(ex) y is between L and H
– negative result
» (ex) a value is not 0 may be a significant disclosure
– existence
» existence of data may be itself a sensitive information
(ex) Is there a value in “special-expertise” attribute?
– probable value
» probability that a certain element has a certain value
Myoung Ho Kim, KAIST
16
Sensitive Data (cont’d)
" Partial disclosure
» information about data
can be used to infer the sensitive data indirectly
e.g., bounds, negative result, existence, probable value
» must protect from both direct and indirect disclosure
Myoung Ho Kim, KAIST
Sensitive Data (cont’d)
!
Security vs. Precision
» complicated by a desire to share non-sensitive data
– Secrecy
» disclose only data that is not sensitive
reject any query that mentions a sensitive field
– Precision
» disclose as much data as possible so that users of the database have
access to the data they need
" We often must sacrifice precision in order to maintain secrecy
Myoung Ho Kim, KAIST
17
Inference Problem
!
Inference Problem
» deriving sensitive data from non-sensitive data
!
Direct attack
» seek sensitive data directly with queries that yield few records
» form a query so specific that it matches exactly one data item
List NAME where
SEX=M and DRUGS=1
Myoung Ho Kim, KAIST
Inference Problem (cont’d)
" n items over k percent rule
» data should be withheld if n items represent over k percent of
the result reported
» (ex) US. Census Bureau does not reveal results where a
small number of people make up a large portion of the
category
Myoung Ho Kim, KAIST
18
Inference Problem (cont’d)
!
Indirect attack
» the US. Census Bureau releases only statistics
suppress individual names, addresses, or other characteristics by
which a single individual can be recognized
» however, indirect attack may infer a result based on statistical results
– statistical inference
» SUM, COUNT, Tracker attacks, linear system vulnerability
– controls for statistical inference attacks
» limited response suppression, combining results, random sample,
random data perturbation, query analysis
Myoung Ho Kim, KAIST
Inference Problem (cont’d)
#
SUM
» infer a value from a reported sum
» (ex) report on the student’s financial aid by sex and dorm
t
m
{
o
\WWW
^WWW
XYWWW
n ZWWW
W
ZWWW
~
[WWW
[WWW
_WWW
{
XYWWW
XXWWW
YZWWW
Sums of Financial Aid by Dorm and Sex
$ disclose that “no female living in Grey receives financial aid”
Myoung Ho Kim, KAIST
19
Inference Problem (cont’d)
#
COUNT
» Count can be combined with the Sum to produce even more
revealing results
» (ex) the count of records for students by sex and dorm
t
m
{
o
X
Y
Z
n Z
X
[
~
X
Z
[
{
\
]
XX
Count of students by Dorm and Sex
$ combined with the Table from SUM, two males in Holmes and West
receive financial aids in the amount of $5000 and $4000
Myoung Ho Kim, KAIST
Inference Problem (cont’d)
#
Tracker
» fool the DBMS into finding desired data by using additional queries
» (ex) Find how many female Caucasians live in Holmes Hall
count ((SEX=F)^(RACE=C)^(DORM=Holmes))
Since the answer is 1, DB manager refuse to answer
This query is equivalent to the following
count (SEX=F)
Answer is 6
minus
count((SEX=F)^((RACE≠C)∨(DORM≠Holmes)))
Answer is 5
Myoung Ho Kim, KAIST
20
Inference Problem (cont’d)
%
COUNT(a^b)
b
a
5
1
" COUNT(a^b) ≡ COUNT(a) – COUNT(a ^ ¬b2
Myoung Ho Kim, KAIST
Inference Problem (cont’d)
#
Linear system vulnerability
» Tracker is a special case of a more general vulnerability
» it may be possible to determine a series of queries that returns results
relating to several different sets
» (ex)
Each of following queries does not reveal any single c value
however, the queries can be solved for each of unknown c values
Myoung Ho Kim, KAIST
21
Inference Problem (cont’d)
!
Controls for statistical inference attacks
– Controls to data items
» suppression
sensitive values are not provided
query is rejected without response
» concealing
the answer provided is close to but not exactly the actual value
– Controls to query
» query analysis
Myoung Ho Kim, KAIST
Inference Problem (cont’d)
#
Limited response suppression
– n item, k percent rule eliminates certain low-frequency elements from
being displayed
» (ex) the cells with count of 1 should be suppressed
t
m
{
o
T
Y
Z
n Z
T
[
~
T
Z
[
{
\
]
XX
Counts by Dorm and Sex
Myoung Ho Kim, KAIST
22
Inference Problem (cont’d)
" This suppression is not sufficient
» the value 1 for Male-Holmes cell can be easily determined by
analyzing the Holmes column
» need to suppress one additional cell on the row and one on the
column
Myoung Ho Kim, KAIST
Inference Problem (cont’d)
#
Combining results
– combining rows or columns to protect sensitive values
Sex and z
Drug-use t
⇒
m
Suppression
by combing z
t
revealing
m
values
W
X
Y
kG|
X Y Z
X X Y
Y Y W
These counts may not seem sensitive.
But, these counts with other results
may permit some inferences.
(ex) Dorm and Sex; Dorm and
Drug-use
kG|
WGGX YGGZ
Y
Z
[
Y
Myoung Ho Kim, KAIST
23
Inference Problem (cont’d)
#
Random sample
» a result is not derived from the whole database
– the result is computed on a random sample of the database
– the sample chosen is large enough to be valid
– the result is not the exact value on the whole database
#
Random data perturbation
» perturbing the values of the database by a small error
– if xi is the true value of data item i in the database, εi is the small random
error added to xi for statistical result
– ε value can be both positive and negative
Myoung Ho Kim, KAIST
Inference Problem (cont’d)
#
Query analysis
» a more complex form of security enforcement
– a query and its implications are analyzed
» to determine whether a result should be provided
– maintain a query history for each user
– judge a query in the context of what inferences are possible for
given results
Myoung Ho Kim, KAIST
24
Multilevel Database
!
Multilevel Database
» some data are more sensitive
– differentiated security
» security of one item may be different from that of others
» two levels – sensitive and nonsensitive – may not be adequate
» security of the aggregate may be higher or lower than that of the
individual items
" these principles lead to a model, in which the security of an
object is defined as one of n levels
Myoung Ho Kim, KAIST
Multilevel Database (cont’d)
!
Some issues in multilevel database
Granularity of security classification
» not only can each element have a distinct sensitivity, combinations
of elements may also have a distinct sensitivity
(Ex)
project-name = “Manhattan”, supervised = “Dept_A”
sensitivities of each elements, and sensitivity of combination of
elements may be different
Myoung Ho Kim, KAIST
25
Multilevel Database (cont’d)
Integrity in multilevel database
– more difficult to achieve integrity in multilevel databases
– because of the *-property for access control
» a process that reads high-level data is not allowed to write a file at
lower level
» sometimes, a process must be able to read all records in the database
and write some new records, e.g., DB backup, DB reorganization
" those processes must be a “trusted process”
Myoung Ho Kim, KAIST
Multilevel Database (cont’d)
Confidentiality
– users trust that a database will provide correct information
– however, the system may use data perturbation for confidentiality
" unknown redundancy may happen: polyinstantiation
Myoung Ho Kim, KAIST
26
Multilevel Database (cont’d)
Polyinstantiation
» one record can appear many times, with different levels of security
» occurs as a consequence of the mandatory policy
(Example)
– suppose a personnel specialist, John knows that Bob works for
the company
– however, Bob’s record does not appear on the roster
– John assumes that this is an error and creates a record for Bob
» there actually is a record on Bob in the file, but his record is not
accessible to John
» creation of new record means that there are now two records for Bob
Myoung Ho Kim, KAIST
Multilevel Database (cont’d)
u
777
oSGi
oSGi
z h
s
j
{z
wGt
zGh
s
zGi
777
– Polyinstantiation can be used to prevent the users with low-clearance
from inferring the existence of the high-classified data
» merely scanning the database to find a record may not be satisfactory
there may be records entered for people with low-clearance
Myoung Ho Kim, KAIST
27
Proposals for Multilevel Security
!
Multilevel security for DB is difficult
» small granularity of the items being controlled
» complex ways that items are combined for processing
» for a query, data of different security levels may be involved
Myoung Ho Kim, KAIST
Proposals for Multilevel Security (cont’d)
!
Partitioning
– database is divided into multiple separate databases
» each at its own sensitivity level
– drawbacks
» destroys the basic advantage of database
elimination of redundancy and improved accuracy through having
only one field to update
» problem of combining high-level data with low-level data
– however, many users with data of mixed sensitivities handle their
data using separate databases
» because of difficulty in establishing and maintaining multilevel DB
Myoung Ho Kim, KAIST
28
Proposals for Multilevel Security (cont’d)
!
Encryption of sensitive data
– sensitive data is encrypted under a key unique to the level of
sensitivity
» chosen plaintext attack
compare the encrypted version of a known value with other
unknown encrypted values
– use a different encryption key for each record
» e.g., use record-id as a part of encryption key
– cipher block chaining (CBC)
» fields of a record are cryptographically linked
Myoung Ho Kim, KAIST
Proposals for Multilevel Security (cont’d)
Drawback of encryption
– each field must be decrypted in order to perform standard database
operations, and this increases the time to process a query
Myoung Ho Kim, KAIST
29
Proposals for Multilevel Security (cont’d)
!
Integrity lock
– provide both integrity and limited access for database
» called “spray paint ” because each item is painted with a color that
denotes its sensitivity
data
sensitivity
Secret Agent
TS
checksum
10FB
sensitivity
checksum
Integrity lock
» checksum: computed by data and sensitivity label
error-detecting code
prevent unauthorized modification of data and its label
Myoung Ho Kim, KAIST
Proposals for Multilevel Security (cont’d)
#
Data is
» stored in plaintext for efficiency of DBMS operations
#
Sensitivity label should be
– unforgeable: cannot create a new sensitivity label for an item
– unique: cannot copy a sensitivity label from another item
– concealed: cannot even determine the sensitivity label of an item
Myoung Ho Kim, KAIST
30
Proposals for Multilevel Security (cont’d)
#
Cryptographic checksum
– this checksum must be unique for a given item
» includes record#, (sensitive) attribute name, data, and sensitivity label
» these four components guard against changing or copying
– encrypted
data
record#
R07
sensitivity
Secret Agent
TS
checksum
10FB
sensitivity
checksum
encrypted
Myoung Ho Kim, KAIST
Proposals for Multilevel Security (cont’d)
!
Multilevel DBMS architecture
– Trusted subject architecture
» a trusted DBMS and a trusted OS
– Woods Hole architecture
» an untrusted DBMS with a trusted front-end
» (ex) Integrity lock architecture
Myoung Ho Kim, KAIST
31
Proposals for Multilevel Security (cont’d)
!
Woods Hole architecture
– use a Trusted Front-End (TFE)
– enhances security of existing systems with minimal change
» most DBMSs are built without consideration of multilevel security
Security perimeter
users
Trusted
Front-End
Untrusted
DBMS
Sensitive
database
Myoung Ho Kim, KAIST
Proposals for Multilevel Security (cont’d)
#
Interaction between a user, a TFE and a DBMS
1. TFE authenticates user’s identity
2. User issues a query to front-end
3. TFE verifies user’s authorization to data
4. TFE issues a query to DBMS
5. DBMS performs a I/O access
6. DBMS returns result of query to front-end
7. TFE verifies validity of data via checksum and checks
classification of data against clearance of user
8. TFE transmits data to user
Myoung Ho Kim, KAIST
32
Proposals for Multilevel Security (cont’d)
Integrity lock DBMS
» TFE is responsible for security function and multilevel protection
– TFE enforces multilevel protection by attaching security labels to
database objects, i.e., integrity lock
" The efficiency of the integrity lock is a serious drawback
» space overhead
» increased processing time
" untrusted DBMS sees all database
» subject to Trojan horse
» i.e., data can be leaked through covert channels
Myoung Ho Kim, KAIST
Proposals for Multilevel Security (cont’d)
!
Commutative filter
» simplification of the trusted interface to the users and DBMS
» tries to capitalize on the efficiency of most DBMS
– user’s query is modified so that only data of an appropriate
sensitivity level is returned to the user
» the filter reformats the query so that DBMS does most of the work
» sensitive information is never extracted from the database
– Advantages
» keeps the size of security filter relatively small
» reduces redundancy between it and the DBMS
» improves the overall efficiency
Myoung Ho Kim, KAIST
33
Proposals for Multilevel Security (cont’d)
(Ex) Query modification by the commutative filter
< Original query >
retrieve NAME where((OCCUP = PHYSICIST)^(CITY = WASHDC))
< Modified query >
retrieve NAME where((OCCUP = PHYSICIST)^(CITY = WASHDC))
from all records R where
((NAME-SECRECY-LEVEL(R) ≤ USER-SECRECY-LEVEL) ^
(OCCUP-SECRECY-LEVEL(R) ≤ USER-SECRECY-LEVEL) ^
(CITY-SECRECY-LEVEL(R) ≤ USER-SECRECY-LEVEL))
Myoung Ho Kim, KAIST
Evaluated Products List
Evaluated products list
– rated by NSA in accordance with TCSEC
– http://www.radium.ncsc.mil/tpep/epl/epl-by-class.html
» as of 2001/07/19
Myoung Ho Kim, KAIST
34
Evaluated Products List (cont’d)
!
A1: verified design
!
B3: security domain
!
B2: structured protection
!
B1: labeled security protection
» mandatory access control, etc
– Trusted applications
» Informix: INFORMIX-OnLine/Secure 4.1, 5.0
» Oracle: Trusted Oracle7
» Sybase: Secure SQL Server version 11.0.6
Myoung Ho Kim, KAIST
Evaluated Products List (cont’d)
!
C2: controlled access protection
– make users individually accountable for the actions
» login procedures, auditing of security-relevant events, and resource
isolation
!
C1: discretionary access protection
– satisfies the discretionary security requirements
!
Minimal protection
– fail to meet the requirements for a higher evaluation class
Myoung Ho Kim, KAIST
35
