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)
April, 2006
Stanford Clean Slate Seminar
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
April, 2006
Stanford Clean Slate Seminar
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)
April, 2006
Stanford Clean Slate Seminar
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)
April, 2006
Stanford Clean Slate Seminar
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
April, 2006
Stanford Clean Slate Seminar
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
April, 2006
Stanford Clean Slate Seminar
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
April, 2006
Stanford Clean Slate Seminar
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!)
April, 2006
Stanford Clean Slate Seminar
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)
April, 2006
Stanford Clean Slate Seminar
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)
April, 2006
Stanford Clean Slate Seminar
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.)
April, 2006
Stanford Clean Slate Seminar
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)
April, 2006
Stanford Clean Slate Seminar
Retrofitting Security onto IP
 Designed for Security
 Firewalls, Router ACLS
 Port Security
 IDS/NDS/IPS
Application
(scan detection, anomaly
detection, signature detection)
Transport
 VLANs
 Pushed Into Service
Network
 Ethernet Switches
Datalink
 NATs, Proxies
Physical
April, 2006
Stanford Clean Slate Seminar
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
April, 2006
Stanford Clean Slate Seminar
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)
April, 2006
Stanford Clean Slate Seminar
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
April, 2006
Stanford Clean Slate Seminar
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
April, 2006
Stanford Clean Slate Seminar
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)
April, 2006
Stanford Clean Slate Seminar
Capability Provides Isolation
Layer
Ethernet SANE
Application
IP ..
Transport
Network
Datalink
Physical
Introduce layer 2.5
Isolation Layer
Contains, encrypted, immutable, route
Esw1
MAC
1,4
April, 2006
MAC
3,2
MAC
2,1
MAC Service
Esw2
port
Stanford Clean Slate Seminar
CAP-ID Expiration
SANE:
Action Sequence!
martin.friends.ambient-streams
Authenticate
Publish
Request
hi, I’m tal, my password is
martin.friends.ambient-streams
Authenticate
martin.friends.ambient-streams
1 4 3 4
4
Ambient streams
allow
sundar,
hi, I’mtal,
martin,
myaditya
password is
4 13 4 4
3 1 2 2 Ambient streams 4 4
Ambient streams
Client port
1 31 1 22
2 Client port 1 3 1 2 2
Client port
1
4
4
2
3
3
4 1
3 4 4
4
Ambient streams
1 3 1 2
2
April, 2006
Ambient streams
1 3 1 2
2
Client port
Client port
Stanford Clean Slate Seminar
Ambient streams
1 3 1 2
2
Client port
•Send topology information to the DC
SANE:
•Provide default connectivity to the DC
•Publish services
at the
DC
•Validate
capabilities
•Specify access
controls
•Forward
packets base on capability
(export streams.ambient
allow tal)
revocations
Domain•Enforce
Controller
•Request access to services
•Use appropriate capability for each packet
Overview
Switches
•Authenticates users
•Contains network topology
•Hosts services (by name)
•Manages permission checking
•Creates and issues capabilities
End-Hosts
April, 2006
Stanford Clean Slate Seminar
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)
April, 2006
Stanford Clean Slate Seminar
Other Nice Properties
Central point for connection logging (DC)
Addition of switches (redundancy) does not
undermine security policy
Anti-mobility
April, 2006
Stanford Clean Slate Seminar
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
April, 2006
Stanford Clean Slate Seminar
Connectivity to the DC
Switches construct spanning tree
Rooted at DC
Switches don’t learn topology
(just neighbors)
Provides basic datagram service to DC
April, 2006
Stanford Clean Slate Seminar
Switch Authentication
Switches authenticate with DC
and establish symmetric key
Ike2 for key establishment K
All subsequent packets to DC
have “authentication header”
Ksw1
Ksw2
Ksw3
Ksw4
Ksw4
sw1
(similar to ipsec esp header)
April, 2006
Stanford Clean Slate Seminar
Ksw3
Ksw2
Establishing Topology
Switches generate neighbor lists
during MST algorithm
K
Send encrypted neighbor-list
to DC
DC aggregates to full topology K
No switch knows full topology
Ksw4
sw1
April, 2006
Stanford Clean Slate Seminar
Ksw1
Ksw2
Ksw3
Ksw4
Ksw3
sw2
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
April, 2006
Stanford Clean Slate Seminar
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”
April, 2006
Stanford Clean Slate Seminar
Connection Setup
? DC
 Switches disallow all Ethernet broadcast
