As cloud storage in particular and networked storage in general gain widespread adoption, the biggest concern for customers is security. The concern is well warranted for two reasons. First, the surface area of exploitation and vulnerability is greatly increased with the communication channel and a possibly shared remote server, in addition to multiple clients. Second, when the networked storage server is maintained by a third party, such as a cloud provider, there is a lack of trust in the way data is managed at the server side. To minimize the risks while out-sourcing the data management, networked storage clients need security mechanisms at their end to ensure data integrity and confidentiality. However, security mechanisms such as encryption, authentication, and virus-scanning often have high-performance overhead. Figuring out the security policy that offers the right balance of security and performance is, therefore, important. To solve this problem, we examine the performance overhead of different security features of a networked storage system and develop security policies that trade-off security and performance. This study was motivated by the lack of previous work on performance overhead of security in the context of networked storage systems. A typical way to enforce security policies in client-server computer systems is using proxies to monitor and regulate the client-server communication, as exemplified by network firewalls. While the security installations go into a proxy, clients and servers are kept intact, and can continue to work without changes. The proxies are usually deployed at the trusted end to fence off security threats from the untrusted end. Besides to providing security, proxies can also improve performance by caching. Considering that storage servers may be slow and over a WAN, as in cloud-backed systems, caching proxies, deployed in the same LAN of the clients, can significantly reduce server access latency. Specifically, we studied the trade-off between security and performance in a Network File System (NFSv4) with a security and caching proxy. We designed and implemented the proxy with a layered architecture, where each security feature is a stackable file system layer. Each layer can be enabled or disabled, and separately configured as required by policy. For example, an anti-virus layer can be configured to the size or type of file that it scans while an integrity layer can be configured, independently, whether or not to detect replay attacks of file data. This layered architecture facilitates the study of security performance trade-off because different security policies can be composed easily via composition of different layers. Our study showed the interesting interaction between security policies and system performance. We found that the order of the same set of security layers has a significant performance impact, and identified the optimal order of anti-virus, encryption, integrity, and cache.

1. Arun Olappamanna Vasudevan
Stony Brook University
http://www.fsl.cs.sunysb.edu/
Finding the Right Balance:
Security vs. Performance
with Network Storage Systems
A
Master’s
Thesis

2. Summary of Contributions
l Co-developed a secure NFSv4 proxy
with integrity-checking, encryption, anti-
virus, and cache
l Contributed to NFS-Ganesha project to
support stacking of multiple FSALs
l Developed buffer scanner in ClamAV
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 2
LOC Proxy-cache,
Anti-virus
Integrity-
Encryption
Total
Source 9,264 3,586 12,850

3. l Motivation
l Background
l Design
l Implementation
l Evaluation
l Conclusions and Future Work
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 3
Outline

4. Cloud Storage
l Availability
u Google Cloud Platform @ 99.9973% up-
time
l Scalability
l Economical
l Accessibility
l Easy to share and collaborate
documents
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 4

5. Security Concerns
l Confidentiality
u Sony Pictures Entertainment
u Photos of celebrities in iCloud hack
l Integrity
u CERN – petabyte scale data
u 22/33,700 files corrupted (8.7 TB)
l Availability
u Symantec report – 43% of respondents
have lost data in cloud!
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 5

6. Threat Model
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 6
Cloud
Secure
Proxy
Clients
LAN
WAN
Trusted Untrusted
Semi-trusted

7. HTTPI
Server
Authentication
Message
Integrity
Message
Confidentiality
HTTP ✖ ✖ ✖
HTTPS ✔ ✔ ✔
HTTPI ✔ ✔ ✖
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 7

8. b
l Motivation
l Background
l Design
l Evaluation
l Implementation
l Conclusions and Future Work
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 8
Outline

9. NFSv4 and Cloud
l Cloud storage gateways
l Amazon Elastic File System (EFS)
l Cloud NAS
u Zadara Storage
u SoftNAS
l NFSv4
u Compounds
u Delegation
u pNFS
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 9

10. Example: IBM Panache
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 10
Client
Client
Client
Client
Panache
cluster
GPFS
pNFS
WAN

11. l Motivation
l Background
l Design
l Implementation
l Evaluation
l Conclusions and Future Work
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 11
Outline

12. Design Goals
l Advanced security features
u Encryption, integrity-check, anti-virus
u Security policies
l Minimal performance penalty
u Cache
l Easy to develop and maintain
u Proxy architecture
u Layered implementation
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 12

13. Proxy Architecture
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 13
Server
Proxy with
security and cache
Clients
LAN
WAN
NFS
NFS

14. NFS-Ganesha
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 14
Client
Proxy NFSv4
Cache_inode
Server
Stackable
FSAL
FSAL_
PROXY
open read write
pxy_open pxy_read pxy_write
File
System
Abstraction
Layers
(FSAL)

15. Layered Architecture
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 15
Client
Proxy
Server
Security
Cache
Client
Proxy
Server
Cache
Security
Model A Model B

16. Model A
Item Support?
Write-back cache ✔
Protect against bad data in cache
from server
✖
Protect against bad data in cache
from client
✔
Additional data for security ✔
Modification of data ✖
Handling security updates ✔
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 16
Client
Proxy
Server
Security
Cache

17. Model A (Write Path)
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 17

18. Model B
Item Support?
Write-back cache ✖
Protect against bad data in cache
from server
✔
Protect against bad data in cache
from client
✖
Additional data for security ✖
Modification of data ✔
Handling security updates ✖
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 18
Client
Proxy
Server
Cache
Security

19. Final Hybrid Design
l Cache – Read and write
in block units
l Anti-virus protects
against malware from
clients
l Crypto and integrity
protect confidentiality
and integrity of data in
server
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 19
Client
Proxy
Server
Anti-virus
Cache
Crypto
Integrity

