Transcript ppt

University of Washington
Computing & Communications
Network Security Principles &
Practice for UW Medicine
Terry Gray
April 2004
University of Washington
Computing & Communications
executive summary
•
•
•
•
•
•
•
conflicting goals: security, usability, supportability
network availability depends on host security
still no substitute for proper host management
perimeter defense is a two-edged sword
inline subnet firewalls are especially problematic
essential to focus on security and supportability
recommend balanced approach to provide security
with minimum collateral damage
2
University of Washington
Computing & Communications
recent events
• attacks
–
–
–
–
–
slammer
blaster
sobig
mydoom
witty
(Jan 2003)
(Aug 2003)
(Sep 2003)
(Feb 2004)
(Mar 2004)
• impact
–
–
–
–
demise of the open/transparent/deterministic Internet
demise of the network utility model
demise of the unmanaged/autonomous PC
demise of reliable email
3
University of Washington
Computing & Communications
the problem
Design a network computing environment
– with excellent security
– excellent supportability
– that users find reliable and responsive
4
University of Washington
Computing & Communications
institutional success criteria
•
•
•
•
•
•
•
•
•
nobody gets hurt, nobody goes to jail
low legal/regulatory costs
low identity theft, loss of privacy
low lost productivity
low life-cycle cost
quick to diagnose/fix
flexible connection security/transparency choices
avoidance of unfair cost-shifting
minimal user confusion
5
University of Washington
Computing & Communications
operational success criteria
• simplicity
– lower cost
– higher MTBF
– lower MTTR
• consistency
– deterministic outlet behavior (Network Utility Model)
– connection transparency (open/deterministic Internet)
– easier problem diagnosis
6
University of Washington
Computing & Communications
conflicting perspectives
• system administrator view
– some prefer local control/responsibility
– some prefer central/big-perimeter defense
– some underestimate cost impact on others
• user view
– want just enough openness to run apps
– prefer “unlisted numbers”?
• network operator view
– concerned about increased support costs and repair
times due to growing complexity and unpredictability
– concerned about loss of network functionality 7
University of Washington
Computing & Communications
generic security toolkit
•
•
•
•
•
•
•
•
•
•
host choice: truly thin clients; species diversity
host configuration management
conventional firewalls
logical firewalls
private addressing (e.g. project 172)
IDS, IPS, ADS
vulnerability scanning, anti-virus tools
QoS (to protect critical traffic types)
isolated networks (physical, VLAN, VPN)
non-technical: policies, education, staff
8
University of Washington
Computing & Communications
UW lines of defense
•
•
•
•
•
•
•
network isolation for critical services
host integrity (Make the OS net-safe)
host perimeter (integral ACLs/firewalling)
cluster/lab perimeter (sanctuary, FW, LFW)
network zone perimeter (P172, FW)
real-time attack detection and containment
user education
9
University of Washington
Computing & Communications
perimeter firewalls
•
•
•
•
•
•
•
•
•
•
•
increase time-to-infection
increase time-to-repair
provide defense-in-depth
may look like a broken network to users
are defeated by a single hacked host
are defeated by tunneling/encryption
often give a false sense of security
encourage backdoors
may be a performance bottleneck
may inhibit legitimate activities, innovation
create a vulnerability zone that is hard to protect:
– vpns, laptops, wifi, usb drives, social engr attacks
– the more you depend on perimeter defense, the more
you must invest in defending the perimeter
10
University of Washington
Computing & Communications
operational impact by firewall type
•
•
•
•
•
•
host -- best case; user interaction w/FW possible
cluster -- no impact on net diagnosis “beyond”
logical -- low impact on basic net diagnosis
subnet -- impacts almost all diagnosis
zone -- impacts inter-zone diagnosis
border --impacts inter-enterprise diagnosis
NB: cost of maintaining firewall config depends on who
is doing it, and how many rules/exceptions there are. 11
University of Washington
Computing & Communications
preserving the network utility model
•
•
•
•
•
goal: consistent behavior across outlets
importance: improves MTTR
status: at risk
problem: conflict with perimeter security?
options for NUM-friendly perimeter defense:
– Logical Firewalls
– Project 172
• barrier: security based on static IP addresses
– requires host & table updates for network changes
– sDHCP project will help to avoid touching each host
12
University of Washington
Computing & Communications
recommendations
• data defense
– secure application protocols (SSH, SSL, K5, RDP)
– transport encryption (e.g. IPSEC)
– backups
• host defense
– central configuration management (enforcing good
passwords, disabling unneeded services, auditing)
– host-based firewalls
– p172 addressing (with NAT or web proxy)
– vulnerability and AV scanning
– honeypots, IDS, ADS
• perimeter defense
– cluster/lab firewalls
– logical firewalls (LFW)
– medical center zone (p172, FW)
13
University of Washington
Computing & Communications
anti-recommendations
• Avoid inline subnet firewalls
– Why? Impact on MTBF, MTTR (try LFWs or cluster FWs)
• Avoid individual IP-based filtering
– Why? Doesn’t scale; impedes network upgrades
• Avoid perverting network topology to match
organizational boundaries
– Why? VLAN complexity increases MTTR
• Avoid simple solutions that are too simple (OSFA)
– Why? Unfair cost-shifting
• Avoid VPNs exporting protected address space
– Why? VPN = attack gateway (use RDP, SSH, SSL, K5, SSL VPNs)
14
University of Washington
Computing & Communications
next-gen med net architecture
 parallel networks; more redundancy
 supportable (geographic) topology
 med ctr subnets = separate backbone zone
 perimeter, sanctuary, and end-point defense
 higher performance
 high-availability strategies
 Workstations spread across independent nets
 Redundant routers
 Dual-homed servers
