Security Incident Response

University Security Incident Response Procedure

Identification:

Potential security incidents are identified by Network Engineering using information from the following sources:

1. Contact from victims: Computer owners or network administrators notify Network Engineering that a computer on the Tufts University network is the source of a Denial-of-Service (DoS) attack, vulnerability scan, or other form of unauthorized access.
2. Contact from system owners: A user or system administrator of a computer system on the Tufts University network contacts Network Engineering and reports indications that his/her system has been compromised. Alternately, system administrators from remote sites may contact Network Engineering with reports that systems under their control have been compromised, and forensic analysis revealed that they had been used to launch attacks against systems on the Tufts University network.
3. Trouble reports/passive monitoring: Complaints about network performance or routine network analysis may reveal excessive or suspicious traffic originating from one or more computers on the Tufts University network.
4. Report compromised machines or suspicious behavior to abuse@tufts.edu. Please include your computer's IP, MAC address, logs of the behavior, your name, phone number, department, date and time of the problem and let us know if this is a critical machine.

Assessment:

Once a potential problem has been identified, Network Engineering staff will analyze it and attempt to confirm that it actually is the result of a security incident. This may include traffic flow recording, packet capture and/or contacting the owner of the affected system(s). This allows Network Engineering to determine the likelihood that a security incident has actually occurred and what level of threat it poses to the network as a whole. Occasionally, this process will result in very brief interruptions of network service, but Network Engineering will make every effort to minimize these. Incidents can be broadly categorized as:

1. Compromised computer is actively causing wide-spread problems or affecting a number of non-Tufts networks or computers. Alternately a computer is transferring confidential or sensitive information to an unauthorized user.
2. Computer is compromised and critical to the business functions of Tufts but is not actively causing problems.
3. DMCA violation is reported to Tufts.
4. Computer is believed to be vulnerable to a known exploit.

Response:

Once a security incident has been positively identified, Network Engineering will act to isolate the affected machine(s). Compromised hosts are often the source of DoS attacks, which greatly degrade the performance of the Tufts University network, and can also be used as launching points for attacks against other systems, potentially opening the university to legal liability. Consequently, Network Engineering must act to remedy security problems immediately.

Depending on the nature of the incident, the Security Officer may be required to work with law enforcement.

Notification:

1. In the case of a compromised computer that is actively causing wide-spread problems or affecting non-Tufts networks or computers, Network Engineering staff will block the computer from the network then notify the contacts.

   Network Engineering staff will first notify the primary contact of the compromised machine. If the primary contact is unavailable or does not provide a timely response, then Network Engineering will attempt to notify the secondary contact.For student owned computers, Network Engineering will notify TOL or OIT via the ticketing system and annotate the Cardinal entry with the ticket number.

2. In the case of a critical computer which is compromised but not actively causing problems, Network Engineering staff will first notify the primary contact of the compromised machine and request that he/she remove it from the network. If the primary contact is unavailable or does not provide a timely response, Network Engineering will attempt to notify the secondary contact. If this also fails, Network Engineering will block access to the computer or disconnect it from the network, as the situation and network infrastructure capabilities permit. In those rare instances when a group feels that the system should not be removed from the network, a variance may be requested and the request will be reviewed by the Vice President for Information Technology and the appropriate information technology administrator for the unit, department or school that made the request.
3. DMCA violations result in the computer being placed in the restricted class. Network Engineering will notify TOL, OIT or ITS as appropriate and annotate the Cardinal entry with the ticket number.
4. When internal security scans reveal that a computer may be vulnerable to a known exploit, Network Engineering staff will notify the primary contact with instructions and a timeline for securing the vulnerability. Timelines will vary depending on the severity of the exploit and how many times the primary contact has already attempted to correct the problem.

Followup:

Once the computer has been disconnected from the network, it is then the owner's responsibility to reformat disks and/or reinstall software on the machine and take any other steps necessary to secure it from future attacks. Instructions for handling and recovering from a compromise which reference standard industry practices are available at Guidelines for handling a compromise.

In cases of DMCA violations, the University's Policy on Fair Use of Copyrighted Material requires "the violator to correct any infringement" and states that the university "may impose disciplinary action on the responsible party." With regard to students, schools retain the right to impose disciplinary action.

Once the computer is secured, the owner should contact Network Engineering, who will then allow it to be reconnected to the network. At this point, a security scan will be run to verify that the system has been secured. Results will be forwarded to the requesting party.

Refusal or official non-compliance by the system's owner will be dealt with on a case-by-case basis, as prescribed by the principles set forth in the Responsible Use Policy.

Concerns:

Please email any concerns or comments to security_officer@tufts.edu.

Revisions:

In order to stay current with the changing security environment, the University Computer Security Incident Response Procedure is subject to revision. Before any such changes take effect, a request for comments will be made to the relevant information technology groups (USG, NOS, SAT, ITC). The current version of the procedure will be posted this location in the Policies and Standards section of the UIT website.