Incident Response Process

A Computer Security Incident occurs when a computer system, a network service, or data is altered, disrupted, abused, or exposed in any way that is a violation of security policy or privacy policy. Such an Incident may occur maliciously or by accident.

Security and Privacy Policies for the University of South Carolina are defined in the following documents:

• IT 1.06 (www.sc.edu/policies/it106.html) - Network Access and Acceptable Use
• BUSF 4.11 (www.sc.edu/policies/busf411.html) - Credit/Debit Card Processing Policy
• ACAF 7.02 (www.sc.edu/policies/acaf702.html) - Data Access Policy

Below is a brief outline and flow of the 6 steps of computer security incident response:

Step 1 – Preparation

During the preparation phase, the IT Security Office, in conjunction with the rest of the University community, makes sure that our designated controls (e.g., policies, standards, guidelines, procedures, hardware controls, software controls, physical controls, etc.) are in place and functioning. These preparatory actions will limit the confusion, disorganization, and panic that accompanies a typical computer security incident.

Step 2 – Identification

Identification procedures determine if a computer security incident has actually occurred. These procedures are designed to identify what the nature of the incident is, the extent of the incident and any additional information needed to begin containment of the incident. Identification usually begins when the IT Security Office notices something odd on a computer or the network and begins to investigate (in conjunction with other University offices), or when the IT Security Office receives an incident notification from an external entity.

As soon as enough verifiable information is collected, the IT Security Office initiates communications with the owner or sponsor of the impacted system and other University officials, as appropriate. If, or when, it is determined that sensitive data is involved, the appropriate data stewards and University officials are immediately notified.

Step 3 – Containment

Containment procedures attempt to actively limit the scope and magnitude of the attack. Any available means will be employed to prevent further compromise of University assets, as deemed appropriate by University officials, and in conjunction with the affected University offices. This can include, but is not limited to, blocking the compromised system at the network level, physically unplugging the compromised system, or otherwise removing access to the compromised service. Every reasonable effort will be made to coordinate containment efforts with the system owner or sponsor, as well as affected customers.

Step 4 – Eradication

This is the step where the IT Security Office, in conjunction with other University offices, will try to eliminate the cause of the incident and generally improve our defenses. The IT Security Office will also perform a deeper analysis of the compromise at this point, which may include a forensic examination. Additional remediation steps are employed as appropriate, such as changing passwords and performing vulnerability assessments to validate our desired security posture. If additional or new evidence is discovered during this phase, it may be necessary to return to Step 2.

Step 5 – Recovery

During the recovery phase, affected services and systems are restored to a functional and trusted state. Special care must be taken during this step to not create, or reintroduce, vulnerabilities that may facilitate another compromise. The following additional actions may also be necessary, depending on the nature of the incident: 1. Notification letters should be sent out to individuals whose personally identifiable information may have been compromised. 2. A frequently asked questions website for the incident should be created. 3. An incident hotline should be created and staffed.

Step 6 - Lessons Learned

Once the incident has passed, this phase becomes the most important part of the incident response process. An incident report should be generated by the IT Security Office, which will include details of the incident, as well as the lessons learned in order to preserve the knowledge. Once the report is complete, all stakeholders should meet to discuss the findings, what went wrong, and what could be done better in the future.