I-CERT: Iowa Computer Emergency Response Team
Version 4.3, updated 4/15/2004
Overview of the I-CERT Program
The effective coordination and resolution of security incidents is dependant 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-CERT’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
-
Assure the availability and integrity of (life) critical systems. Preventing loss of human life is always the highest priority.
-
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.
-
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.
-
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.
-
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-CERT 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 viruses (an “infection” by 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)
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.
-
Faculty, staff, and students must report unusual computer activity to their Supervisor, to their Help Desk, or to the Information Technology Security Office.
-
Supervisors and Technical System Administrators must report all computer security incident events directly to the Information Technology Security Office.
-
If an event occurs after normal business hours that appears to be an active threat, affect a mission-critical system, or have campus-wide scope, the I-CERT should be contacted immediately.
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 Technology Security Office (ITSO) staff will 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-CERT may provide contact coverage.
If the source of the incident information is unfamiliar or not trusted, the ITSO 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 ITSO and the I-CERT 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 ITSO (and if necessary the I-CERT) 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?
- Is a critical business function or application involved?
- What is the entry point of the incident event? (network, phone line, 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 both the ITSO and with the I-CERT. The ITSO has responsibility to make a quick assessment of an incident and invoke the help of the I-CERT if necessary. The ITSO and the I-CERT will also work with local technical staff and other appropriate personnel as necessary to assign a priority level for the incident event.
I-CERT Incident Priorities:
Priority Level |
General Description |
1 |
An active (in-progress) threat; Involves a mission-critical system or has campus-wide scope |
2 |
Threat is not currently active (was discovered after the fact); Involves a mission-critical system and/or has campus-wide scope |
3 |
An active (in-progress) threat; Involves non-critical system(s), or is not affecting all of campus |
4 |
Threat is not active; No critical systems are involved, and/or does not affect a large percentage of campus systems |
MANAGEMENT CHAIN OF COMMAND FOR PRIORITY 1 and 2 INCIDENTS:
The following persons will be notified immediately:
University Chief Information Officer, Steve Fleagle
Information Technology Security Officer, Jane Drews
Director of HealthCare Information Systems, Lee Carmen
The I-CERT team will be gathered to work in conjunction with the ITSO, Department Network Security Contacts (NSC’s), and local technical support, as necessary to resolve the level 1 or 2 priority incidents.
The I-CERT team will be available as a resource to assist with diagnosis of problems at level 3 and 4 priorities, only 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-CERT and its activities to be distributed among several locations and units of the University. In particular, the I-CERT will be comprised of staff from the Information Technology Security Office, the Health Care Information Systems department, the ITS Telecommunications and Networking Services department, the ITS Systems and Platforms department, and the HCIS Telecommunications department. The managers of the two primary University Help Desks will also be represented in the team. Several other members will be recruited on an as needed basis. The ITSO will coordinate all contacts with Law Enforcement, Legal Counsel, and University External Relations.
Points of Contact: Method:
I-CERT membership - |
Request Tracker E-Mail Queues: |
Local technical staff |
Department Network/Security Contacts Lookup: http://www.its.uiowa.edu/cio/itsecurity/nsc/main.asp NSC-uibuildingcode@list.uiowa.edu All Department Network/Security Contacts: |
Infrastructure technical staff |
security@uiowa.edu (335-6332) its-helpdesk@uiowa.edu (384-4357, 335-5516) helpdesk-hcis@uiowa.edu (335-6500) hcis-itsecurity@uihc.uiowa.edu After Hours, call 384-4357, select emergency option, and ask the attendant to contact the IT Security Office. |
Administrative staff, Supervisors |
|
Investigative/Law Enforcement personnel |
UI Department of Public Safety 335-5022, 911, or dial 195 within the UI Hospitals & Clinics. Iowa City Police Department: 911 Federal Bureau of Investigation 1-866-483-5137 or via https://tips.fbi.gov/ |
Phone: (319) 335-2841 |
|
University External Relations |
Steven Parrott 335-0552 |
Vendors, Service Providers |
Iowa Communications Network, ? |
Community users (faculty, staff, students) |
nsc-all@list.uiowa.edu (Security Contacts) helpdesk-announce@list.uiowa.edu (Interested Users) ui-netfolks@list.uiowa.edu (Network Contacts) |
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 ITSO and I-CERT will at all times 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.
Containment
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 such as remote file transfer on a UNIX system, etc). Sometimes this decision is trivial; shut the system down if the system is classified or senstive, 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 ITSO and I-CERT will assist with containment activities as necessary.
Eradication
Once the incident has been contained, the cause must then be eradicated. This usually requires an analysis and diagnosis of what occurred on or to the system. 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 ITSO and I-CERT will assist with analysis and diagnosis of the attack, and to determine the vulnerability that was exploited, as necessary.
Recovery
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 ITSO and I-CERT 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 ITSO may issue alerts, warnings, or recommendations to the University about certain actions to take to reduce vulnerabilities that were exploited during the incident. The I-CERT may also need to update its Operations Handbook to reflect new procedures.
6. Incident Log Records & Reporting
Information in the ITSO and/or I-CERT 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 the I-CERT will be involved in potential prosecutions, the information might also 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 helpdesk tracking tool called Request Tracker. The base system has been modified to insert fields that are specific to our tracking process. The following is an overview of how to access and use the system.
SYSTEM VIEWS: There are four ways to access the system.
The first is the full graphical user interface, at https://irdb.its.uiowa.edu:8083/ This view requires a username and password and is not currently tied into Hawk ID authentication.
The second method is to access the system via e-mail. This view only allows tickets to be created or updated and will be explained in detail in the EMAIL section.
The third and fourth methods are view only web pages that are designed to allow the helpdesk and the general public to see very specific pieces of each ticket.
The helpdesk view is password protected and is located at
https://irdb.its.uiowa.edu:8083/NoAuth/helpdesk/index.html
The public view is open to anyone on campus and can be seen at http://cio.uiowa.edu/ITsecurity/incident/ports.shtml
EMAIL:
The IRDB system uses header tags similar to e-mail headers. Each incident queue corresponds to an email account, as described below. 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. The following headers are accepted and processed by the IRDB system. Each of these tags has values that will be parsed by the IDRB system. The information should start right after the colon without a space in between.
EMAIL CODE DESCRIPTIONS:
X-Status: new = This is the default status
open = A ticket receives this status after it is modified.
closed = The ticket should be resolved
resolved = Same as closed
X-IP: This is a free form field that will accept the standard IP notation.
X-Room: This is a free form field that will accept an alphanumerical room number.
X-Building: This is a fixed field that only accepts known U of I mail routing building codes
X-Location:This is a free form field that will accept an alphanumerical department name
X-MAC: This is a free form field that accepts a MAC address separated by either a colon or dash.
X-Port: This is a free form field that accepts our standard port notation
(usb-3@6/1 or usb-3@Fa3/3).
X-NBT: This is a free form field that accepts an alphanumeric NetBIOS name.
X-USER: This is a free form field that accepts an alphanumeric User or Administrator name.
X-Category: abuse = Typically for illegal activities (Email Harassment, Fraud, etc)
bandwidth = Excessive use of network resources
compromise = A machine showing signs of unauthorized users, services, or data
dmca = Copyright infringement complaints
dos = Denial of Service Attacks (network attacks)
misuse = Policy issues, possibly affecting the network or security that aren’t technically banned but are
causing problems (Bit Torrent, Kazaa, P2P)
spam = unsolicited or commercial email complaints
theft = Theft of physical property (computers, network equipment)
virus = Malicious code such as virus or worm infections (Sobig, etc)
scan = port scanning (usually looking for vulnerabilities to exploit.)
X-HawkID: This is a free form field that accepts an alphanumeric Hawk ID (university identifier) account.
X-Restricted:This is a flag to indicate privacy issues (confidential information is in the record.)
QUEUES:
RESNET – All tickets that involve student machines located in the residence halls.
CAMPUS – All tickets in the university’s 128.255 network except for those servicing the Residence halls. These tickets are assigned to the IT Security Office.
HOSPITAL – All tickets in the university’s 129.255 network, associated with the University of Iowa Hospitals & Clinics. These tickets are assigned to the HCIS helpdesk and HCIS Telecommunications.
OFFCAMPUS- This queue is used to send reports of off campus machines that are attacking resources here on campus. These reports usually result from IDS or other system logs.
VIEW SECURITY:
GUI- each authorized user of the system is granted access to one or more queues, and all details and data fields associated with tickets housed in that queue. Authorized users may or may not have read/modify/delete authority to records in each queue based on their role in the institution. All members of the I-CERT team will have full access to all records and queues.
EMAIL – only individuals authorized to send email into the RT system may do so. This precaution was designed to prevent flooding the system with tickets, and from sending duplicate, erroneous, or “spam” to the system.
HELPDESK WEB – individuals employed in the ITS help desk may view many details regarding incidents contained in the RESNET and CAMPUS queues. They are not authorized to see tickets in the HOSPITAL queue.
CAMPUS WEB – this limited view is IP restricted to campus and hospital network addresses. It is designed to facilitate communication about network ports (jacks) which have been disabled from the network for security (administrative) reasons.
7. The I-CERT 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-CERT team meetings
Member Qualifications
-
Full-time University Staff in an IT position
-
Experience in system administration, networking, and/or information security, or a combination
-
Successfully completed the Modular Information Security Training Course
-
Available in emergency if needed
-
Permission from employing department
Appendix I:
I-CERT members contact information (Use iowa-cert@list.uiowa.edu for group contact)
Name |
Phone |
|
Jane Drews |
jane-drews@uiowa.edu |
335-5537 |
Robert Vinson |
robert-vinson@uiowa.edu |
335-5484 |
Steve Schallau |
steven-schallau@uiowa.edu |
356-1210 |
Rick Deerberg |
rick-deerberg@uiowa.edu |
356-8245 |
Jason Smith |
jason-smith@uiowa.edu |
356-0078 |
ITS Systems (TBD) |
||
AJ Klopp |
aj-klopp@uiowa.edu |
335-5016 |
Charlie McGuire |
charles-mcguire@uiowa.edu |
335-6144 |
Tracy Scott |
tracy-scott@uiowa.edu |
384-0771, 384-4357 |
HCIS Helpdesk (TBD) |
, 335-6500 |
|
Jason Alexander |
jason-alexander@uiowa.edu | 356-0071 |
At-Large (TBD): |
||
At-Large (TBD): |
||
At-Large (TBD): |
After-Hours Support Procedures:
-
Call the ITS Help Desk at 384-4357, select the emergency option, and ask the attendant to page the networking person on call.
-
Call the HCIS Mainframe Operations at 356-0001 and ask the attendant to page the HCIS Telecommunications person on call.
-
Send email message to the iowa-cert@list.uiowa.edu
On-call Networking staff will determine if the situation warrants (immediate) contact of I-CERT members, and if so, will contact IT Security Office personnel.
Appendix II:
Supporting Documents:
Information Technology Security Incident Escalation Policy: http://cio.uiowa.edu/Policy/IT-Security-Incident-Escalation.shtml
Network Citizenship Policy: http://cio.uiowa.edu/Policy/NetworkCitizenship.shtml
USA Patriot Act information: http://cio.uiowa.edu/itsecurity/usapatriot-at-ui.shtml
Defense-in Depth White Paper
Program Resources:
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
P. Holbrook, and J. Reynolds, RFC:1244, Site Security Policy Handbook, July 1991.
The SANS Institute, Computer Security Incident Handling, Step by Step, version 1.5, May 1998.
http://www.cert.org/archive/pdf/csirt-handbook.pdf
Carnegie Mellon Software Engineering Institute, Handbook for Computer Security Incident Response Teams, April 2003.