1

Final Report

Workshop in Information Security – Distributed Databases Project

Access Control Security vs. Performance

By: Yosi Barad, Ainat Chervin and Ilia Oshmiansky

Project web site ::// . .http infosecdd yolasite com

2

Final Report

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.

123

4

3

Final Report

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.

5

6

7

4

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

Our Plan:

9

8

5

Plan Step 1: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.

6

Plan Step 2:

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)

7

Plan Step 3:

Compare the local test results to the results of our initial tests

Network drive configuration Local disks configuration

8

Plan Step 4: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.

9

Plan Step 5: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.

10

Plan Step 6:Compare our implementations

• We have implemented 2 version of Cassandra ACL: Cassandra Acl v1.1 (Code, JavaDoc):

The Acl saved within the value in the database. Cassandra Acl v1.2 (Code, JavaDoc):

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).

11

Plan Step 7:

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.

12

Plan Step 8: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.

13

Plan Step 8:Measure the security holes that may exist due to the

inconsistency of the ACLs

14

Plan Step 8:Measure the security holes that may exist due to the

inconsistency of the ACLs

15

Plan Step 9: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.

16

Progress Compared to Plan:

Final Report

Plan Step StatusExpand 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

  

17

Final Report

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: http://course.cs.tau.ac.il/secws12/ http://infosecdd.yolasite.com/

18

Final Report

Questions?