Upload
joseph-evans
View
213
Download
0
Tags:
Embed Size (px)
Citation preview
Themes From theSecurity Assessment Exercise
Vern Paxson
International Computer Science Instituteand
Lawrence Berkeley National Laboratory
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?