Themes From the Security Assessment Exercise

1. Themes From theSecurity Assessment Exercise Vern Paxson International Computer Science Institute and Lawrence Berkeley National Laboratory vern@icir.org June 27, 2007

2. 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

3. 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)

4. 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)

5. 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?

6. 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

7. 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

8. 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

9. 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

10. 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?

11. 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

12. 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

13. 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?

14. 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?

15. 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)

16. 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?

17. 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

18. 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?

19. 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

20. 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?

21. 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?

22. 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”

23. 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)

24. 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?