2.1 Overview

As we have stated in Chapter 1, secure big data technologies integrate big data technologies with security technologies. In this chapter, we will discuss security technologies. In particular, we will discuss various aspects of data security and privacy. Big data technologies will be discussed in Chapter 7 after we provide an overview of some related technologies such as data mining and cloud computing.

Since much of the discussion in this book is on big data analytics and security, we will provide a fairly comprehensive overview of access control in data management systems. In particular, we will discuss security policies as well as enforcing the policies in database systems. Our focus will be on discretionary security policies. We will also discuss data privacy aspects. More details on secure data management can be found in [FERR00] and [THUR05a].

The most popular discretionary security policy is the access control policy. Access control policies were studied for operating systems back in the 1960s and then for database systems in the 1970s. The two prominent database systems, System R and INGRES, were the first to investigate access control for database systems (see [GRIF76] and [STON74]). Since then several variations of access control policies have been reported including role-based access control (RBAC) and attribute-based access control [NIST]. Other discretionary policies include administration policies. We also discuss identification and authentication under discretionary policies. Note that much of the discussion in this chapter will focus on discretionary security in relational database systems. Many of the principles are applicable to other systems such as object database systems, distributed database systems, and cloud data management systems (see e.g., [THUR94]).

Before one designs a secure system, the first question that must be answered is what is the security policy to be enforced by the system? Security policy is essentially a set of rules that enforce security. Security policies include mandatory security policies and discretionary security policies. Mandatory security policies are the policies that are “mandatory” in nature and enforced by the systems. Discretionary security policies are policies that are specified by the administrator or the owner of the data.

By policy enforcement, we mean the mechanisms to enforce the policies. For example, back in the 1970s, the relational database system products such as System R and INGRES developed techniques such as the query modification mechanisms for policy enforcement (see e.g., [GRIF76] and [STON74]). The query language Structured Query Language (SQL) has been extended to specify security policies and access control rules. More recently languages such as eXtensible Markup Language (XML) and resource description framework (RDF) have been extended to specify security policies (see e.g., [BERT02] and [CARM04]).

The organization of this chapter is as follows. In Section 2.2, we introduce discretionary security including access control and authorization models for database systems. We also discuss RBAC systems. In Section 2.3, we discuss ways of enforcing discretionary security including a discussion of query modification. We also provide an overview of the various commercial products. This chapter is summarized in Section 2.4. Figure 2.1 illustrates the concepts discussed in this chapter. We assume that the reader has some knowledge of data management. For more details on this topic we refer the reader to some texts such as [DATE90] and [THUR97]. We also provide an overview of database systems in Appendix B.

2.2 Security Policies

The organization of this section is as follows. In Section 2.2.1, we will provide an overview of access control policies. Administration policies will be discussed in Section 2.2.2. Issues in identification and authentication will be discussed in Section 2.2.3. Auditing a database management system will be discussed in Section 2.2.4. Views as security objects will be discussed in Section 2.2.5. Figure 2.2 illustrates various components of discretionary security policies discussed in this section.

2.2.1 Access Control Policies

Access control policies were first examined for operating systems. The essential point here is that can a process be granted access to a file? Access could be read access or write access. Write access could include access to modify, append, or delete. These principles were transferred to database systems such as INGRES and System R. Since then various forms of access control policies have been studied. Notable among those are the RBAC policies which are now implemented in several commercial systems. Note that access control policies also include mandatory policies. Figure 2.3 illustrates the various types of access control policies.

2.2.1.1 Authorization-Based Access Control Policies

Many of the access control policies are based on authorization policies. Essentially what this means is that users are granted access to data based on authorization rules. In this section, we will discuss various types of authorization rules. Note that in the book chapter by Ferrari and Thuraisingham [FERR00], a detailed discussion of authorization policies is provided.

2.2.1.1.1 Positive Authorization

Early systems focused on what is now called positive authorization rules. Here user John is granted access to relation EMP or user Jane is granted access to relation DEPT. These are access control rules on relations. One can also grant access to other entities such as attributes and tuples. For example, John has read access to attribute salary and write access to attribute name in relation EMP. Write access could include append, modify, or delete access.

2.2.1.1.2 Negative Authorization

