1 / 19

A Privacy-Preserving Interdomain Audit Framework

A Privacy-Preserving Interdomain Audit Framework. WPES 2006. Adam J. Lee Parisa Tabriz Nikita Borisov University of Illinois, Urbana-Champaign. Security Auditing. Necessary for the maintenance of secure and robust systems Logs contain sensitive information

Download Presentation

A Privacy-Preserving Interdomain Audit Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Privacy-Preserving Interdomain Audit Framework WPES 2006 Adam J. Lee Parisa Tabriz Nikita Borisov University of Illinois, Urbana-Champaign

  2. Security Auditing • Necessary for the maintenance of secure and robust systems • Logs contain sensitive information • Often performed centrally within one organization

  3. Motivation for Distributed Audit Privacy-Preserving • Coordinated attacks are a growing threat[1] • Correlated network reconnaissance • Application-level abuses • But there is still that whole privacy thing… • Now we can… • Detect coordinated attacks • Avoid single point of failure • Analyze data otherwise protected under privacy legislation [1] S. Katti, B. Krishnamurthy, and D. Katabi. Collaborating Against Common Enemies. Internet Measurement Conference, 2005.

  4. Practical Scenarios • Virtual Organizations • Grid Computing • Research Labs • Organizations with multiple sites This work Privacy Policy Spectrum Anonymized Logs Raw Logs

  5. Plan of Action… • System Architecture • Threat Model • Log Obfuscation Techniques • Implementation and Evaluation • Discussion and Future Work

  6. System Architecture Alert! Alert! Auditor Organization Organization Organization Audit Group

  7. Threat Model • The Organizations… • Keep secrets secret • May try to probe other organizations • The Auditor… • An “honest, but curious” adversary • Probabilistic guarantees against a Byzantine adversary

  8. Data Formats • Identifiers (ie. DEBUG, WARN) • Numbers (ie. 80, 3.14) • Trees (ie. 192.168.0.1) • Partially Ordered Sets (ie. RBAC systems) • Lists (ie. Packet header fields)

  9. Obfuscation Levels • Full Disclosure • Local Exact Match • Portion Dropping • Local Prefix Match • Local Greater-Than • Basic Numeric Transformations • Local Blinded Arithmetic • Complete Obfuscation

  10. Local Exact Match Suppose we want an auditor to verify if some message value of a log matches, but not leak any information about the value of that field… • Use a keyed-hash MAC to obfuscate value • Can only recover original data by brute force search in space of possible values Warn Debug Warn Warn Error Warn Warn Error Debug Warn

  11. Local Prefix Match Suppose we are only interested in certain IP address subnets matching in a log field… • Use the keyed-hash MAC construction on each “portion” of a hierarchical log field. • Compared to other prefix-preserving schemes, can be done in one pass 192 168 0 1 192 168 0 2 192 168 10 31

  12. User Staff Student Graduate Undergrad User Staff Student Graduate Undergrad Local Greater-Than Suppose we want to know if some user belongs to a group role in a system… • Represent a transformed poset as a bloom filter to test set membership

  13. Local Blinded Summation Suppose we want to provide daily summary reports on intrusions and alerts to all audit members without leaking information about actual statistics. • Use homomorphic encryption • Given the complexity of homomorphic computation, appropriate for batched processing + = 505 134 639

  14. A Basic Implementation GLO IDS Logs Analysis Engine Alert! Application Logs Alert Manager Traffic Logs Organization Auditor

  15. Evaluation • On a standard computer… • P4 2.5GHz Processor, 512M RAM, Linux, blah, blah • The processing rates are reasonable… • NCSA IDS rates: ~30 records/second • GLO • Fastest: Complete obfuscation on a number, poset, identifier is ~20,000 records/second. • Slowest: Prefix-preserving match on a tree is ~7,000 records/second • A typical network log is processed fast enough… • A log similar to tcpdump processes at ~3,500 records/second

  16. Catching Liars and Cheaters • How do we assure the auditor is running the correct software? Trusted computing platforms • How can we detect false or incomplete alarms? Sign logs to verify alerts Plant fake log sequences • How do we detect probing organizations? Define rules to detect gaming

  17. Information Disclosure • Fields in logs are often related • Common knowledge can circumvent obfuscation (the crowd boos) Choose data fields to be reported carefully Consider functional dependencies

  18. Future Work • Combating information leakage • Standard log conversion and optimized obfuscation • Investigation into distributed attack detection • Key management protocol for audit group

  19. Cliff’s Notes • Architecture and obfuscation methods for privacy-preserving distributed audit • An encouraging evaluation of obfuscation techniques • Some challenges and incentive for further research Questions?

More Related