Secure Network Provenance Wenchao Zhou Qiong Fei Arjun

Secure Network Provenance Wenchao Zhou*, Qiong Fei*, Arjun Narayan*, Andreas Haeberlen*, Boon Thau Loo*, Micah Sherr+ *University of Pennsylvania +Georgetown http: //snp. cis. upenn. edu/ University

Motivation Route r 2 Why did my route to foo. com change? ! Innocent Reason? Malicious Attack? D A Alice Route r 1 n E foo. com B C An example scenario: network routing ¨ System administrator observes strange behavior ¨ Example: the route to foo. com has suddenly changed ¨ What exactly happened (innocent reason or malicious attack)? 2

We Need Secure Forensics n For network routing … ¨ Example: incident in March 2010 n n Traffic from Capital Hill got redirected … but also for other application scenarios ¨ Distributed hash table: Eclipse attack ¨ Cloud computing: misbehaving machines ¨ Online multi-player gaming: cheating n Goal: secure forensics in adversarial scenarios 3

Ideal Solution Route r 2 Q: Explain theto Why did mywhy route to foo. com change? ! changed to r 2. D E A Alice foo. com C B The Network A: Because someone accessed Router D and changed the configuration from X to Y. n Not realistic: adversary can tell lies 4

Challenge: Adversaries Can Lie Everything is fine. Router I should cover up E advertised a new route. the intrusion. Route r 2 Q: Explain why the route to foo. com changed to r 2. D E A Alice foo. com C B The Network n Problem: adversary can … n n . . . fabricate plausible (yet incorrect) response … point accusation towards innocent nodes 5

Existing Solutions n Existing systems assume trusted components ¨ Trusted OS kernel, monitor, or hardware n E. g. Backtracker [OSDI 06], PASS [USENIX ATC 06], Re. Virt [OSDI 02], A 2 M [SOSP 07] ¨ These components may have bugs or be compromised ¨ Are there alternatives that do not require such trust? n Our solution: ¨ We assume no trusted components; ¨ Adversary has full control over an arbitrary subset of the network (Byzantine faults). 6

Ideal Guarantees n n Fundamentally impossible Ideally: explanation is always complete and accurate Fundamental limitations ¨ E. g. Faulty nodes secretly exchange messages ¨ E. g. Faulty nodes communicate outside the system n What guarantees can we provide? 7

Realistic Guarantees Route r 2 Q: Why did my route to foo. com change to r 2? D E A foo. com Alice B Aha, at least I know which node is compromised. n n n The Network C A: Because someone accessed Router D and changed its router configuration from X to Y. No faults: Explanation is complete and accurate Byzantine fault: Explanation identifies at least one faulty node Formal definitions and proofs in the paper 8

Outline n Goal: A secure forensics system that works in an adversarial environment Explains unexpected behavior ¨ No faults: explanation is complete and accurate ¨ Byzantine fault: exposes at least one faulty node with evidence ¨ n n Model: Secure Network Provenance Tamper-evident Maintenance and Processing Evaluation Conclusion 9

Provenance as Explanations route(D, foo. com) D link(D, E) route(E, foo. com) E link(E, B) route(A, foo. com) A Alice route(A, B) link(A, B) route(A, D) …… B n route(B, foo. com) link(B, C) C foo. com route(C, foo. com) link(C, foo. com) Origin: data provenance in databases ¨ Explains the derivation of tuples (Ex. SPAN [SIGMOD 10]) ¨ Captures the dependencies between tuples as a graph ¨ “Explanation” of a tuple is a tree rooted at the tuple 10

Secure Network Provenance route(A, foo. com) link(A, B) route(B, foo. com) link(B, C) n route(C, foo. com) link(C, foo. com) Challenge #1. Handle past and transient behavior ¨ Traditional data provenance targets current, stable state ¨ What if the system never converges? ¨ What if the state no longer exists? 11

Secure Network Provenance Time = t 1 Time = t 2 Time = t 3 route(A, foo. com) route(C, foo. com) link(C, foo. com) n route(B, foo. com) route(C, foo. com) link(B, C) link(A, B) link(C, foo. com) route(B, foo. com) route(C, foo. com) link(B, C) link(C, foo. com) Challenge #1. Handle past and transient behavior Timeline ¨ Traditional data provenance targets current, stable state ¨ What if the system never converges? ¨ What if the state no longer exists? ¨ Solution: Add a temporal dimension 12

