Open Network Security or

1
Open Network Security or closed network
insecurity?

• Terry GrayDirector, Networks Distributed
  Computing
• 14 March 2002

2
UW Environment

• 1.5 B/yr enterpise (75 research/clinical)
• 55,000 machines
• Infinite variety and vintage of computers
• Incredibly complex/diverse org structure
• Relatively little centralized desktop mgt
• Every depts middle name is Autonomous
• CC provides core I.T. infrastructure
• Depts responsible for end-system support

3
Conventional Security Wisdom

• Popular Myth The network caused the problem,
  so the network should solve it So good
  security depends on
• border firewalls
• border VPNs
• Unpopular Reality In a large, diverse
  organization such as UW, security is not achieved
  by either one.

4
Unconventional Security Wisdom

• If you think technology can solve your security
  problems, then you don't understand the problems
  and you don't understand the technology. Bruce
  Schneier
• Secrets and Lies

5
Grays Network Security Axioms

• Network security is maximizedwhen we assume
  there is no such thing.
• Firewalls are such a good ideaevery host should
  have one. Seriously.
• Remote access is fraught with periljust like
  local access.

6
Perimeter Protection Paradox

• Firewall perceived value is proportional to
  number of systems protected.
• Firewall effectiveness is inversely proportional
  to number of systems protected.
• Probability of compromised systems existing
  inside
• Lowest-common-denominator blocking policy

7
Credo

• Open networks
• Closed servers
• Protected sessions

8
Security Elements

• Architectural
• Authentication Authorization
• Encryption
• Packet filtering
• Operational
• Prevention
• Detection
• Recovery
• Policy
• Risk Management
• Liability Management

9
Start with a Security PolicyNow theres an
idea...

• Define who can/cannot do what to whom...
• Identify and prioritize threats
• Identify assumptions, e.g.
• Security perimeters
• Trusted systems and infrastructure
• Hardware/software constraints
• Block threats or permit good apps?
• Minimize organizational distance between policy
  definition, configuration, and enforcement points

10
Network Risk Profile(notwithstanding recent SNMP
exploits)
11
Heroic (but futile) Endeavors

• Getting anyone to focus on policies first
• Getting any consensus on border blocking
• Patching old end-systems
• Pretending that clients are only clients
• Securing access to older network gear

12
Bad Ideas

• Departmental firewalls within the core.
• VPNs only between institution borders.
• Over-reliance on large-perimeter defenses...e.g.
  believing firewalls can substitute for good
  host/application administration...

13
Good Ideas

• Two-factor authentication
• End-to-End encryption IPSEC
• End-to-End encryption SSH/SSL/K5
• Proactive vulnerability probing
• Centralized desktop management service
• Latest OS versions (w/integral firewalls)
• Bulk email virus scanning
• Server sanctuaries
• Logical firewalls

14
Jury Still Out

• Intrusion Detection Systems
• DDoS trackers
• Thin Clients

15
When do VPNs make sense?

• E2E
• Whenever config cost is acceptably small
• Non-E2E
• When legacy apps cannot be accessed via secure
  protocols, e.g. SSH, SSL, K5.and
• When the tunnel end-points are very near the
  end-systems.

16
Where do firewalls make sense?

• Pervasively (But of course we have a firewall)
• For blocking spoofed source addresses
• Small perimeter/edge
• Cluster firewalls, e.g. server sanctuaries, labs
• OS-based and Personal firewalls
• Large perimeter/border
• Maybe to block an immediate attack?
• Maybe if there is widespread consensus to block
  certain ports? (Aye, and theres the rub)
• And then again, maybe not...

17
Fundamental Firewall Truths...

• Bad guys arent always "outside" the moat
• One persons security perimeter is anothers
  broken network
• Organization boundaries and filtering
  requirements constantly change
• Perimeter defenses always have holes

18
The Dark Side of Border Firewalls Its not just
that they dont solve the problem very well
large-perimeter firewalls have serious
unintended consequences

