DATABASE SECURITY ISSUES

I. INTRODUCTION.

Database security concerned with ensuring the secrecy, integrity, and availability of data stored in a database. Secrecy requires that data be protected from unauthorized disclosure, including indirect disclosure via inference. Integrity requires that data be protected from unauthorized or erroneous modification, including insertion of false data, data contamination and destruction of data, all of which leave a database in an invalid or inconsistent state.

Availability requires that data be available to authorized users at the time of need. Threats to data integrity affect availability since a user may have to wait for lost or corrupted data to be recovered or reconstructed from back-up files. Availability is also threatened by denial-of-service attacks, where an attacker monopolizes system resources in such a way that other users cannot get needed service.

The secrecy, integrity, and availability requirements of a system are defined by a security policy, which is then enforced by various security mechanisms. A system is considered to be secured if it correctly enforces its policy.

Statement of the Problem

1. What are the security measures implemented?

2. Authorized accessed on database systems.

3. What are the procedures on implementing the database systems?

4.Testing procedures on databases?

5. What is inference in databases?

1

II. WHAT AUTHOR SAY.

Database Security by Dorothy E. Denning

The security policy for a database system may have several components:

- A discretionary access policy control, which specifies what users are authorized perform what operations on what data, and the rules whereby users can, at their discretion, grant and revoke their authorizations to other users.

- A mandatory access control policy, which specifies the rules whereby users can obtain direct or indirect access to classified data, and the rules for sanitizing and reclassifying data. These policies apply only to multilevel databases. which are databases that contain information of different classifications.

Database Security and Controls by Ravi S. Sandhu and Sushil Jajodia

Secrecy, Integrity and Availability

The objective of data security can be divided into three separate, but interrelated, areas as follows.

Secrecy is concerned with improper disclosure of information. The terms confidentiality or non-disclosure are synonyms for secrecy.

Integrity is concerned with improper modification of information or processes.

Availability is concerned with improper denial of access to information. The term denial of service is also used as a synonym for availability.

These three objectives arise in practically every information system.

For example, in a payroll system secrecy is concerned with preventing an employee from finding out the boss's salary. Integrity is concerned with preventing an employee from changing his or her salary; and availability is concerned with ensuring that the paychecks are printed on time as required by law. Similarly, in a military command and control system.

Secrecy is concerned with preventing the enemy from determining the target coordinates of a missile. Integrity is concerned with preventing the enemy from altering

2

the target coordinates and availability is concerned with ensuring that the missile does get launched when the order is given.

Any system will have these three requirements co-existing to some degree. There are of course differences regarding the relative importance of these objectives in a given system. The commercial and military sectors both have similar needs for highintegrity systems. The secrecy and availability requirements of the military are oftenmore stringent than in typical commercial applications.

These three objectives also differ with respect to our understanding of the objectives themselves and of the technology to achieve them. It is easiest to understand the objective of secrecy. Integrity is a less tangible objective on which experts in the field have diverse opinions. Availability is technically the least understood aspect. In terms of technology, the dominance of the commercial sector in the marketplace has led vendors to emphasize mechanisms for integrity rather than for military-like secrecy needs. The availability objective is so poorly understood that no product today even tries to address it directly.

Security Policy

Security policy is to elaborate the three generic security objectives ofsecrecy, integrity and availability, in the context of a particular system. The generic objectives have all used the term "improper" in their definition. A statement of security policy largely consists of defining what is the meaning of "improper" for a particular system.

The meaning of "improper" is sometimes mandated by law, such as for secrecy in the classified military and government sectors. Legal and professional requirements apply to medical records and other sensitive personal information about individuals. Due to conflict of interest considerations so-called Chinese Walls are required to prevent business consultants from accessing confidential information for two or more companies competing in the same market sector. In general, however, security policy is largely determined within an organization rather than imposed by mandate from outside. This is particularly so in the integrity and availability arenas. understood that no product today even tries to address it directly.

Prevention, Detection and Tolerance

The objective of data security can be approached in two distinct, and mutually supportive, ways.

3

Prevention ensures that security breaches cannot occur. The basic technique is that the system examines every action and checks its conformance with the security policy before allowing it to occur. This technique is called access control.

Detection ensures that sufficient history of the activity in the system is recorded in an audit trail, so that a security breach can be detected after the fact. This technique is called auditing.

Every system employs some mix of these two techniques. Sometimes the distinction between these two techniques gets blurred. For example, consider a system which monitors the audit trail in real time looking for imminent security violations so as to prevent them. Such a system is preventive in nature, yet the technology used is basically a detective one. The distinction is nevertheless a useful one. Our focus in this chapter is on preventive techniques.

Prevention is the more fundamental technique. An effective detection mechanism requires a mechanism to prevent improper modification of the audit trail. Moreover, detection is ultimately useful only to the extent that it prevents improper activity by threatening punitive action.

Finally, there is the third "technique" of tolerance in which the potential for some security breaches is tolerated; because either these breaches are too expensive to prevent or detect, or the likelihood of their occurrence is considered sufficiently low, or security measures are acceptable to users only up to some reasonable point. Every practical system tolerates some degree of risk with respect to potential security breaches. It is, however, important to understand what risk is being tolerated and what is being covered by preventive/detective mechanisms.

Assurance

Security mechanisms, whether preventive or detective in nature, can be implemented with various degrees of assurance. Assurance is directly related to the effort required to subvert the mechanism. Low assurance mechanisms are easy to implement but also relatively easy to subvert. Subtle bugs in system and/or application software have led to numerous security breaches. On the other hand, high assurance mechanisms are notoriously difficult to implement. They also tend to sure from degraded performance. Fortunately, rapid advances in hardware performance are making the performance penalty acceptable.

4

Access Controls in Current Systems

The access controls provided in the current generation of commercially available Database Management Systems. Our focus is on relational systems. The access controls described here are often referred to as discretionary access controls as opposed to the mandatory access controls of multilevel security.

The purpose of access controls is to ensure that a user is only permitted to perform those operations on the database for which that user is authorized. Access controls are based on the premise that the user has been correctly identified to the system by some authentication procedure. Authentication typically requires the user to supply his or her claimed identity (e.g., user name, operator number, etc.) along with apassword or some other authentication token. Authentication may be performed by the Operating System, the Database Management System, a special Authentication Server, or some combination thereof.

Granularity and Modes of Access Control

Access controls can be imposed at various degrees of granularity in a system. Somepossibilities are enumerated below.

- The entire database.- Some collection of relations.- One relation.- Some columns of one relation.- Some rows of one relation.- Some columns of some rows of one relation.

Data Dependent Access Control

Database access controls are often data dependent. For example, some users may be limited to seeing salaries which are less than $30,000. Similarly, a manager may be restricted to seeing salaries for employees in his department. We now discuss two basic techniques, viz., view-based access controls and query modification, for implementing data-dependent access controls in relational databases.

View based access control - A base relation is a "real" relation in the database, that is it is actually stored in the Database. A view is a "virtual" relation which is derived from base relations and other views. The database stores the view definitions and materializes the view as needed.

Query Modification - is another technique for enforcing data-dependent access controlsfor retrieval. In this technique, a query submitted by a user is modified to includefurther restrictions as determined by the user's authorization.

5

Granting and revocation allow users to selectively and dynamically grant privileges to other users, and subsequently revoke them if so desired.

Multilevel Security Requirements

The focus of multilevel security is on secrecy, and this section reflects this focus. The granting of access is under user control. Users who possess a privilege with the grant option are free to grant it to whomever they choose to. We first show that this approach has serious limitations with respect to secrecy requirements. We then describe how mandatory access controls get around this limitation. Next we introduce the covert channel problem which even mandatory controls are unable to solve. Finally, we briefly discuss the evaluation criteria for secure computer systems developed by the U.S. Department of Defense. It should be noted that although multilevel security has been developed primarily for the military sector, it is applicable in the commercial sector also.

