Network Insecurity: challenging conventional wisdom

1
Network Insecuritychallenging conventional
wisdom

• Terry Gray
• UW Computing Communications
• 10 October 2000

2
Words to live by...

• 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

3
Start with a Security Policy

• Defining who can/cannot do what to whom...
• Identification and prioritization of threats
• Identification of assumptions, e.g.
• Security perimeters
• Trusted systems and infrastructure
• Policy drives securitylack of policy drives
  insecurity

4
Approaches

• Operational Issues
• Prevention
• Detection
• Recovery
• Policy Issues
• Risk Management
• Liability Management

5
Policy Priorities

• Education/Awareness Security is everyones
  responsibility there are no silver bullets.
• Standards and adequate resources for computer
  administration.

6
Technical Priorities

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

7
Network Security Axioms

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

8
The SCCA VPN Issue

• Problems with border-to-border VPNs
• Costs a lot doesnt improve security
• Advantages of end-to-end strategies
• Needed anyway
• Misconceptions about the Gigapop
• Is it really a public network?

9
Perimeter Protection Paradox

• Firewall perceived value is proportional to
  number of systems protected.
• Firewall effectiveness is inversely proportional
  to number of systems protected.

10
Network Risk Profile
11
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 administration...

12
When do VPNs make sense?

• When legacy apps cannot be accessed via secure
  protocols, e.g. SSH, SSL, K5.
• AND
• When the tunnel end-points are on or very near
  the end-systems.See also IPSEC enclaves

13
When does Firewalling make sense?

• Large perimeter
• To block things end-system administrators cannot,
  e.g. spoofed source addresses.
• When there is widespread consensus to block
  certain ports.
• Small perimeter/edge
• Cluster firewalls
• Personal firewalls

14
The Dark Side of Firewalls

• Large-perimeter firewalls are often sold as
  panaceas but they dont live up to the hype,
  because they
• Assume fixed security perimeter
• Give a false sense of security
• May inhibit legitimate activities
• May be hard to manage
• Won't stop many threats
• Are a performance bottleneck
• Encourage backdoors

15
Even with Firewalls...

• Bad guys arent always "outside" the moat
• One persons security perimeter is anothers
  broken network
• Organization boundaries and filtering
  requirements constantly change
• Security perimeters only protect against a
  limited percentage of threats must examine
  entire system
• Cannot ignore end-system management
• Use of secure applications is a key strategy

16
More words to live by...

• "It's naive to assume that just installing a
  firewall is going to protect you from all
  potential security threat. 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

17
Suggestions

• Do the application, host, and auth stuff.
• Try to cluster critical servers, then evaluate
  additional protection measures...
• Physical firewall protecting server rack?
• Local addressing NAT?
• IPSEC enclave?
• Logical firewall/Inverse VPN?
• Personal firewalls, e.g. ZoneAlarm?

18
Policy Procedure

• Need to work on policies, resources, and
  consensus (e.g. re tightening perimeters.)
• UW CC Efforts
• Dittrich Co.
• Trying to get more high-level support.
• Writing white papers.
• Pro-active probing.
• Security consulting services.
• IDS, attack analysis, etc.
• Virus scanning measures.
• Acquiring/distributing tools, e.g.SSH.
• Evaluating more aggressive port blocking.

19
Resources

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