The question is if John’s access to an object is not specified, does this mean John does not have access to that object? In some systems, any authorization rule that is not specified is implicitly taken to be a negative authorization, while in other systems negative authorizations are explicitly specified. For example, we could enforce rules such as John does not have access to relation EMP or Jane does not have access to relation DEPT.

2.2.1.1.3 Conflict Resolution

When we have rules that are conflicting then how do we resolve the conflicts? For example, we could have a rule that grants John read access to relation EMP. However, we can also have a rule that does not grant John read access to the salary attribute in EMP. This is a conflict. Usually a system enforces the least privilege rule in which case John has access to EMP except for the salary values.

2.2.1.1.4 Strong and Weak Authorization

Systems also enforce strong and weak authorizations. In the case of strong authorization, the rule holds regardless of conflicts. In the case of weak authorization, the rule does not hold in case of conflict. For example, if John is granted access to EMP and it is a strong authorization rule and the rule where John is not granted access to salary attribute is a weak authorization, there is a conflict. This means the strong authorization will hold.

2.2.1.1.5 Propagation of Authorization Rules

The question here is how do the rules get propagated? For example, if John has read access to relation EMP, then does it automatically mean that John has read access to every element in EMP? Usually this is the case unless we have a rule that prohibits automatic propagation of an authorization rule. If we have a rule prohibiting the automatic propagation of an authorization rule, then we must explicitly enforce authorization rules that specify the objects that John has access to.

2.2.1.1.6 Special Rules

In our work on mandatory policies, we have explored extensively the enforcement of content and context-based constraints. Note that security constraints are essentially the security rules. Content and context-based rules are those where access is granted depending on the content of the data or the context in which the data is displayed. Such rules can be enforced for discretionary security also. For example, in the case of content-based constraints, John has read access to tuples only in DEPT D100. In the case of context or association-based constraints, John does not have read access to names and salaries taken together, however, he can have access to individual names and salaries. In the case of event-based constraints, after the election, John has access to all elements in relation EMP.

2.2.1.1.7 Consistency and Completeness of Rules

One of the challenges here is ensuring the consistency and completeness of constraints. That is, if the constraints or rules are inconsistent, then do we have conflict resolution rules that will resolve the conflicts? How can we ensure that all of the entities (such as attributes, relations, elements, etc.) are specified in access control rules for a user? Essentially what this means is, are the rules complete? If not, what assumptions do we make about entities that do not have either positive or negative authorizations specified on them for a particular user or a class of users?

We have discussed some essential points with respect to authorization rules. Some examples are given in Figure 2.4. Next, we will discuss some popular access control models and they are RBAC, which is now implemented in commercial systems and attribute-based access control implemented in web-based systems.

2.2.1.2 Role-Based Access Control

RBAC has become one of the most popular access control methods (see [SAND96]). This method has been implemented in commercial systems including Trusted Oracle. The idea here is to grant access to users depending on their roles and functions.

The essential idea behind RBAC is as follows. Users need access to data depending on their roles. For example, a president may have access to information about his/her vice presidents and the members of the board, while the chief financial officer may have access to the financial information and information on those who report to him. A director may have access to information about those working in his division, while the human resources director will have information on personal data about the employees of the corporation. Essentially, RBAC is a type of authorization policy which depends on the user role and the activities that go with the role.

Various research efforts on role hierarchies have been discussed in the literature. There is also a conference series called Symposium on Access Control Models and Technologies that evolved from RBAC research efforts. For example, how does access get propagated? Can one role subsume another? Consider the role hierarchy illustrated in Figure 2.5. This means if we grant access to a node in the hierarchy, does the access propagate upward? That is, if a department manager has access to certain project information, does that access get propagated to the parent node, which is a director node? If a section leader has access to employee information in his/her section, does the access propagate to the department manager who is the parent in the role hierarchy? What happens to the child nodes? That is, does access propagate downward? For example, if a department manager has access to certain information, then do his subordinates have access to that information? Are there cases where the subordinates have access to data that the department manager does not have? What happens if an employee has to report to two supervisors, one his department manager and the other his project manager? What happens when the department manager is working on a project and has to report to his project leader who also works for him?

