I-CSIRT: Iowa Computer Security Incident Response Team

Version 6.1, updated 6/28/2011

Overview of the I-CSIRT Program

The effective coordination and resolution of security incidents is dependent on an appropriate combination of people, technology and processes.  Staff must understand their role in the response of computer security incidents, be appropriately trained, and must be empowered to perform their responsibilities.   Technology brings an essential toolset for intrusion prevention, intrusion detection, and the appropriate monitoring and tracking of incidents.   The process elements described herein are the crux of incident response, and include event categorization, assessment, response, and reporting procedures. 

I-CSIRT’s Mission

The philosophy behind the formation of a computer security incident response capability is to plan for adverse events in advance.  When an attack occurs or is in progress, many decisions must be made quickly.  Having a predetermined course of action, and the capability to invoke it in a timely manner, provides for an appropriate, efficient, and thorough response.
Documentation is essential, so that all involved parties know who to contact, how to contact them, and what their individual responsibilities are.  Policies of The University of Iowa and The University of Iowa Hospitals and Clinics must be communicated so that all parties know what to do when an event or crisis occurs.

Program Goals

  1. Assure the availability and integrity of (life) critical systems. Preventing loss of human life is always the highest priority.
  2. Maintain and restore institutional data and computer services.  Protecting the irrecoverable loss of sensitive, confidential or proprietary information and preventing damage to systems which can result in costly down time and recovery time is essential.
  3. Determine how an incident event occurred. Providing direct technical assistance to local staff as needed to perform forensic analysis to aid the recovery process as well as prevention of future incident events. 
  4. Avoid escalation and/or propagation of events. The timely detection of security incident events will significantly reduce the seriousness and probability of collateral spread.  Facilitating the timely, centralized reporting of incidents is critical.
  5. Avoid negative publicity. Efficient incident handling minimizes the potential for negative exposure to the media, reduces the risk of legal consequences, and also reduces the possibility for negative customer perception.

I-CSIRT Processes

1. Notification of Computer Security Incidents
Everyone in the University community needs to know who they need to contact upon detection (or suspicion) of a computer security incident.  A security incident is defined as an adverse event in relation to the security of computer systems or computer networks. Examples of security incidents are:

  • Intrusion of computer systems via the network (often referred to as “hacking”)
  • Occurrence of computer malware (a virus, worm, or Trojan program)
  • Probes for vulnerabilities via the network to a range of computer systems (often referred to as “scans”)
  • Denial of service attacks (lack of network or system response)
  • Breach of information security (account compromise)
  • Inappropriate information leakage or destruction (data compromise)   

The proper channels for notification of the involved parties are necessary so that a timely response can be initiated.  In all cases, the first thing that anyone associated with the University must do when they suspect a computer security incident event has occurred or is underway is to REPORT THE PROBLEM.

  1. Faculty, staff, and students must report unusual computer activity to their Supervisor or to the ITS Help Desk, and to the Information Security and Policy Office.
  2. Supervisors and Technical System Administrators must report all computer security incident events directly to the Information Security and Policy Office.
  3. If an event occurs after normal business hours and that appear to be an active threat, affect a mission-critical system, or have campus-wide scope, the I-CSIRT should be contacted using the after-hours procedures outlined below.

It is better to report activity that turns out to be harmless, than to ignore suspicious activity that causes damage because you aren’t sure if it “means anything”.

2. Verification of Incident Event and Categorization
When first notified of an event, Information Security and Policy Office (ISPO) staffs take steps to verify the existence of the incident, its extent, and to notify appropriate contacts within the University as well as others affected by the incident.  Normally, this responsibility rests with the Security Office.  After normal business hours, the I-CSIRT may also provide contact coverage.
If the source of the incident information is unfamiliar or not trusted, the ISPO will verify the report, especially if the source has identified themselves as a representative of a legal or investigative agency.  Verification will be firsthand, if possible, to ensure that the incident is not a harmless misunderstanding or even a hoax. The ISPO and/or the I-CSIRT will have resources available to be aware of false alarms and other activity that may only resemble something more serious.

