Transcript Information Security Databases and (Inter)Networks

Information Security
Databases and (Inter)Networks
Prof. dr. P.M.E. De Bra
Department of Computing Science
Eindhoven University of Technology
Parts / Topics / Issues
• Introduction: information security in
information systems.
• (Relational) database security models.
• Designing secure (relational) databases.
• Statistical database security.
• Security in active and object-oriented
databases.
• Intrusion detection in databases.
• Secure database access through Internet.
Information System Security
• secrecy: preventing/detecting/deterring the
improper disclosure of information.
– company policy (and the legal system) determine
who may have access to which information.
• integrity: preventing/detecting/deterring the
improper modification of information.
– company policy determines who may modify
which data. (the system must enforce the policy)
• availability: preventing/detecting/deterring
improper denial of access to data or services.
Database concepts
• Data management:
– lowest level: operating system
– higher level: database management system
• Data models:
– logical: dbms dependent model, typically a
relational model.
– conceptual: a model that describes the concepts
to be represented in the database, typically
using an entity-relationship model, or a
semantic or functional model.
Database concepts (cont.)
• Data Definition Language (DDL): used to
define data structures (relations).
• Data Manipulation Language (DML):
used to add, delete and modify data. The
DML is often embedded in a programming
language. (It is often used indirectly by endusers, through forms-based interfaces.)
• Query Language (QL): a declarative
language to specify which data to retrieve.
It may be used directly by (some) end-users.
Security threats in databases
• Type of threat: release of information,
modifications or denial of service.
• Cause of unintentional threats:
– Natural or accidental disaster: causes damage
to the hardware; results in loss of data and/or
denial of service.
– Errors or bugs in hardware or software: may
result in unauthorized access or updates.
– Human errors: incorrect input or incorrect use
of applications; results similar to those of bugs.
Security threats in databases (cont.)
• Intentional abuse by users:
– Authorized users may abuse their privileges
and authority to leak information to others or to
make modifications that harm their employer.
– Hostile agents (outsiders and insiders) may
attempt unauthorized actions. Examples:
• virus: self-replicating damaging code.
• trojan horse: hidden part of legitimate code
performs invisible unauthorized actions.
• trapdoor: special input activates code that
circumvents security mechanisms.
Security policies and mechanisms
• A policy defines what the security system is
expected to do. Most policies concentrate
on defining which reading and update
actions on which data are authorized.
• A mechanism defines how the security
system should enforce the chosen policy.
• The security system assurance defines
how well the mechanisms are able to
enforce the policy. It is a quality measure.
Database protection requirements
• Protection from improper access:
the DBMS must determine if an access
request from a user or application is
permissible.
– Fine granularity: Access rights can be defined
for tables, records, attributes and values.
– Redundant access rights: A user has rights to
certain data and to certain applications; the
“normal” use of these applications should not
lead to data the user is not authorized for.
Protection requirements (cont.)
• Protection from inference:
It must not be possible to infer values a user
is not authorized to access from data that
user is authorized to access.
– Semantic relations: A user may abuse
knowledge of relations or integrity constraints
to infer values.
– Statistic inference: A user may trace back
information on a single individual from
statistical aggregated information. (This is most
likely when accessing “small” samples.)
Protection requirements (cont.)
• Integrity of the database:
– Integrity constrains are used to prevent
entering data (by mistake or on purpose) that
are considered “impossible”.
– Backup and recovery procedures are used to
avoid the loss of data (and recent updates) due
to software or hardware failures.
Database systems typically use:
• periodic complete or incremental backup.
• logging of update requests so that the
updates can be “replayed” after a crash.
Protection requirements (cont.)
• Operational integrity of data:
A database executes transactions concurrently.
– The DBMS must ensure the ACID property:
• Atomicity: Either all or none of the actions of
a transaction are performed.
• Consistency: After completing a transaction no
integrity constraint may be violated.
• Isolation: No intermediate result of actions of a
transaction is visible outside the transaction.
• Durability: After completion of the
transaction, the results are permanent.
Protection requirements (cont.)
• Operational integrity of data (cont.):
ACID is achieved through two-phase locking.
– When a transaction wishes to read an object it
first requests a shared lock.
– When a transaction wishes to write an object it
first requests an exclusive lock.
– When a transaction completes (commit or abort)
it releases all locks.
serializability: as if transactions were
executed one after another.
isolation: transactions are independent.
Protection requirements (cont.)
• Accountability and auditing:
All accesses (or attempts) to data items
should be registered. Ideally each access to
each value for each attribute of each record
should be recorded. But this would be
impractical regarding time and cost.
• User authentication:
All users must have a unique identity. A
secure “log-in” procedure is needed. There
may be duplication with OS login-procedures.
Protection requirements (cont.)
• Management and protection of sensitive
data:
– A data item can be sensitive by itself, in
combination with other data, or by being part
of a sensitive record.
– Users with access to sensitive data must be
prevented from propagating this privilege to
other users.
– Users with access to sensitive data must be able
to work with other users and with non-sensitive
data.
Protection requirements (cont.)
• Multilevel protection:
A finer distinction than “sensitive” vs. “nonsensitive” may be needed.
– Data items have an associated level of
sensitivity. Different attributes of a record may
have a different level. Different values of the
same attribute may have a different level.
– Aggregated data may have a different (higher
or lower) level than the individual data items.
– Each user has a clearance level which
determines which data may be accessed.
Protection requirements (cont.)
• Confinement:
The transfer of data between programs may be
restricted. Transfer occurs along
– authorized channels: used to supply output
through authorized actions (e.g. report generation).
– memory channels: communication occurs via
shared memory (ram memory or files).
– covert channels: communication occurs via
system functions not normally intended for
communication (e.g. infer data values from the
time needed to perform a certain action).
Security controls
• Flow control: regulates the copying of
information between objects.
• Inference control: protects data from
indirect detection. (This is generally
complicated.)
• Access control: verifies which subjects
(users, processes) may perform which
actions (read, write, execute) on which
objects.
Security controls (cont.)
• Flow control:
– Data (values) can sometimes be inferred from
partial information. Testing on the value of X
reveals information about that value, although
not always the exact value of X itself.
– When data is read from X and written into Y,
that data becomes available through Y.
Often, the sensitivity level is associated with
the record (or attribute), not the value. If X is a
sensitive record and Y is not, the sensitive data
becomes available through the Y record.
Security controls (cont.)
• Inference control:
protecting data from indirect detection.
– Indirect access: the user does not ask for Y but
infers its value from a query asking for X.
SELECT X FROM r WHERE Y = value
– Correlated data: the user has access to
information from which unauthorized data can
be calculated or estimated.
– Missing data: the error message when trying to
access data may reveal something about this
data (like that it exists).
Security controls (cont.)
• Access control:
Consists of policies and procedures:
– Minimum privilege policy (mandatory): user has
access only to what she needs to know.
– Maximum privilege policy (discretionary): user
has access to everything that is not forbidden.
– External mechanisms: prevent unauthorized
people from physical access to the entire database.
– Internal mechanisms: prevent unauthorized
access to data by people with access to the system.
Minimum privilege (closed system)
Access request
Does there exist a
rule authorizing
the access?
yes
Access
permitted
no
Access
denied
Rules:
authorized
accesses
Maximum privilege (open system)
Access request
Does there exist a
rule denying
the access?
no
Access
permitted
yes
Access
denied
Rules:
denied
accesses
Authorization management
• Who can grant and revoke access rights.
– Hierarchical decentralized authorization:
a hierarchy of (sub)administrators is used to
distribute administrative responsibilities.
– Ownership: upon object creation (for relations,
not for individual tuples in a relation) the
creator can grant or revoke access to the object.
– Cooperative authorization: consensus among
a predefined group of users is needed to change
access rights.
Access control policies
• Grouping subjects (users) and objects in
order to share access modes according to
given authorizations and rules.
– Grouping simplifies the specification of
security policies and the implementation of
security mechanisms.
– Grouping complicates the consequences of
users belonging to more than one group, or
users changing group membership.
Multilevel security systems are easier: they
use a hierarchy of levels for groups.
Security classes
• subjects (users) and objects are assigned a
security class. An object security class is an
ordered pair (L,C):
– L: classification level, e.g. 0=unclassified,
1=confidential, 2=secret, 3=top secret
– C: category, e.g. production, personnel,
engineering, administration.
Security classes can be compared:
SC  (L,C) and SC'  (L', C' )
SC  SC' iff L  L' and C  C'
Mandatory policies
• A set of axioms determines the relations to
be verified between the subject class and the
object class before allowing access. The
relations depend on the access mode.
• Access rights can only be changed by the
authorizer.
(Full control on the authorization system is
kept by the authorizer.)
Mandatory policies
Access request
Security axioms
Does the request satisfy
the axioms of the
mandatory policy?
yes
no
Access
permitted
Access
denied
Security
classes of
subjects/objects
Discretionary policies
• For each subject a set of authorization
rules specifies the privileges owned on the
objects.
• Discretionary means that users can grant
and revoke access rights on some objects.
This implies decentralized administrative
control through ownership.
• Propagation of rights, and revoking
propagated rights is complicated.
Discretionary policies
Access request
Authorization
rules
Does the request
satisfy the
authorization rules?
no
yes
no
Access
denied
Is an optional
predicate of the
rules satisfied?
yes
Access
denied
Access
permitted
Evolution in database security
• External level: controls physical access to
the database system (to the site).
• Internal level: controls access by insiders,
who have a right to access the system.
External security becomes less important.
Internal security becomes more important.
• Trust in users who have some access rights
is dangerous.
• External security is less effective for
databases connected to public networks.
Conclusion of the Introduction
• Security deals with access to, modification
of data, and denial of service.
• Security is not an add-on but an integral
part of every secure database.
• There is no single security policy that works
for every database application.
• A secure database is first and foremost a
reliable database with solid backup and
recovery procedures, concurrency control
and integrity constraints.