Mandatory access controls are based on security labels associated with each data item and each user. A label on a data item is called a security classification, while a label on a user is called a security clearance. In a computer system every program run by a user inherits the user's security clearance. In other words the user's clearance applies not only to the user as a human being, but also to every program executed by that user. It is important to understand that a particular program, such as a text editor, when executed by a Secret user is run as a Secret process; whereas when it is executed by an Unclassified user it is run as an Unclassified process. Moreover, the classifications and clearances once assigned cannot be changed (except by the security officer).

Security labels in the military and government sectors consist of two components: a hierarchical component and a (possibly empty) set of categories. The hierarchical component consists of the following, listed in decreasing order of sensitivity.

- Top secret (TS)- Secret (S)- Confidential (C)- Unclassified (U)

The categories consist of items such as NUCLEAR, CONVENTIONAL, NAVY,ARMY, NATO, etc. The label X is said to dominate label Y provided the hierarchical component of X is greater than or equal to the hierarchical component of Y, and the categories of X contain all the categories of Y.

For example:- X = (TOP-SECRET, {NUCLEAR, ARMY}) dominates Y = (SECRET, {ARMY})- X = (SECRET, {NUCLEAR, ARMY}) dominates Y = (SECRET, {NUCLEAR})- X = (TOP-SECRET, {NUCLEAR}) is incomparable to Y = (SECRET, {ARMY}),i.e., neither one dominates the other.

6

Note that two labels which dominate each other are exactly identical.

Commercial organizations also use similar labels for protecting sensitive information. The main difference is that procedures for assigning clearances to users are much less formal than in the military or government sectors. We will henceforth limit ourselves to hierarchical labels, i.e., labels without any categories. The reader is cautioned that there are many subtle issues which arise due to incomparable labels (i.e., labels with categories). However, the basic concepts can be demonstrated with hierarchical labels. We usually use the labels Secret and Unclassified in our discussion.

When a user signs on (i.e., logs in) to the system he or she specifies the security level of that session. The level of the session must be dominated by the user's clearance. That is, a Secret user can sign on as Unclassified, but an unclassified user cannot sign on as Secret. Once the user is signed on at a specific level all programs executed by him or her will be run at that level.

The following rules for mandatory access control were formulated by Bell and LaPadula.

- Simple Security: A subject (i.e., a running program) with label X can read an object (i.e., a data item) with label Y only if X dominates Y.

- Star-Property: A subject with label X can write an object with label Y only if Y dominates X.

For example, a Secret subject can read Secret and Unclassified data, but cannot write Unclassified data. So even with Trojan Horses in the software, it is not possible to copy information from Secret data items to unclassified data items.

The simple-security requirement applies equally to humans and programs. The star-property on the other hand is not applied to the human users, but rather to programs. Human users are trusted not to leak information. A Secret user can write an unclassified document, because it is assumed that he or she will only put unclassified information in it. Programs, on the other hand, are not trusted because they may have Trojan Horses embedded in them. A program running at the Secret level is therefore not allowed to write to unclassified data items.

Covert Channels

Unfortunately, mandatory controls do not solve the Trojan Horse problem completely. A program running at the Secret level is prevented from writing directly to Unclassified data item. There are, however, other ways of communicating information to Unclassified programs.

Unfortunately, mandatory controls do not solve the Trojan Horse problem completely. A program running at the Secret level is prevented from writing directly to

7

Unclassified data item. There are, however, other ways of communicating information to Unclassified programs.

For example, the Secret program can acquire large amounts of memory in the system. This fact can be detected by an Unclassified program which is able to observe how much memory is available. Even if the Unclassified program is prevented from directly observing the amount of free memory, it can do so indirectly by making a request for a large amount of memory itself. Granting or denial of this request will convey some information about free memory to the Unclassified program. Such indirect methods of communication are called covert channels. Covert channels present a formidable problem for multilevel security. They are difficult to detect, and once detected are difficult to close without incurring significant performance penalties. Covert channels do tend to be noisy due to interference by the activity of other users in the system. Nevertheless, standard coding techniques for communication on noisy channels can be employed by the Trojan Horses to achieve error-free communication, with data rates which can be as high as several million bits per second.

Evaluation Criteria

In 1985 the U.S. Department of Defense published the Trusted Computer System Evaluation Criteria, popularly known as the Orange Book. This document established a metric against which computers systems can be evaluated for security. The metric consists of a number of levels, A1, B3, B2, B1, C2, C1, and D; listed here in decreasing order of how secure the system is.

For each level, the Orange Book lists a set of requirements that a system must have to achieve that level of security. Briefly, the D level consists of all systems which are not secure enough to qualify for any of A, B, or C levels. Systems at levels C1 and C2 provide discretionary protection of data, systems at level B1 provide mandatory access controls, and systems at levels B2 or above provide increasing assurance, in particular against covert channels. The level A1, which is most rigorous, requires verified protection of data.

In 1991 the U.S. Department of Defense published the Trusted Database Interpretation of the Trusted Computer System Evaluation Criteria, popularly known asthe TDI. The TDI describes how a DBMS and the underlying OS can be evaluated separately and in conjunction. Several efforts are underway to build secure DBMS products satisfying these criteria.

8

Inference and Aggregation

Even in multilevel secure DBMSs, it is possible for users to draw inferences from the information they obtain from the database. The inference could be derived purelyfrom the data obtained from the database system, or it could additionally depend onsome prior knowledge which was obtained by users from outside the database system. An inference presents a security breach if more highly classified information can be inferred from less classified information.

There is a significant difference between the inference and covert channel problems. Inference is a unilateral activity, in which an Unclassified user legitimately accesses Unclassified information from which that user is able to deduce Secret information. Covert channels, on the other hand, require cooperation of a Secret Trojan Horse which transmits information to an Unclassified user by indirect means of communication. The inference problem will exist even in an ideal system which is completely free of covert channels.

There are many difficulties associated with determining when more highly classified information can be inferred from less classified information. The biggest problem is that it is impossible to determine precisely what a user knows. The inference problem is somewhat manageable if we adopt the closed-world assumption and assume that if information Y can be derived using information X, then both X and Y are contained in the database. In reality, however, the outside knowledge that users bring plays a significant role in inference.

There are two important cases of the inference problem, which often arise indatabase systems.

- An aggregation problem occurs whenever there is a collection of data items that is classified at a higher level than the levels of individual data items by themselves. A classic example from a military context occurs when the location of individual ships is unclassified, but the aggregate information concerning the location of all ships in the fleet is secret. Similarly, in the commercial sector the individual sales figures for branch offices might be considered less sensitive than the aggregate sales figures for the entire company.

- A data association problem occurs whenever two values seen together are classified at a higher level than the classification of either value individually. As an example, the list consisting of the names of all employees and the list containing all employee salaries are unclassified, while a combined list giving employee names with their salaries is classified.

9

Notice that the data association problem is different from the aggregation problem since what is really sensitive is not the aggregate of the two lists, but the exact association giving an employee name and his or her salary.

We now describe some techniques for resolving the inference problem. Although these methods can be extremely useful, a complete and generally applicable solution to the inference problem remains an elusive goal.

Appropriate Labeling

If Unclassified information x permits disclosure of Secret information y, one way to prevent this is to reclassify all or part of information x such that it is no longer possible to derive y from the disclosed subset of x. To illustrate, suppose that an attribute A is Unclassified while attribute B is Secret. Suppose the database enforces the constraint A + B < 20, and that the constraint is known to Unclassified users. The value of B does not affect the value of A directly, but it does constrain the set of possible values A can take. Thus we have an inference problem. This inference can be prevented by reclassifying A as Secret.

Query Restriction

Many inference violations arise as a result of a query which returns data at the user's level, but its evaluation requires accessing data above the user's level.

Polyinstantiation is another technique that can be used to prevent inference violations. To illustrate, suppose an Unclassified user wants to enter a row in a relation in which each row is labeled as S (Secret) or U (Unclassified). If the same key is already occurring in an S row, we cannot prevent the Unclassified from inserting the U row without leakage of 1 bit of information by inference. In other words the classification of the row has to be treated as part of the relation key. Thus U rows and S rows will always have different keys, since the keys will have different security classes.

Auditing can be used to control inferences. For instance, a history can be kept of all queries made by a user. Whenever the user makes a query, the history is analyzed to determine whether the response to this query, correlated with the responses to earlier queries, could result in an inference violation. If a violation could arise, the systems can take appropriate action (for example, abort the query).

