Final Report Workshop in Information Security – Distributed Databases Project Access Control Security vs. Performance By: Yosi Barad, Ainat Chervin and Ilia Oshmiansky 1 Project web site:

Final Report 2 Our Plan: Expand Cassandra and Accumulo set-ups to the local hard drives. Run benchmark tests on the local configuration Compare the local test results to the results of our initial tests Compare our implementation performance against the Cassandra and Accumulo performance.

Final Report 3 Our Plan: Improve our implementation- Creating a new column for the ACL to be stored in Cassandra Compare our implementations Upgrade from YCSB to YCSB++ benchmark tool.

Measure the security holes that may exist due to the inconsistency of the ACLs Improve the security through stronger consistency between Cassandra nodes Final Report 4 Our Plan:

Plan Step 1: 5 Expand Cassandra and Accumulo set-ups to the local hard drives. We extended the configuration of the following databases to local drives: 1.Cassandra configuration included:  1 cluster containing 1 node.  1 cluster containing 3 nodes. 2.Our Cassandra ACL configuration included:  1 cluster containing 1 node.  1 cluster containing 3 nodes. 3.Accumulo configuration included:  1 cluster containing 1 node.  Hadoop and Zookeeper installed and configured on the Accumulo node.

Plan Step 2: 6 Run benchmark tests on the local configuration We ran the benchmark test on the local hard disks. This time we got better results:  More stable  Achieved higher performance (in terms of throughput)

Plan Step 3: 7 Compare the local test results to the results of our initial tests Network drive configuration Local disks configuration

Plan Step 4: 8 Compare our implementation performance against the Cassandra original performance. We measured Cassandra original performance using only values. We measured our implementation performance as we increased the number entries in the ACLs each time.

Plan Step 5: 9 Creating a new column for the ACL to be stored in Cassandra database We modified Cassandra behavior:  for each column insertion we saved another column which maintained the ACL.  Once a user tries to retrieve or delete a column from the database we invoke the corresponding ACL column.  If the user has read or write permission on that ACL – the according operation is approved.  Otherwise the operation is denied and a message is prompt to the user.

Plan Step 6: 10 Compare our implementations We have implemented 2 version of Cassandra ACL:  Cassandra Acl v1.1 (Code, JavaDoc): Cassandra Acl v1.1CodeJavaDoc The Acl saved within the value in the database.  Cassandra Acl v1.2 (Code, JavaDoc): Cassandra Acl v1.2CodeJavaDoc The Acl saved in a new column in the database. We ran benchmark tests on both of them. Version 1.1 has better performance (greater throughput). Version 1.2 provides better security (doesn’t hold the value in the memory as it traverse on the ACLs).

Plan Step 7: 11 Upgrade from YCSB to YCSB++ benchmark tool Once we installed YCSB++:  We were able to measure the Read after writes in the database. We used Zookeeper to synchronize the operations of the producer and the consumer activated by YCSB++. We edited YCSB++ code:  So we could measure the read after update in the database.  Since It may simulate a change applied to the ACLs.

Plan Step 8: 12 Measure the security holes that may exist due to the inconsistency of the ACLs We ran the test among computers in the lab. The inconsistency windows we obtained were very small (using same LAN). In order to obtain more durable time lags we tried to:  Extend the number of clusters - up to 6 Cassandra clusters.  Introduced a new Wi-Fi cluster among the other clusters. We Installed our implementation on a laptop connected to network. This time our tests obtained more concrete time lags which implied on a larger inconsistency windows.  We simulated latency on the network between the nodes.

Plan Step 8: 13 Measure the security holes that may exist due to the inconsistency of the ACLs

Plan Step 8: 14 Measure the security holes that may exist due to the inconsistency of the ACLs

Plan Step 9: 15 Improve the security through stronger consistency between Cassandra nodes We tried to obtain a consistent state among the nodes in order to reduce the inconsistency windows We configured the consistency level of the read/write to ALL. Tradeoffs between consistency and latency are tunable in Cassandra. One can achieve stronger consistency with an increased latency. Write consistency level – ALL preserves a consistence state. Read consistency level – ALL preserves a consistence state. Recommendation:  Mostly read operations – set write consistency level to ALL.  Mostly write operations – set read consistency level to ALL.

Progress Compared to Plan: Final Report 16 Plan StepStatus Expand Cassandra and Accumulo set-ups to the local hard drives Run benchmark tests on the local configuration Compare the local test results to the results of our initial tests Compare our implementation performance against the Cassandra and Accumulo performance. Improve our implementation- Creating a new column for the ACL to be stored in Cassandra Compare our implementations Upgrade from YCSB to YCSB++ benchmark tool. Measure the security holes that may exist due to the inconsistency of the ACLs Improve the security through stronger consistency between Cassandra nodes

Final Report 17 Overall We implemented two versions of Cassandra ACL. We tested and benchmarked our implementation versus the original Cassandra and Accumulo. We measured the security holes created due to inconsistency windows. We try to improve the security through configuration of a consistent state between cassandra nodes which reduce the inconsistency windows. You may find all of our work, implementation, Javadoc, documentation on our websites:  

Final Report 18 Questions?