restrict accesses by considering the sensitivity of information about the process and the origin/source of data.
When an auditor needs to check the processes that led to a data object, ideally, for a full traceability, the auditor needs to have access to the process and all direct/indirect origins. The access control system should be able to decide whether the auditor is granted to trace all of the origin/source of the data. It is possible that the access control policy states that parts of them are sensitive to specific auditor. So, the access control system to the provenance should be able to define the policies and implement access control to provenance by considering the direct and indirect relationships in the provenance assertions.
4.1.2 Contributions
In this chapter, we propose a method to implement access control system to the provenance by considering the sensitivity of information about the process and the origin/source of data and also whether the auditor is allowed to access all direct/indirect relationships. We define the access right we call TRACE, that is rather than controlling access for each provenance assertion, we implement the access collectively to the assertion that describes a data object and all assertions that describe the origin of the data object. We combine TRACE with the multi-label method for efficient access control definition to support more granularity of the access restrictions. We propose the implementation by using trusted reference monitor and also alternative implementation by using encryption.
level from the data documented by the provenance [44]. They give an example of employee’s performance review where the employees are encouraged to read the data produced by the employee’s review process, but they are usually not told who had inputs in writing of the process. In this case, the sensitivity level of provenance is higher that sensitivity level of the data. Another example is the letter of recommendation, e.g., letter of recommendation for application to universities.
In this case, the student who is recommended in the letter of recommendation does know the people who wrote the but the student is not allowed to open the envelope of the letter and read the letter. In this case, the sensitivity level of provenance is lower than the sensitivity level of the data.
Braun et al. also argue that provenance needs a new security model [44]. They also propose a security model for provenance based on observation of the usage of provenance [113]. They focus on the security model but do not deeply discuss how to protect integrity of the provenance. Their main proposal is that we need to control access to heads and tails of the edges and the attributes of the nodes in the provenance graph. However, there is no mechanism proposed to implement their access control model.
Tan et al. list six security issues in an SOA-Based provenance system [114]. These security issues are (1) enforcing access control over process documentation, (2) trust framework for actors and provenance stores, (3) accountability and liability for p-assertions, (4) sensitivity of information in p-assertions, (5) long-term stor-age of p-assertions, and (6) creating authorizations for new p-assertions. They emphasis that the first issue is unique to the provenance purposes because the requirements are different from regular data.
Groth et al. have proposed an architecture of provenance system including the security architecture in an EU sponsored project [2]. They have implemented the architecture in an SOA-based provenance store. They suggested that access con-trol should be specifiable at the level of individual p-assertions and at individual elements within p-assertion if needed. They also suggested to use role-based ac-cess control and content-based acac-cess control although no detail explanation and implementation of their proposal.
Syalim et al. discusses the grouping method for improving efficient of access control to provenance graph [104]. They analyze the efficiency of the access control to the provenance that employs grouping mechanism. Chebotko et al. [115] proposed a
secure scientific workflow provenance querying with security view. Security view is a subset of data and processes. Another related work is the work Nagappan et al. [116]. They proposed a model of sharing confidential provenance information where an actor who are willing to share the provenance information can share the query for that provenance information.
Ni et al. proposed an access control language for a general provenance model [117]. They define the provenance of a piece of data as “the documentation of messages, operations, actors, preferences, and context that let to that piece of data”. Operation is a process performed on or caused by some messages. Actors can be applications or human being. Context and preferences are special messages that are used in operation.
Ni et al. proposed access control language for provenance although no specific implementation is described [117]. The access control language consists of the components as follows:
• Target. The target includes the subjects and records to which the policy is applied. The subject can be a collection of users, the records can be also a collection of provenance records. We can include restriction for specific selection of the subjects in the collection.
• Condition. Condition is a boolean expression that define more requirement for the access, for example time limit, location, etc.
• Effect. Effect is the rights of the subject to the provenance records. The effect supports the following values: Absolute Permit, Deny, Necessary Permit, and Finalizing Permit.
• Obligation. An obligation is an operation that should be executed by the subject before (pre-obligation) or after (post-obligation) accessing the prove-nance records. For example, the actors who own proveprove-nance record require each user provide their agreement before access, or to be informed after access.
Cadenhead et al. proposed [1] access control method by query pattern to the provenance in the form of XML using SPARQL. They use Open Provenance Model and propose access control language shown in Figure 4.1. The access control can decide the access by 5 relationships defined in the OPM model, but no definition for grouping the access control based on a deeper relationships.
<policy ID="1" >
<target>
<subject>anyuser</subject>
<record>Doc1_2</record>
<restriction>
Doc1_2 [WasGeneratedBy] process AND
process [WasControlledBy] physician|surgeon
</restriction>
<scope>non-transferable</scope>
</target>
<condition>purpose == research</condition>
<effect>Permit</effect>
</policy>
Figure 4.1: An Access Control Language for Provenance [1]