1. PRIVACY-PRESERVING COLLABORATIVE NETWORK ANOMALY DETECTION Haakon Ringberg

2. Unwanted network traffic Haakon Ringberg 2  Problem  Attacks on resources (e.g., DDoS, malware)  Lost productivity (e.g., instant messaging)  Costs USD billions every year  Goal: detect & diagnose unwanted traffic  Scale to large networks by analyzing summarized data  Greater accuracy via collaboration Protect privacy using cryptography

3. Network Challenges with detection  Data volume  Some commonly used algorithms analyze IP packet payload info  Infeasible at edge of large networks 3 Haakon Ringberg

4. Challenges with detection  Data volume  Attacks deliberately mimic normal traffic  e.g., SQL-injection, application-level DoS 1 4 Haakon Ringberg Network I’m not sure about Beasty Let me in! 1 [Srivatsa TWEB ’08], 2 [Jung WWW ’02] Anomaly Detector

5. Challenges with detection  Data volume  Attacks deliberately mimic normal traffic  e.g., SQL-injection, application-level DoS 1  Is it a DDoS attack or a flash crowd? 2  A single network in isolation may not be able to distinguish 5 Haakon Ringberg 1 [Srivatsa TWEB ’08], 2 [Jung WWW ’02] Network

6. CNN.com FOX.com Collaborative anomaly detection  “Bad guys tend to be around when bad stuff happens” 6 Haakon Ringberg I’m just not sure about Beasty :-/

7. Collaborative anomaly detection  “Bad guys tend to be around when bad stuff happens”  Targets (victims) could correlate attacks/attackers 1 7 Haakon Ringberg 1 [Katti IMC ’05], [Allman Hotnets ‘06], [Kannan SRUTI ‘06], [Moore INFOC ‘03] 2 George W. Bush Fool us once, shame on you. Fool us, we can’t get fooled again! “Fool us once, shame on you. Fool us, we can’t get fooled again!” 2 CNN.com FOX.com

8. Corporations demand privacy  Corporations are reluctant to share sensitive data  Legal constraints  Competitive reasons 8 Haakon Ringberg I don’t want FOX to know my customers CNN.com FOX.com

9. Common practice Haakon Ringberg 9 AT&T Sprint Every network for themselves!

10. -like system Greater scalability Provide as a service System architecture Haakon Ringberg 10 AT&T Sprint Collaboration infrastructure For greater accuracy Protects privacy N.B. collaboration could also be performed between stub networks

11. Dissertation Overview Haakon Ringberg 11 Providing Technologies Venue Collaboration Infrastructure Privacy of participants and suspects Cryptography Submitted ACM CCS ‘09 Detection at a single network Scalable Snort- like IDS system Machine Learning Presented IEEE Infocom ’09 Collaboration Effectiveness Quantifying benefits of coll. Analysis of Measurements To be submitted

12. Chapter I: scalable signature-based detection at individual networks Work with at&t labs: Nick Duffield Patrick Haffner Balachander Krishnamurthy 12

13.  Intrusion Detection Systems (IDSes)  Protect the edge of a network  Leverage known signatures of traffic  e.g., Slammer worm packets contain “MS-SQL” (say) in payload  or AOL IM packets use specific TCP ports and application headers 13 IP header TCP header App header Payload Background: packet & rule IDSes Enterprise

14. A predicate is a boolean function on a packet feature e.g., TCP port = 80 A signature (or rule) is a set of predicates  Leverage existing community  Many rules already exist  CERT, SANS Institute, etc  Classification “for free”  Accurate (?) Benefits 14 Background: packet and rule IDSes

15.  Too many packets per second  Packet inspection at the edge requires deployment at many interfaces Drawbacks 15 A predicate is a boolean function on a packet feature e.g., TCP port = 80 A signature (or rule) is a set of predicates Network

