Augmenting Storage with an Intrusion Response Primitive to Ensure the Security of Critical Data Ashish Gehani Surendar Chandra University of Notre Dame & Gershon Kedem Duke University 1
INTRODUCTION : Intrusion Response • Vulnerabilities continuously discovered • Patches not always possible • Intrusion detection cuts exposure • Previous responses aimed at threat • We curtail consequence • Cryptography / Replication expensive → Focus on critical data − 2
MOTIVATION : Prevention Inadequate • Limited response options – Raise alarm – Close network connection – Kill process • Occurs after attack → Data compromised − • Irreversible → High response threshold to reduce false positives − 3
GOALS : Response Primitive • Guarantee security – Confidentiality via encryption – Integrity via signed hashing – Availability via replication • Reduce Mean Time To Response • Compartmentalize the impact • Simple interface – Automate recovery – Usable granularity 4
BACKGROUND : Secure Filesystems • Symmetric ciphers (CFS, TCFS, CryptFS) → Read permission = Write permission − • Self-certifying (SFS, SFS-RO, MS EFS) → Confidentiality not ensured − • Distributed (Secure File System, Cepheus) → Access rights depend on network − • No replication • No detector interface 5
OVERVIEW : RICE • Provide response primitive – Protection when needed – Data should survive compromise • Invoked by detector when risk is high • Latency from encryption is high – Keep data protected – Unprotect when used – Encryption transformed to key deletion • Reversible via authentication 6
OVERVIEW : Architecture Application Intrusion Detector Write Read Unsigned Unencrypted Data Data ✠ ✟ ✟ ✠ ✟ ✠ ✝ ✞ ✝ ✞ ✝ ✞ ✠ ✟ ✠ ✟ ✟ ✠ ✝ ✞ ✞ ✝ ✝ ✞ ✠ ✟ ✠ ✟ ✟ ✠ ✝ ✞ ✞ ✝ ✞ ✝ Control Write Signed Public/Private Keys Filesystem API Encrypted Delta Capability Manager � ✁ � ✁ � ✁ � ✁ � ✁ ✁ � Remote Node � ✁ ✁ � Write � ✁ � ✁ Read Signed Encrypted Data Data ✂ ✄ ✂ ✄ ✂ ✄ ☎ ✆ ✆ ☎ ✆ ☎ ✂ ✄ ✄ ✂ ✂ ✄ ☎ ✆ ☎ ✆ ✆ ☎ ✄ ✂ ✂ ✄ ✂ ✄ ☎ ✆ ☎ ✆ ☎ ✆ Filesystem 7
DESIGN : Protection Groups • Associates threat with group of targets • Compartmentalize response → Rest of system operates normally − • Minimizes key manipulation → Reduces response time − • Orthogonal to access control groups • Group g has asymmetric key pair e g , d g 8
DESIGN : Confidentiality • File f encrypted with capability s f → Protected file ˆ f = Encrypt ( s f , f ) − • File f in group g → Read capability f r = Encrypt ( e g , s f ) − • Application reads f → RICE computes s f = Decrypt ( d g , f r ) − f = Decrypt ( s f , ˆ f ) • If g threatened – RICE deletes d g , f – f confidentiality safe 9
DESIGN : Integrity • Authentication on close( ) with Write capability e g – File delta computed : δ f – δ f hashed : h δ f = H ( δ f ) ˆ – Hash signed : h δ f = S ( e g , h δ f ) • If g threatened – RICE deletes e g – Subsequent δ f unauthenticated – Changes since open( ) lost 10
DESIGN : Availability • Backups are synchronous • High frequency → Low loss, High cost − • Upper bound on frequency – Finding changed files, Replicating • Duplicate file on open( ) • Compute delta on close( ) → Asynchronous, No tradeoff − • Transfer deltas to remote node • Deltas sufficient for post-intrusion reconstruction 11
IMPLEMENTATION : Group Manager • RICE metadata in groups database • Password protected • List, Add, Remove operations • Input, Output to / from capabilities file 12
IMPLEMENTATION : Capability Manager • System initialization → Read capabilities file − • java.io.FileInputStream calls unsealFile( ) → Decryption, Integrity verification − • java.io.FileOutputStream calls sealFile( ) → Encryption, Delta computation, Replication − • Open RICE file count = 0 → Commit capabilities file − 13
IMPLEMENTATION : Intrusion Detector Interface • Runtime protection – Remove group g write access → Delete e g , Unauthenticated writes possible − – Remove group g read access → Delete d g , Invoke disable( ) − – disable( ) deletes decrypted files, duplicates • Regaining access – Invoke enable( ) → User authentication − – Buffer enable( ) requests for performance 14
EVALUATION : Example Usage • AccountManager uses /tmp for scratch files SubmitData allows uploads to /tmp • AccountManager assumes atomicity for : Copy, Append, Change Permission, Move Race Condition ⇒ • Event 16 denies password file writes in /tmp directory Event 19 Chinese Wall’s upload servlet execution Event 22 Chinese Wall’s writes of scratch password file Event 23 RICE disable( ) of Documents object group 15
EVALUATION : RICE Security Benefit 16
EVALUATION : Micro Benchmark 17
EVALUATION : Macro Benchmark Applications • Check - array, arithmetic, bit operations • Mtrt - ray tracer • Jess - puzzle expert system • Compress - Lempel-Ziv compressor • Db - memory resident database • Mpegaudio - MP3 decompressor • Jack - lexical parser 18
EVALUATION : Macro Benchmark 19
EVALUATION : Macro Benchmark - With Caching 20
CONCLUSION : • RICE mediates file access • Allows dynamic data security / performance tradeoff • Intrusion detector can trigger : – Read permission enforcement with encryption – Write permission verifiability with digital signatures – Data availability with remote delta replication • Reversible through authentication 21
Recommend
More recommend