Themes From the Security Assessment Exercise Vern Paxson

Themes From the Security Assessment Exercise Vern Paxson International Computer Science Institute and 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 softwareintensive 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 – Do. S, 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 & crossvalidation

Things Not Discussed Much • Billing & accountability: – Future network could have forms of billing that tie fine-grained user actions to $$ • E. g. , Qo. S, services accessed – This will necessarily drive notions of identity, accountability – Do. S becomes $$ from end sources – Is there anything we can assume (or antiassume) 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 Do. S: – 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?