RBAC has been examined for relational systems, object systems, distributed systems, and now some of the emerging technologies such as data warehouses, knowledge management systems, semantic web, e-commerce systems, and digital libraries. Furthermore, object models have been used to represent roles and activities (see e.g., Proceedings of the IFIP Database Security Conference series and more recently the Proceedings of the ACM Conference series on Data and Applications Security and Privacy).

2.2.1.3 Usage Control

More recently Sandhu et al. [SAND96] have developed yet another access control-like model that is the usage control (UCON) model (see e.g., the work reported in [PARK04]). The UCON model attempts to incorporate some additional featured into RBAC including attribute mutability and obligations.

2.2.1.4 Attribute-Based Access Control

Due to the fact that roles are not uniform across organization, it was felt that RBAC was not sufficient in web-based systems. Around the same time, web services and service-oriented architectures gained popularity and are not widely used. Therefore, am access control model based on claims was developed for such an environment. This model is attribute-based access control. Here, a user makes certain claims about him or herself. These claims are then verified by the organization that wants to give the user access to the resources. If the user’s claims are valid, then the policies are checked as to whether such a user has access to the resources. Attribute-based access control has become extremely popular in the last decade.

2.2.2 Administration Policies

While access control policies specify access that specific users have to the data, administration policies specify who is to administer the data. Administration duties would include keeping the data current, making sure the metadata is updated whenever the data is updated, and ensuring recovery from failures and related activities.

Typically, the database administrator (DBA) is responsible for updating say the metadata, the index and access methods and also ensuring that the access control rules are properly enforced. The system security officer (SSO) may also have a role. That is, the DBA and SSO may share the duties between them. The security-related issues might be the responsibility of the SSO, while the data-related issues might be the responsibility of the DBA. Some other administration policies being considered include assigning caretakers. Usually owners have control of the data that they create and may manage the data for its duration. In some cases, owners may not be available to manage the data, in which case they may assign caretakers (i.e., custodians).

Administration policies get more complicated in distributed environments, especially in a web environment. For example, in web environments, there may be multiple parties involved in distributing documents including the owner, the publisher, and the users requesting the data. Who owns the data? Is it the owner or the publisher? Once the data has left the owner and arrived at the publisher, does the publisher take control of the data? There are many interesting questions that need to be answered as we migrate from a relational database environment to a distributed and perhaps a web environment. These also include managing copyright issues, data quality, data provenance, and governance. Many interesting papers have appeared in recent conferences on administration policies. Figure 2.6 illustrates various administration policies.

2.2.3 Identification and Authentication

For the sake of completion, we discuss identification and authentication as part of our discussion on discretionary security. By identification we mean users must identify themselves with their user ID and password. Authentication means the system must then match the user ID with the password to ensure that this is indeed the person he or she is purporting to be. A user may also have multiple identities depending on his/her roles. Identity management has received a lot of attention especially with the advent of web services (see [BERT06]).

Numerous problems have been reported with the password-based scheme. One is that hackers can break into the system and get the passwords of users and then masquerade as the user. In a centralized system, the problems are not as complicated as in a distributed environment. Now, with the World Wide Web and e-commerce applications, financial organizations are losing billions of dollars when hackers masquerade as legitimate users.

More recently biometrics techniques are being applied for identification and authentication. These include face recognition, fingerprint recognition, and voice recognition techniques to authenticate the user. These techniques are showing a lot of promise and are already being used. We can expect widespread use of biometric techniques as face recognition technologies advance.

2.2.4 Auditing: A Database System

Databases are audited for multiple purposes. For example, they may be audited to keep track of the number of queries posed, the number of updates made, the number of transactions executed, and the number of times the secondary storage is accessed so that the system can be designed more efficiently. Databases can also be audited for security purposes. For example, have any of the access control rules been bypassed by releasing information to the users? Has the inference problem occurred? Has privacy been violated? Have there been unauthorized intrusions?

Audits create a trail and the audit data may be stored in a database. This database may be mined to detect any abnormal patterns or behaviors. There has been a lot of work in using data mining for auditing and intrusion detection. Audit trail analysis is especially important these days with e-commerce transactions on the web. An organization should have the capability to conduct an analysis and determine problems like credit card fraud and identity theft.

2.2.5 Views for Security

