• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Network Security Principles

Network Security Principles






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Network Security Principles Network Security Principles Presentation Transcript

    • Network Security Principles & Practice for UW Medicine Terry Gray April 2004
    • 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
    • recent events
      • attacks
        • slammer (Jan 2003)
        • blaster (Aug 2003)
        • sobig (Sep 2003)
        • mydoom (Feb 2004)
        • witty (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
    • the problem
      • Design a network computing environment
        • with excellent security
        • excellent supportability
        • that users find reliable and responsive
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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.
    • 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
    • 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)
    • 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)
    • 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
    • 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
      • never underestimate non-technical barriers to progress
    • additional background
    • 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
    • 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.
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • history
    • 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
    • Network Security Trends High Low password guessing self-replicating code password cracking exploiting known vulnerabilities disabling audits back doors hijacking sessions sniffers packet spoofing automated probes/scans denial of service www attacks Attack Sophistication “ stealth” / advanced scanning techniques burglaries DDOS attacks Blended attacks Source: 1980 1985 1990 1995 2000
    • 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