secure network provenance

Click here to load reader

Post on 24-Feb-2016

72 views

Category:

Documents

0 download

Embed Size (px)

DESCRIPTION

Secure Network Provenance. Wenchao Zhou * , Qiong Fei *, Arjun Narayan *, Andreas Haeberlen *, Boon Thau Loo*, Micah Sherr + * University of Pennsylvania + Georgetown University http://snp.cis.upenn.edu/. Motivation. Route r 2. An example scenario: network routing - PowerPoint PPT Presentation

TRANSCRIPT

Tracking & Mitigating Adversarial Behavior with Secure Network Provenance

Secure Network ProvenanceWenchao Zhou*, Qiong Fei*, Arjun Narayan*, Andreas Haeberlen*, Boon Thau Loo*, Micah Sherr+

*University of Pennsylvania +Georgetown Universityhttp://snp.cis.upenn.edu/

1MotivationAn example scenario: network routingSystem administrator observes strange behaviorExample: the route to foo.com has suddenly changedWhat exactly happened (innocent reason or malicious attack)?2Why did my route to foo.com change?!

Alice

foo.com

Route r1Route r2Innocent Reason?Malicious Attack?

ADEBC2Motivation: We saw some unexpected behavior. Innocent explanation or malicious behavior?We Need Secure ForensicsFor network routing Example: incident in March 2010Traffic from Capital Hill got redirected but also for other application scenariosDistributed hash table: Eclipse attackCloud computing: misbehaving machinesOnline multi-player gaming: cheating

Goal: secure forensics in adversarial scenarios3Existing systems make various assumptions about trusted components, we don't

Go through quicklyNot BGP3Ideal Solution4

The NetworkA: Because someone accessed Router D and changed the configuration from X to Y.

Alice

foo.com

Route r2ADEBCNot realistic: adversary can tell liesWhy did my route to foo.com change?!Q: Explain why the route to foo.com changed to r2.4Configuration from X to Y.

Non realistic, as adversaries can lie.Challenge: Adversaries Can Lie5

The NetworkQ: Explain why the route to foo.com changed to r2.

Alice

foo.com

Route r2ADEBCProblem: adversary can ... fabricate plausible (yet incorrect) response point accusation towards innocent nodesEverything is fine. Router E advertised a new route.I should cover up the intrusion. 5adversary can lie (in the title)Existing SolutionsExisting systems assume trusted componentsTrusted OS kernel, monitor, or hardwareE.g. Backtracker [OSDI 06], PASS [USENIX ATC 06], ReVirt [OSDI 02], A2M [SOSP 07] These components may have bugs or be compromisedAre there alternatives that do not require such trust?Our solution:We assume no trusted components;Adversary has full control over an arbitrary subset of the network (Byzantine faults). 6Narration: many of you have seen systems that address the problem.

Completely take over the machine, then behave arbitrarily 6Ideal GuaranteesIdeally: explanation is always complete and accurateFundamental limitationsE.g. Faulty nodes secretly exchange messagesE.g. Faulty nodes communicate outside the systemWhat guarantees can we provide?7Fundamentally impossibleFundamental limitation / not our systems fault.E.g. outside the system. 7Realistic GuaranteesNo faults: Explanation is complete and accurateByzantine fault: Explanation identifies at least one faulty nodeFormal definitions and proofs in the paper8

The NetworkQ: Why did my route to foo.com change to r2?A: Because someone accessed Router D and changed its router configuration from X to Y.

Alice

foo.com

Route r2ADEBCAha, at least I know which node is compromised.

Explained to you informally what guarantees

Rigorous and formal proof in the paper. 8OutlineGoal: A secure forensics system that works in an adversarial environmentExplains unexpected behaviorNo faults: explanation is complete and accurateByzantine fault: exposes at least one faulty node with evidence

Model: Secure Network ProvenanceTamper-evident Maintenance and ProcessingEvaluationConclusion99Provenance as ExplanationsOrigin: data provenance in databasesExplains the derivation of tuples (ExSPAN [SIGMOD 10])Captures the dependencies between tuples as a graphExplanation of a tuple is a tree rooted at the tuple10

Alice

foo.com

route(C, foo.com)link(C, foo.com)route(A, B)ABCDEroute(B, foo.com)link(B, C)route(A, foo.com)link(A, B)route(D, foo.com)link(D, E)route(E, foo.com)link(E, B)route(A, D)10Secure Network ProvenanceChallenge #1. Handle past and transient behaviorTraditional data provenance targets current, stable stateWhat if the system never converges?What if the state no longer exists?11route(C, foo.com)link(C, foo.com)route(B, foo.com)link(B, C)route(A, foo.com)link(A, B)11Secure Network ProvenanceChallenge #1. Handle past and transient behaviorTraditional data provenance targets current, stable stateWhat if the system never converges?What if the state no longer exists?Solution: Add a temporal dimension12route(C, foo.com)link(C, foo.com)route(B, foo.com)link(B, C)route(A, foo.com)link(A, B)route(C, foo.com)link(C, foo.com)route(B, foo.com)link(B, C)route(C, foo.com)link(C, foo.com)

