babyÖ±²¥app

Identification and Management of Security Risks in Information Systems

Table of Contents 

• Purpose
• 1. Standard
  • 1.1 System Classification
  • 1.2 Conducting a Risk Analysis
  • 1.3 Risk Remediation Timeframes
• 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 University of babyÖ±²¥app 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 University of babyÖ±²¥app Data Classification Standard¹ 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 Qualys²

IT Service Providers should also consider the adverse impact³ 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

All other information systems are subject to the remediation timeframe outlined below in Table 3.

Table 3. Standard remediation timeframes

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 University of babyÖ±²¥app 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)

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 University of babyÖ±²¥app Risk Acceptance Process⁴ is available to employees and affiliates of the University of babyÖ±²¥app 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 University of babyÖ±²¥app 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 Computers⁵ and Servers⁶. 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 University of babyÖ±²¥app Data Classification Standard: https://www.cu.edu/security/data-classification  

² Qualys Vulnerability Severity Levels https://qualysguard.qg2.apps.qualys.com/qwebhelp/fo_portal/knowledgebase/severity_levels.htm 

³Â Data Classification Adverse Impact: https://www.cu.edu/security/about-adverse-impact 

⁴ University of babyÖ±²¥app Risk Acceptance Process: https://www.cu.edu/security/risk-acceptance-process 

⁵ Secure Computing Standard for Computers: /policies/secure-computing-standard-computers 

⁶ Secure Computing Standard for Servers: /policies/secure-computing-standard-servers 

Contact Information

Questions or concerns relating to this standard should be directed to the University of babyÖ±²¥app Boulder Office of Information Technology Security at security@colorado.edu.