There is a side benefit of this approach: it may deter many inference attacks by threatening discovery of violations. There are two disadvantages of this approach: One, it may be too cumbersome to be useful in practical situation. Two, it can detect very limited types of inferences (since it is based on the hypothesis that a violation can always be detected by analyzing the audit records for abnormal behavior.)

10

Tolerating Limited Inferences

Tolerance methods are useful in those cases in which the inference bandwidth is so small that these violations do not pose any threat. Consider the following example. Suppose that data are classified at the column level, and that we have two relations, one called PD with the Unclassified attribute PLANE and Secret attribute DESTINATION, and another called DF with the Unclassified attribute DESTINATION and Unclassified attribute FUEL-NEEDED. Suppose also that, although knowledge of the fuel needed for a particular plane can give information about the destination of the plane, there are too many destinations requiring the same amount of fuel for this to be a serious inference threat. Moreover, we do not want to go to the trouble of clearing everybody responsible for fueling the plane to the Secret level. Thus we wish to make the derived relation with attributes PLANE and FUEL-NEEDED available to Unclassified users.

Even though we have decided that this information does not provide a serious inference threat, we cannot allow Unclassified users to extract the required information from PD and PF by, say, executing the following query.

SELECT PLANE, FUEL-NEEDEDFROM PD, DFWHERE PD.DESTINATION = DF.DESTINATION

Doing so opens up a covert channel for leaking Secret information to Unclassifiedusers.

One solution is to use the snapshot approach, where a trusted user creates a derived Secret relation with attributes PLANE and FUEL-NEEDED and then downgrades it to Unclassified. Although this "snapshot" cannot be updated automatically without opening a covert channel, it can be kept more or less up-to-date by having the trusted user re-create it from time to time.

A "snapshot" or a "sanitized file" is an important technique for controlling inferences, especially in offline, static databases. In particular, it has been used quiteeffectively by the United States Bureau of the Census.

Integrity Principles and Mechanisms

In this section we discuss the problem of data integrity. Integrity is a much less tangible objective than secrecy. Our approach to integrity is pragmatic and utilitarian. We define integrity as being concerned with the improper modification of information (much as confidentiality is concerned with improper disclosure). We understand modification to include insertion of new information, deletion of existing information as well as changes to existing information.

11

The reader may have seen similar definitions of integrity using "unauthorized" instead of "improper." Our use of the latter term is significant and should not be dismissed lightly. Integrity breaches can and do occur without authorization violations. In other words authorization is only one piece of the solution and we must also deal with the malicious user who exercises his or her authority improperly.

The Insider Threat

It is important to understand that the threat posed by a corrupt authorized user is quite different in the context of integrity as compared to secrecy.

A corrupt user can leak secrets by using the computer to legitimately access confidential information, and then passing on this information to an improper destination by some non-computer means of communication (e.g., a telephone call). It is simply impossible for the computer to know whether or not step was followed by step. We therefore have no choice but to trust our insiders to be honest and alert. The military and government sectors have established elaborate procedures for this purpose, while the commercial sector is much more informal in this respect. Security research which focuses on secrecy therefore considers the principal threat to be Trojan Horses embedded in programs. That is, the focus is on corrupt programs rather than corrupt users.

Analogously, a corrupt user can compromise integrity by manipulating stored data, or falsifying source or output documents. A computer system can do little by itself to solve the problem of false source or output documents, for which we must rely on the traditional techniques of paper-based manual systems. However, the manipulation of stored data simply cannot be done without use of the computer. In principle, the computer system is in a position to detect or prevent such manipulation. Integrity must therefore focus on the corrupt user as the principal problem. In fact the Trojan Horse problem can itself be viewed as a problem of corrupt system or application programmers, who improperly modify the software under their control. Also note that the problem of the corrupt user remains even if we are willing to trust all our software to be free of Trojan Horses.

12

Integrity Principles

In this section we identify basic principles for achieving data integrity. Principleslay down broad goals without specifying how to achieve them. We will map these principles to DBMS mechanisms. Principles lay out what needs to be done while mechanisms establish how these principles are to be achieved.

Seven integrity principles are enumerated below.

1. Well-formed Transactions. The concept of the well-formed transaction is that users should not manipulate data arbitrarily, but only in restricted ways that preserve integrity of the database.

2. Least Privilege. Programs and users should be given the least privilege necessary to accomplish their task.

3. Separation of Duties. Separation of duties is a time honored principle for prevention of fraud and errors, going back to the very beginning of commerce. Simply stated, no single individual should be in a position to misappropriate assets on his own. Operationally this means that a chain of events which affectsthe balance of assets must require different individuals to be involved at key points, so that without their collusion the overall chain cannot take effect.

4. Reconstruction of Events. This principle seeks to deter improper behavior by threatening its discovery. The ability to reconstruct what happened in a system stems from the notion of accountability. Users are accountable for their actions to the extent that it is possible to determine what they did.

5. Delegation of Authority. This principle concerns the critical issue of how privileges are acquired and distributed in an organization. Clearly the procedures to do so must reflect the structure of the organization and allow for effective delegation of authority.

6. Reality Checks. Cross-checks with external reality are an essential part of integrity control. For example, if an internal inventory record does not correctly reflect the number of items in the warehouse, it makes little difference if the value of the recorded inventory is being correctly recorded in the balance sheet.

7. Continuity of Operation. This principle states that system operations should be maintained to some appropriate degree in the face of potentially devastating events which are beyond the organization's control. This catch-all description is intended to include natural disasters, power outages, disk crashes and the like. With this principle we are clearly stepping into the scope of availability. We have mentioned it here for the sake of completeness.

13

Well-formed Transactions

The concept of a well-formed transaction corresponds very well to the standard DBMS concept of a transaction. A transaction is defined as a sequence of primitive actions which satisfies the following properties.

Correct state transform: each transaction if run by itself in isolation and given a consistent state to begin with will leave the database in a consistent state.

Serializability: the net effect of executing a set of transactions is equivalent to executing them in some sequential order, even though they may actually be executed concurrently (i.e., their actions are interleaved or simultaneous).

Failure atomicity: either all or none of the updates of a transaction take effect. (We understand update to mean modification, i.e., it includes insertion of new data, deletion of existing data and changes to existing data.)

Progress: every transaction will eventually complete, i.e., there is no indefinite blocking due to deadlock and no indefinite restarts due to livelocks.

The basic requirement is that the DBMS must ensure that updates are restricted to transactions. Clearly, if users are allowed to bypass transactions and directly manipulate relations in a database, we have no foundation to build upon. In other words updates should be encapsulated within transactions. This restriction may seem too strong, because in practice there will always be a need to perform ad hoc updates. However, ad hoc updates can themselves be carried out by means of special transactions! Of course the authorization for these special ad hoc transactions should be carefully controlled and their usage properly audited.

DBMS mechanisms can help in assuring the correctness of a state by enforcing consistency constraints on the data. Consistency constraints are also often called integrity constraints or integrity rules in the database literature. Since we are using integrity in a wider sense we prefer the former term.

The relational data model in particular imposes two consistency constraints.

Entity integrity stipulates that attributes in the primary key of a relation cannot have NULL values. This amounts to requiring that each entity represented in the database must be uniquely identifiable.

Referential integrity is concerned with references from one entity to another. A foreign key is a set of attributes in one relation whose values are required to match those of the primary key of some specific relation. Referential integrity requires that a foreign key either be all NULL or a matching tuple exist in the latter relation. This amounts to ruling out dangling references to non-existent entities.

14

Entity integrity is easily enforced. Referential integrity on the other hand requires more effort and has seen limited support in commercial products. The precise manner in which to achieve it is also very dependent on the semantics of the application. This is particularly so when the referenced tuple is deleted. There are several choices as follows: prohibit this delete operation, delete the referencing tuple (with a possibility of further cascading deletes), or set the foreign key attributes in the referencing tuple to NULL.