Time = t1Time = t2Time = t3Timeline12Secure Network ProvenanceChallenge #2. Explain changes, not just stateTraditional data provenance targets system stateOften more useful to ask why a tuple (dis)appearedSolution: Include deltas in provenance13route(C, foo.com)link(C, foo.com)route(B, foo.com)link(B, C)route(A, foo.com)link(A, B)route(C, foo.com)link(C, foo.com)route(B, foo.com)link(B, C)route(C, foo.com)link(C, foo.com)

Time = t1Time = t2Time = t3Timeline+route(A, foo.com)+route(C, foo.com)+route(B, foo.com)+link(C, foo.com)13Secure Network ProvenanceChallenge #3. Partition and secure provenanceA trusted node would be ideal, but we dont have oneNeed to partition the graph among the nodes themselvesPrevent nodes from altering the graph14route(C, foo.com)link(C, foo.com)route(B, foo.com)link(B, C)route(A, foo.com)link(A, B)route(D, foo.com)link(D, E)route(E, foo.com)link(E, B)14Partitioning the Provenance GraphStep 1: Each node keeps vertices about local actionsSplit cross-node communicationsStep 2: Make the graph tamper-evident

15route(C, foo.com)link(C, foo.com)route(B, foo.com)link(B, C)route(A, foo.com)link(A, B)route(D, foo.com)link(D, E)route(E, foo.com)link(E, B)RECVSEND

15Securing Cross-Node EdgesStep 1: Each node keeps vertices about local actionsSplit cross-node communicationsStep 2: Make the graph tamper-evidentSecure cross-node edges (evidence of omissions)16RECVSEND

SENDRECEIVE

Signedcommitmentfrom BSigned ACKfrom ARouter ARouter B16OutlineGoal: A secure forensics system that works in an adversarial environmentExplains unexpected behaviorNo faults: explanation is complete and accurateByzantine fault: exposes at least one faulty node with evidence

Model: Secure Network ProvenanceTamper-evident Maintenance and ProcessingEvaluationConclusion17Secure network provenance, how to maintain efficiently, and given the information how do we answer queries 17System OverviewStand-alone provenance systemOn-demand provenance reconstructionProvenance graph can be huge (with temporal dimension)Rebuild only the parts needed to answer a query18ApplicationPrimary systemProvenance systemNetwork

UsersOperatorQuery engineMaintenance engineExtract provenanceMaintain provenanceQuery provenanceMaintenance engineQuery engine18Extracting DependenciesOption 1: Inferred provenance Declarative specifications explicitly capture provenanceE.g. Declarative networking, SQL queries, etc.Option 2: Reported provenance Modified source code reports provenanceOption 3: External specification Defined on observed I/Os of a black-box system19take-away messages: depending on application. Already specify the dependency information source code19Secure Provenance MaintenanceMaintain sufficient information for reconstructionI/O and non-deterministic events are sufficientLogs are maintained using tamper-evident loggingBased on ideas from PeerReview [SOSP 07]20

Alice

foo.com

ABCDE

SENDRCV-ACKRECVACK

Input and output (sufficient for reconstructing the provenance)20Secure Provenance QueryingRecursively construct the provenance graphRetrieve secure logs from remote nodesCheck for tampering, omission, and equivocationReplay the log to regenerate the provenance graph

21

Alice

foo.com

ABCDEroute(A, foo.com)link(A, B)Explain the route from A to foo.com.RECV (from B)

No need for the details of the verificationReiterate that this is an example21Secure Provenance QueryingRecursively construct the provenance graphRetrieve secure logs from remote nodesCheck for tampering, omission, and equivocationReplay the log to regenerate the provenance graph

22

Alice

foo.com

ABCDEroute(B, foo.com)link(B, C)route(A, foo.com)link(A, B)

RECV (from C)

22Secure Provenance QueryingRecursively construct the provenance graphRetrieve secure logs from remote nodesCheck for tampering, omission, and equivocationReplay the log to regenerate the provenance graph23

Alice

foo.com

route(C, foo.com)link(C, foo.com)ABCDElink(B, C)route(A, foo.com)link(A, B)route(B, foo.com)

OK. Now I know how the route was derived.

23OutlineGoal: A secure forensics system that works in an adversarial environmentExplains unexpected behaviorNo faults: explanation is complete and accurateByzantine fault: exposes at least one faulty node with evidence

Model: Secure Network ProvenanceTamper-evident Maintenance and ProcessingEvaluationConclusion24Evaluation ResultsPrototype implementation (SNooPy)How useful is SNP? Is it applicable to different systems? How expensive is SNP at runtime?Traffic overhead, storage cost, additional CPU overhead?Does SNP affect scalability?What is the querying performance?Per-query traffic overhead?Turnaround time for each query?25AdvertisementNarration: how expensive, how useful, how querying performance.Grey things out25Usability: ApplicationsWe evaluated SNooPy withQuagga BGP: RouteView (external specification)Explains oscillation caused by router misconfigurationHadoop MapReduce: (reported provenance)Detects a tampered Mapper that returns inaccurate resultsDeclarative Ch