Views as a mechanism for security has been studied a great deal both for discretionary security and mandatory security. For example, one may not want to grant access to an entire relation especially if it has, say, 25 attributes such as healthcare records, salary, travel information, personal data, and so on. Therefore, the DBA could define views and grant users access to the views. Similarly, in the case of mandatory security, views could be assigned security levels.

Views have problems associated with them including the view update problem (see [DATE90]). That is, if the view is updated, then we need to ensure that the base relations are updated. Therefore, if a view is updated by John and John does not have access to the base relation, then can the base relation still be updated? That is, do we create different views for different users and then the DBA merges the updates on views as updates on base relations? Figure 2.7 illustrates views for security.

2.3 Policy Enforcement and Related Issues

The organization of this section is as follows. SQL extensions for security are discussed in Section 2.3.1. In Section 2.3.2, we discuss query modification. Impact of discretionary security on other database functions will be discussed in Section 2.3.3. Note that we will focus on relational database systems. Figure 2.8 illustrates the various aspects involved in enforcing security policies. These include specification, implementation, and visualization (where visualization tools are being used for the visualization of the policies).

2.3.1 SQL Extensions for Security

This section discusses policy specification. While much of the focus will be on SQL extensions for security policy specification, we will also briefly discuss some of the emerging languages. Note that SQL was developed for data definition and data manipulation for relational systems. Various versions of SQL have been developed including SQL for objects, for multimedia, and for the web. That is, SQL has influenced data manipulation and data definition a great deal over the past 30 years (see [SQL3]).

As we have stated, SQL is a data definition and data manipulation language. Security policies could be specified during data definition. SQL has GRANT and REVOKE constructs for specifying grant and revoke access to users. That is, if a user John has read access to relation EMP, then one could use SQL and specify something like “GRANT JOHN EMP READ” and if the access is to be revoked, then we need something like “REVOKE JOHN EMP READ.” SQL has also been extended with more complex constraints such as granting John read access to a tuple in a relation and granting Jane write access to an element in a relation.

In [THUR89], we specified SQL extensions for security assertions. These assertions were for multilevel security. We could use similar reasoning for specifying discretionary security policies. For example, consider the situation where John does not have read access to names and salaries in EMP taken together, but he can read names and salaries separately. One could specify this in SQL-like language as follows.

  GRANT JOHN READ
  EMP.SALARY
  GRANT JOHN READ
  EMP.NAME
  NOT GRANT JOHN READ
  Together (EMP.NAME, EMP.SALARY).

If we are to grant John read access to the employees who earn <30K, then this assertion is specified as follows.

  GRANT JOHN READ
  EMP
  Where EMP.SALARY <30K

Note that the assertions we have specified have been incorporated into any standards. These are some of our ideas. We need to explore ways of incorporating these assertions into the standards. SQL extensions have also been proposed for RBAC. In fact, products such as Oracle’s Trusted database product enforce RBAC. The access control rules are specified in an SQL-like language.

Note that there are many other specification languages that have been developed. These include XML, RDF, and related languages for the web and the semantic web. Semantic web is essentially an intelligent web. SQL-like languages have been specified for XML and RDF. For example, XML-QL was developed for XML which then evolved into a language called XQuery. SPARQL is now the query language for RDF (see [THUR07]). We will use such languages in our systems to be discussed in Part IV. Figure 2.9 illustrates specification aspects for security policies.

2.3.2 Query Modification

Query modification was first proposed in the INGRES project at the University of California at Berkeley (see [STON74]). The idea is to modify the query based on the constraints. We have successfully designed and implemented query modification for mandatory security (see [DWYE87], [THUR87], and [THUR93]). However, much of the discussion in this section will be on query modification based on discretionary security constraints. We illustrate the essential points with some examples.

Consider a query by John to retrieve all tuples from EMP. Suppose that John only has read access to all the tuples where the salary is <30K and the employee is not in the Security department. Then the query

  Select * from EMP
  Will be modified to
  Select * from EMP
  Where salary <30K
  And Dept is not Security

Where we assume that the attributes of EMP are say name, salary, age, and department.

Essentially what happens is that the “where” clause of the query has all the constraints associated with the relation. We can also have constraints that span across multiple relations. For example, we could have two relations EMP and DEPT joined by Dept #. Then the query is modified as follows:

  Select * from EMP
  Where EMP.Salary < 30K
  And EMP.D# = DEPT.D#
  And DEPT.Name is not Security