15
University of Washington
Computing & Communications
key lessons














network reliability & host security are inextricably linked
$ for $, best security investment is central host management
five 9s (5 min/yr) is hard (unless we only attach phones?)
controlling “inside” access is hard --hublets, wireless, laptops, VPNs
even host firewalls don’t guarantee safety
perimeter firewalls may increase user confusion, MTTR
perimeter firewalls won’t stop next-generation attacks
it only takes one compromise inside to defeat a firewall
Nebula existence proof: security in an open network is possible
DDOS attacks: defense-in-depth is a Good Thing
security via individual static IP configuration does not scale well
NAT survives pending a better “unlisted number” mechanism
security/liability trumps innovation/philosophy/ops costs
16
never underestimate non-technical barriers to progress
University of Washington
Computing & Communications
additional background
University of Washington
Computing & Communications
context: a perfect storm










increased dependence on network apps
decreased tolerance for outages
decades of deferred maintenance...
inadequate infrastructure investment
some old/unfortunate design decisions
some fragile applications
fragmented host management
increasingly hostile security environment
increasing legal/regulatory liability
importance of research/clinical leverage
18
University of Washington
Computing & Communications
seven security axioms
1. Network security is maximized
when we assume there is no such thing.
2. Large security perimeters mean large vulnerability zones.
3. Firewalls are such a good idea,
every computer should have one. Seriously.
4. Remote access is fraught with peril, just like local access.
5. One person's security perimeter is another's broken network.
6. Private networks won't help (Limits of isolation).
7. Network security is about psychology as well as technology.
19
University of Washington
Computing & Communications
design tradeoffs
 networks = connectivity; security = isolation
 fault zone size vs. economy/simplicity
 reliability vs. complexity
 prevention vs. (fast) remediation
 security vs. supportability vs. functionality
(conflicting admin, ops, user perspectives)
 policy control via host address vs. enet jack
 differences in NetSec approaches relate to:
 Balancing priorities (security vs. ops vs. function)
 Local technical and institutional feasibility
20
University of Washington
Computing & Communications
design tradeoff examples
• defense-in-depth conjecture (for N layers)
– Security:
MTTE (exploit)
 N**2
– Functionality: MTTI (innovation)  N**2
– Supportability: MTTR (repair)
 N**2
