|
Overview
As long as the system is working correctly, emerging network provenance techniques can construct such explanations. However, if some of the nodes are faulty or have been compromised by an adversary, the situation is complicated by the fact that the adversary can cause the nodes under his control to lie, suppress information, tamper with existing data, or report nonexistent events. This can cause the provenance system to turn from an advantage into a liability: its answers may cause operators to stop investigating an ongoing attack because everything looks fine. The goal of this project is to provide secure network provenance, that is, the ability to correctly explain system states even when (and especially when) the system is faulty or under attack. Towards this goal, we are substantially extending and generalizing the concept of network provenance by adding capabilities needed in a forensic setting, we are developing techniques for securely storing provenance without trusted components, and we are designing methods for efficiently querying secure provenance. We are evaluating our techniques in the context of concrete applications, such as Hadoop MapReduce or BGP interdomain routing.
Publications
Contributors
Faculty: Funding This work is funded by the National Science Foundation under the Trustworthy Computing program (grant number CNS-1065130). | ||||
| Web site contact: Andreas Haeberlen | ||||
Operators of distributed systems often find themselves needing to answer a
diagnostic or forensic question. Some part of the system is found to be in
an unexpected state; for example, a suspicious routing table entry is
discovered, or a proxy cache is found to contain an unusually large number of
advertisements. The operators must determine the causes of this state before
they can decide on an appropriate response. On the one hand, there may be an
innocent explanation: the routing table entry could be the result of a misconfiguration,
and the cache entries could have appeared due to a workload change. On the
other hand, the unexpected state may be the symptom of an ongoing attack: the
routing table entry could be the result of route hijacking, and the cache
entries could be a side-effect of a malware infection. In this situation, it
would be helpful to be able to ask the system to "explain"
its own state, e.g., by describing a chain of events that link the state
to its root causes, such as external inputs.