The relational model in addition encourages the use of domain constraints whereby the values in a particular attribute (column) are constrained to come from some given set. These constraints are particularly easy to state and enforce, at least so long as the domains are defined in terms of primitive types such as integers, decimal numbers and character strings. A variety of dependency constraints which constrain the tuples in a given relation have been extensively studied in the database literature.

In the limit a consistency constraint can be viewed as an arbitrary predicate which all correct states of the database must satisfy. The predicate may involve any number of relations. Although this concept is theoretically appealing and flexible in its expressive power, in practice the overhead in checking the predicates for every transaction has been prohibitive. As a result relational DBMS's typically confine their enforcement of consistency constraints to domain constraints and entity integrity.

Least Privilege

The principle of least privilege translates into a requirement for refine-grained access control. For purpose of controlling read access DBMSs have employed mechanisms

Separation of Duties

Separation of duties finds little support in existing products. Although it is possible to use existing mechanisms for this purpose, these mechanisms have not been designed with this end in mind. As a result their use is awkward at best. Separation of duties is inherently concerned with sequences of transactions, rather than individual transactions in isolation. For example consider a situation in which payment in the form of a check is prepared and issued by the following sequence of events.

1. A clerk prepares a voucher and assigns an account.

2. The voucher and account are approved by a supervisor.

15

3. The check is issued by a clerk who must be different from the clerk in step 1. Issuing the check also debits the assigned account. (Strictly speaking we should debit one account and credit another in equal amounts. The important point for our purpose is that issuing a check modifies account balances.)

This sequence embodies separation of duties since the three steps must be executed by different people. The policy moreover has a dynamic favor in that a particular clerk can prepare vouchers as well as, on different occasions, issue checks. However, a clerk cannot issue a check for a voucher prepared by himself.

Reconstruction of Events

The ability to reconstruct events in a system serves as a deterrent to improper behavior. In the DBMS context the mechanism to record the history of a system is traditionally called an audit trail. As with the principle of least privilege, a high-end DBMS should be capable of reconstructing events to the finest detail. In practise this ability must be tempered with the reality that gathering audit data indiscriminately can generate overwhelming volume. Therefore a DBMS must also allow fine-grained selectivity regarding what is audited. It should also structure the audit trail logically so that it is easy to query. For instance, logging every keystroke does give us the ability to reconstruct the system history accurately. However, with this primitive logical structure one needs substantial effort to reconstruct a particular transaction.

In addition to the actual recording of all events that take place in the database, an audit trail must also provide support for true auditing, i.e., an audit trail must have the capability for an auditor to examine it in a systematic manner. In this respect DBMSs have a significant advantage, since their powerful querying abilities can be used for this purpose.

Delegation of Authority

The need to delegate authority and responsibility within an organization is essential to its smooth functioning. It appears in its most developed form with respect to monetary budgets. However the concept applies equally well to the control of other assets and resources of the organization.

In most organizations the ability to grant authorization is never completely unconstrained. For example, a department manger may be able to delegate substantial authority over departmental resources to project managers within his department and yet be prohibited to delegate this authority to project managers outside the department. Traditional delegation mechanisms based on the concept of ownership, e.g., as embodied in the SQL GRANT and REVOKE statements, are not adequate in this context. Further work remains to be done in this area.

16

Reality Checks

This principle inherently requires activity outside of the DBMS. The DBMS does have obligation to provide an internally consistent view of that portion of the database which is being externally verified. This is particularly so if the external inspection isconducted on an ad hoc on-demand basis.

Continuity of Operation

The basic technique to deal for maintaining continuity of operation in the face of natural disasters, hardware failures and other disruptive events, is redundancy in various forms. Recovery mechanisms in DBMS's must also ensure that we arrive at a consistent state.

Fundamentals of Database Systems 5th Edition by Elmarsi/Navathe

Types of Security

- Legal and ethical issues- Policy issues- System-related issues- The need to identify multiple security levels 

Threats to databases

- Loss of integrity- Loss of availability- Loss of confidentiality

To protect databases against these types of threats four kinds of countermeasures can be implemented:

- Access control- Inference control- Flow control- Encryption

A DBMS typically includes a database security and authorization subsystem that is responsible for ensuring the security portions of a database against unauthorized access.

Two types of database security mechanisms:- Discretionary security mechanisms- Mandatory security mechanisms

17

The security mechanism of a DBMS must include provisions for restricting access to the database as a whole. This function is called access control and is handled by creating user accounts and passwords to control login process by the DBMS.

The security problem associated with databases is that of controlling the access to a statistical database, which is used to provide statistical information or summaries of values based on various criteria.

The countermeasures to statistical database security problem is called inference control measures.

Another security is that of flow control, which prevents information from flowing in such a way that it reaches unauthorized users.

Channels that are pathways for information to flow implicitly in ways that violate the security policy of an organization are called covert channels.

A final security issue is data encryption, which is used to protect sensitive data (such as credit card numbers) that is being transmitted via some type communication network.

The data is encoded using some encoding algorithm. An unauthorized user who access encoded data will have difficulty deciphering it, but authorized users are given decoding or decrypting algorithms (or keys) to decipher data.

Data Security and The Database Administrator

The database administrator (DBA) is the central authority for managing a database system.

The DBA’s responsibilities include- granting privileges to users who need to use the system- classifying users and data in accordance with the policy of the organization

The DBA is responsible for the overall security of the database system.

The DBA has a DBA account in the DBMS.Sometimes these are called a system or SUPERUSER account

These accounts provide powerful capabilities such as:1. Account creation2. Privilege granting3. Privilege revocation4. Security level assignment

Action 1 is access control, whereas 2 and 3 are discretionarym and 4 is used to control mandatory authorization.

18

Access Protection, User Accounts, and Database Audits

Whenever a person or group of person s need to access a database system, the individual or group must first apply for a user account. The DBA will then create a new account id and password for the user if he/she deems there is a legitimate need to access the database he user must log in to the DBMS by entering account id and password whenever database access is needed.

The database system must also keep track of all operations on the database that are applied by a certain user throughout each login session. To keep a record of all updates applied to the database and of the particular user who applied each update, we can modify system log, which includes an entry for each operation applied to the database that may be required for recovery from a transaction failure or system crash.

If any tampering with the database is suspected, a database audit is performed A database audit consists of reviewing the log to examine all accesses and operations applied to the database during a certain time period. A database log that is used mainly for security purposes is sometimes called an audit trail.

Discretionary Access Control Based on Granting and Revoking Privileges

The typical method of enforcing discretionary access control in a database system is based on the granting and revoking privileges.

Types of Discretionary Privileges

The account level: At this level, the DBA specifies the particular privileges that each account holds independently of the relations in the database.

The relation level (or table level): At this level, the DBA can control the privilege to access each individual relation or view in the database.The privileges at the account level apply to the capabilities provided to the account itself and can include

the CREATE SCHEMA or CREATE TABLE privilege, to create a schema or base relation;

the CREATE VIEW privilege; the ALTER privilege, to apply schema changes such adding or removing

attributes from relations; the DROP privilege, to delete relations or views; the MODIFY privilege, to insert, delete, or update tuples; and the SELECT privilege, to retrieve information from the database by using a

SELECT query.

19

The second level of privileges applies to the relation level

This includes base relations and virtual (view) relations.

The granting and revoking of privileges generally follow an authorization model for discretionary privileges known as the access matrix model where

The rows of a matrix M represents subjects (users, accounts, programs)

The columns represent objects (relations, records, columns, views, operations).

Each position M( i , j ) in the matrix represents the types of privileges (read, write, update) that subject i holds on object j.

To control the granting and revoking of relation privileges, each relation R in a database is assigned and owner account, which is typically the account that was used when the relation was created in the first place.

The owner of a relation is given all privileges on that relation.

In SQL2, the DBA can assign and owner to a whole schema by creating the schema and associating the appropriate authorization identifier with that schema, using the CREATE SCHEMA command.

The owner account holder can pass privileges on any of the owned relation to other users by granting privileges to their accounts.

In SQL the following types of privileges can be granted on each individual relation R:

SELECT (retrieval or read) privilege on R:

Gives the account retrieval privilege..

In SQL this gives the account the privilege to use the SELECT statement to retrieve tuples from R.