16.  Too many packets per second  Packet inspection at the edge requires deployment at many interfaces  DPI (deep-packet inspection) predicates can be computationally expensive Drawbacks 16 Packet has: Port number X, Y, or Z Contains pattern “foo” within the first 20 bytes Contains pattern “bar” within the last 40 bytes A predicate is a boolean function on a packet feature e.g., TCP port = 80 A signature (or rule) is a set of predicates Background: packet and rule IDSes

17. src IP dst IP src Port dst Port Durat ion # Packets A B5 min36 ……………… Our idea: IDS on IP flows 17 How well can signature-based IDSes be mimicked on IP flows? Efficient Only fixed-offset predicates Flows are more compact Flow collection infrastructure is ubiquitous IP flows capture the concept of a connection

18. Idea 18 1. IDSes associate a “label” with every packet 2. An IP flow is associated with a set of packets 3. Our system associates the labels with flows

19. Snort rule taxonomy 19 Header-onlyMeta- Information Payload dependent Inspect only IP flow header Inexact correspondence Inspect packet payload e.g., port numberse.g., TCP flagse.g., ”contains abc” Relies on features that cannot be exactly reproduced in IP flow realm

20. Simple translation 20 3. Our systems associates the labels with flows Simple rule translation would capture only flow predicates Low accuracy or low applicability dst port = MS SQL contains “Slammer” 20 dst port = MS SQL Snort rule: Only flow predicates: Slammer Worm

21. Machine Learning (ML) 21 3. Our systems associates the labels with flows Leverage ML to learn mapping from “IP flow space” to label e.g., IP flow space = src port * # packets * flow duration : if raised otherwise src port # packets

22. Boosting 22 Boosting combines a set of weak learners to create a strong learner h1h1 h2h2 h3h3 H final sign

23. dst port = MS SQL contains “Slammer” Benefit of Machine Learning (ML)  ML algorithms discover new predicates to capture rule  Latent correlations between predicates  Capturing same subspace using different dimensions 23 dst port = MS SQL Snort rule:Only flow predicates:ML-generated rule: Slammer Worm dst port = MS SQL packet size = 404 flow duration

24. Evaluation 24  Border router on OC-3 link  Used Snort rules in place  Unsampled NetFlow v5 and packet traces  Statistics  One month, 2 MB/s average, 1 billion flows  400k Snort alarms

25. Accuracy metrics  Receiver Operator Characteristic (ROC)  Full FP vs TP tradeoff  But need a single number  Area Under Curve (AUC)  Average Precision (AP) 25 AP of p 1 - p p FP per TP 25

26.  Training on week 1, testing on week n  Minimal drift within a month  High degree of accuracy for header and meta 26 5 FP per 100 TP 43 FP per 100 TP Classifier accuracy Rule classWeek1-2Week1-3Week1-4 Header rules1.000.99 Meta- information 1.00 0.95 Payload0.700.710.70

27. Variance within payload group  Accuracy is a function of correlation between flow and packet-level features 27 RuleAverage Precision MS-SQL version overflow1.00 ICMP PING speedera0.82 NON-RFC HTTP DELIM0.48

28. Computational efficiency 28 1. Machine learning (boosting) 33 hours per rule for one week of OC48 2. Classification of flows 57k flows/sec 1.5 GHz Itanium 2 Line rate classification for OC48 Our prototype can support OC48 (2.5 Gbps) speeds:

29. Chapter II: Evaluating the effectiveness of collaborative anomaly detection Work with: Matthew Caesar Jennifer Rexford Augustin Soule 29

30. Methodology 1. Identify attacks in IP flow traces 2. Extract attackers 3. Correlate attackers across victims 1) 2)3) 30

31. Identifying anomalous events  Use existing anomaly detectors 1  IP scans, port scans, DoS  e.g., IP scan is more than n IP addresses contacted  Minimize false positives  Correlate with DNS BL  IP addresses exhibiting open proxy or spambot behavior 1 [Allan IMC ’07], [Kompella IMC ’04] 31

32. Cooperative blocking  A set ‘S’ of victims agree to participate  Beasty is blocked following initial attack  Subsequent attacks by Beasty on members of ‘S’ are deemed ineffective Beasty is very bad! 32

