Final Report

Workshop in Information Security –

Distributed Databases Project

Access Control Security vs. Performance

By: Yosi Barad, Ainat Chervin and Ilia Oshmiansky

1

http://infosecdd.yolasite.comProject 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): 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).

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 Step Status

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:

http://course.cs.tau.ac.il/secws12/

http://infosecdd.yolasite.com/

Final Report

18

Questions?