Quarantining Process used by IT Staff Members

Introduction

Quarantining is the process of isolating or removing a system from Rice’s network. Systems are quarantined based on observed threats to other systems (Rice and/or non-Rice) or by direction from university officials (President’s Office, General Counsel’s Office, Rice Police Department, Human Resources, etc). All requests from non-Rice law enforcement agencies should go through the Office of the General Counsel.

Currently, the quarantining process involves disallowing a network device’s MAC address (a network device’s unique identification number) from traversing our networking hardware and disabling the physical network jack the device is plugged into.

This essentially isolates the network device from the rest of the Rice network.

Threats

Threat Observation

Threats are observed through passive scanning sensors on the network and reports from other Rice and non-Rice users and groups.

The sensors identify potential threats based on the observation of sudden, unexpected spikes in anomalous traffic from one or more hosts and traffic signatures matched to a known threat.

Other users and groups on campus also have systems that detect such traffic and report anomalies to the Information Security Office. The ISO responds to these reports after the anomalies are verified.

Threat Level Determination

The threat level is determined by the nature and severity of the observed traffic. If a system is observed in what appears to be an attack against multiple Rice and/or non-Rice systems, it is classified as a high-risk threat. If a system is simply observed with traffic with a known malicious signature, such as a virus infection, the system is classified as a low-risk threat.

Quarantine

Quarantine as Directed from University Officials

In rare circumstances, university officials may request that a system be quarantined or removed from the network. In each case, timeline and notification parameters will be determined by collaboration between the requestor and the Information Security Office.

Quarantine due to High-Risk Threats

Systems that are determined to be a high-risk threat are either immediately quarantined or otherwise removed from the network. The Information Security Office will notify the IT Support Provider and/or the Primary User as soon as they are identified.

Quarantine due to Low-Risk Threats

Systems that present a low-risk threat will be quarantined after an attempt is made to contact the IT Support Provider or Primary User of the system. The Information Security Office will allow three hours between attempted contact with the IT Support Provider/Primary User and the quarantine or removal from the network. If a contact for the system cannot be identified, the OIT Help Desk will be notified instead.

Exceptions

The systems are providing critical services, such as multi-user servers and workstations.

If possible, steps will be taken to keep critical services online while either containing or eliminating the malicious process(es) until the system can be taken down and remedied with less user impact.

Also, the Information Security Office will attempt to notify before the system is removed from the network; however, if a contact cannot be identified or a response has not otherwise been received, the system will be either quarantined or removed from the network immediately for high-risk threats and after three hours for low-risk threats.

The Information Security Office determines that the system should stay online as part of an investigation.

The Information Security Office is directed by a university official to keep a system online despite a threat.

Remediation

In the event the system was quarantined or removed from the network due to a system compromise:

Forensic analysis of the system must be performed to determine:

If anyone had personally identifying information that could have been compromised. If so, as per Texas State Law, those individuals must be identified and notified of the compromise and to what data the attacker had access (Texas Security Breach Notification Law - SB122).

If the system was part of a larger compromise. Information on the system may point to other systems that have not been identified and/or detected. If account information on the system was compromised, those with accounts on the system must be identified and instructed to change their passwords on all appropriate systems. A complete reload of the system must be performed.

An image of the system may be requested for further analysis and review before the system is reloaded.

The IT Support Provider will work with the Information Security Office on a timeline, including providing workarounds for mission critical systems and applications, as needed. In the event the system was quarantined or removed from the network due to a virus infection:

The responsible IT Support Provider must clear the infection from the machine before it can be allowed back onto the Rice network.

A complete reload of the system may be necessary if account or other personal information was compromised.

Examples

Example 1: SSH Scan

A system on the Rice network is detected actively scanning other Rice systems on tcp port 22, trying to log on repeatedly with multiple usernames and passwords faster than a person could do so.

As the system is actively attacking other systems, it is classified as high-risk. The Information Security Office has no documentation defining the system as a server; therefore, it is quarantined.

Immediately after, the Information Security Office attempts to call and email either the owner or the IT Support Provider for the system based upon its network address, indicating that the system has been quarantined for SSH scanning other systems on campus.

Remediation should include a forensic analysis, a reload of the system and all system passwords should be changed.

Example 2: DMCA

The General Counsel’s office receives official contact from a copyright holder that a Rice system has infringed upon that copyright by the unauthorized sharing of a movie in Divx format.

The system is quarantined. The user is referred to the appropriate judicial body.; Instructions regarding quarantine will be communicated to IT from the judicial body.

Example 3: Virus Infection

A system is detected with a virus through its connection to a site known to listen for successful infections.

The virus in question spreads via email and is not using the infected machine to attack other systems. The system is therefore considered a low-threat risk. The Information Security Office has no documentation defining the system as a server.

The Information Security Office attempts to call and email either the owner or the IT Support Provider for the system based upon its network address, indicating that the system will be quarantined for a virus infection in three hours if contact is not made.

Remediation should simply be either installing or updating the virus scan product.

Example 4: A Known Server Scanning SSH

A system on the Rice network is detected actively scanning other Rice systems on tcp port 22, trying to log on repeatedly with multiple usernames and passwords faster than a person could do so.

As the system is actively attacking other systems, it is classified as high-risk. The Information Security Office has documentation defining the system as a server; therefore, it is not immediately quarantined.

The Information Security Office attempts to call and email either the owner or the IT Support Provider for the system, indicating that the system has been observed SSH scanning other systems on campus.

Given that the system is a server, steps are taken to contain the infection while keeping the system online – port blocks are put in place to and from the system except what is determined to be necessary and the user community is notified.

A remediation plan is established, including a forensic analysis and a reload of the system. Also, users are forced to change their passwords as the system held local user accounts