33. DHCP lease issues  Dynamic address allocation  IP address first owned by Beasty  Then owned by innocent Tweety  Should not block Tweety’s innocuous queries 10.0.0.1 ? 33

34. DHCP lease issues  Dynamic address allocation  IP address first owned by Beasty  Then owned by innocent Tweety  Should not block Tweety’s innocuous queries Update DNS BL hourly Block IP addresses for a period shorter than most DHCP leases 1 1 [Xie SIGC ’07] 34

35. Methodology  IP flow traces from Géant  DNS BL to limit FP  Cooperative blocking of attackers for Δ hours  Metric is fraction of potentially mitigated flows 35

36. Blacklist duration parameter Δ  Collaboration between all hosts  Majority of benefit can be had with small Δ 36

37. Number of participating victims  Randomly selecting n victims to collaborate in scheme  Reported number average of 10 random selections 37

38. Number of participating victims  Collaboration between most victimized hosts  Attackers are more like to continue to engage in bad action “x” than a random other action 38

39. Chapter conclusion  Repeat-attacks often occur within one hour  Substantially less than average DHCP lease  Collaboration can be effective  Attackers contact a large number of victims  10k random hosts could mitigate 50%  Some hosts are much more likely victims  Subsets of victims can see great improvement 39

40. Chapter III: Privacy-preserving collaborative anomaly detection Work with: Benny Applebaum Matthew Caesar Michael J Freedman Jennifer Rexford 40

41. E( ) Secure Correlation Privacy-Preserving Collaboration Haakon Ringberg 41 CNN FOX Google E( ) Protect privacy of Participants: do not reveal who suspected whom Suspects: only reveal suspects upon correlation

42. System sketch  Trusted third party is a point of failure  Single rogue employee  Inadvertent data leakage  Risk of subpoena 42 Haakon Ringberg Secure Correlation CNN FOX Google MSFT

43. System sketch  Trusted third party is a point of failure  Single rogue employee  Inadvertent data leakage  Risk of subpoena  Fully distributed impractical  Poor scalability  Liveness issues 43 Haakon Ringberg CNN FOX Google MSFT

44.  Managed by separate organizational entities  Honest but curious proxy, DB, participants (clients)  Secure as long as proxy and DB do not collude Haakon Ringberg 44 CNN FOX ProxyDB Split trust Recall: Participant privacy Suspect privacy

45. 1. Clients send suspect IP addrs (x)  e.g., x = 127.0.0.1 2. DB releases IPs above threshold Protocol outline 45 Client / Participant Proxy DB x# 123 32 x But this violates suspect privacy! Recall: Participant privacy Suspect privacy

46. Protocol outline 1. Clients send suspect IP addrs (x) 2. DB releases IPs above threshold 46 Client / Participant Proxy DB H(x)# 123 32 Still violates suspect privacy! Hash of IP address H(x) Recall: Participant privacy Suspect privacy

47. Protocol outline 1. Clients send suspect IP addrs (x) 2. IP addrs blinded w/F s (x)  Keyed hash function (PRF)  Key s held only by proxy 3. DB releases IPs above threshold 47 F s (x)# F s (1)23 F s (3)2 Client / Participant Proxy DB F s (x) Still violates suspect privacy! Keyed hash of IP address Recall: Participant privacy Suspect privacy

48. Protocol outline 1. Clients send suspect IP addrs (x) 2. IP addrs blinded w/E DB (F s (x))  Keyed hash function (PRF)  Key s held only by proxy 3. DB releases IPs above threshold 48 F s (x)# F s (1)23 F s (3)2 Client / Participant Proxy DB E DB (F s (x)) But how do clients learn E DB (F s (x))? Encrypted keyed hash of IP address Recall: Participant privacy Suspect privacy

49. Protocol outline 1. Clients send suspect IP addrs (x) 2. IP addrs blinded w/E DB (F s (x))  Keyed hash function (PRF)  Key s held only by proxy 3. E DB (F s (x)) learned through secure function evaluation 4. DB releases IPs above threshold 49 F s (x)# F s (1)23 F s (3)2 Client / Participant Proxy DB F s (x) x s Recall: Participant privacy Suspect privacy E DB (F s (x)) Possible to reveal IP addresses at the end