We have used some simple examples for query modification. The detailed algorithms can be found in [DWYE87] and [STON74]. The high level algorithm is illustrated in Figure 2.10.

2.3.3 Discretionary Security and Database Functions

In Section 2.3.2, we discussed query modification which is essentially processing security constraints during the query operation. Query optimization will also be impacted by security constraints. That is, once the query is modified, then the query tree has to be built. The idea is to push selections and projections down in the query tree and carry out the join operation later.

Other functions are also impacted by security constraints. Let us consider transaction management. Bertino and Musto have developed algorithms for integrity constraint processing for transactions management (see [BERT89]). We have examined their techniques for mandatory security constraint processing during transaction management. The techniques may be adapted for discretionary security constraints. The idea is to ensure that the constraints are not violated during transaction execution.

Constraints may be enforced on the metadata. For example, one could grant and revoke access to users to the metadata relations. Discretionary security constraints for metadata could be handled in the same way they are handled for data. Other database functions include storage management. The issues in storage management include developing appropriate access methods and index strategies. One needs to examine the impact of the security constraints on the storage management functions. That is, can one partition the relations based on the constraints and store them in such a way so that the relations can be accessed efficiently? We need to develop secure indexing technologies for database systems. Some work on secure indexing for geospatial information systems is reported in [ATLU04]. Databases are audited to determine whether any security violation has occurred. Furthermore, views have been used to grant access to individuals for security purposes. We need efficient techniques for auditing as well as for view management.

In this section, we have examined the impact of security on some of the database functions including query management, transaction processing, metadata management, and storage management. We need to also investigate the impact of security on other functions such as integrity constraint processing and fault-tolerant computing. Figure 2.11 illustrates the impact of security on the database functions. It should be noted that some of the discussions in this section have been extended for big data management. This will be our focus especially in Parts IV and V of this book.

2.4 Data Privacy

Data privacy is about protecting sensitive information of individuals. While different definitions of privacy have been proposed, the most common definition is that a person decides what information is to be released about him or her. While data privacy has been studied for decades, especially with statistical databases, with the advent of the World Wide Web and the efforts on applying data mining for counter-terrorism applications, there has been an increasing interest in this topic over the past 15 years. Much research has been reported on balancing the need between privacy and security. The first effort on privacy-preserving data mining was reported in [AGRA00]. Several other efforts on this topic followed since the early 2000s [KANT04]. In addition, treating the privacy problem as a variation of the inference problem was studied in [THUR05b].

With the developments in big data technologies, there is significant interest in data privacy. For example, a National Science Foundation workshop on Big Data Security and Privacy was held in September 2014 and the results have been reported in [NSF14]. We will discuss some of the findings at this workshop in Part V. With advancements in technology such as data analytics and the interest in data privacy among the policy makers, lawyers, social scientists, and computer scientists, we can expect significant developments in protecting the privacy of individuals as well as ensuring their security. More details on big data security and privacy will be provided in Part V of this book.

2.5 Summary and Directions

In this chapter, we have provided an overview of discretionary security policies in database systems. We started with a discussion of access control policies including authorization policies and RBAC. Then we discussed administration policies. We briefly discussed identification and authentication. We also discussed auditing issues as well as views for security. Next, we discussed policy enforcement. We also discussed SQL extensions for specifying policies as well as provided an overview of query modification.

There is still a lot of work to be done. For example, much work is still needed on RBAC and attribute-based access control for emerging technologies such as digital libraries and the semantic web. We need administration policies to manage multiparty transactions in a web environment. We also need biometric technologies for authenticating users. Digital identity is becoming an important research area especially with cloud systems.

Security policy enforcement is a topic that will continue to evolve as new technologies emerge. We have advanced from relational to object to multimedia to web-based to cloud-based data management systems. Each system has some unique features that are incorporated into the security policies. Enforcing policies for the various systems will continue to be a major focus. We also need to carry out research on the consistency and completeness of policies. Policy visualization may help toward achieving this.

Policy management in the cloud and big data is an active area of research. Our work includes access control as well as policy-based information sharing in the cloud. The experimental systems we have developed on security policy enforcement in the cloud are discussed in Part IV.

