Cybersecurity Summit 2004: Conclusions and Recommendations Tom Bettge and Ginger Caldwell Scientific Computing Division National Center for Atmospheric Research Boulder, CO USA 23 March 2005

Overview l l Motivation for Cybersecurity Summit 2004 (CSS 2004) –Unauthorized and unprecedented intrusion into numerous university and federally funded research computer systems –FBI Case 216 –NSF’s concern about cybersecurity for projects and facilities l By invitation only –120 participants –Systems and security professionals –Center Management –End Users …..in a confidential setting.

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

23 March 2005 Program Committee l Tom Bettge, ChairNCAR l RuthAnne BevierCalifornia Institute of Technology l Ginger Caldwell NCAR l Walter Dykas Oak Ridge National Laboratory l Victor Hazlewood SDSC l Chris Hempel Texas Advanced Computer Center l Jim Marsteller PSC l Marla Meehl NCAR l George Strawn NSF l John Towns NCSA l Howard Walter National Energy Research Scientific Computer Center

23 March 2005 Attendance by Agency/Job Duty

23 March 2005 Attendance from Geographic Region

23 March 2005 CSS 2004 Breakout Group Topics l l User Policies/Education l l System Admin Policies/Education l l Network Based Intrusion Detection l l Host Based Intrusion Detection l l Grid Security

23 March 2005 CSS 2004 Common Themes l l Incident Response l l Training and Education l l Security Planning l l Future Meetings

23 March 2005 Incident Response Conclusions l Widespread nature caused by collaborative relationships, yet communication between labs was deficient l Trust relationships between labs/centers was weak –Timely response was inhibited by easily determined, trusted contacts l Responses to intrusion events must be coordinated

23 March 2005 Incident Response Recommendations l For incident reporting and tracking, a contact model is needed to bring multi-agency security teams together l Site: Security starts at home…….local sites need to establish incident response link on web for incident reporting l 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

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

23 March 2005 Training and Education Recommendations l Case 216 can/should be used to heighten awareness and foster acceptance of need for education l NSF should explore, in conjunction with its community, methods to provide security training in an efficient and cost effective manner. l 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

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

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

23 March 2005 Future Meetings l Face-to-face meetings of security professionals, users, management, and agency program managers are valuable and should continue. –…not incident based! l NSF and other agencies should sponsor an annual event to provide forum for establishing and maintaining trust infrastructure. …but avoid duplication with existing forums!

23 March 2005 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.

23 March 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 % right -- how can we possibly expect Joe User to?

23 March 2005 Final Comments l l User Awareness / Education –security of wireless –basic connection to VPN l l 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

23 March 2005 End