MODIFY privileges on R: This gives the account the capability to modify tuples of R.

In SQL this privilege is further divided into UPDATE, DELETE, and INSERT privileges to apply the corresponding SQL command to R.

In addition, both the INSERT and UPDATE privileges can specify that only certain attributes can be updated by the account.

20

In SQL the following types of privileges can be granted on each individual relation R (contd.):

REFERENCES privilege on R:

This gives the account the capability to reference relation R when specifying integrity constraints.

The privilege can also be restricted to specific attributes of R

Notice that to create a view, the account must have SELECT privilege on all relations involved in the view definition.

Specifying Privileges Using Views

The mechanism of views is an important discretionary authorization mechanism in its own right. For example,

If the owner A of a relation R wants another account B to be able to retrieve only some fields of R, then A can create a view V of R that includes only those attributes and then grant SELECT on V to B.

The same applies to limiting B to retrieving only certain tuples of R; a view V’ can be created by defining the view by means of a query that selects only those tuples from R that A wants to allow B to access.

Revoking Privileges

In some cases it is desirable to grant a privilege to a user temporarily. For example,

The owner of a relation may want to grant the SELECT privilege to a user for a specific task and then revoke that privilege once the task is completed.

Hence, a mechanism for revoking privileges is needed. In SQL, a REVOKE command is included for the purpose of canceling privileges.

Whenever the owner A of a relation R grants a privilege on R to another account B, privilege can be given to B with or without the GRANT OPTION.

If the GRANT OPTION is given, this means that B can also grant that privilege on R to other accounts.

Suppose that B is given the GRANT OPTION by A and that B then grants the privilege on R to a third account C, also with GRANT OPTION. In this way, privileges on R can propagate to other accounts without the knowledge of the owner of R.

21

If the owner account A now revokes the privilege granted to B, all the privileges that B propagated based on that privilege should automatically be revoked by the system.

Example

Suppose that the DBA creates four accountsA1, A2, A3, A4

and wants only A1 to be able to create base relations. Then the DBA must issue the following GRANT command in SQL

GRANT CREATETAB TO A1;

In SQL2 the same effect can be accomplished by having the DBA issue a CREATE SCHEMA command as follows:

CREATE SCHEMA EXAMPLE AUTHORIZATION A1;

User account A1 can create tables under the schema called EXAMPLE.

Suppose that A1 creates the two base relations EMPLOYEE and DEPARTMENT

A1 is then owner of these two relations and hence all the relation privileges on each of them.

Suppose that A1 wants to grant A2 the privilege to insert and delete tuples in both of these relations, but A1 does not want A2 to be able to propagate these privileges to additional accounts:

GRANT INSERT, DELETE ON

EMPLOYEE, DEPARTMENT TO A2;

22

Specifying Limits on Propagation of Privileges

Techniques to limit the propagation of privileges have been developed, although they have not yet been implemented in most DBMSs and are not a part of SQL.

Limiting horizontal propagation to an integer number i means that an account B given the GRANT OPTION can grant the privilege to at most i other accounts.

Vertical propagation is more complicated; it limits the depth of the granting of privileges.

3 Mandatory Access Control and Role-Based Access Control for Multilevel Security

The discretionary access control techniques of granting and revoking privileges on relations has traditionally been the main security mechanism for relational database systems.

This is an all-or-nothing method:

A user either has or does not have a certain privilege.

In many applications, and additional security policy is needed that classifies data and users based on security classes.

This approach as mandatory access control, would typically be combined with the discretionary access control mechanisms.

Typical security classes are top secret (TS), secret (S), confidential (C), and unclassified (U), where TS is the highest level and U the lowest: TS ≥ S ≥ C ≥ U

The commonly used model for multilevel security, known as the Bell-LaPadula model, classifies each subject (user, account, program) and object (relation, tuple, column, view, operation) into one of the security classifications, T, S, C, or U:

Clearance (classification) of a subject S as class(S) and to the classification of an object O as class(O).

Two restrictions are enforced on data access based on the subject/object classifications:

23

Simple security property: A subject S is not allowed read access to an object O unless class(S) ≥ class(O).

A subject S is not allowed to write an object O unless class(S) ≤ class(O). This known as the star property (or * property).

To incorporate multilevel security notions into the relational database model, it is common to consider attribute values and tuples as data objects.

Hence, each attribute A is associated with a classification attribute C in the schema, and each attribute value in a tuple is associated with a corresponding security classification.

In addition, in some models, a tuple classification attribute TC is added to the relation attributes to provide a classification for each tuple as a whole.

The value of the TC attribute in each tuple t – which is the highest of all attribute classification values within t – provides a general classification for the tuple itself, whereas each Ci provides a finer security classification for each attribute value within the tuple.

The apparent key of a multilevel relation is the set of attributes that would have formed the primary key in a regular(single-level) relation.

A multilevel relation will appear to contain different data to subjects (users) with different clearance levels.

In some cases, it is possible to store a single tuple in the relation at a higher classification level and produce the corresponding tuples at a lower-level classification through a process known as filtering.

In other cases, it is necessary to store two or more tuples at different classification levels with the same value for the apparent key.

This leads to the concept of polyinstantiation where several tuples can have the same apparent key value but have different attribute values for users at different classification levels.

In general, the entity integrity rule for multilevel relations states that all attributes that are members of the apparent key must not be null and must have the same security classification within each individual tuple.

In addition, all other attribute values in the tuple must have a security classification greater than or equal to that of the apparent key.

24

This constraint ensures that a user can see the key if the user is permitted to see any part of the tuple at all.

Other integrity rules, called null integrity and interinstance integrity, informally ensure that if a tuple value at some security level can be filtered (derived) from a higher-classified tuple, then it is sufficient to store the higher-classified tuple in the multilevel relation.

Discretionary Access Control (DAC) policies are characterized by a high degree of flexibility, which makes them suitable for a large variety of application domains.

The main drawback of DAC models is their vulnerability to malicious attacks, such as Trojan horses embedded in application programs.

By contrast, mandatory policies ensure a high degree of protection in a way, they prevent any illegal flow of information.

Mandatory policies have the drawback of being too rigid and they are only applicable in limited environments.

In many practical situations, discretionary policies are preferred because they offer a better trade-off between security and applicability.

Role Based Access Control

Role-based access control (RBAC) emerged rapidly in the 1990s as a proven technology for managing and enforcing security in large-scale enterprisewide systems.

Its basic notion is that permissions are associated with roles, and users are assigned to appropriate roles.

Roles can be created using the CREATE ROLE and DESTROY ROLE commands.

The GRANT and REVOKE commands discussed under DAC can then be used to assign and revoke privileges from roles.

RBAC appears to be a viable alternative to traditional discretionary and mandatory access controls; it ensures that only authorized users are given access to certain data or resources.

Many DBMSs have allowed the concept of roles, where privileges can be assigned to roles.

25

Role hierarchy in RBAC is a natural way of organizing roles to reflect the organization’s lines of authority and responsibility.

Another important consideration in RBAC systems is the possible temporal constraints that may exist on roles, such as time and duration of role activations, and timed triggering of a role by an activation of another role.

Using an RBAC model is highly desirable goal for addressing the key security requirements of Web-based applications.

In contrast, discretionary access control (DAC) and mandatory access control (MAC) models lack capabilities needed to support the security requirements emerging enterprises and Web-based applications.

Statistical Database Security

Statistical database security techniques must prohibit the retrieval of individual data.

The database may contain confidential data on individuals, which should be protected from user access.

Users are permitted to retrieve statistical information on the populations, such as averages, sums, counts, maximums, minimums, and standard deviations.

This can be achieved by prohibiting queries that retrieve attribute values and by allowing only queries that involve statistical aggregate functions such as COUNT, SUM, MIN, MAX, AVERAGE, and STANDARD DEVIATION, is called statistical queries

It is DBMS’s responsibility to ensure confidentiality of information about individuals, while still providing useful statistical summaries of data about those individuals to users. Provision of privacy protection of users in a statistical database is paramount.

Flow Control

26

Flow control regulates the distribution or flow of information among accessible objects.

A flow between object X and object Y occurs when a program reads values from X and writes values into Y.

