Purpose

The purpose of the Vulnerability Management Standard is to ensure that all networked ISU systems, applications, and network devices remain secure, stable, and compliant with regulatory requirements by implementing a structured approach to vulnerability management.

This standard aligns with state and federal regulatory and contractual requirements as well as industry best practices to mitigate security vulnerabilities, reduce risks of threats, and maintain operational continuity, providing a structured approach to mitigate security risks and support the University's secure operational environment.

Scope

This standard applies to all firmware and software on systems owned or managed by or on behalf of the University ("systems"), including but not limited to servers, endpoints, and appliances. This standard is relevant to all University departments and units that manage, maintain, or use scoped systems including utilizing vendor management of these systems.

Scope Exemptions

This standard does not apply to systems with all network capabilities disabled or disconnected.

This standard does not apply to personal devices not managed by the University.

The timeline in this standard is superseded by vulnerability remediation timelines documented in any vulnerability management playbooks or initiatives.

Standard

University teams and departments ("teams") managing systems within this standard's scope must meet the following criteria:

1. Systems must have an individual or team assigned responsibility for vulnerability management.
2. Teams must maintain a documented inventory of system hardware and software under their vulnerability management scope.
3. Teams must monitor industry vulnerability resources and security advisories to identify vulnerabilities.¹
4. Change processes must be documented and followed for vulnerability remediation.
5. Systems must be enrolled in a vulnerability management solution² with authenticated scans⁸ configured where supported.
6. Teams must review server³ vulnerability reports at least weekly.
7. Teams must review endpoint³ vulnerability reports at least monthly.
8. Teams must review system vulnerability reports before completing initial system implementation and after any major system upgrade.
9. Teams must remediate⁴ critical severity⁵ vulnerabilities within 30 days.
10. Teams must remediate high severity vulnerabilities for Internet-facing systems within 30 days.⁶
11. Teams must remediate vulnerabilities within 30 days that are categorized or described as one or more of the following:
    1. Enables remote code execution
    2. Authentication or authorization weakness
    3. Enables arbitrary injection
    4. Enables data exfiltration/modification/loss
12. Systems must be maintained with an appropriate level of vulnerability risk.⁷

Exceptions

While this standard is intended to apply comprehensively, there may be instances where certain systems or support teams are unable to meet the full requirements. In such cases, exceptions must be formally requested and reviewed.

Requests for exceptions must be submitted to the Information Security Office through the University’s ticketing system or by emailing informationsecurityoffice@ilstu.edu. Each request must include:

• The information technology team and functional business units associated with the exception request
• Systems and firmware/software affected by the exception
• A detailed use case explaining why the exception is necessary and what compensating security controls, if any, will be implemented

The Information Security Office will review all exception requests in accordance with the Information Security Program's exception management process. Approval will be granted only when it is determined that operational needs outweigh the security risks, and where appropriate compensating controls are in place to mitigate those risks. All approved exceptions will be documented, periodically reviewed, and may be subject to additional security monitoring.

Additional Information

Footnotes

The following information provides supporting information referenced in the other sections of this document:

1. Monitoring for industry vulnerability resources can be done via a variety of mechanisms such as vendor announcements/advisories, subscribing to vendor emails, external party notices (CISA, CIS, etc.), vendor or industry forums, media publications, and more.
2. Vulnerability management solutions detect and report vulnerabilities and configuration deficiencies present on a system. Solutions include but are not limited to Defender for Endpoint, InsightVM, or Red Hat Advanced Cluster Security.
3. Servers are systems that provide services to other systems including but not limited to server operating systems, appliances, hypervisors, networking equipment, databases, web applications, and more. Endpoints are systems that exclusively consume services from other systems including but not limited to desktops, laptops, tablets, mobile devices, and more. All systems are classified as either a server or an endpoint. Vulnerability report requirements also apply if a vendor is managing an ISU-owned system.
4. Remediating a vulnerability includes but is not limited to installing a patch, changing configuration settings, or disabling a service. If remediation via standard patch management is not feasible, ISO-approved workarounds or other compensating controls must be implemented and documented to achieve remediation.
5. Vulnerability severity is determined by the most recent CVSS score of the vulnerability. In the absence of an available CVSS score, the vendor advisory rating should be used. Consult the ISO if neither are available.
6. Internet-facing systems can be reached over the Internet via an Internet connection open request. Examples include having a public IP address or being Internet-accessible through a load balancer or gateway (Netscaler/ADC).
7. Appropriate vulnerability risk will differ depending on the system. A public-facing server will have a low tolerance for vulnerability risk, and a network-internal endpoint will have a higher tolerance. Tools that may assist include a system's InsightVM risk score, Defender security score, vulnerability count by severity, or a team's average risk score per system. Consult the Information Security Office for assistance evaluating vulnerability risk.
8. Authenticated scans may be required by vulnerability management solutions using remote scanning. For example, Rapid7 InsightVM utilizes authenticated remote scans, and Microsoft Defender does not use authenticated remote scans.

