Does Agile Enterprise Architecture = Agile + Enterprise Architecture?
A Protection Architecture for Enterprise Networks · Dan Boneh (Stanford) Nick McKeown (Stanford)...
-
Upload
truongminh -
Category
Documents
-
view
219 -
download
0
Transcript of A Protection Architecture for Enterprise Networks · Dan Boneh (Stanford) Nick McKeown (Stanford)...
2005 Stanford Security Forum 2006
Martin Casado (Stanford)Tal Garfinkel (Stanford)Aditya Akella (CMU/Stanford)Michael Freedman (NYU)Dan Boneh (Stanford)Nick McKeown (Stanford)Scott Shenker (ICSI/Berkeley)
A ProtectionArchitecture for Enterprise Networks
2005 Stanford Security Forum 2006
Talk Outline
Example: Breaking into an Enterprise network
Problems with enterprise security today
SANE: rethinking the network architecture
2005 Stanford Security Forum 2006
Incidental attacks (phishing, spam, worms, viruses, kiddies)
External, Targeted AttacksCompetitors (e.g. getloaded.com vs. truckstop.com)Idealists (e.g. SCO)
Insiders (29% of all attacks?)
Enterprise Threat Environment
2005 Stanford Security Forum 2006
Incidental attacks (worms, viruses, kiddies)External Targeted Attacks
More access to resourcesAbility to hire skilled attacker
Insiders (29% of all attacks?)Locality (access to internal network)Knowledge of internal workings
Enterprise Threat Environment
2005 Stanford Security Forum 2006
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 accessCannot limit availability of network resources
Goals: Map out operationsGain access to sensitive informationAbility to disrupt internal communications if needed
2005 Stanford Security Forum 2006
Step 1: ReconnaissanceNetcraft 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] [email protected]. HeL Lo at <[email protected] >Gin ( dot ) H ( dot ) Polka ( at ) bank ( dot ) COMCar Mc Kubrik · kubik AT NOSPAM bank dot comChris Finkledine at [email protected] Spade at [email protected]@bank.com
2005 Stanford Security Forum 2006
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 [email protected] 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 ...
2005 Stanford Security Forum 2006
Step 2: Contact
Post to forumEstablish rapportGet IM/emailWrite custom trojanSend infected file over IM, email, etc.
router
Alicebob
2005 Stanford Security Forum 2006
Step 3: Do Bad Stuff
Gather local informationLocal network parametersEmail addresses, documents etc.
Gain access to trafficSniffing (switches)Redirection (ARP, DHCP, DNS etc.)
Further attack through binary injectionRedirect + proxyMany vulnerable protocols(http, smtp, htp, nfs, SMB)
Determine DoS attack channels
router
Alicebob
2005 Stanford Security Forum 2006
Properties of the Attack
Does not require elite attackerSimple to launch by an insiderEffective against traditional perimeter security models
Difficult to stop with signature detectionWeak internal protection allows propagation of attack once inside
2005 Stanford Security Forum 2006
IP vs. Security
Overly permissive (e.g. broadcast on ARP request)
Many heavily trusted components (end-hosts, dhcp, dns, directory service, routers etc.)
IP addresses are meaningless (can be forged, stolen, changed etc.) (NOTE: very weak notion of identity)
No hiding of info (reconnaissance is easy)
No formal support for enforcing access controls
within a network
2005 Stanford Security Forum 2006
Retrofitting Security onto IPACLS or filtering rules at routerStatic ARP cache at routerPort security on switchStatic ARP cache on end-hostsSignature detectionProxies at choke points (full TCP termination)VLANs for isolation
Router
2005 Stanford Security Forum 2006
Common Solutions = Crummy Networks(and not-great security)
Inflexible Hard to move a machine
(yet difficult to know if someone has moved)Really difficult to deploy a new protocol
BrittleChange a firewall rule, break security policyAdd a switch, break security policy
Confusing Many disparate point solutionsState = a bunch of soft stateHard to state meaningful policies
Lose redundancyIntroduce choke pointsCan't migrate routes b/c of all the soft state
Strong coupling oftopology and securitypolicy
2005 Stanford Security Forum 2006
Argument Thus FarTargeted attacks can be quite effectiveIP not designed for attack resistance
permissiveMany trusted componentsUnauthenticated end-pointsNo attempt to control access to information
Attempts to retrofit access controls have resulted in less-than-ideal networks
2005 Stanford Security Forum 2006
Our Approach: Start from Scratch
Secure by designReduce trusted computing baseLeverage characteristics unique to Enterprise
Centrally managedKnown usersStructured connectivity
Simple policy declarationRetain flexibility and redundancy (decouple topology and security policy)
2005 Stanford Security Forum 2006
SANE(Secure Architecture for the Networked Enterprise)
Centrally declared policy defines all connectivityPolicy declared over users, services, hosts(e.g. Alice can access internal-web using http)
All communication requires permission (at the flow level)Users must authenticate before using networkNetwork information is tightly controlled
2005 Stanford Security Forum 2006
SANE:High-Level Operation
Publishmartin.friends.ambient-streamsallow tal, sundar, aditya
Authenticatehi, I’m tal, my password is
martin.friends.ambient-streamsRequestmartin.friends.ambient-streams
Global Network Policy:(allow all host all)
Authenticatehi, I’m martin, my password is
2005 Stanford Security Forum 2006
SANE:Component Overview
Domain Controller
Switches
End-Hosts
•Authenticates switches/end-hosts•Contains network topology•Computes routes•Handles permission checking for all flows
•Send network topology information to the DC•Provide default connectivity to the DC•Enforce paths created by DC•Handle flow revocation
•Publish services at the DC•Specify access controls(export streams.ambient allow tal)•Request access to services
2005 Stanford Security Forum 2006
Connectivity to the DC
Switches construct spanning treeRooted at DCSwitches don’t learn topology(just neighbors)Provides basic datagram service to DC
2005 Stanford Security Forum 2006
Establishing Shared KeysSwitches authenticate with DCand establish symmetric keyIke2 for key establishmentAll subsequent packets to DC have “authentication header”(similar to ipsec esp header)
Ksw1
Ksw2
Ksw3
Ksw4
Ksw1
Ksw3Ksw4
Ksw2
2005 Stanford Security Forum 2006
Establishing Topology
Switches generate neighbor listsduring MST algorithmSend encrypted neighbor-listto DCDC aggregates to full topologyNo switch knows full topology
Ksw1
Ksw2
Ksw3
Ksw4
Ksw1
Ksw3Ksw4
Ksw2
2005 Stanford Security Forum 2006
User AuthenticationDC creates route from itself to authentication serverUse third-party mechanism for user authentication
KerberosRadiusAD
DC places itself on-route for all authentication Snoops protocol to determine if authentication is successfulIdentifies user by location + networkidentifier (e.g. MAC address)
DC
Kerberos
2005 Stanford Security Forum 2006
Connection SetupSwitches disallow all Ethernet broadcast(and respond to ARP for all IPs)First packet of every new flow is sentto DC for permission checkDC sets up flow at each switchPackets of established flows areforwarded using multi-layerswitching
DC
<src,dst,sprt,dprt>
Alice Bob
<ARP reply>
?<src,dst,sprt,dprt>
2005 Stanford Security Forum 2006
Permission check before connectivitySimple mechanism Users only access resources they have permission toPolicy enforced at every switchAuthenticated end hosts (bound to location)High level policy declaration(topology independent)
Control information regardingpacket path, topology
Security Properties (revisited)
2005 Stanford Security Forum 2006
Central point for connection logging (DC)Addition of switches (redundancy) does not undermine security policyApplication-informed routingAnti-mobility
Other Nice Properties
2005 Stanford Security Forum 2006
Backwards compatibilityMiddlebox integrationPerformanceFault Tolerance
Managing the DC as a single point of failureAdaptive routing
Extensions and Considerations
2005 Stanford Security Forum 2006
Easing Deployment
Use trivial 2-port switches(bumps)
On links betweenEthernet switches
Can be enhanced by usingVLAN per port
2005 Stanford Security Forum 2006
Middle Box 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
2005 Stanford Security Forum 2006
Decouple control and data path in switchesSoftware control path (connection setup)(slightly higher latency)Simple, fast, hardware forwarding path (Gigabits)
Performance
Dest MAC Addrcheck
Flow Table
Broadcast
EncryptionForwarding
Software
Not Found
2005 Stanford Security Forum 2006
DC: Single Point of Failure?
Exists today (DNS)Permission check is fastReplicate DC
Computationally (multiple servers)Topologically (multiple servers in multiple places)
2005 Stanford Security Forum 2006
StatusBuilt software version of similar system (using capabilities)
All components in softwareRan in group network (7 hosts) 1 month
Currently in development of full systemSwitches in hardware + softwareDC using standard PC