Vulnerability Management Standard
Identification and Management of Security Risks in Information Systems
Table of ContentsÂ
- Purpose
- 1. Standard
- 2. Temporary Security Exception
- 3. Risk Acceptance
- 4. Administration and Enforcement
- Appendix
Purpose
The use of information systems while conducting University business bears inherent risks that may lead to breaches of confidentiality, exploitation of vulnerabilities, or other abuse of University assets. To safeguard against these risks, this standard defines a means by which vulnerable information systems should be identified, classified, and, if necessary, isolated from the ÀÖ²¥´«Ã½ network or the internet pending remediation. The following sections define system classifications, guidelines for conducting a risk analysis, and risk remediation expectations.
This standard references terms and definitions from other articles published in the University's Information Technology security policy suite, which defines and establishes the IT Security Program. All references are documented in the Appendix along with contact information for the Office of Information Technology (OIT) Security team.
1. Standard
The requirements in this standard apply to all University-owned or managed systems and devices (physical, virtual, or cloud based), regardless of ownership, operation, platform, or network location. This standard shall ensure that vulnerabilities are adequately remediated within acceptable timeframes to minimize risk to the University. For the purposes of this standard, remediation may include:
- Applying an update per vendor instructions
- Implementing a workaround that protects a vulnerable system from exploitation
- Temporary mitigations, such as disabling an affected service to prevent exploitation of the vulnerability until a permanent patch becomes available
1.1 System Classification
To appropriately respond to risk, IT Service Providers are responsible for the classification of the information systems that they manage. Information systems should be classified based on the type of data that is stored, processed, and transmitted.
The ÀÖ²¥´«Ã½ Data Classification Standard1 provides guidance for classifying data as Highly Confidential, Confidential, or Public, and classifying adverse impact as High, Moderate, or Low. The confidentiality levels of data on the system and the level of adverse impact from potential compromise should be considered when determining the information system’s classification; any information system that stores, processes, or transmits Highly Confidential data, or would have a High adverse impact if compromised, must be classified as a High-Risk system.Â
IT Service Providers are responsible for disclosing system classifications to OIT Security whenever asset information is requested.
1.2 Conducting a Risk Analysis
Once an information security risk has been detected, IT Service Providers should reference the severity level assigned by OIT Security to appropriately prioritize remediation efforts. If a risk has not been assigned a severity level by OIT Security, the IT Service Provider is responsible for conducting a risk analysis to determine the appropriate severity level and prioritizing remediation accordingly.Â
Severity levels are ranked on a scale of one to five, with five being the most severe. The five severity levels are outlined below in Table 1.
Table 1. Severity levels adapted from Qualys2
Severity | Description |
---|---|
Level 1 (Minimal) | Intruders may be able to collect information about the host (open ports, services, etc.) and may be able to use this information to find other vulnerabilities. |
Level 2 (Medium) | Intruders may be able to collect sensitive information from the host, such as the precise version of software installed; with this information, intruders can easily exploit known vulnerabilities specific to software versions. |
Level 3 (Serious) | Intruders may be able to access specific information stored on the host, including security settings. This could result in potential misuse of the host by intruders. For example, vulnerabilities at this level may include partial disclosure of file contents, access to certain files on the host, directory browsing, disclosure of filtering rules and security mechanisms, denial of service attacks, and unauthorized use of services, such as mail-relaying. |
Level 4 (Critical) | Intruders may be able to gain control of the host, or there may be potential leakage of highly sensitive information. For example, vulnerabilities at this level may include full read access to files, potential backdoors, or a listing of all the users on the host. |
Level 5 (Urgent) | Intruders can easily gain control of the host, which can lead to the compromise of the entire network’s security. For example, vulnerabilities at this level may include full read and write access to files, remote execution of commands, and the presence of backdoors. |
IT Service Providers should also consider the adverse impact3 of the affected system when conducting a risk analysis. Severity levels should be adjusted to match the environment and circumstances of the risk at the IT Service Provider’s discretion.
Once a risk analysis has been performed, the vulnerability severity level should be recorded and used by the IT Service Provider to identify the appropriate risk remediation timeline. Timelines are documented in the following section, 1.3 Risk Remediation Timeframes. Severity levels and remediation timelines must also be referenced when pursuing a Temporary Security Exception or risk acceptance.
1.3 Risk Remediation Timeframes
Once a risk is identified, OIT Security will determine how long the risk should be allowed to exist before defensive security measures—such as quarantining a device or removing a device’s internet access—are put into place. Such timeframes are referred to as the Time To Remediation (TTR). TTRs are determined by the information system classification and the vulnerability severity level.
Information systems that are classified as high-risk are subject to the following remediation timelines outlined below in Table 2.
Table 2. Remediation timeframes for high-risk information systems
Risk Level | Acceptable Time-To-Remediation (TTR) |
---|---|
Level 5 | Business must be suspended until remediated |
Level 4 | Business must be suspended until remediated |
Level 3 | 15 days |
All other information systems are subject to the remediation timeframe outlined below in Table 3.
Table 3. Standard remediation timeframes
Risk Level | Acceptable Time-To-Remediation (TTR) |
---|---|
Level 5 w/serious known exploit | 48 hours |
Level 5 | 5 days |
Level 4 | 15 days |
Level 3 | 30 days |
Timelines for remediation of Level 2 and Level 1 vulnerabilities are not dictated by this standard; such vulnerabilities should be addressed with best effort and swiftly remediated. If systems subject to PCI DSS are not remediated within acceptable timeframes, the campus ISA and University Treasury will determine if the merchant account is to be suspended. OIT Security will confirm remediation with a verification scan at the end of the expected timeframe for completion. The Information Security Office reserves the right to take the remediation actions specified in Section 4. Administration and Enforcement at any time.
2. Temporary Security Exception
A Temporary Security Exception is a choice to temporarily suspend security policies that address a risk. The Temporary Security Exception process accommodates circumstances where risk remediation is not feasible within the standard timeframes outlined in section 1.3, Table 3.Â
IT Service Providers, administrators, departments, or other presiding entities may seek a Temporary Security Exception to manage a delayed remediation effort, appease a strong business reason, or respond to some other extenuating circumstance related to a risk.
A Temporary Security Exception Request should be submitted to ÀÖ²¥´«Ã½ Boulder Office of Information Technology Security at security@colorado.edu to document and request a Temporary Security Exception when the following conditions exist:
•   The affected information system is not classified as high-risk
•   A risk analysis has been performed that identifies the potential impact of a risk as Level 3 or above
•   There exists a justification for the expected time to remediation to be longer than the standard timeframe
Time to remediation (TTR) denotes the amount of time that OIT Security will withhold security measures—such as quarantining an affected device or revoking its internet access—after a risk has been identified. Table 4 summarizes the standard TTR for each risk level alongside the TTR that can be requested in a Temporary Security Exception.
Table 4. Risk levels and acceptable time to remediation (TTR)
Risk Level | Standard TTR | TTR with an Approved Temporary Security Exception |
---|---|---|
Level 5 w/serious known exploit | 48 hours | 4 days |
Level 5 | 5 days | 10 days |
Level 4 | 15 days | 30 days |
Level 3 | 30 days | 60 days |
To ensure proper usage and accountability for Temporary Security Exceptions, approval by an administrative officer, director, or department chair is required. If regulatory compliance obligations exist, approval from the appropriate University compliance authority is also required.Â
Multiple Temporary Security Exceptions cannot be filed for the same risk. If a risk is not remediated by the end of its extended TTR, Risk Acceptance may be sought out in accordance with the Information Risk Acceptance Process. Any exception may be revoked by the Chief Information Officer.
3. Risk Acceptance
To accommodate circumstances where an information system carries a risk that cannot be remediated or otherwise cannot conform to a University policy, procedure, standard, or guideline, the ÀÖ²¥´«Ã½ Risk Acceptance Process4 is available to employees and affiliates of the ÀÖ²¥´«Ã½ Boulder. Risk acceptance requests and decisions must follow the CU Office of Information Security process.
4. Administration and Enforcement
University-owned or managed systems and devices (physical, virtual, or cloud based), regardless of ownership, operation, platform, or network location are subject to vulnerability scanning and penetration testing by OIT Security. Network, system, and application performance and availability may be affected by these security practices. OIT Security is the only entity authorized to perform campus-wide network scanning of all ÀÖ²¥´«Ã½ Boulder computer systems; however, departmental system administrators may scan systems within their area of responsibility. Departmental scans must be coordinated with OIT Security to avoid scans being perceived as unauthorized intrusion attempts.Â
IT Service Providers are responsible for the assessment and application of security patches on systems under their management and supervision. When a security flaw is identified by OIT Security, a severity level will be determined that reflects the sensitivity of data on the vulnerable system, the risk of exploitation, and the potential adverse impact to University operations. The severity level will be used to determine the appropriate actions to protect University information and information systems. If any system is endangering computing and/or network resources, OIT may temporarily block access or remove it from the network. Once network access is revoked in any way, a vulnerability scan by OIT Security is required before access may be restored.Â
All University-owned or managed systems and devices must be enrolled in the campus anti-malware, detection and response application or an approved equivalent service in accordance with the Secure Computing Standards for Computers5 and Servers6. Enrollment provides for real-time scanning to detect, prevent, and remove malware; detect malicious activity; and to mitigate potential vulnerabilities. Device owners are responsible for gathering and sending hardware and software information to OIT’s central inventory for vulnerability tracking, network identification, and audit preparedness. Violations of policy will be referred to the IT Service Provider’s supervisor and/or departmental director, as appropriate.
Appendix
1ÌýThe ÀÖ²¥´«Ã½ Data Classification Standard: https://www.cu.edu/security/data-classification Â
2 Qualys Vulnerability Severity Levels https://qualysguard.qg2.apps.qualys.com/qwebhelp/fo_portal/knowledgebase/severity_levels.htmÂ
3Â Data Classification Adverse Impact:Â https://www.cu.edu/security/about-adverse-impactÂ
4 ÀÖ²¥´«Ã½ Risk Acceptance Process: https://www.cu.edu/security/risk-acceptance-processÂ
5Â Secure Computing Standard for Computers: /policies/secure-computing-standard-computersÂ
6Â Secure Computing Standard for Servers: /policies/secure-computing-standard-serversÂ
Contact Information
Questions or concerns relating to this standard should be directed to the ÀÖ²¥´«Ã½ Boulder Office of Information Technology Security at security@colorado.edu.