• Perimeter Protection Paradox (for D devices)
– Firewall efficiency/value  D
– Firewall effectiveness  1 / D
• border blocking criteria (OSFA policy)
– Threat can’t reasonably be addressed at edge
– Won’t harm network (performance, stateless block)
– Widespread consensus to do it
• security by IP address
21
University of Washington
Computing & Communications
limits of isolation:
attack gateways
 hosts connected to two different networks can
become attack gateways between the two
 example: home PCs with VPN connection to
protected network
 safer remote access: SSH, SSL, K5, RDP, SSL VPNs
22
University of Washington
Computing & Communications
med center zone perimeter
• purpose
–
–
–
–
–
time to defend against zero-day events
protect the otherwise unprotected
defense-in-depth
reduced annoyance/noise traffic
DOS attack mitigation
• options
– conventional inline firewall
– private addressing + NAT or proxies
– both
23
University of Washington
Computing & Communications
protecting non-fixable devices
 FDA-approved devices, printers, etc
 protection options (besides zone perimeter):
 private addressing
 individual firewall, VPN, or NAT box ($25 - $2500)
--depending on performance requirements
 cluster/lab perimeter firewalls
 logical firewalls
24
University of Washington
Computing & Communications
NOC view of firewall approaches
EPFW = End-Point Firewall
LFW = Logical Firewall w/masquerading NAT
SFW = Subnet Firewall
BZFW = Border or Zone Firewall
P172 = Project 172-phase III (Private addresses with NAT)
IDEAL EPFW LFW P172 SFW BZFW
Policy Enforcement Point?
Host Host Subnet Zone Subnet Zone
Requires host reconfigure?
No
Yes
Yes
Yes
No
No
Requires network reconfig?
No
No
No
No
Yes
Yes
Destroys E2E transparency?
No
No
No
No
Yes
Yes
Assured NOC access to switches? Yes Yes Yes
Yes
No*
No*
User sees why app failed?
Yes
Yes
No
No
No
No
NOC-Predictable semantics?
Yes
No
No
Yes
No
No
Inherent "unlisted number"?
No
Yes
Yes
No
No
"unlisted number" possible?
Yes Yes
Yes
Yes
Yes
Yes
Adverse impact on internal
network troubleshooting:
Low Low Med
Med
High
Low
Adverse impact on external
network troubleshooting:
Low Low Med
Med
High
High
Size of vulnerability zone:
Small Small Med
Large Med
Large
* Can be mitigated by proper access lists and/or OOB connectivity
University of Washington
Computing & Communications
history
26
University of Washington
Computing & Communications
UW network security chronology
•
•
•
•
•
•
•
•
•
•
•
•
•
1988: Five anti-interoperable networks
1994: Nebula shows network utility model viable
1998: Defined OSFA border blocking policy
2000: Published Network Security Credo
2000: Added source address spoofing filters
2000: Proposed separate medical center network zone
2000: Proposed server sanctuaries
2001: Ban clear-text passwords on C&C systems
2001: Proposed pervasive host firewalls
2001: Developed logical firewall solution
2002: Developed Project-172 solution
2003: Slammer, Blaster… death of the open Internet
2003: Begin work on flex-net architecture
27
University of Washington
Computing & Communications
Network Security Trends
“stealth” /
advanced scanning
techniques
denial of service
Attack
Sophistication
High
Low
sniffers
back doors
disabling audits
Blended
attacks
DDOS
wwwattacks
attacks
automated probes/scans
packet spoofing
hijacking
burglaries sessions
exploiting known vulnerabilities
password cracking
self-replicating code
password guessing
1980
1985
Source:
1990
1995
2000
28
University of Washington
Computing & Communications
impact of recent security events
•
•
•
•
•
•
•
•
•
•
•
•
more perimeter firewalls (demise of open Internet, NUM)
more VPNs
more tunneling (“firewall friendly” apps)
more encryption (thanks to RIAA)
more collateral damage (from attacks & remedies)
worse MTTR (complexity, broken tools)
constrained innovation (e.g. p2p, voip)
cost shifted from “guilty” to “innocent”
pressure to fix computer security problems in network
pressure for private nets
pressure to make network topology match org boundaries
blaster: triggered more perimeter defense, but showed
weakness of conventional perimeter defense
29