Flow controls check that information contained in some objects does not flow explicitly or implicitly into less protected objects.

A flow policy specifies the channels along which information is allowed to move.

The simplest flow policy specifies just two classes of information:

confidential (C) and nonconfidential (N)

and allows all flows except those from class C to class N.

Covert Channels

A covert channel allows a transfer of information that violates the security or the policy.

A covert channel allows information to pass from a higher classification level to a lower classification level through improper means.

Covert channels can be classified into two broad categories:

Storage channels do not require any temporal synchronization, in that information is conveyed by accessing system information or what is otherwise inaccessible to the user.

Timing channel allow the information to be conveyed by the timing of events or processes.

Some security experts believe that one way to avoid covert channels is for programmers to not actually gain access to sensitive data that a program is supposed to process after the program has been put into operation.

6 Encryption and Public Key Infrastructures

27

Encryption is a means of maintaining secure data in an insecure environment.

Encryption consists of applying an encryption algorithm to data using some prespecified encryption key.

The resulting data has to be decrypted using a decryption key to recover the original data.

The Data and Advanced Encryption Standards

The Data Encryption Standard (DES) is a system developed by the U.S. government for use by the general public.

It has been widely accepted as a cryptographic standard both in the United States and abroad.

DES can provide end-to-end encryption on the channel between the sender A and receiver B.

DES algorithm is a careful and complex combination of two of the fundamental building blocks of encryption:

substitution and permutation (transposition).

The DES algorithm derives its strength from repeated application of these two techniques for a total of 16 cycles.

Plaintext (the original form of the message) is encrypted as blocks of 64 bits.

After questioning the adequacy of DES, the National Institute of Standards (NIST) introduced the Advanced Encryption Standards (AES).

This algorithm has a block size of 128 bits and thus takes longer time to crack.

Public Key Encryption

In 1976 Diffie and Hellman proposed a new kind of cryptosystem, which they called public key encryption.

Public key algorithms are based on mathematical functions rather than operations on bit patterns.

28

They also involve the use of two separate keys in contrast to conventional encryption, which uses only one key.

The use of two keys can have profound consequences in the areas of confidentiality, key distribution, and authentication.

The two keys used for public key encryption are referred to as the public key and the private key.

The private key is kept secret, but it is referred to as private key rather than a secret key (the word used in conventional encryption to avoid confusion with conventional encryption).

A public key encryption scheme, or infrastructure, has six ingredients:

Plaintext: This is the data or readable message that is fed into the algorithm as input.

Encryption algorithm: The encryption algorithm performs various transformations on the plaintext.

Public and private keys: These are pair of keys that have been selected so that if one is used for encryption, the other is used for decryption. The exec transformations performed by the encryption algorithm depend on the public or private key that is provided as input.

A public key encryption scheme, or infrastructure, has six ingredients

Ciphertext: This is the scrambled message produced as output. It depends on the plaintext and the key. For a given message, two different keys will produce two different ciphertexts.

Decryption algorithm: This algorithm accepts the ciphertext and the matching key and produces the original plaintext.

Public key is made for public and private key is known only by owner.

A general-purpose public key cryptographic algorithm relies on

one key for encryption and a different but related key for decryption.

The essential steps are as follows:

29

Each user generates a pair of keys to be used for the encryption and decryption of messages.

Each user places one of the two keys in a public register or other accessible file. This is the public key. The companion key is kept private (private key).

If a sender wishes to send a private message to a receiver, the sender encrypts the message using the receiver’s public key.

When the receiver receives the message, he or she decrypts it using the receiver’s private key.

No other recipient can decrypt the message because only the receiver knows his or her private key.

Two keys, d and e, are used for decryption and encryption.

An important property is that d and e can be interchanged.

n is chosen as a large integer that is a product of two large distinct prime numbers, a and b.

The encryption key e is a randomly chosen number between 1 and n that is relatively prime to (a-1) x (b-1).

The plaintext block P is encrypted as Pe mod n.

Because the exponentiation is performed mod n, factoring Pe to uncover the encrypted plaintext is difficult.

However, the decryption key d is carefully chosen so that (Pe)d mod n = P.

The decryption key d can be computed from the condition that d x e= 1 mod ((a-1)x(b-1)).

Thus, the legitimate receiver who knows d simply computes (Pe)d mod n = P and recovers P without having to factor Pe .

Digital Signatures

30

A digital signature is an example of using encryption techniques to provide authentication services in e-commerce applications.

A digital signature is a means of associating a mark unique to an individual with a body of text.

The mark should be unforgettable, meaning that others should be able to check that the signature does come from the originator.

A digital signature consists of a string of symbols.

Signature must be different for each use. This can be achieved by making each digital signature a function of

the message that it is signing, together with a time stamp.

Public key techniques are the means creating digital signatures.

Multi-level Database Security Polyinstantiation by Dr. Natarajan Meghanathan

Multi-Level Security (MLS) Database

With the use of Multi-Level Security (MLS), a DBMS can allow subjects with different security clearances to simultaneously access objects with different security levels.

The Security clearances and security levels typically considered are: Top Secret (TS), Secret (S), Confidential (C) and Unclassified (U).

MLS allows subjects with higher security clearance to easily allow access objects with equal or lower security level.

The ordering among these clearances and security levels is as follows:

– TS > S > C > U

The MLS approach is a classical example for the Mandatory Access Control (MAC) model as the security clearance and security level for the subjects and objects are uniformly adopted enterprise-wide.

Typically, each field (element object) in the table is assigned a security level and the security level for a tuple is the highest of the security evels of its constituent element objects.

Example for MLS Database

31

Consider the following Storage database wherein, for simplicity, eachtuple is assigned a security level.

Each room contains two compartments (X and Y). The combination of the room number and the compartment forms the Primary Key. There has to be “two” views of the above table. The DBA and other managerial-level users have to be able to see all the six tuples of the above table; whereas, a regular user should not be able to see the third tuple that has a Confidential information (Bank Records!!)

If a regular user with security clearance ‘Unclassified’ runs thefollowing SQL Query.

– Select * from Storage

The results should be:

However, the above display of records leads the Unclassified user to believe that there is nothing in the Compartment X of Room no. 451. If the user executes an Insert SQL

32

query like “INSERT INTO Storage VALUES (‘451’, ‘X’, ‘Fruits’, ‘Unclassified’); then the DBMS would return an Access denied feedback.

The ‘Access Denied’ feedback could mean to the Unclassified user that there is already a tuple with the primary key matching with what he is trying to insert and that the security level of the tuple is greater than his security clearance. This is referred to as an “Indirect Channel.” If the employee comes to know about the presence of something that is more than “Unclassified” in Compartment X of Room no. 451, then he/she could potentially do something harmful to the entity being stored over there and cause damage to the organization.

Polyinstantiation

To avoid such a dangerous inference, the organization could allow the employee to insert a tuple at the Unclassified level in the database. However, this would lead to a situation wherein there are two tuples with the same value for the primary key: Room no. 451 and Compartment X. The presence of two or more rows (tuples) with the same value(s) for the primary key, obviously with different security levels for each tuple is called “Polyinstantiation.”

Example for MLS Database Polyinstantiation

When user with security classification “Confidential” or above executes the SQL query “Select * from Storage,” all the above 7 tuples would be returned. The user has to however discard the polyinstantiated tuples with security level below to that of the user.

33

When user with security classification “Unclassified” executes the SQL query “Select * from Storage,” the tuples that are of security level “Unclassified” would only be returned. The user is made to believe that there are Fruits in Compartment X of Room No. 451. This is better than displaying “NULL” for the sensitive attribute and raising suspicion for the Unclassified that something sensitive is over there.

Visible and Invisible Polyinstantiation

Visible Polyinstantiation occurs when a user with a higher security clearance attempts to insert a tuple into a database that already has a tuple, with the same primary key, at a lower security level. Invisible Polyinstantiation occurs when a user with a lower security clearance attempts to insert a tuple into a database that already has a tuple, with the same primary key, at a higher security level. The Polyinstantiation that we created in the previous slides (Storage database Example) is an example for Invisible Polyinstantiation.

