Themes From theSecurity Assessment Exercise

Vern Paxson

International Computer Science Instituteand

Lawrence Berkeley National Laboratory

vern@icir.org

June 27, 2007

Overview

• Each effort asked to assess its security vulnerabilities, assumptions & capabilities

• Responses from 21 groups (incl. adjuncts)

• Goal for this session:– Summarize, looking for themes– VP: some editorializing inevitable :-)

• Focus on what rather than who

Some Philosophical Points I liked

• For truly integrated security, security semantics must be understood by the network architecture, in the same way that semantics of endpoint, forwarding, routes, address, etc. are. For example, a step in a routing algorithm might read:– When an LSA is received from a currently

trusted router about a link to a currently untrusted router ...

• (from Rudra Dutta / SILO)

Philosophy, con’t

• Carefully crafted custom network security features, based on cryptography or other software-intensive techniques, often get bypassed for a variety of reasons, especially due to ignorance, and configuration or performance frustrations

• (Ibid)

What Everyone Wants: Identity

• Prevalent assumption: verifiable, unspoofable identities

• However, scope varies …– Global PKI or secure name service

– Enclave/Provider

– Fundamentally scoped / chainable (MIT’s UIA)

– Just a handle that persists consistently over time, unguessable ala capability

• … as does granularity:– End systems? Bill-payers?

What About Anonymity?

• Frequently not explicitly considered in assessment

• Some see as a service your (trusted) provider or a third-party can provide

• VP: I wonder about anonymity as an explicit type of identity (to align w/ policies)– Can picture shades of anonymity, e.g., crowd

equivalence; persistent vs. transient

Identity & Attribution

• UCSD/UW effort

• Preserves privacy in absence of problem

• Assumes trusted end-system hardware

• Granularity is end-system / TPM– Not necc. tackling stepping-stone problem

• Effort also includes auditable exported content

Other Issues Regarding Identity

• Does it extend to identifying data?– Seems different: one-to-many, not one-to-one

• With virtualization, do identities ever need to cross between virtual domains?

• What about theft? Not discussed much.– Any general principles?

• VP: worry we’ll have bootstrap problems unless basic design elements in place soon– E.g., we’ll find we need routing to provide properties;

for these, routing folks are relying on strong identities

Common Theme:Communication Setup

• Numerous efforts predicate communication on a setup phase that:– Provides point of consent, policy control/negotiation,

billing

– Allows generation of capabilities, rendezvous• Granularity of associated identity affects amortization

– Allows diffusion of service access• E.g., anycast for initial service location

– Provides point of sender work amplification

• VP: I wonder again about bootstrapping the design

Other Common Themes

• End systems will include (some) trusted hardware– VP: how far should we go in assuming this globally vs.

it’ll often/sometimes be the case? How big a toehold?

• Crypto assumptions:– Can rely on strong, wire-speed crypto (non-pub-key)

• Availability of a solid trust system– Identifiers + authorization

• Secure routing assumed– VP: not clear what this is beyond connectivity. Network

assures locators are proxies for identity?

Some Specific Themes

• Secure geo-location information– Sensornet building block

• Ideally, multi-resolution for degrees of anonymity

• But who controls this? Does user need to trust infrastructure? Does user ask for it, or does infrastructure impose it?

– Could help some forms of defenses• E.g., consistency checks on identity, resource

consumption

Store-and-Forward Complexities

• If network accommodates significant forwarding delays, then– How do (semi-)isolated elements validate

identity & authorization?

– Loops might be optimal, rather than anathema

– Thus, what’s a replay attack vs. robust forwarding?

• Same problem can arise for multi-pathing

Network Inspection

• End system might ask network to inspect traffic on its behalf– DoS, attack filtering– Significant performance gains / resource

conservation (e.g., caching, anti-spam)

• Or of course network may do it unasked

• Additional inspection for management, trouble-shooting– Who can do what with this information?

Exposing Security Costs

• Metrics for cost / benefit tradeoffs?– Cost = # messages (and presumably CPU)

– What about: introduction of additional failure modes? Risk of identity exposure?

• Notions of explicitly selectable levels of security– E.g., global PKI vs. local vs. relying on cached

credentials vs. self-signed identities for trust in presence of disconnection?

Leveraging Diversity

• Multiple viewpoints: allows consistency checks / cross validation– VP: crucial to accommodate these failing for

benign reasons

• Diffuse locations for data, service– Of course, raises consistency & cost issues

– As well as broader exposure of data, or at least visibility into who accesses it

• (Avoiding monocultures)

Issues Regarding Composition

• Interplay between network mechanisms & costs to security mechanisms– E.g., multipathing vs. amortizing session

authentication information on a per-flow basis

• VP: will meta-networks wind up needing to support cross-talk?– If so, how are “hyper-domains” blended?

New Capabilities

• Robust routing will be much more adaptive in presence of attack– VP: not sure how much this fundamentally

changes landscape vs. improves things somewhat

• Management providing greater, integrated views of activity & landscape– Both for direct security analysis & cross-

validation

Things Not Discussed Much

• Billing & accountability:– Future network could have forms of billing that

tie fine-grained user actions to $$• E.g., QoS, services accessed

– This will necessarily drive notions of identity, accountability

– DoS becomes $$ from end sources

– Is there anything we can assume (or anti-assume) in this regard?

Things Not Discussed Much, con’t

• DRM:– Inevitable this will spill over into the network?

– Implications for content inspection, caching?

• Infrastructure threats beyond DoS:– Theft-of-service, theft-of-customer

Things Not Discussed Much, con’t

• For new services, how to validate/audit that it’s fully/correctly provided?– …. in the presence of adversaries

• For both this and forms of network inspection, how to conduct these– At varying semantic levels

– With non-global knowledge?

Things Not Discussed Much, con’t

• Interdependence between security and management– What sort of security can management

services themselves draw upon …

– … given that they have to work when things (including security mechanisms) are broken?

Things Not Discussed Much, con’t

• What about leveraging mutual aid and the fact that there are many more benign actual users than malicious ones?– E.g., collaborative filtering, aggregated/shared

analysis– E.g., mechanisms for our friends / social

networks to help us in times of overload or uncertainty

– “In the real world, selective trust is what makes society work”

Things That Gave Me Pause

• Some assumptions that security issues could be addressed external to an effort– True: for pinpoint crypto ~ securing a session– False: for system properties / vulnerabilities– How do we best address this division?

• Distributed algorithms for which– Adversarial inputs not under consideration

• These differ from failures / misconfigurations

– Or assumed readily thwarted (e.g., crypto)

Things We Should Work Out Soon

• Identity building blocks

• Assumptions about trusted hardware

• Maybe: role of billing / accountability

• Capture:– Spectrum of properties being assumed

– Spectrum of properties being provided

– And for these, what “buy-in” costs / assumptions do they entail?