Roles & Responsibilities

Compliance

The Information Security Office will report on vulnerability status to ensure compliance with this standard and University policies. Systems out of compliance with this standard or the University Security Program policy will be escalated for remediation planning, and continued noncompliance may result in systems being segmented from the University network.

Supporting References

The following information provides supporting references that informed the development of this standard:

Appropriate Use Policy: https://policy.illinoisstate.edu/technology/9-2/

Information Security Program Policy: https://policy.illinoisstate.edu/technology/9-8/

Vulnerability Playbooks: High Risk Vulnerability Response Playbook Urgent Risk Vulnerability Response Playbook

NIST 800-40 Guide to Enterprise Patch Management: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf

NIST 800-53 Security and Privacy Controls: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

CIS Controls v8.1: https://www.cisecurity.org/controls/v8-1

CIS Vulnerability Management Standard: https://www.cisecurity.org/-/media/project/cisecurity/cisecurity/data/media/files/uploads/2020/06/Vulnerability-Scanning-Standard.docx

CIS Control v8 Guidance

Illinois State University leverages the CIS Controls framework, validated through the CIS Community Defense Model, to ensure our cybersecurity measures effectively mitigate the most prevalent real-world threats, including those identified in the MITRE ATT&CK framework, thereby enhancing our defenses against known adversary behaviors.

7.1 Establish and Maintain a Vulnerability Management Process: Establish and maintain a documented vulnerability management process for enterprise assets. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard.

7.2 Establish and Maintain a Remediation Process: Establish and maintain a risk-based remediation strategy documented in a remediation process, with monthly, or more frequent, reviews. 

7.5 Perform Automated Vulnerability Scans of Internal Enterprise Assets: Perform automated vulnerability scans of internal enterprise assets on a quarterly, or more frequent, basis. Conduct both authenticated and unauthenticated scans, using a SCAP-compliant vulnerability scanning tool.

7.6 Perform Automated Vulnerability Scans of Externally-Exposed Enterprise Assets: Perform automated vulnerability scans of externally-exposed enterprise assets using a SCAP-compliant vulnerability scanning tool. Perform scans on a monthly, or more frequent, basis. 

7.7 Remediate Detected Vulnerabilities: Remediate detected vulnerabilities in software through processes and tooling on a monthly, or more frequent, basis, based on the remediation process. 

13.1 Centralize Security Event Alerting: Centralize security event alerting across enterprise assets for log correlation and analysis. Best practice implementation requires the use of a SIEM, which includes vendor-defined event correlation alerts. A log analytics platform configured with security-relevant correlation alerts also satisfies this Safeguard.

13.2 Deploy a Host-Based Intrusion Detection Solution: Deploy a host-based intrusion detection solution on enterprise assets, where appropriate and/or supported.

16.2 Establish and Maintain a Process to Accept and Address Software Vulnerabilities: Establish and maintain a process to accept and address reports of software vulnerabilities, including providing a means for external entities to report. The process is to include such items as: a vulnerability handling policy that identifies reporting process, responsible party for handling vulnerability reports, and a process for intake, assignment, remediation, and remediation testing. As part of the process, use a vulnerability tracking system that includes severity ratings, and metrics for measuring timing for identification, analysis, and remediation of vulnerabilities. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard. Third-party application developers need to consider this an externally-facing policy that helps to set expectations for outside stakeholders.