References

[AGRA00]. R. Agrawal and R. Srikant, “Privacy-Preserving Data Mining,” SIGMOD Conference, pp. 439–450, 2000.

[ATLU04]. V. Atluri and S. Chun, “An Authorization Model for Geospatial Data,” IEEE Transaction on Dependable and Secure Computing, 1 (4), 238–254, 2004.

[BERT89]. E. Bertino and D. Musto, “Integrity Constraint Processing During Transaction Processing,” Acta Informatica, 26 (1–2), 25–57, 1988.

[BERT02]. E. Bertino et al., “Access Control for XML Documents,” Data and Knowledge Engineering, 43 (3), 2002.

[BERT06]. E. Bertino, “Digital Identity Management and Protection,” Proceedings of the 2006 International Conference on Privacy, Security and Trust, Ontario, Canada, 2006.

[CARM04]. B. Carminati et al., “Security for RDF,” Proceedings of the DEXA Conference Workshop on Web Semantics, Zaragoza, Spain, August, 2004.

[DATE90]. C. Date, An Introduction to Database Systems, Addison-Wesley, Reading, MA, 1990.

[DWYE87]. P. Dwyer et al., “Multilevel Security for Relational Database Systems,” Computers and Security, 6 (3), 252–260, 1987.

[FERR00]. E. Ferrari and B. Thuraisingham, “Secure Database Systems,” In Advances in Database Management, M. Piatini and O. Diaz, editors, Artech House, UK, 2000.

[GRIF76]. P. Griffiths and B. Wade, “An Authorization Mechanism for a Relational Database System,” ACM Transactions on Database Systems, 1 (3), 242–255, 1976.

[KANT04]. M. Kantarcioglu and C. Clifton, “Privacy-Preserving Distributed Mining of Association Rules on Horizontally Partitioned Data,” IEEE Transactions on Knowledge and Data Engineering, 16 (9), 1026–1037, 2004.

[NIST]. Guide to Attribute-Based Access Control (ABAC) Definition and Considerations, NIST Special Publication 800-162, 2014.

[NSF14]. National Science Foundation Workshop, http://csi.utdallas.edu/events/NSF/NSF-workhop-Big-Data-SP-Feb9-2015_FINAL.pdf

[PARK04]. J. Park and R. Sandhu, “The UCON Usage Control Model,” ACM Transactions on Information and Systems Security, 7 (#1), 128–174, 2004.

[SAND96]. R. Sandhu et al., “Role-Based Access Control Models,” IEEE Computer, 29 (2), 38–47, 1996.

[SQL3]. en.wikipedia.org/wiki/SQL, American National Standards Institute, Draft, Maynard, MN, 1992.

[STON74]. M. Stonebraker and E. Wong, “Access Control in a Relational Database Management System by Query Modification,” Proceedings of the ACM Annual Conference, ACM Press, NY, 1974.

[THUR87]. B. Thuraisingham “Security Checking in Relational Database Management Systems Augmented with Inference Engines,” Computers and Security, 6 (6), 479–492, 1987.

[THUR89]. B. Thuraisingham and P. Stachour, “SQL Extensions for Security Assertions,” Computer Standards and Interface Journal, 11 (1), 5–14, 1989.

[THUR93]. B. Thuraisingham, W. Ford, and M. Collins, “Design and Implementation of a Database Inference Controller,” Data and Knowledge Engineering, 11 (3), 5–14, 1993.

[THUR94]. B. Thuraisingham, “Security Issues for Federated Database Systems,” Computers and Security, 13 (6), 509–525, 1994.

[THUR97]. B. Thuraisingham, Data Management Systems: Evolution and Interoperation, CRC Press, Boca Raton, FL, 1997.

[THUR05a]. B. Thuraisingham, Database Security, Integrating Database Systems and Information Security, CRC Press, Boca Raton, FL, 2005.

[THUR05b]. B. M. Thuraisingham, “Privacy Constraint Processing in a Privacy-Enhanced Database Management System,” Data and Knowledge Engineering, 55 (2), 159–188, 2005.

[THUR07]. B. Thuraisingham, Building Trustworthy Semantic Webs, CRC Press, Boca Raton, FL, 2007.