A Protection Architecture for Enterprise Networks (and comments on security-centric network design)

1. A Protection Architecture for Enterprise Networks(and comments on security-centric network design) Martin Casado (Stanford) Tal Garfinkel (Stanford) Aditya Akella (CMU/Stanford) Michael Freedman (NYU) Dan Boneh (Stanford) Nick McKeown (Stanford) Scott Shenker (ICSI/Berkeley)

2. What I’m Going to Talk About • A lot about security in the Enterprise • A little bit about security on the Internet • Generally exploit this opportunity to pontificate

3. Public vs. Private Networks • Public (google, ebay, stanford.edu etc.) • Get as wide exposure • (mostly) everyone welcome • Want some protection from evil-doers • Private (internal commercial, financial etc.) • Special purpose • Limited user base • Knows what’s running where • Fundamentally different(but use same technologies)

4. Infrastructure Support for Public Services • Ability to identify individual users • Ability to revoke access to individual users(stop them from using your network resources) • Ability to determine location of individual users(regulatory compliance) • (more on this later)

5. Infrastructure Support for Private Networks • identify individual users by userid • revoke access to users • determine location of individual users and • strictly define connectivity between users, hosts, services, protocols and access points • control routes at the session level • centralized trust and control • restrict access to information

6. Supported by IP • identify individual users by userid • revoke access to users • determine location of individual users and • strictly define connectivity between users, hosts, services, protocols and access points • control routes at the session level • Centralized trust and control • Restrict access to information

7. Motivation Punch Line • Attempting to do all these things today • … but without the support of the architecture • Result is: • Insecure network • Inflexible network • Hard to manage network

8. Defining Connectivity • Why? • Attempt at limiting resources to that which is needed • Limit damage of internal malware, perimeter breach, or insider • Today: Use lots of filtering • MAC, IP, transport • Physical ports (VLANs) • Deep packet inspection (e.g. first data packet of a protocol) • Full proxies • Access control lists on services(not network aware … but could be!)

9. Defining Connectivity (the bad) • Network only really aware of addresses • Firewall rules embeds topology into configuration state • Difficult to move machines • Hard to read and understand (100k lines of proprietary, different configurations) • Forwarding path unaware of filtering rules • Will try to circumvent if it can • Adding a new network component not good(hence have “choked” networks) • Higher level filtering can be undermined by lower levels(e.g. permissive link layer)

10. Control Over Routing • Why? • Different access points have different security requirements(e.g. wireless users must go through http proxy) • Different protocols have different security requirements(e.g. all files sent over IM must be checked for viruses) • Different user groups have different security requirements(e.g. log all connections from marketing) • Today: make all routes go through the same point (large, expensive do-it-all proxies) • Or use two/three/four separate networks • Or application protocol aware routing (Ciscos OER, application aware routing)

11. Centralized Trust and Control • Why? • Limited number of trusted components • Networks often centrally administered • Pretty new area, but products are starting to pop up • Consentry • Apani • Securify • Networks by nature are distributed • Distributed routing computation (trust every router) • Many (many many) heavily trusted components (DNS, DHCP server, gateway, routers, switches, end-hosts, directory services, authentication services, proxies etc.)

12. Restrict Access to Information • Why? (first resource available to attacker) • Turn off (normally filter at host or perimeter firewall) • RST • ICMP (TTL Time exceeded, echo reply, port unreach) • Detect • ARP scans • Automated IP scans • Limit visibility network resources • VLAN • NATs, Proxies etc. • Still really hard to do (e.g Topology information passed unencrypted in routing protocols) • No “switch” for auditing(should be controlled the same as other resources)

13. Retrofitting Security onto IP • Designed for Security • Firewalls, Router ACLS • Port Security • IDS/NDS/IPS (scan detection, anomaly detection, signature detection) • VLANs • Pushed Into Service • Ethernet Switches • NATs, Proxies Application Transport Network Datalink Physical

14. Common Solutions = Crummy Networks(and mediocre security) • Inflexible • Hard to move a machine (yet difficult to know if someone has moved) • Really difficult to deploy a new protocol • Brittle • Change a firewall rule, break security policy • Add a switch, break security policy • Confusing • Many disparate point solutions • State = a bunch of soft state • Hard to state meaningful policies • Lose redundancy • Introduce choke points • Can't migrate routes b/c of all the soft state

15. Lets Start from Scratch • Leverage characteristics unique to Enterprise • Centrally managed • Known users • Structured connectivity • Reduce number of trusted components • Simplify policy declaration • Retain flexibility and redundancy (decouple topology and security policy)

16. Instead of • Default on + filter Default off + permission • Distributed, cryptic policy simple and centralized • security choke-point fine grained control of routes • Distributed trust centralized • Permissive link layer low level enforcement

