Final Report
Workshop in Information Security –
Distributed Databases Project
By: Yosi Barad, Ainat Chervin and Ilia Oshmiansky
Project web site: http://infosecdd.yolasite.com
Access Control Security vs. Performance
1
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.
2
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.
3
Final Report
Our Plan:
Measure the security holes that may exist
due to the inconsistency of the ACLs
Improve the security through stronger
consistency between Cassandra nodes
4
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.
5
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)
6
Plan Step 3:
Compare the local test results to the results of our initial tests
Network drive configuration
7
Local disks configuration
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.
8
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.
9
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).
10
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.
11
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.
12
Plan Step 8:
Measure the security holes that may exist due to the
inconsistency of the ACLs
13
Plan Step 8:
Measure the security holes that may exist due to the
inconsistency of the ACLs
14
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:
15
 Mostly read operations – set write consistency level to ALL.
 Mostly write operations – set read consistency level to ALL.
Final Report
Progress Compared to Plan:
Plan Step
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
16
Status
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/
17
Final Report
Questions?
18