Cybersecurity Summit 2004: Conclusions and Recommendations

1
Cybersecurity Summit 2004Conclusions and
Recommendations

• Tom Bettge and Ginger Caldwell
• Scientific Computing Division
• National Center for Atmospheric Research
• Boulder, CO USA

23 March 2005
2
Overview

• Motivation for Cybersecurity Summit 2004 (CSS
  2004)
• Unauthorized and unprecedented intrusion into
  numerous university and federally funded research
  computer systems
• FBI Case 216
• NSFs concern about cybersecurity for projects
  and facilities
• By invitation only
• 120 participants
• Systems and security professionals
• Center Management
• End Users

..in a confidential setting.
3
Goals of CSS 2004

• Share information on Case 216
• Explore needs of maintaining open, collaborative
  research environment while protecting the
  integrity of computing assets
• Develop and/or enhance communication via trust
  relations
• Develop secure computing environments while
  evaluating the impact on researchers, the
  computers, and the network
• Discuss different needs/requirements between
  centers

4
Program Committee

• Tom Bettge, Chair NCAR
• RuthAnne Bevier California Institute of
  Technology
• Ginger Caldwell NCAR
• Walter Dykas Oak Ridge National Laboratory
• Victor Hazlewood SDSC
• Chris Hempel Texas Advanced Computer Center
• Jim Marsteller PSC
• Marla Meehl NCAR
• George Strawn NSF
• John Towns NCSA
• Howard Walter National Energy Research
  Scientific Computer Center

5
Attendance by Agency/Job Duty
6
Attendance from Geographic Region
7
CSS 2004 Breakout Group Topics

• User Policies/Education
• System Admin Policies/Education
• Network Based Intrusion Detection
• Host Based Intrusion Detection
• Grid Security

8
CSS 2004 Common Themes

• Incident Response
• Training and Education
• Security Planning
• Future Meetings

9
Incident Response Conclusions

• Widespread nature caused by collaborative
  relationships, yet communication between labs was
  deficient
• Trust relationships between labs/centers was weak
• Timely response was inhibited by easily
  determined, trusted contacts
• Responses to intrusion events must be coordinated

10
Incident Response Recommendations

• For incident reporting and tracking, a contact
  model is needed to bring multi-agency security
  teams together
• Site Security starts at home.local sites need
  to establish incident response link on web for
  incident reporting
• Site Create incident response plan as part of
  comprehensive security policy
• Procedure to notify users/customers
• Procedure for notifying peer sites
• Define protocol to alerting legal authorities
• Instructions on public relations issues

11
Training and Education Conclusions

• Users
• passwords are weak
• understanding of risks and protection is poor
• Systems Administrators only slightly better than
  user understanding of security
• Intrusion events usually exploit known and
  patchable vulnerabilities, and could be prevented
• Education needed by systems administrators,
  users, and center management

12
Training and Education Recommendations

• Case 216 can/should be used to heighten awareness
  and foster acceptance of need for education
• NSF should explore, in conjunction with its
  community, methods to provide security training
  in an efficient and cost effective manner.
• Site Develop a comprehensive security plan
• security education
• strong security policies and enforcement
  mechanisms that sufficiently gain the attention
  of all personnel
• develop plan in collaboration with peer centers

13
Security Planning Conclusions

• Current security activities are primarily
  reactive
• Planning should begin at system design and
  installation
• Case 216 revealed need for better intrusion
  monitoring and logging
• need effective and efficient forensic analysis
• automated!
• Grid amplifies existing security issues, rather
  than creating new ones
• e.g., local sites likely to strengthen firewalls

14
Security Planning Recommendations

• NSF should impose security requirements on grant
  awards
• include a security plan and a security budget
• NSF should fund study to investigate replacements
  for passwords which are user friendly
• careful about One Time Passwords (OTP)
• NSF should increase support (find balance?) for
  security tool development
• automated security tool development
• Community should build cooperation relations with
  firewall/router vendors to address common needs

15
Future Meetings

• Face-to-face meetings of security professionals,
  users, management, and agency program managers
  are valuable and should continue.
• not incident based!
• NSF and other agencies should sponsor an annual
  event to provide forum for establishing and
  maintaining trust infrastructure.

but avoid duplication with existing forums!
16
From a CSS Participant
Near the end of the second day in DC, it occurred
to me that, hey, here's a room full of
security-minded people, so I bet we're batting
close to (if not at) 100 in the non-sniffability
game. So I fired up a copy of tcpdump just to
check ...
There were numerous unencrypted connections to
pop and imap and smtp servers..perhaps they were
using PGP-encryption.even so, I've got
hostname, username, password information that
quite a few people used to identify themselves to
their mail servers.
17
..and it gets worse..
But wait, it gets a lot worse. There were three
telnet sessions active one was to a host at a
supercomputing center, and one of the others was
to a machine in the army.mil domain!
If we, individuals with an expressed interest in
computer security, can't get it right -- 100
right -- how can we possibly expect Joe User to?
18
Final Comments

• User Awareness / Education
• security of wireless
• basic connection to VPN
• Security Enterprise Service
• simplify techno-jargon
• simplify the procedures
• The problem of secure computing in an open
  environment with many users is unsolved, and it
  appears to be quite hard. The best we can hope
  for is gradual mitigation, converging on a safer
  world.
• Bill Cheswick

19
End