20. l Motivation
l Background
l Design
l Implementation
l Evaluation
l Conclusions and Future Work
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 20
Outline

21. Anti-Virus
l ClamAV
u Signature-based anti-virus scanner
u Full-file scans
l Server-data is protected by integrity
u Scan only writes from clients
u Every 5 minutes (configurable) and at close
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 21

22. Cache
l Write-back data cache
u Every 5 minutes (configurable) and at close
u Meta-data is not cached
l Persistent cache
u Sparse local files for cached remote files
u Page-cache in memory
l Thread-safe implementation
u Per-file range locks
u Handling asynchronous write-backs
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 22

23. Integrity
l SCSI standard Data Integrity Field (DIF)
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 23

24. Integrity with NFSv4.2
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 24
APP
OS
NFS Client
NFS Server
OS
HBA
Device
WAN
DIX
DIF
WRITE_PLUS(data, integrity_tag)
READ_PLUS: data, integrity_tag
WRITE(data)
WRITE(data)
READ: data
READ: data
DIX: Data Integrity eXtension

25. Integrity and Encryption
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 25
PDATA
ADATA
Cipher-text
Integrity_tag
AES-GCM
Plain-text
data
Authentication
data
File key

26. l Motivation
l Background
l Design
l Implementation
l Evaluation
l Conclusions and Future Work
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 26
Outline

27. Experimental Setup
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 27
Virtual SCSI
device with
DIX support
Proxy
Anti-virus
Cache
Crypto
Integrity
Client 1
Client 3
Client 2
Client 4
Client 5
Server
LAN (0.2ms RTT)
10 GbE
WAN (30ms RTT)
1 GbE

28. Experiments
l Micro-workloads
u 100 files pre-allocated
u Repeat for 2 minutes:
§ Open a random file
§ Read n times
§ Write m times
§ Close file
l Macro-workloads (Filebench)
u File server and Mail server
u Web server
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 28

29. Combinations of Features
Configs Proxy Integrity Encryption Caching Anti-virus
P (baseline) ✔ ✖ ✖ ✖ ✖
I ✔ ✔ ✖ ✖ ✖
IE ✔ ✔ ✔ ✖ ✖
IC ✔ ✔ ✖ ✔ ✖
ICE ✔ ✔ ✔ ✔ ✖
ICEA ✔ ✔ ✔ ✔ ✔
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 29

30. 1:1 Read-Write ratio 1 MB
0
20
40
60
80
100
120
140
160
P I IC IE ICE ICEA
#Ops/Sec
Security and Caching Configs
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 30
2.2X 2.3X

31. 1:1 Read-Write ratio 10 MB
0
20
40
60
80
100
120
140
160
180
P I IC IE ICE ICEA
#Ops/Sec
Security and Caching Configs
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 31
-21%
2.9X
2.4X
-23%

32. Speed-up vs. Read-Write ratio
0
1
2
3
4
5
6
7
8
9
10
1 2 4 8 16
SpeedupFactorRelativetoBaseline
Read-to-Write Ratio
I
IC
ICE
ICEA
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 32

33. 1:16 Read-Write ratio 1 MB
0
5
10
15
20
25
30
35
40
45
50
P I IC IE ICE ICEA
#Ops/Sec
Security and Caching Configs
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 33
+5%

34. File Server Workload
0
5
10
15
20
25
30
35
40
45
P I IC IE ICE ICEA
#Ops/Sec
Security and Caching Configs
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 34
-25%

35. Web Server Workload
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 35
0
20
40
60
80
100
120
140
160
180
200
P I IC IE ICE ICEA
#Ops/Sec
Security and Caching Configs
-60%
+77% +75%

36. Evaluation Summary
l Integrity
u Overhead: 3–26%
l Encryption with integrity
u No additional overhead
l Anti-virus
u Overhead: up to 23% for 10MB files
l Cache
u Performance: up to 8x
l File server, Mail server, Web server
u With all features: 23–28% overhead
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 36

37. l Motivation
l Background
l Design
l Implementation
l Evaluation
l Conclusions and Future Work
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 37
Outline

38. Conclusions
l Designed and implemented a secure
NFS proxy with cloud back-end
l Overhead of security
u Integrity and Encryption give similar
overheads
u Anti-virus overhead depends on file-size
l Caching can offset security overhead to
a great extent
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 38

39. Future Work
l Security
u Use Merkle tree or versioning scheme for integrity
u Meta-data confidentiality
l Performance
u Anti-virus scanning incrementally
u Relax NFS strict consistency
§ Use RESTful protocols between proxy and server
l Kurma – Secure Geo-Replicated Multi-Cloud
Storage Gateways
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 39

40. Acknowledgements
l My advisor, Dr. Erez Zadok
l Ming Chen, Kelong Wang
l My family and friends
l Committee members
l NSF
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 40

41. Arun Olappamanna Vasudevan
Stony Brook University
http://www.fsl.cs.sunysb.edu/
Finding the Right Balance: Security vs. Performance
with Network Storage Systems
A
Master’s
Thesis
Q&A

42. Kurma: Secure Geo-Replicated Multi-Cloud
Storage Gateways
Region
1
Clients
Region
2
metadata
metadata
metadata
Region
3
Azure
S3
Drive
Untrusted
Secure
Gateway
Public Clouds
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 42

43. Model A (Read Path)
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 43

44. Model B (Read Path)
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 44

45. Model B (Write Path)
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 45

46. Final Hybrid Design
(Read Path)
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 46

47. Final Hybrid Design
(Write Path)
05/15/2015 Arun Olappamanna Vasudevan—Masters Defense 47