50. Protocol summary  Clients send suspects IPs  Learns F s (x) using secure function evaluation  Proxy forwards to DB  Randomly shuffles suspects  Re-randomizes encryptions  DB correlates using F s (x)  DB forwards bad Ips to proxy 50 F s (x)# F s (3) 12 Client E DB (F s (3)) F s (3) D s (F s (3)) = 3

51. Architecture  Proxy split into client-facing and decryption oracles  Proxies and DB are fully parallelizable Clients Client-Facing Proxies Proxy Decryption Oracles Front-End DB Tier Back-End DB Storage 51

52. Evaluation  All components implemented  ~5000 lines of C++  Utilizing GnuPG, BSD TCP sockets, and Pthreads  Evaluated on custom test bed  ~2 GHz (single, dual, quad-core) Linux machines 52 AlgorithmParameterValue RSA / ElGamalkey size1024 bits Oblivious Transferk80 AESkey size256

53. Scalability w.r.t. # IPs 53  Single CPU core for DB and proxy each

54. Scalability w.r.t. # clients 54  Four CPU cores for DB and proxy each

55. Scalability w.r.t. # CPU cores 55  n CPU cores for DB and proxy each

56. Summary  Collaboration protocol protects privacy of  Participants: do not reveal who suspected whom  Suspects: only reveal suspects upon agreement  Novel composition of crypto primitives  One-way function hides IPs from DB; public key encryption allows subsequent revelation; secure function evaluation  Efficient implementation of architecture  Millions of IPs in hours  Scales linearly with computing resources 56

57. 1. Speed  ML-based architecture supports accurate and scalable Snort-like classification on IP flows 2. Accuracy  Collaborating against mutual adversaries 3. Privacy  Novel cryptographic protocol supports efficient collaboration in privacy-preserving manner Conclusion 57

58. Future Work Highlights 1. ML-based Snort-like architecture  Cross-site: train on site A and test on site B  Performance on sampled flow records 2. Measurement study  Biased correlation results due to biased DNSBL (ongoing)  Rate at which information must be exchanged  Who should cooperate: end-points or ISPs? 3. Privacy-preserving collaboration  Other applications, e.g., Viacom-vs-YouTube concerns 58

59. THANK YOU! Collaborators: Jennifer Rexford, Benny Applebaum, Matthew Caesar, Nick Duffield, Michael J Freedman, Patrick Haffner, Balachander Krishnamurthy, and Augustin Soule

60.  Accuracy is a function of correlation between flow and packet-level features w/o dst port w/o mean packet size 0.990.83 0.790.06 0.020.22 60 RuleOverall Accuracy MS-SQL version overflow1.00 ICMP PING speedera0.82 NON-RFC HTTP DELIM0.48 Difference in rule accuracy

61. Choosing an operating point 61 XZ Y X = alarms we want raised Z = alarms that are raised Precision Y Z Exactness Recall Y X Completeness AP is a single number, but not most intuitive Precision & recall are useful for operators  “I need to detect 99% of these alarms!”

62. Choosing an operating point 62 RulePrecision w/recall 1.00 Precision w/recall=0.99 MS-SQL version overflow1.00 ICMP PING speedera0.020.83 CHAT AIM receive message0.020.11 AP is a single number, but not most intuitive Precision & recall are useful for operators  “I need to detect 99% of these alarms!”

63. Quantifying the benefit of collaboration Effectiveness of collaboration is a function of 1. Whether different victims see the same attackers 2. Whether all victims are equally likely to be targeted 63

64. IP address blinding Haakon Ringberg 64  DB requires injective and one-way function on IPs  Cannot use simple hash  F s (x) is keyed hash function (PRF) on IPs  Key s held only by proxy Client E DB (F s (x))

