Effective Incident Response Teams: Two Case Studies

1. Effective Incident Response Teams: Two Case Studies Tuesday, April 05, 2005 10:00 a.m. - 11:00 a.m. Imperial Room I (lower level) David Escalante, Director of Computer Policy & Security, Boston College Calvin Weeks, Director, OU Cyber Forensics Lab, University of Oklahoma

2. Summary • Why you need/want incident response • What is best practice • Problems with best practice for Higher Ed • OU established model • BC established model • Roles • What works and what does not

3. Why You Need Incident Response • Compliance with laws and regulations • Gramm-Leach Bliley Act (GLBA) • Sarbanes-Oxley (SOX) • Health Information Privacy Portability Act (HIPPA) • FERPA • Security improvement • Improve network and system uptime • What is an “incident” for the purposes of this presentation? • Strong incident response cultures • Government (in some places) • ISPs • Financials (recently) • ISACs

4. Resources • SEI/CERT • http://www.cert.org/csirts/Creating-A-CSIRT.html • http://www.sei.cmu.edu/publications/documents/03.reports/03hb002.html • O’Reilly book • FIRST: The Forum of Incident Response and Security Teams • http://www.first.org/ • RFC 2196, Site Security Handbook • RFC 2350, Expectations for Computer Security Incident Response • NIST • http://csrc.nist.gov/topics/inchand.html • NSA • Educause • http://www.educause.edu/Browse/645?PARENT_ID=660

5. Summary of Best Practices • Create a Dedicated team • Have clearly Defined roles • Build a formal Reporting structure • Write a series of Defined plans • Publish the team’s interfaces widely

6. Issues for Higher Ed • Dedicated Team? • And what’s your budget! • If team is multi-departmental, those politics come into play • Define Roles… • OK. Who will fill them? • Reporting Structure. • OK, but who is in charge or who has the authority? EDUs tend to be non-hierarchical • Defined Plans • The best laid plans are almost never followed. • Publish Contact & other Information • Communications channels in EDUs are diffuse • Audience is different technical levels

7. Oklahoma Structure

8. OU Iterative Approach • Phase one – 2001 • Assign Security Officer • Phase two – 2002 • Establish Computer Assessment Response Team (CART) • Phase three – 2002 • Established Field Security Officers (FSO) • Phase four – 2003 • Approved Computer Security Incident Response Team (CSIRT) • Phase five – 2003 • Established IT Service Centers • Phase six – 2004 • Established OU Cyber Forensics Lab (OUCFL)

9. BC Structure President

10. BC Iterative Approach • Phase 1 - 2002 • Senior Management recognizes need for security office due to serious computer security incident • Phase 2 - 2003 • Office of Computer Policy & Security established and staffed • Phase 3 - 2003 • Create “best practice” style incident response team • Phase 4 - 2004 • Refine team based on real-world experience • Phase 5 - 2005 • Re-define incidents and response based on cultural issues on campus, moving toward universal culture of security

11. Phase 3 -- 2003 • Use the resources on the earlier slide to define Computer Security Incident Response Team (CSIRT) • And immediately run into problems • Everyone wanted to be on the team • Management vs. practitioners issue • When a real incident came up, didn't need whole team, and sometimes needed other resources not on team • Lack of tools in an incident • Team runs into exhaustion, lack of interest, or both

12. Phase 4 -- 2004 • Stop using formal team from Phase 3 • Resolve management vs. practitioner issue by setting up senior management team interface with intermediary to incident team • Security group declares team in the course of declaring incident • Clarify responsibilities (Security is the boss) • Flexibility and understanding of process is more important than who's doing what role in a given incident -- in our last major incident, CIO was boss, not Security, all worked the same since everyone understood roles and just people were swapped

13. Phase 5 -- 2005 • Security group has too many incidents to make progress on other, strategic tasks • Need to empower other parts of IT and university to run “minor” incidents • Framework and tools for doing this • Improve incident reporting such that we achieve better coverage and more accurate classification • Improve initial handling of people and technology issues when incident occurs

14. OU Workflow

15. OU Roles • CART – Executive oversight • Service Centers – Direct Customer Support during incident • Security Team – Handle and execute security response plan • FSO – Coordinate with response efforts • OUCFL – Perform any forensics, investigations, and/or law enforcement communications. • CSIRT – is the handbook that we use only as a reference and guide.

16. 80% 40% Quantitative Reactive 20% 10% 5% COSTS and Resource Utilization 5% 80% 40% 20% 10% 10% 20% 80% 40% 5% 5% 10% 20% Proactive Qualitative 40% 80% OU Response Cost Relation Model Security Model and Posture

17. What works/does not work? • User is very happy • Easier to track response capability • Large or sensitive incidents is a new learning process every time • Better control over desired actions or reactions to the incident • Sometimes the whole process is slower than desired • Better and more information is achieved

18. Questions Calvin Weeks, EnCE, CISSP, CISM OU Cyber Forensics Lab cweeks@ou.edu http://cfl.ou.edu David Escalante, CISSP david.escalante@bc.edu