Effective Incident Response Teams: Two Case Studies

1
Effective Incident Response Teams Two Case
Studies

• Tuesday, April 05, 2005
• 1000 a.m. - 1100 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.r
  eports/03hb002.html
• OReilly 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

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 teams interfaces widely

6
Issues for Higher Ed

• Dedicated Team?
• And whats 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
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_at_ou.edu
• http//cfl.ou.edu
• David Escalante, CISSP
• david.escalante_at_bc.edu