Information Security Databases and (Inter)Networks

1
Information SecurityDatabases and (Inter)Networks

• Prof. dr. P.M.E. De Bra
• Department of Computing Science
• Eindhoven University of Technology

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

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

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

5
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 end-users, 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.

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

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

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

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

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

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

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

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

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

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

16
Protection requirements (cont.)

• Multilevel protection
  A finer distinction than
  sensitive vs. non-sensitive 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.

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

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

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

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

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

22
Minimum privilege (closed system)
Access request
Does there exist a rule authorizing the access?
Rules authorized accesses
yes
no
Access permitted
Access denied
23
Maximum privilege (open system)
Access request
Does there exist a rule denying the access?
Rules denied accesses
no
yes
Access permitted
Access denied
24
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.

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

26
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. 0unclassified,
  1confidential, 2secret, 3top secret
• C category, e.g. production, personnel,
  engineering, administration.
• Security classes can be compared

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

28
Mandatory policies
Access request
Security axioms
Does the request satisfy the axioms of the
mandatory policy?
Security classes of subjects/objects
yes
no
Access permitted
Access denied
29
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.

30
Discretionary policies
Access request
Authorization rules
Does the request satisfy the authorization rules?
Access denied
no
yes
no
Access denied
Is an optional predicate of the rules satisfied?
Access permitted
yes
31
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.

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