Introduction
This document describes the response and escalation procedures for vulnerability management of hosts connected to the University of Waterloo campus network.
Definitions
The university's vulnerability management solution, QualysGuard, has five vulnerability severity levels (1 through 5), and three vulnerability types:
Documentation from Qualys defines the severity types and levels as follows:
Confirmed vulnerabilities
A Confirmed Vulnerability is a design flaw or misconfiguration which makes your host(s) and/or sub-network susceptible to malicious attacks from local or remote attackers. Depending on the severity of the security risk, a successful exploitation of a Confirmed Vulnerability can vary from the disclosure of information to a complete compromise of the host.
| Severity level | Description |
|---|---|
| 5 - Urgent | Intruders can easily gain control of the host, which can lead to a complete compromise any user account/host/network interacting with the host. |
| 4 - Critical | Intruders can possibly gain control of the host, or there may be potential leakage of highly sensitive information. |
| 3 - Serious | Intruders may be able to gain access to specific information stored on the host, including security settings. This could result in potential misuse of the host by intruders. |
| 2 - Medium | Intruders may be able to collect sensitive information from the host. With this type of information, intruders can easily exploit known vulnerabilities specific to software versions. |
| 1 - Minimal | Intruders can collect information about the host and may be able to use this information to find and exploit other vulnerabilities. |
Potential vulnerabilities
A Potential Vulnerability is a vulnerability that QualysGuard cannot confirm exists. In these cases, at least one necessary condition for the vulnerability is detected. The only way to verify the existence of this type of vulnerability would be to perform an intrusive scan, which could result in a denial of service - an unacceptable collateral risk. Instead, potential vulnerabilities need to be investigated further.
| Security Level | Description |
|---|---|
| 5 - Urgent | If the vulnerability exists, intruders can easily gain control of the host, which can lead to a complete compromise any user/host/network interacting with the host. |
| 4 - Critical | If the vulnerability exists, intruders can possibly gain control of the host or there may be potential leakage of highly sensitive information. |
| 3 - Serious | If the vulnerability exists, intruders may be able to gain access to information stored on the host, including security settings. This could result in potential misuse of the host by intruders. |
| 2 - Medium | If the vulnerability exists, intruders may be able to collect sensitive information from the host. With this type of information, intruders can easily exploit known vulnerabilities. |
| 1 - Minimal | If the vulnerability exists, intruders can collect information about the host and may be able to use this information to find and exploit other vulnerabilities. |
Information gathered
Information Gathered is a vulnerability that includes visible information about the network related to the host, such as traceroute information, Internet Service Provider (ISP), or a list of reachable hosts. Information Gathered issues include Network Mapping data, such as detected firewalls, SMTP banners, or a list of open TCP services.
| Severity | Description |
|---|---|
| 3 - Serious | Intruders may be able to detect highly sensitive data, such as global system user lists. |
| 2 - Medium | Intruders may be able to determine the operating system running on the host and view banner versions. |
| 1 - Minimal | Intruders may be able to retrieve sensitive information related to the host, such as open UDP and TCP services lists, and firewalls. |
Assumptions and expectations
Information Systems & Technology (IST), in meeting its responsibility for campus network management, will provide a mechanism for system managers to maintain up-to-date email contact information and security classification label for each IP address (block) that is assigned. IST will use this contact information for notification of discovered vulnerabilities.
System managers are expected to keep email contact information current using the IST-provided mechanism(s). Systems managers, as information custodians, are also expected to label hosts that store and/or process Restricted or Highly Restricted information using the IST-provided mechanism.
System managers are expected to apply security patches for application and operating system software on a regular basis. Applying patches to production systems introduces some risk, which is mitigated by testing. To allow time for testing, and allowances for service windows, it is acknowledged that it may take as long as 3 weeks for a new security patch to be applied to a system.
Vulnerability alerting and escalation procedure
This procedure applies only to confirmed and potential vulnerabilities that have been publicly known for longer than three weeks unless there is evidence that attempts are being made to exploit a particular vulnerability.
- IST will periodically scan the university campus network for security vulnerabilities.
- For each host (i.e., IP address) where a vulnerability is discovered, a report will be emailed to the email address on record that outlines any vulnerabilities found, the severity level of the vulnerabilities, and remediation information.
- Staff in the IST Security Operations Centre (SOC) will track discovered vulnerabilities.
- Systems managers who receive reports of vulnerabilities are expected to act, within the appropriate escalation threshold, to acknowledge the notification and remediate the vulnerability. If the system manager feels that remediation is not possible within the current escalation window, the system manager will notify the SOC that this is the case as soon as possible. The SOC will then immediately notify the Director, Information Security Services for follow-up.
- Vulnerability notifications that remain unaknowledged within the escalation threshold will be escalated by the SOC.
- The SOC will not escalate if it is determined and confirmed that the discovery is a false positive as a result of a problem with the scanning software. False positives will be reported immediately to the Director, Information Security Services by the SOC.
- Unless instructed otherwise by the Director, Information Security Services or the Associate Provost, IST, if a host remains vulnerable after the second escalation, SOC staff will take steps to disconnect or otherwise isolate the vulnerable host from the campus network.
Escalation thresholds (confirmed and potential vulnerabilities)
| Information Classification Level | Vulnerability Severity Level | Time Before Escalation To Next Level |
|---|---|---|
| Highly Restricted | >2 | 2 business days |
| Any | 5 | 2 business days |
| Restricted | 4 | 2 business days |
| Confidential or Public | 4 | 2 weeks |
| Not Highly Restricted | 4 weeks |
Note: Any discovered vulnerability that exposes confidential information will be treated as a computer security incident.
Escalation levels
| Escalation Level | Description |
|---|---|
| 0 - Initial Alert | Initial email to the person(s) of record responsible for the host and corresponding netblock |
| 1 - First Escalation | Escalation to the appropriate Computing Technology and Services Committee (CTSC) member, copy to the Director, Information Security Services |
| 2 - Second Escalation | Escalation to the appropriate University Committee on Information Systems & Technology (UCIST) member by the Director, Information Security Services, copy to the Associate Provost, Information Systems & Technology |
| 3 - Third Escalation | Immediate isolation of the host from the campus network |