17. Momentary Detour • Currently two competing approaches to securing Enterprise: A) Detect when things are bad behaviorally(e.g. anomaly detection) • Don’t know network state • How are you going to define a new protocol? • What if your heuristics are bad? B) Strictly define what is permissible • Limit connectivity to what is needed to get the job done • Assume traffic using that is OK

18. SANE • Declare policy centrally over users, protocols, services and access points • All communications require a “capability” from a central arbiter • Capabilities encode the route • All switches enforce the capability(it is included and enforced at layer 2)

19. Ethernet SANE IP .. Capability Provides Isolation Layer • Contains, encrypted, immutable, route Application Transport Introduce layer 2.5Isolation Layer Network Datalink Physical Esw1 MAC 1,4 CAP-ID Expiration MAC 3,2 MAC 2,1 MAC Service port Esw2

20. Ambient streams 1 1 1 1 3 3 3 3 1 1 1 1 1 4 4 1 1 2 2 2 2 2 2 2 2 3 3 3 3 3 4 4 4 4 4 4 4 4 4 Client port Client port Client port Client port 1 1 2 2 Ambient streams Ambient streams Ambient streams Ambient streams Ambient streams 2 2 Client port Client port SANE:Action Sequence! Authenticatehi, I’m tal, my password is Publishmartin.friends.ambient-streamsallow tal, sundar, aditya martin.friends.ambient-streams Requestmartin.friends.ambient-streams Authenticatehi, I’m martin, my password is 1 2 1 4 4 2 3 3 4 1

21. Send topology information to the DC • Provide default connectivity to the DC • Validate capabilities • Forward packets base on capability • Enforce revocations SANE:Overview • Publish services at the DC • Specify access controls(export streams.ambient allow tal) • Request access to services • Use appropriate capability for each packet Domain Controller • Authenticates users • Contains network topology • Hosts services (by name) • Manages permission checking • Creates and issues capabilities Switches End-Hosts

22. Security Properties • Permission check before connectivity(Users only access resources they have permission to) • Policy enforced at every switch • Centralized, simply policy declaration (topology independent) • Control of routes • Information restricted to administrator • Authenticated end hosts (bound to location)

23. Other Nice Properties • Central point for connection logging (DC) • Addition of switches (redundancy) does not undermine security policy • Anti-mobility

24. But … • How to communicate with the DC? • How to protect the DC? • How to securely get topology to DC? • Go to DC for each flow … are you inSANE? • This is really, really clean slate • Fork lift upgrade entire network • Change all end-hosts to work with capabilities • Change notion of services and naming

25. Connectivity to the DC • Switches construct spanning tree Rooted at DC • Switches don’t learn topology(just neighbors) • Provides basic datagram service to DC

26. Ksw4 Ksw1 Ksw3 Ksw2 Ksw1 Ksw2 Ksw3 Ksw4 Switch Authentication • Switches authenticate with DCand establish symmetric key • Ike2 for key establishment • All subsequent packets to DC have “authentication header”(similar to ipsec esp header)

27. Ksw4 Ksw1 Ksw3 Ksw2 Ksw1 Ksw2 Ksw3 Ksw4 Establishing Topology • Switches generate neighbor listsduring MST algorithm • Send encrypted neighbor-listto DC • DC aggregates to full topology • No switch knows full topology

28. Centralized? (and you call yourself a network researcher) • Exists today .. Sort of (DNS) • Permission check is fast(and control path != data path) • Replicate DC • Computationally (multiple servers) • Topologically (multiple servers in multiple places) • Loads aren’t as high as you might think

29. Backwards Compatibility(Ethane) • Use first packet of flow for permission check • Ports, IP addresses • Can guess application type • Instead of source routes use virtual circuits • Instead of replacing switches, add “bumps”

30. Connection Setup ? DC • Switches disallow all Ethernet broadcast(and respond to ARP for all IPs) • First packet of every new flow is sentto DC for permission check • DC sets up flow at each switch • Packets of established flows areforwarded using multi-layerswitching <src,dst,sprt,dprt> <ARP reply> <ARP,bob> <src,dst,sprt,dprt> Alice Bob

31. Easing Deployment • Use trivial 2-port switches(bumps) • On links betweenEthernet switches • Can be enhanced by usingVLAN per port

32. Status • Built software version SANE • All components in software • Ran in group network (7 hosts) 1 month • Currently in development of “Ethane” • Switches in hardware + software • DC using standard PC

33. Network Support for Public Services? • Ability to identify individual users • Ability to revoke access to individual users • Ability to determine location of individual users(regulatory compliance)

34. Problem: Identity • First level of identity is the IP address • Is it forged? (maybe) • Is half of Thailand behind it? (maybe) • Obviously a bad discriminator • Allow 1 person, allow half of Thailand (e.g. IPA) • Ban 1 person, ban half of Thailand (e.g. AOL proxies) • Today’s solution? • Use high-bandwidth infrastructure for TCP handshake • Use separate, low-function login service • Only allow “blessed” sessions to use services • Is this sufficient? • Tomorrow’s solution? (hip? Note … IPv6 does nothing to help us here)