65. x F s (x) Secure Function Evaluation Haakon Ringberg 65  IP address blinding can be split into per-IP-bit x i problem  Client must learn E DB (F s (x i ))  Client must not learn s  Proxy must not learn x i  Oblivious Transfer (OT) accomplishes this 1,2  Amortized OT makes asymptotic performance equal to matrix multiplication 3 Client x s E DB (F s (x)) 1 [Naor et al. SODA ’01], 1 [Freedman et al. TCC ’05], 2 [Ishai et al. CRYPTO ’03]

66. Public key encryption  Clients encrypt suspect IPs (x)  First w/proxy’s pubkey  Then w/DB’s pubkey  Forwarded by proxy  Does not learn IPs  Decrypted by DB  Does not learn IPs  Does not allow for DB correlation due to padding (e.g., OAEP) 66 Haakon Ringberg Client E DB (E PX (x)) E PX (x)

67. How client learns F s (x)  Client must learn F s (x)  Client must not learn ‘s’  Proxy must not learn ‘x’  Naor-Reingold PRF  s = { s i | 1 ≤ i ≤ 32}  PRF = g^(∏ x i =1 s i )  Add randomness u i to obscure s i from client Haakon Ringberg 67 Message = u i * s i

68. How client learns F s (x)  For each bit x i of the IP, the client learns  u i * s i, if x i is 1  u i, if x i is 0  The user also learns ∏ u i Haakon Ringberg 68 x 0 =0x 1 =1x 31 =1 x = u0u0 u 1 * s 1 u 31 * s 31 F s (x) = s0s0 s1s1 s 31 s =

69. How client learns F s (x)  User multiplies together all values  Divides out ∏ u i  Acquires F s (x) w/o having learned ‘s’ Haakon Ringberg 69 ∏ u i * ∏ x i =1 s i ∏ x i =1 u i * s i * ∏ x i =0 u i ∏ u i * ∏ x i =1 s i / ∏ u i ∏ u i F s (x) = ∏ x i =1 s i

70. How client learns F s (x)  User multiplies together all values  Divides out ∏ u i  Acquires F s (x) w/o having learned ‘s’ Haakon Ringberg 70 But how does the client learn s i * u i, if x i is 1 u i, if x i is 0 Without the proxy learning the IP x?

71. Oblivious Transfer (details) 1. Client sends f(x=0) and f(x=1)  Proxy doesn’t learn x 2. Proxy sends  v(0) = E g(f(0)) (1 + r)  v(1) = E g(f(1)) (s + r) 3. Client decrypts v(x) with g(f(x ))  Calculates g(f(x))  Cannot calculate g(f(1-x)) 71 Haakon Ringberg Client x g(f(x)) s Public: f(x) g(x) f(0) f(1) v(0) v(1)

72. Oblivious Transfer (more details) Haakon Ringberg 72 Proxy chooses random c and r (at startup) Proxy publishes c and g r Client chooses random k (for each bit) Preprocessing: 1.Key x = g k Key 1-x = c * g -k 2.Key x r = (g r ) k Used to decrypt y x 1.Key 0 r = Key 0 r Key 1 r = c r / Key 0 r 2.y 0 = AES Key 1 r (u) y 1 = AES Key 0 r (s * u) Key 0 y0y1y0y1

73. Oblivious Transfer (more details) Haakon Ringberg 73 1.Key x = g k Key 1-x = c * g -k 2.Key x r = (g r ) k Used to decrypt y x 1.Key 0 r = Key 0 r Key 1 r = c r / Key 0 r 2.y 0 = AES Key 1 r (u) y 1 = AES Key 0 r (s * u) Key 0 y0y1y0y1 Proxy never learns x Client can calculate Key x r = (g r ) k easily, but cannot calculate c r (due to lack of r), which is needed for Key 1-x r = c r * (g r ) -k

74. Other usage scenarios 1. Cross-checking certificates  e.g., Perspectives 1  Clients = end users  Keys = Hash of certificates received 2. Distributed ranking  e.g., Alexa Toolbar 2  Clients = Web users  Keys = Hash of web pages 74 1 [Wendlandt USENIX ’08], 2 [www.alexa.com]