3. Scope and Boundaries
Once the incident is verified, the ISPO (and if necessary the I-CSIRT) will be responsible to determine its scope, and to set a priority for the incident.  Identification of an incident event is certainly the key to invoking a response.  Evaluating the scope and impact of the problem must be the first priority thereafter.  Correct identification of the boundary of an incident is necessary to effectively respond; otherwise, duplication (or lack) of effort or other unnecessary or inappropriate actions are likely to occur. The impact of an incident determines its priority for allocation of resources to resolve it; without an accurate and timely assessment it’s difficult to determine the correct response.  A set of criteria must be defined to properly evaluate and set the scope and boundary for incident events.
Criteria to indicate a CRITICAL (Level 1 or Level 2 Priority) event:

  • Is this a multi-site event? How many computers are involved or affected? How many users?
  • Is sensitive, confidential, or proprietary information involved?  Personally identifiable health information? Social Security numbers? Credit card numbers?
  • Is a critical business function or application involved?
  • What is the entry point of the incident event? (network, local computer, etc)
  • Is the media (press) involved?
  • What is the potential damage of the incident event?
  • Is the event in progress?  Are intruders logged in?  Is there current network activity?

Responsibility for evaluating the scope and boundary for an incident event rests with the ISPO and with the I-CSIRT.  The ISPO has responsibility to make a quick assessment of an incident and invoke the help of the I-CSIRT if necessary.  The ISPO and the I-CSIRT will also work with local technical staff and other appropriate personnel as necessary to assign a priority level for the incident event.

I-CSIRT Incident Priorities:

Priority Level General Description
1 An active (in-progress) threat;
Involves a mission-critical system, sensitive data, or has campus-wide scope

Threat is not currently active (was discovered after the fact);
Involves a mission-critical system, sensitive data, and/or has campus-wide scope


An active (in-progress) threat;
Involves non-critical system(s), or is not affecting all of campus


Threat is not active; No critical systems are involved, and/or does not affect a large percentage of campus systems 




The following persons will be notified immediately:

University Chief Information Security Officer, Jane Drews

Associate VP and University Chief Information Officer, Steve Fleagle

Associate VP and Chief Information Officer, UI HealthCare, Lee Carmen

The I-CSIRT team will be gathered to work in conjunction with the ISPO, Department Network Security Contacts (NSC’s), and local technical support, as necessary to resolve level 1 or 2 priority incidents.

The I-CSIRT team will also be available as a resource to assist with diagnosis of problems at level 3 and 4 priorities, as necessary.




4. Reporting Structure and Methods
The existence of reporting and communications structures within The University of Iowa and the Hospitals and Clinics make it most feasible for the I-CSIRT and its activities to be distributed among several locations and units of the University. In particular, the I-CSIRT will be comprised of representatives from:

  • Information Security and Policy Office
  • ITS Enterprise Infrastructure – Systems, Networking 
  • Healthcare Information Systems – Security, Systems, Help Desk, and Networking 
  • ITS Enterprise Services – Help Desk   
  • Other members will be recruited on an as needed basis.

The ISPO will coordinate all contacts with Department of Public Safety, external Law Enforcement, University Legal Counsel, and University Vice President for Strategic Communications.

Points of Contact:                   Method:

I-CSIRT membership - contact the ISPO 
Local technical staff Department Network/Security Contacts (NSC) Lookup:
NSC-[buildingcode]@list.uiowa.edu  (insert UI building code)
NSC-ALL@LIST.UIOWA.EDU  (all NSC contacts)
Infrastructure technical staff it-security@uiowa.edu  (335-6332)
its-helpdesk@uiowa.edu (384-4357, 335-5550)
helpdesk-hcis@uiowa.edu (335-6500) 
Administrative staff, Supervisors https://www.dna.its.uiowa.edu/Whitepages/
Investigative/Law Enforcement University Police 335-5022, 911, or dial 195 in the UI Hospitals & Clinics
Iowa City Police Department: dial 911
Federal Bureau of Investigation   1-866-483-5137 or via https://tips.fbi.gov/
University General Counsel Phone: (319) 335-2841
Office of Strategic Communication Phone: (319) 384-0005
Other sites which may be affected Contact the network technical contact for the site (determined using the “whois” command), or contact via the “abuse@site” standard email address

The ISPO and I-CSIRT will respect the confidentiality of incident event information. However, affected parties must be advised that they may be under other obligations (legal, policy) for reporting which override privacy considerations.

5. Response to the Event
The response to an event will fall into the general categories of containment, eradication, recovery, and follow-up. 