• Operational consequences
• Force artificial mapping between biz and net
  perimeters
• Catch 22 more port blocking -gt more port 80
  tunneling
• Cost more than you think to manage MTTR goes up
• May inhibit legitimate activities
• Are a performance bottleneck
• Organizational consequences
• Give a false sense of security
• Encourage backdoors
• Separate policy configuration from best policy
  makers
• Increase tensions between security, network, and
  sys admins

19
Mitnicks Perspective

• "It's naive to assume that just installing a
  firewall is going to protect you from all
  potential security threats. That assumption
  creates a false sense of security, and having a
  false sense of security is worse than having no
  security at all."Kevin Mitnick
• eWeek 28 Sep 00

20
Do You Feel Lucky?

• QUESTION If a restrictive border firewall
  surrounds your --and 50,000 other-- computers,
  should you feel safe?
• ANSWER Only if you regularly win the lottery!

21
Distributed Firewall Management

• Given the credo of
• Open networks
• Closed servers
• Protected sessions
• What about all the desktops?
• Organizations that can tolerate a restrictive
  border firewall usually centrally manage
  desktops
• Thus, they can also centrally configure
  policy-based packet filters on each desktop and
  dont need to suffer the problems of border
  firewalls
• Centrally managing desktop firewalls possible
  even if desktops generally unmanaged

22
UWs Logical Firewall

• If edge and/or E2E protection isnt possible, and
  the idiots running the net wont help
• Plugs into any network port
• Departmentally managed
• Opt-in deployment
• Doesnt interfere with network management
• Uses Network Address Translation (NAT)
• Intended for servers can be used for clients
• Web-based rules generator
• Gibraltar Linux foundation

23
Server Sanctuaries

• Cluster sensitive/critical servers together
• But dont forget geographic-diversity needs
• Then provide additional logical and physical
  security

24
Technical Priorities

• Application security (e.g. SSH, SSL, K5)
• Host security (patches, minimum svcs)
• Strong authentication (e.g. SecureID)
• Net security (VPNs, firewalling)

25
Policy Procedure

• Policy definition enforcement structure
• Education/awareness its everyones job
• Standards and documentation
• Adequate resources for system administration
• High-level support for policies
• Pro-active probing
• Security consulting services
• IDS and forensic services
• Virus scanning measures
• Acquiring/distributing tools, e.g. SSH

26
Risk Liability Issues

• Liability over network misuse?
• Policies define acceptable use
• Post-audit strategy for enforcement
• Wireless perimeter control?
• Are networks an attractive nuisance?
• Risk of server compromise?
• Strong preventive stance
• Pre-audit via proactive probing
• Greater sensitivity -gt greater security

27
Reality Check

• John Gilmore The Internet deals with censorship
  as if it were a malfunction and routes around it
• Isnt this also true of other forms of
  policy-based restrictions, including Kazaa
  clamping and border port blocking?

28
Inverted Networks

• New trend in big companies (e.g. DuPont)
• Ditch the border firewall
• Assume LANs are dirty
• Use VPNs from each workstation to servers
• Hey, an open network, with closed servers and E2E
  encryption!
• Why didnt we think of that? )

29
Worrisome Trends

• Increasing sophistication of attacks
• Increasing number of attacks
• Tunneling everything thru port 80
• Partially connected Internets
• Increasing complexity anddiagnostic difficulty

30
Encouraging Trends

• Enterprise decision makers are engaged
• Vendors are paying more attention
• Software is slowly getting better
• ?

31
Conclusions

• Central network services think of as an ISP
• Conventional wisdom wont work in our world
• Border firewalls can actually be harmful
• We cant afford to settle for fake security
• There are no silver bullets
• The hardest problems are non-technical
• Its still going to be a long, up-hill battle
• Dont forget disaster preparedness and recovery
  (e.g. High-Availability system design)

32
Resources

• http//staff.washington.edu/gray/papers/credo.html
  
• http//staff.washington.edu/corey/fw/
• http//staff.washington.edu/dittrich
• http//www.sans.org/