(and respond to ARP for all IPs)
<src,dst,sprt,dprt>
 First packet of every new flow is sent
to DC for permission check
<ARP reply>
 DC sets up flow at each switch
 Packets of established flows are
forwarded using multi-layer
switching
<src,dst,sprt,dprt>
Alice
April, 2006
Stanford Clean Slate Seminar
Bob
Easing
Deployment
Use trivial 2-port switches
(bumps)
On links between
Ethernet switches
Can be enhanced by using
VLAN per port
April, 2006
Stanford Clean Slate Seminar
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
April, 2006
Stanford Clean Slate Seminar
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)
April, 2006
Stanford Clean Slate Seminar
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)
April, 2006
Stanford Clean Slate Seminar
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
April, 2006
Stanford Clean Slate Seminar
Third Party Vetting Model
peer
peer
peer
peer
Likely per-flow state
And other anomaly detection voodoo
•IPsec tunnel
•Or private circuit
 Is this the right model?
 Is per-flow state at a few points rather than
throughout 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?
April, 2006
Stanford Clean Slate Seminar
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?
April, 2006
Stanford Clean Slate Seminar
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.
April, 2006
Stanford Clean Slate Seminar
Questions?
April, 2006
Stanford Clean Slate Seminar
Middlebox Integration
Control of routes is powerful
DC can force routes
through middlebox
based on policy
E.g. signature detection for
all flows from laptops and
users in marketing
April, 2006
Stanford Clean Slate Seminar
Signature
detection
Performance
Decouple control and data path in switches
Software control path (connection setup)
(slightly higher latency)
Simple, fast, hardware forwarding path
(Gigabits)
April, 2006
Stanford Clean Slate Seminar
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?)
April, 2006
Stanford Clean Slate Seminar
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
April, 2006
Stanford Clean Slate Seminar
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
April, 2006
 Gain access to sensitive information
Stanford Clean Slate Seminar
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 com
lilo [at sign] shingle [dot] bank [dot] com
laura@rapnet.something.bank.com
Dr. HeL Lo at <dhello@bank.com >
Gin ( dot ) H ( dot ) Polka ( at ) bank ( dot ) COM
Car Mc Kubrik · kubik AT NOSPAM bank dot com
Chris Finkledine at chrisfink@bank.com
David Spade at spadea@bank.com
Alicebob@bank.com
April, 2006
Stanford Clean Slate Seminar
Step 1.5: Profiling
Google/groups: “*Alicebob*”
“*alicebob*bank*”
"someone please email me and tell me how to lose the weight? im trying the
atkins 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 you
don't mind me asking....when was your tr? lengths? Is this your first pregnancy
since your TR? I go for my TR on 10/24/03 so I am just trying to get lots of
info together. Again Congratulations and I will lift you, dh and little one in
prayer!!!”
etc ...
April, 2006
Stanford Clean Slate Seminar
Step 2: Contact
Post to forum
Establish rapport
Get IM/email
Write custom trojan
Send infected file over IM, email,
etc.

router
Alicebob
April, 2006
Stanford Clean Slate Seminar
Step 3: Do Bad Stuff
Gather local information
Local network parameters
Email addresses, documents etc.
Gain access to traffic
Sniffing (switches)
Redirection
router
(ARP, DHCP, DNS etc.)
Further attack through
Redirect + proxy
Many vulnerable protocols
binary injection
(http, smtp, htp, nfs, SMB)
Determine
April, 2006
DoS attack channels
Stanford Clean Slate Seminar
Alicebob
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
April, 2006
Stanford Clean Slate Seminar