Secure Network Provenance Time = t 1 Time = t 2 Time = t 3 route(A, foo. com) +route(A, foo. com) route(C, foo. com) link(C, foo. com) n route(B, foo. com) route(C, foo. com) link(B, C) link(A, B) link(C, foo. com) route(B, +route(B, foo. com) route(C, foo. com) +route(C, foo. com) link(B, C) link(C, foo. com) +link(C, foo. com) Challenge #2. Explain changes, not just state Timeline ¨ Traditional data provenance targets system state ¨ Often more useful to ask why a tuple (dis)appeared ¨ Solution: Include “deltas” in provenance 13

Secure Network Provenance route(D, foo. com) link(D, E) route(E, foo. com) link(E, B) route(A, foo. com) link(A, B) route(B, foo. com) link(B, C) n route(C, foo. com) link(C, foo. com) Challenge #3. Partition and secure provenance ¨ A trusted node would be ideal, but we don’t have one ¨ Need to partition the graph among the nodes themselves ¨ Prevent nodes from altering the graph 14

Partitioning the Provenance Graph route(D, foo. com) link(D, E) route(E, foo. com) link(E, B) route(A, foo. com) link(A, B) RECV SEND route(B, foo. com) link(B, C) n route(C, foo. com) link(C, foo. com) Step 1: Each node keeps vertices about local actions ¨ Split cross-node communications n Step 2: Make the graph tamper-evident 15

Securing Cross-Node Edges Signed commitment from B Signed ACK from A RECEIVE SEND RECV Router A n SEND Router B Step 1: Each node keeps vertices about local actions ¨ Split cross-node communications n Step 2: Make the graph tamper-evident ¨ Secure cross-node edges (evidence of omissions) 16

Outline n Goal: A secure forensics system that works in an adversarial environment Explains unexpected behavior ¨ No faults: explanation is complete and accurate ¨ Byzantine fault: exposes at least one faulty node with evidence ¨ n n Model: Secure Network Provenance Tamper-evident Maintenance and Processing Evaluation Conclusion 17

System Overview Users Primary system Provenance system Operator Query engine Application Extract provenance Maintain provenance Query provenance Maintenance engine Network n n Stand-alone provenance system On-demand provenance reconstruction ¨ Provenance graph can be huge (with temporal dimension) ¨ Rebuild only the parts needed to answer a query 18

Extracting Dependencies n Option 1: Inferred provenance ¨ Declarative specifications explicitly capture provenance ¨ E. g. Declarative networking, SQL queries, etc. n Option 2: Reported provenance ¨ Modified source code reports provenance n Option 3: External specification ¨ Defined on observed I/Os of a black-box system 19

Secure Provenance Maintenance n Maintain sufficient information for reconstruction ¨ I/O and non-deterministic events are sufficient ¨ Logs are maintained using tamper-evident logging n Based on ideas from Peer. Review [SOSP 07] E D foo. com Alice A …… RECV ACK B C …… SEND RCV-ACK 20

Secure Provenance Querying n Recursively construct the provenance graph ¨ Retrieve secure logs from remote nodes ¨ Check for tampering, omission, and equivocation ¨ Replay the log to regenerate the provenance graph E D Alice A Explain the route from A to foo. com route(A, foo. com) RECV (from B) link(A, B) B C 21

Secure Provenance Querying n Recursively construct the provenance graph ¨ Retrieve secure logs from remote nodes ¨ Check for tampering, omission, and equivocation ¨ Replay the log to regenerate the provenance graph E D foo. com route(A, foo. com) Alice A route(B, foo. com) RECV (from C) link(A, B) B link(B, C) C 22

Secure Provenance Querying n Recursively construct the provenance graph ¨ Retrieve secure logs from remote nodes ¨ Check for tampering, omission, and equivocation ¨ Replay the log to regenerate the provenance graph E D foo. com route(A, foo. com) Alice A OK. Now I know how the route was derived. route(B, foo. com) link(A, B) B link(B, C) C route(C, foo. com) link(C, foo. com) 23

Outline n Goal: A secure forensics system that works in an adversarial environment Explains unexpected behavior ¨ No faults: explanation is complete and accurate ¨ Byzantine fault: exposes at least one faulty node with evidence ¨ n n Model: Secure Network Provenance Tamper-evident Maintenance and Processing Evaluation Conclusion 24

Evaluation Results n Prototype implementation (SNoo. Py) ¨ How useful is SNP? Is it applicable to different systems? ¨ How expensive is SNP at runtime? Traffic overhead, storage cost, additional CPU overhead? n Does SNP affect scalability? ¨ What is the querying performance? n Per-query traffic overhead? n Turnaround time for each query? n 25

Usability: Applications n We evaluated SNoo. Py with ¨ Quagga BGP: Route. View (external specification) Explains oscillation caused by router misconfiguration ¨ Hadoop Map. Reduce: (reported provenance) n Detects a tampered Mapper that returns inaccurate results ¨ Declarative Chord DHT: (inferred provenance) n Detects an Eclipse attacker that always returns its own ID n n SNoo. Py solves problems reported in existing work 26

Runtime Overhead: Storage Over 50% of the overhead was due to signatures and acks. Batching messages would help. n Manageable storage overhead ¨ One week of data: E. g. Quagga – 7. 3 GB; Chord – 665 MB 27

Query Latency largely due to replaying logs Verification Replay Download dominated by verifying logs and snapshots n n Query latency varies from application to application Reasonable overhead 28

Summary n Secure network provenance in untrusted environments ¨ Requires no trusted components ¨ Strong guarantees even in the presence of Byzantine faults n Formal proof in a technical report ¨ Significantly extends traditional provenance model n Past and transient state, provenance of change, … ¨ Efficient storage: reconstructs provenance graph on demand ¨ Application-independent n (Quagga, Hadoop, and Chord) Questions? Project website: http: //snp. cis. upenn. edu/ 29