35. Problem: Protecting Downstream BW • Lots of shared queues (cross traffic) • Packets may not get to destination to trigger filtering • I manually set my TTL • I futz with the transport checksum so your proxy drops it • SYN packet source may be forged (cannot filter) • Note: Overprovision by magical power of 2 not really helpful • Today’s solutions • Get flooded • Identify “aggregates” in the network • Hire someone else to figure out what is going on

36. Third Party Vetting Model peer peer peer peer • IPsec tunnel • Or private circuit Likely per-flow state And other anomaly detection voodoo • Is this the right model? • Is per-flow state at a few points rather thanthroughout the network OK? • How about having a static, layer-2 circuit to protect trust relationships (sounds reasonable to me) • Can we generalize this to offer and support as a service from the Internet?

37. Problem: GeoLocation • Information isn’t really stored anywhere • Registries aren’t accurate • DNS loc isn’t widely used • People lie when filling out online accounts • Proxies and Dial-Ups further complicate things • Todays solution? • A lot of bad academic tools (e.g. unDNS, netgeo) • A few decent commercial offerings (Quova, Akamai)Offering 90 – 95% accuracy at country level • Still, may be breaking the law 5% of the time • Tomorrows solution? • should this even be at the network level? • oh no!, what about privacy?

38. Security and the Internet • Does IP provide adequate security the public Networks?(no, but its pretty close ..) • Will a future Internet look similar to IP(maybe) • What is the problem then? • Malware • SPAM • Admission Control • Phishing etc.

39. Questions?

40. Middlebox Integration • Control of routes is powerful • DC can force routesthrough middlebox based on policy • E.g. signature detection forall flows from laptops and users in marketing Signaturedetection

41. Performance • Decouple control and data path in switches • Software control path (connection setup)(slightly higher latency) • Simple, fast, hardware forwarding path (Gigabits)

42. Enterprise Threat Environment • Incidental attacks (phishing, spam, worms, viruses, kiddies) • External, Targeted Attacks • Competitors (e.g. getloaded.com vs. truckstop.com) • Idealists (e.g. SCO) • Insiders (29% of all attacks?)

43. Enterprise Threat Environment • Incidental attacks (worms, viruses, kiddies) • External Targeted Attacks • More access to resources • Ability to hire skilled attacker • Insiders (29% of all attacks?) • Locality (access to internal network) • Knowledge of internal workings

44. Example: External Targeted Attack • Target: Large company (Bank.com) • Attacker Profile: Skill-level equivalent to a B.S. in computer science • Rules of Engagement: • No physical access • Cannot limit availability of network resources • Goals: • Map out operations • Gain access to sensitive information • Ability to disrupt internal communications if needed

45. Step 1: Reconnaissance Netcraft search: bank (find all relevant domains) Google/groups: @bank.com “*at*bank*com” “*bank*com” “at*bank*” frufru at media dot bank dot comlilo [at sign] shingle [dot] bank [dot] comlaura@rapnet.something.bank.comDr. HeL Lo at <dhello@bank.com >Gin ( dot ) H ( dot ) Polka ( at ) bank ( dot ) COMCar Mc Kubrik · kubik AT NOSPAM bank dot comChris Finkledine at chrisfink@bank.comDavid Spade at spadea@bank.comAlicebob@bank.com

46. Step 1.5: Profiling Google/groups: “*Alicebob*” “*alicebob*bank*”"someone please email me and tell me how to lose the weight? im trying theatkins but its sooo hard! catie how did you lose 67 lbs? what did you eat??please email me at alicebob@bank.com and tell me ok??"“You are truly blessed!!! I wish you a happy and healthy 8 more months. If youdon't mind me asking....when was your tr? lengths? Is this your first pregnancysince your TR? I go for my TR on 10/24/03 so I am just trying to get lots ofinfo together. Again Congratulations and I will lift you, dh and little one inprayer!!!”etc ...

47. router Alicebob Step 2: Contact • Post to forum • Establish rapport • Get IM/email • Write custom trojan • Send infected file over IM, email, etc.

48. router Alicebob Step 3: Do Bad Stuff • Gather local information • Local network parameters • Email addresses, documents etc. • Gain access to traffic • Sniffing (switches) • Redirection (ARP, DHCP, DNS etc.) • Further attack through binary injection • Redirect + proxy • Many vulnerable protocols(http, smtp, htp, nfs, SMB) • Determine DoS attack channels

49. Properties of the Attack • Does not require elite attacker • Simple to launch by an insider • Effective against traditional perimeter security models • Difficult to stop with signature detection • Weak internal protection allows propagation of attack once inside