trademark

Recommendations

Info

10.0 Data Provenance (cont.) hashed component and will not impact other components in the hash chain. That is to say, different parts of provenance records can achieve independent persistence. 10.8 Utilize dynamic fine-grained access control 10.8.1 Why? To allow only authorized users to obtain certain data. Fine-grained data access control provides users (data consumers) with access privileges that are determined by attributes. In most real-world cases, user-assigned privileges and/or attributes vary with time and location, which may need to be incorporated in access control decision. 10.8.2 How? Using attribute-based encryption, fine-grained access control can be applied to encrypted provenance data. In order to reach the dynamic property, users can introduce the dynamic attribute and weighted attribute into the attribute-based encryption. The dynamic attribute can be described as a frequently changing attribute, such as a location coordinate, while other attributes are considered weighted attributes. These attributes have different weights according to their importance, which are defined in the access control system. Every user in the system possesses a set of weighted attributes, and the data owner encrypts information for all users who have a certain set of attributes. However, a user’s private key has a specific kind of weighted access structure. In order to decrypt a message, a ciphertext with a set of weighted attributes must satisfy the weighted access structure. The weight of the attribute can be increased or decreased to reflect the dynamic property. 10.9 Implement scalable fine-grained access control 10.9.1 Why? To protect large-scale provenance data. A considerable amount of provenance data is stored and exchanged in databases. Database systems allow data consumers access to various types of provenance data in accordance to access policies designed by the data owner. However, an access policy should be scalable in order to meet the ever-growing volume of provenance data and user activity within a group. If the access policy is not scalable, any future policy modifications that may be necessary will be difficult to implement. CLOUD SECURITY ALLIANCE Big Data Working Group Guidance © Copyright 2016, Cloud Security Alliance. All rights reserved. 58
10.0 Data Provenance (cont.) 10.9.2 How? Attribute-based encryption can be utilized to achieve fine-grained access control, which was introduced in the previous section. To achieve scalability, data owners can introduce a semi-trusted proxy that exploits the “so-called” proxy re-encryption technology. This will allow the proxy to decrypt the message and re-encrypt it with the new access structure. Since the proxy is “honestbut-curious”—which indicates it will try to gather as much private information as possible based on possession—users cannot allow the proxy to fully decrypt the message. Ideally, users would control the policy while the proxy is utilized to produce a partial ciphertext for the policy specified by that purpose. When access structure attributes in the ciphertext need to be modified by the data owner, the newly specified policy is given to the proxy. Initially, the proxy uses the previous partial attribute set to decrypt the partial ciphertext, and then applies the newly specified policy to encrypt the partially decrypted ciphertext. Because the proxy does not have the full attribute set, the proxy can only partially decrypt the message and not the entirety of the provenance data. 10.10 Establish flexible revocation mechanisms 10.10.1 Why? To prevent access by unauthorized entities. With such high volumes of provenance data stored in databases, maintaining effective access control is a constant challenge for data managers. Access to the data can be easily abused (even if the privilege of accessing the data is expired) when the access permission is not appropriately updated. (For instance, a fired employee could still abuse access privilege if access is not revoked in timely manner.) In some cases, data may only be valid during a particular time interval. Data managers also need an efficient data revocation scheme after the data has expired. 10.10.2 How? One existing method to keep data secure during transmission is to transform the original data into ciphertext form. Before the provenance data is sent to the untrusted server, the data owner encrypts the information by using the secret key. Anyone who is untrusted by the transmitter cannot have the secret key and, therefore, cannot decrypt the ciphertext to get the original data. Only the authorized party can decrypt the ciphertext by using the secret key. Users can also utilize encryption to secure outsourcing of computation tasks on untrusted servers. Before users send out the high-burden computation task to the cloud server, the data owner can first “blind” the original information by using lightweight encryption technology. At that junction, the data owner can outsource the encrypted information to the cloud server to handle the high-burden computation task. Because the cloud server does not have the secret key, this server cannot disclose the original provenance data. When the computation task is finished, the data owner can use the secret key to recover the data handled by the cloud server. By using encryption, the data owner can outsource the computational task and enable confidential storage of the task and data in the untrusted server. CLOUD SECURITY ALLIANCE Big Data Working Group Guidance © Copyright 2016, Cloud Security Alliance. All rights reserved. 59
Page 2 and 3:
The permanent and official location
Page 4 and 5:
Table of Contents (cont.) 3.1.1 Why
Page 6 and 7:
Table of Contents (cont.) 8.7 Emplo
Page 8 and 9: Introduction The term “big data
Page 10 and 11: 1.0 Secure Computations in Distribu
Page 12 and 13: 1.0 Secure Computations in Distribu
Page 14 and 15: 2.0 Security Best Practices for Non
Page 16 and 17: 2.0 Security Best Practices for Non
Page 18 and 19: 3.0 Secure Data Storage and Transac
Page 20 and 21: 3.0 Secure Data Storage and Transac
Page 22 and 23: 4.0 Endpoint Input Validation/Filte
Page 24 and 25: 4.0 Enpoint Input Validation/Filter
Page 26 and 27: 4.0 Enpoint Input Validation/Filter
Page 28 and 29: 5.0 Real-Time Security/Compliance M
Page 30 and 31: 5.0 Real-Time Security/Compliance M
Page 32 and 33: 6.0 Scalable and Composable Privacy
Page 38 and 39: 7.0 Cryptographic Technologies for
Page 44 and 45: 8.0 Granular Access Control (cont.)
Page 46 and 47: 8.0 Granular Access Control (cont.)
Page 48 and 49: 9.0 Granular Audits It is a best pr
Page 50 and 51: 9.0 Granular Audits (cont.) 9.5 Saf
Page 52 and 53: 9.0 Granular Audits (cont.) 9.10 Cr
Page 54 and 55: 10.0 Data Provenance (cont.) the da
Page 56 and 57: 10.0 Data Provenance (cont.) 10.5 I
Page 60 and 61: References [ABC+07] Giuseppe Atenie
Page 62 and 63: References (cont.) [KL10] Seny Kama
show all

trademark

Create successful ePaper yourself

Delete template?

Save as template?