Consequence of Polyinstantiation:

An after-effect of allowing polyinstantiation is that there will be an explosion of tuples in a database. If the number of security levels is 4, for every tuple, that could be entered with the highest security level in the database table, there would be at most three “Cover Story” tuples that could be recorded. Polyinstantiation is inevitable in Multi-level world.

34

Security and Control Issues within Relational Databasesby David C. Ogbolumani, CISA, CISSP, CIA, CISM Practice Manager – Information Security

Keypoints

The Database Environment Top Database Threats Key Control Layers Security Features within Databases Applications Systems and Databases Common Database Issues

The Database Environment

Database servers are the most important systems in virtually all organizations. They store critical information that supports business including the following:

Email Financial Data Sales Data Personnel Data Intellectual Property Operation and Security Data, etc.

Modern Databases are created using Structured Query Language (SQL) which is the standard for database interoperability.

Relational Database Management System

This refers to the software system that is used to create a database and they include well known products such as the following:

Oracle MS SQL and MS Access IBM DB2 and Informix Teradata (NCR) Sybase Postgre SQL MySQL

Top Database Security Threats

35

Privilege Abuse

Abusing legitimate privileges for unauthorized purposes Excessive privileges that exceeds job function requirement

Weak Authentication

Weak or ineffective password policies Theft of login credentials, social engineering Poor encryption

Weak Systems Configuration

Use of default Configurations Installation of improper tools and services Lack of security baseline

Database and Operating System Vulnerabilities

SQL Injections Cross Site Scripting Root Kits Weak communication protocols

Poor Audit Trail

Front-End Application Vulnerabilities

Backup

Incomplete and failed backups Theft or improper storage of backup storage media or hard drives

Common Security Features in Databases

Basic Security Mechanism in databases includes

Identification and Authentication requirements System Privilege and Object Access Control Audit Trail Mechanism Data Encryption Network Security Auditing/Fine Grain Auditing.

Identification and Authentication

36

Users can access databases through a variety of means including remotely, wireless access, scanners, through the internal network, etc. There are associated risks with each access means.

Each user may be identified and authenticated by either the operating system or the database system. For example:

The Administrator can specify an Oracle password for each Oracle user when the account is created, or

In UNIX a user account e.g. DavidO can be Oracle user “OPS$DavidO” and connect without a password

This is feature disabled by default for remote users

MSSQL has mixed authentication. Users may log in with either an operating system ID, or a separate database user account.

Reviewing Users and Passwords

Obtain a list of all Database User Accounts

Describe dba_users Select * from sys.dba_users

Identify the purpose and use of each user account

Identify generic accounts Identify shared account Service Accounts Guest or anonymous logins

Review Password Policies defined in both the database and operating systems. Check for the use of common default passwords or blank passwords.

37

Review user profiles as they contain the following important password control mechanism such as these settings:

Failed login attempts Password Expiration Account lockout duration Minimum and Maximum password length Password reuse Password grace period before the account expires

Earlier versions of SQL prior to SQL 2000 lack controls such as password complexity, expiration, lockout, and password history.

Application Systems Connections

Popular Application Systems such as JDE, PeopleSoft, SAP/R3 and other applications also connect directly to the database. Home grown and legacy applications also connect to the database and in many cases these are done with hard coded passwords.

Key Security and Control Issues include the following:

Access to data outside the Application System Application System Access and Security Application Systems Internal Controls

Many popular applications as well as home grown applications are configured to use their passwords to login to the database. Such application may supply its UserID and password and not the end user’s. In this case

Neither the Operating System nor Database is aware of the end user’s identity

Neither the OS or Database (e.g. Oracle) can enforce access control decisions or monitoring based on end user identity.

Such passwords are sometimes hard coded in the application or script and rarely changed.

The password may be stored in a user-accessible or unencrypted file

Bypassing Application Controls

38

This can occur when a user has an ID with direct access to the database and the underlying tables.

They can update compensation tables or other sensitive data

SOL*PLUS would allow the user update access outside the application

Risk Management professionals should evaluate database and application security to determine if level of protection is sufficient.

Users should not be directly defined in the database if they login with a front end application.

Reviewing Access Control

Roles, Responsibilities and Privileges - Rules defining what users can do

System Privileges - Allows a user to perform a particular database command or operation

Object Privileges - Allows a user to access an object in a particular manner

Statement Privileges - Selective auditing of related groups of statements regarding a particular type of database structure or schema object.

Review the operating system permissions of all key database files. Privileges are provided directly to users or through roles.

Logging and Monitoring

Define what actions and abuses that need to be checked such as the following:

Successful database access Changes to database structure Failed logon attempts Attempts to access the database with non-existent user names Attempts to access the database at unusual hours. Checks for users sharing database accounts Multiple access attempts using different usernames from the same terminal

Database auditing is viewed as being complex and slow but this is generally not true.

Vulnerability Analysis

39

Conduct periodic Vulnerability Assessments

Vulnerability Assessment Tests probe for known vulnerabilities

Identify vulnerable software versions Identify vulnerable services Probes the database for known weaknesses Test for default and weak passwords

Common tools that are used for the following include

Nessus, Retina, Saint (Generic Assessments) App Detective, NGSSquirrel, (Specific to Databases)

Common Database Security Issues

Users with excessive privileges

Users with administrative privileges

Users whose privileges are higher than their role requires

Users who have moved or changed job roles

Lack of logging and No Auditing of Privileged users

Failure to Segregate Duties appropriately

Inadequate review of Audit logs

Generic, shared, and terminated users with access to production systems

Guest user in production databases

Improperly configured systems and weak patch management

Incomplete backup and failure to encrypt backup data

Database System Security by Paul J. Wagner UMSSIA 2008

40

Database system security is more than securing the database; to achieve a secure database system, we need a:

Secure database Secure DBMS Secure applications / application development Secure operating system in relation to database system Secure web server in relation to database system Secure network environment in relation to database system