The purpose of containment is to limit the extent of an attack.  An essential part of containment is decision making (e.g., determining whether to shut a system down, to disconnect from a network, to monitor system or network activity, to set traps, to disable functions on a system, etc).  Sometimes this decision is trivial; shut the system down if the system is classified or sensitive, or if proprietary information is at risk!  In other cases, it may be worthwhile to risk having some damage to the system if keeping the system up might enable you to identify an intruder.  The ISPO and I-CSIRT will assist with containment activities as necessary.

Once the incident has been contained, the cause must then be discovered and eradicated.  This usually requires an analysis and diagnosis of what occurred on or to the system, potentially using forensic techniques and/or preservation of evidence. What files were modified, added, or removed; processes that have changed or been added, accounts that have been tampered with, and so on. In addition, the vulnerability that was exploited must be determined.  Finally, the changes as well as the vulnerability must be removed.  The ISPO (and if it becomes necessary the I-CSIRT) will assist with analysis and diagnosis of the attack, and to determine the vulnerability that was exploited.

Once the cause of an incident has been eradicated, the recovery phase defines the next stage of action.  The goal of recovery is to return the system to normal.  Local service providers or system owners are responsible for all recovery activities.

Follow-Up (De-Brief) for Priority 1 and 2 Incidents
Post-incident activities should include an examination of how the incident started: which vulnerabilities were exploited, how access was gained, and other relevant details; how the ISPO and/or I-CSIRT became aware of the incident; how the incident was resolved; whether existing procedures were adequate or require updating; whether vulnerabilities still need to be closed; and whether new contacts were made.
As a result of a post-incident analysis, the ISPO may issue alerts, warnings, or recommendations to the University about certain actions to take to reduce vulnerabilities that were exploited during the incident.

6. Incident Log Records & Reporting
Information in the ISPO and/or I-CSIRT incident logs is helpful for establishing contacts, piecing together the cause, course, and extent of an incident, and for post-incident analysis and a final assessment of damage. Additionally, if there are prosecutions, the information might be used as evidence. An incident log should minimally contain the following information:  actions taken, with times noted; all conversations, including the person(s) involved, with the date and time, and a summary; and all system events and other pertinent information such as audit logs.

Incident Response Data Base
The Incident Response Data Base (IRDB) for tracking security incidents has been implemented in a tool called Request Tracker.  The base system has been modified to insert fields that are specific to our tracking processes and information needs.

The IRDB system uses header tags similar to e-mail headers. Each incident queue corresponds to an email account.  Tickets may be updated by specifying the Incident Ticket Number in the subject line of an email message in the format “[IRDB #nnn]” where nnn is the target ticket number.


7.  The I-CSIRT Team

Member Responsibilities

  • Communicate about problems, know all communication paths
  • Identify/scope problems, assist with classification
  • Provide assistance to control/contain incidents
  • Provide assistance with analysis/diagnosis of problems (level 1 & 2 priority)
  • Be available in a crisis situation, after hours if necessary
  • Sign confidentiality agreement, respect privacy/confidentiality of incident information at all times
  • Participate in (level 1 & 2 priority) incident de-brief activities, develop incident post mortem reports
  • Monitor the recovery stage of incidents, as needed
  • Log all activity in IRDB system
  • Obtain permission from department to participate 
  • Recommend corrective actions to prevent incident reoccurrence
  • Attend regular I-CSIRT team meetings

Member Qualifications 

  • Full-time University Staff  in an IT position
  • Experience in system administration, networking, and/or information security, or a combination
  • Available in emergency if needed
  • Permission from employing department

After-Hours Support Contact Procedures:

  1. Call the ITS Help Desk at 384-4357, select the emergency option, and ask the attendant to page the Information Security & Policy Office person on call.  
  2. Call the HCIS Mainframe Operations at 356-0001 and ask the attendant to page the Healthcare Information Security person on call. 
  3. Send email message to it-security@uiowa.edu

1.  John P. Wack, Establishing a Computer Security Incident Response Capability, NIST Special Publication 800-3, November, 1991.  http://cs-www.ncsl.nist.gov/secplcy/rfc1244.txt
2.  P. Holbrook, and J. Reynolds, RFC:1244, Site Security Policy Handbook, July 1991.
3.  The SANS Institute, Computer Security Incident Handling, Step by Step, version 1.5, May 1998.
4.  http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=6305 Carnegie Mellon Software Engineering Institute, Handbook for Computer Security Incident Response Teams,  April 2003.
5. PDF icon I-CSIRT Flow Chart