1 / 24

Themes From the Security Assessment Exercise

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

braith
Download Presentation

Themes From the Security Assessment Exercise

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related