1. Information Security Databases 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 Access permitted Access denied yesno

23. Maximum privilege (open system) Access request Does there exist a rule denying the access? Rules: denied accesses Access permitted Access denied noyes

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. 0=unclassified, 1=confidential, 2=secret, 3=top 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 Does the request satisfy the axioms of the mandatory policy? Security classes of subjects/objects Access permitted Access denied yesno Security axioms

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 Does the request satisfy the authorization rules? Authorization rules Access denied Is an optional predicate of the rules satisfied? noyes Access denied no 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.