Historical database security framework is to separate set of usernames, passwords and database administrator assigns privileges for each user. Privileges assigned by users and level of confidentiality. General password policies ( length, domain, changing and protection.

Managing Privileges - Have 2 types (System - actions) and (Object – data)

Problem: M (users) x N (privileges) possible combinations.

Solution: Roles (a security pattern) Collections of (usually system) privileges. Manage with Grant / Revoke, higher level tools Giving (or removing ) privileges or roles to (from) users.Data Encryption - Sensitive data should be encrypted within database. Most databases now have utilities for this.

41

Examine cost of this process

May slow access time,, use resources May interfere with system administration

Don’t forget about data once out of the database Need to decrypt for users Ensure data is still protected when DB sends it to a client for usage,, or when

client sends to DB.

Database Issues - Inference Attack

Statistical Database – database used for statistical purposes, usually Online Analytical Processing (OLAP) as in data warehouse situations. Generally allows only aggregate functions queries (may be limited to SUM,, COUNT,, AVERAGE) on a group off rows. and may not all low queries on individual rows.

Problem: it may still be possible to infer individual data values from such a database.

Inference Attack Example:

Base query: find count of all UWEC students

Example SQL: SELECT Count(*) FROM StudentDB;

returns single number, ~10,000, doesn't expose any individual information, but we can do more…

Inference Attack Example:Find count of UWEC students that:

Have a local address in Eau Claire Have a GPA of between 3.1 and 3.2 Are majoring in computer science

SELECT Count(*) FROM StudentDB WHERE cond1 AND cond2 AND cond3 AND …

Getting count down to fewer and fewer students as we add filter conditions. If count gets down to 1, you know an individual exists with those characteristics.

May even be able to gain private information. Find average hourly pay rate for UWEC students that have the above characteristics.

42

Inference Attack Prevention Techniques:

Return an approximate number of rows (e.g. between A and B) Limit the number of filtering conditions on a query. Return ranges for values, especially for sensitive fields (e.g. salary falls between

X and Y)

Difficult to balance functionality and security with such data.

Database Issue - Correlation Attack

Data in database may be anonymous. However, it may able to be correlated with another set of data which is not anonymous. Anonymity can thus be removed.

Example: Statistical analysis of public but anonymized Netflix date set using internet movies database (imdb.com) data. By comparing rankings and timestamps from Netflix data, authors identified a subset of individuals through correlated data from IMDB.

Secure Application Development

Access to Oracle Database of environment through applications. Need to consider security of applications using database as well as security of data in database itself.

SQL Injection

Definition - inserting malicious SQL code through an application interface. Often through web application, but possible with any interface.

Typical scenario

Three-tier application (web interface, application, database)

Overall application tracks own usernames and passwords in database (advantage: can manage users in real time)

Web interface accepts username and password, passes these to application layer as parameters

Example: Application Java code (receiving username and password from client) contains SQL statement:

43

String query = "SELECT * FROM users_table " + " WHERE username = " + " ‘ " + username + " ‘ " + " AND password = " + " ‘ " + password + " ‘ "

Expected Result:

"SELECT * FROM users_table WHERE username = ‘wagnerpj‘ AND password = ‘paulpass‘;

Note: String values must be single quoted in SQL, so application provides these before and after each passed string parameter.

Application is expecting one username/password pair row to be returned if success, no rows if failure.

Common variant to simplify the above check:

SELECT COUNT(*) FROM users_table WHERE username = ‘someuser‘ AND password = ‘somepass‘;

Attacker enters:

Any username (valid or invalid)

Password of: Aa' OR '' = '

Query becomes:

SELECT * FROM users_table WHERE username = ‘anyname‘ AND password = ‘Aa‘ OR ‘ ‘ = ‘ ‘;

Note: WHERE clause => ? and F or T => F or T => T

AND has higher precedence than OR. All user/pass rows returned to application. If application checking for 0 vs. more than 0 rows, attacker is in.

SQL Injection Prevention

Not checking the controlling input properly, specifically, not controlling string input.

44

Note: there are a variety of ways SQL injection can happen.

Regular inclusion of SQL metacharacters through

Variable interpolation String concatenation with variables and/or constants String format functions like sprintf() String templating with variable replacements

Hex or Unicode encoded metacharacters.

First possible solution: Check content.

Client code check to ensure certain content rules are met Server code checks content as well Specifically - don't allow apostrophes to be passed

Problem: there are other characters that can cause problems; e.g. // SQL comment character ; // SQL command separator % // SQL LIKE subclause wildcard character

Many possible variations os SQL Injection. Many potential metacharacters to filter, dependent on DBMS variety. Maybe filtering input by blacklisting metacharacters isn't the best approach.

Regular Statements - SQL query (a string) is generated entirely at run-time. Custom procedure and data are complied and run. Compilation allows combination of procedure and data, allowing problems with SQL metacharacters.

Better Solution - Prepared statements (Parameterized Queries). SQL query is precompiled with placeholders. Data is added in at run-time, converted to correct type for the given fields.

Issues with Prepared Statements

Cannot use them in all situations. Generally limited to replacing field values in SELECT, INSERT, UPDATE, DELETE statements.

Example: if also asking user for information that determines choice of table name, cannot use a prepared statement.

Additional Precautions

45

Do not access the database as privileged user, attacker who gains access through user will have that user's privileges.

Limit database user to only what they need to do, e.g. reading information from database, no insert/update/delete.

Do not allow direct access to database from the internet, requires user to go through your(controlled) applications.

Do not embed database accounts passwords in your code, encrypt and store them in a repository that is read at application startup.

Do not expose information in error messages, e.g. do not display stack traces.

Applications Issues

Be aware of how information is transmitted between client applications and database.

Student Research Project at UWEC tested 5 DBMSs and various clients (vendor and user)

Most common client applications (vendor-supplied or user-programmed) at least encrypt the connection password.

Some clients encrypt the connection user Certain DBMSs have varying levels of security (e.g. PostgreSQL) One DBMS transmits the connection password length (MS SQL Server 2005

Edition)

Be aware of how application exposes information.

Example: Panel rating system displays each reviewer’s rating for each proposal, but doesn't display individual ratings for a given proposal unless you've entered your rating. Default display is in recommended discussion ordered, so no information disclosed.

However, panel rating system also allows you to sort data by any column, including ratings (average). This allows you to see the approximate average rating by other reviewers before entering your rating. Not a big deal here, but point is that applications may be able to be used in certain ways to expose information

Secure Application Development

46

Application Security in the Enterprise Environment

J2EE – JDBC, Servlets, JSPs, JNDI, EJBs, ..... .NET – many components Need to be aware of security issues with each component, interaction of

components.

Use of Proxy Applications

Assume network filtering most evil traffic Application can control fine-grain behavior, application protocol security.

Security Patterns (from J2EE Design Patterns Applied)

Single-Access Point Pattern, single point of entry into system. Example violation: online course system.

Check Point Pattern - centralized enforcement of authentication and authorization.

Role Pattern - disassociation of users and privileges.

Secure Operating System

DBMS interacts with operating system.

File manipulation Can often run shell commands from DBMS DBMS procedural languages often have packages that interact directly with OS Installation of DBMS uses file system DBMS uses OS resources

Interaction of Oracle and OS

Windows

Secure administrative accounts Control registry access Need good account policies

Linux/Unix

47

Choose different account names that standard suggestions Restrict use of the account that owns Oracle software Secure temporary directory Some oracle files are SUID(root) Command line SQL*Plus with user/pass parameters appears under ps output

Secure Web Server.

Interaction of Oracle and Web Server. Apache now provided within Oracle as its application server, started by default.

Apache issues

Standard configuration has some potential problems. Ensure secure communication from web clients to web server. Use MaxClients to limit possible connections.

Internet Information Server (IIS) issues.

Integration with other MS products (e.g. Exchange Server) May known vulnerabilities over past versions (patches available)

Secure Network

Interaction of Databases and Network.

Features for:

Authentication Integrity Encryption- use of SSL

Server generally behind firewall

Good to separate DB and Web servers Connections normally initiated on port 1521, but then dynamically selected.

Other network issues to consider Possibility of hijacking a sys/sysmgr connection. Various sniffing and spoofing issues.

Auditing

48

Good policy; develop a comprehensive audit system for database activity tracking

Database system: can accomplish with triggers

Can write to OS as well as into database for additional security, accountability for all working with databases.

Overall Security Examination of Database System in Networked Environment

1. Database: Set-up client(s), test databases for: Privileged access accounts Public access through other known/discovered usernames

2. DBMS: Check for known vulnerabilities Check overall system level, patch level Test for specific problems gathered from web search, literature

3. Application Test for SQL Injection, other application weaknesses.

Similar types for tasks for OS, Web Server, Network components

Task: develop report, including specifics for all areas.

III. ANALYSIS:

Has I read all the articles from different authors and gathered information about database security issues they have different approach on how to detailed their work, aside from the explanations included.

Some authors say that security issues are from the Database Administration, wrong implementation of system, some are compatibility issues and interference that unauthorized access to the databases. As a whole the articled I read is tackled all sides for security issues and steps on how to prevent data loss and unauthorized access occur. Some issues fall under hardware and compatibility other are user accessibility on how to query a report depending confidentially of the data.

IV. CONCLUSION:

49

For this research, database security not only focus on one segment of the system but also the attributes are validated and tested, to secure the database system security to all levels of confidential information stored in it. Knowing the steps and what are the thing needed when I comes to deploy and application or integrated system

V.RECOMMENDATION:

Database security is more on testing and data confidentiality on how to protect information from unauthorized access. Authors discussed about procedures on how to check policies limit the view of users and access with restrictions. Recommend this research about database security for more information gathering in all aspects of database management system at this time there are more new databases like NoSQL, NewSQL, Graph DB etc... there are new database security procedures, test will deploy and check the validity of all its attributes, new database management systems must scrutinize for the complete security of the data stored on new database systems.

REFERENCES:

http://searchsecurity.techtarget.com/tip/Implementing-database-security-and-integrityhttp://www.slideshare.net/amiable_indian/database-systems-securityhttp://databases.about.com/od/security/Database_Security_Issues.htmhttp://www.darkreading.com/database

DATABASE SECURITY ISSUES

50

Davie Ben B. Estrella Dr. Rosicar E. Escober PUPOU - MSIT Advance Database Organization

51