Incident Handling and Response and Security Risk Assessment and Analysis

EDUCAUSE Security Conference: Incident Tracking and Reporting

Created by Lida L. Larsen (EDUCAUSE) on April 20, 2007
Summary
Incident Tracking and Reporting
Kathy Bergsma, University of Florida
Joshua Beeman, University of Pennsylvania
 
2007 EDUCAUSE Security Professionals Conference
Thursday, April 12, 2007
Denver, CO
 
Notes:
 
Kathy Bergsma reported on the UFL environment.

UFL has more than 50K students and is decentralized.
 
The first thing UFL tracks is the current contacts for security incident reporting.
It includes network managers, server managers, information security managers and administrators and others.
 
UFL has created an incident response standard that describes 8 response steps from discovery to resolution, establishes an incident response team, defines team and unit responsibilities, and sets up specific procedures for different types of incidents. It is available online at http://www.it.ufl.edu/policies/security/uf-it-sec-incident-response-rewrite.html
 
What UFL tracks:
  • incident identification sources such as IDS (Intrusion Detection System), Email abuse complaints, flow data, and honeypots (decoys)
  • critical elements such as IP address, unit, type, severity, containment and resolution times
 
Various options and tools are available for ticket creation when incidents are identified and the UFL incident response team receives daily reports on open tickets. In addition, bi-weekly automated reminders for open tickets are sent to their owners. The centralized unit enters a ticket from the point of discovery via IDS (currently using Dragon but switching to Snort)   The decentralized unit has access to enter updates on to the ticket thereafter. Everything is done via the web.
 
Vulnerability detection is done with continuous Nessus top-20 scans and the results are tracked in SQL.   They are able to find the weak spots in their systems and compare data from year to year. The hardware for this is distributed across three machines and takes up to 3 days for a complete scan.
 
Individual unit reports are generated each semester that compare the unit to the 5 most active units in regard to number of incidents, number of incidents adjusted for unit size, average number of days to contain incidents, number of critical vulnerabilities, and number of critical vulnerabilities adjusted for unit size. No unit wants to be in the top 5 group which are highlighted in bright primary colors that draw attention to their security issues. The report also posts the number of each incident type and the comparison to the previous semester.