augmenting storage with an intrusion response primitive
play

Augmenting Storage with an Intrusion Response Primitive to Ensure - PowerPoint PPT Presentation

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


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

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

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

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

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

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

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

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

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

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

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

  12. IMPLEMENTATION : Group Manager • RICE metadata in groups database • Password protected • List, Add, Remove operations • Input, Output to / from capabilities file 12

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

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

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

  16. EVALUATION : RICE Security Benefit 16

  17. EVALUATION : Micro Benchmark 17

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

  19. EVALUATION : Macro Benchmark 19

  20. EVALUATION : Macro Benchmark - With Caching 20

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