University-wide Vulnerability Management standards are intended to augment the University-wide Policy that governs vulnerability management. Standards should not be considered a replacement for policy, they extend and help operationalize policy.

The UWVM program is structured around the NIST Cybersecurity Framework (NIST CSF) 2.0, with direct integration of the CIS Controls version 8. Standards help to:

• Identify relevant systems, process and vulnerabilities
• Protect the University by implementing safeguards and processes that reduce the potential exploitation of vulnerabilities
• Detect vulnerabilities that may be high impact to the business
• Respond to vulnerability findings
• Recover vulnerable systems by executing formalized workflows that meet or exceed the University standard

The scope of these standards aligns directly with University-wide Policy and applies to all Harvard University technology assets:

• Servers (cloud, VM, on-prem)
• Other hardware assets
• Network Infrastructure
• Network connected devices
• Software
• Cloud infrastructure (as part of CSPM)

University leadership: School and unit CIOs, CISOs, and senior IT leadership responsible for reviewing reporting, assessing risk, and making resource-allocation decisions.

UWVM core team: Under HUIT ISDP this team manages the UWVM program including system administration of detection tools, CAASM/Clearinghouse tools, and integrations. They maintain technology standards, facilitate best practices, and escalate urgent issues. Core team members, in partnership with key stakeholders are also responsible for program design and operation, and communication with University leadership and School Privacy and Security Officers (SPSOs) on program status.

UWVM extended team: This group includes SPSOs and designated staff, acting as local administrators within their school or unit and aiding in process development. They are critical for sharing UWVM information within their units and escalating urgent issues to the Core team while collaborating with the Core team to set standards and review risks. They are expected to address any deficiencies in remediation, maintenance, threat assessment, and risk controls.

Vulnerability Coordinators: Oversee vulnerability tracking, prioritize remediation efforts, ensure compliance with University policies, and provide updates on progress. Vulnerability Coordinators work closely with Remediation Owners to resolve vulnerabilities promptly.

Remediation Owners: Maintain hardware, software, or platforms, ensuring system upkeep through patching, configuration, and risk mitigation.

Risk Owners: Specific to the formal exceptions process as defined by each school and unit, these are typically non-IT business leaders at the VP or Managing Director level, that assume risks in specific technology areas where exceptions are required. Risk owners play a key role in the exception process, explicitly accepting risks where vulnerabilities cannot be addressed according to Operational Level Agreements.

The UWVM program establishes a set of Operational Level Agreements (OLAs) for addressing vulnerabilities through: 1) remediation, 2) mitigating actions that change Harvard scoring and therefore impose a different SLA, 3) obtaining a valid exception approval or 4) obtaining a valid false positive approval.

If a vulnerability remains outstanding beyond OLA, without a valid exception or designation as a false positive, ISDP in partnership with HUIT and the school security teams may take action to address the risk directly. This may include a number of escalating actions up to and including removal of assets from Harvard networks.

Operational Level Agreements 

OLA timelines measure the window from when the vulnerability was first identified in the public space NOT when the vulnerability was first found on the associated asset. OLA timelines will be used for reporting and workflow purposes.

Risk calculation: The University-wide Vulnerability Management program establishes a single risk measure that can be compared across all vulnerability and exposure types. The measure, the Harvard Vulnerability and Exposure Risk Score (HVERS) quantifies the risk presented to the University by the vulnerability or exposure impacting a specific asset or resource.

The risk calculation and scoring will result in a score assigned to each vulnerability. Scores are based on a 10-point scale. CVE-based vulnerabilities that are not ingested into the UWVM centralized reporting tool, will assume scores based on the severity rating provided by the associated detection platform:

All risk scoring considers the probability of successful exploitation of an exposure and the impact to the University if the exploit results in compromise.
Vulnerability on Server scoring includes:

• Probability of exploitation:
  • Vulnerability – FIRST.org’s Exploit Prediction Scoring System (EPSS) Score, CISA Known Exploited
  • Asset – internet facing tag
•  Impact of compromise: 
  • Vulnerability – CVSS Score
  • Asset – Criticality tag, data_class tag
• 25% Likelihood of exploit, 25% Severity of Vulnerability, 10% criticality of asset, 20% data sensitivity of asset, 30% whether asset is considered “internet-facing”

Server Configuration Compliance gaps take into account the risk presented by the device upon which the gap is found, and the risk presented by the gap. Specifically:

• Device risk:
  • Criticality tag, data_class tag, internet_facing tag
• Gap risk:
  • Working CrowdStrike agent, working Scanning agent (Nessus or Qualys), Working Splunk Forwarder, Wiz coverage (for cloud)
• 10% criticality of asset, 20% data sensitivity of asset, 30% whether asset is considered “internet-facing”, 50% SCC Exploit score (depends on type of gap)

Cloud Security Posture Management exposure scoring differs depending on whether the primary associated asset is a virtual machine (EC2, Azure Compute, GCP Compute, etc.) or some other type of asset. In all cases the score will be a combination of the alert risk taken from Wiz and: 

• Environment risk
  • Virtual Machines: internet_facing tag, data_class tag, criticality tag
  • All others: internet wide exposure (determined at the account/subscription level, highest level data_class in the account/subscription, highest level Criticality in the account/subscription
• Cloud configuration risk
  • Wiz alert risk score
• Weightings and HVERS formula for CSPM-related issues differs dependent on the primary resource type associated with the issue representing a toxic combination of findings.
   

Vulnerabilities not remediated through OS patching or specific remediating action may be addressed with the following or some combination of the following:

1. Mitigating action that significantly reduces the risk posed to the organization and potentially adjusts the Harvard risk score based on any change to the underlying factors.
2. Request for an exception submitted through a formal exception process
3. Request for vulnerability to be designated as a false positive through a formal false positive identification process

In the absence of remediation or one of the three actions listed above, ISDP in partnership with the appropriate security team(s) may take action to directly address the risk.

Exceptions: Each exception (exposure-asset pair) will be assigned an expiration date. Upon expiration if the vulnerability or exposure is still outstanding it will require immediate action and will be immediately and automatically considered in breach of the OLA). Standard UWVM processes will track approved exceptions and where possible alert associated individuals that an approved exception is nearing expiration.

Each school and unit at Harvard can either adopt the UWVM Exception standard or develop their own formalized process. Any deviation from the standard must meet the standard as a baseline requirement. This baseline will support full transparency so that the UWVM program can accurately track approved exceptions, University-wide. Approved exceptions do not actively mitigate risk, they shift the risk ownership from one entity to another.

False positives: False positives occur when the technology platform indicates that a vulnerability exists when in fact it does not.

The route to approval for false positives is quicker and less onerous than exceptions. False positive requests are made with a duration, and as best practice, requires verification that conditions persist to continue to treat as a false positive. Approved false positives will be tracked and integrated with reporting and workflow management, and where possible UWVM will establish alerting for false positives nearing expiration. False positives carry no actual risk and therefore do not require business owners to approve and accept.

Schools and units may use the UWVM standard false positives process or create their own using the UWVM standard as the baseline. 

True Positive by Design: Specific case identifying a configuration-based cloud exposure that was architected intentionally and needs to remain in-place support broader cloud functionality. In cases of True Positive by Design exposures, the risk identified by the scanning tool is inherent to the required functionality. For example, a public website must be exposed to the Internet to be useful as a website. 

Cases of true positive design are more rare, and exclusive to the Cloud Security Posture Management exposure type. Requests are considered on a case-by-case basis in consultation with cloud architects in HUIT. The process governing True Positive by Design is similar to False Positives. Due to the centralized nature of cloud security, all True Positive by Design requests will be managed by the UWVM Program team. True Positive by Design exceptions do not have an end date.

Detection tooling: Infrastructure components should be actively scanned (as of November 2024) for:

• Server based vulnerabilities
• Cloud Security exposures (for cloud assets)

Wherever possible server-based vulnerability scanning should be conducted via agented scans scheduled to execute with daily jobs. Agents must be installed on all server assets, any exceptions will need to be addressed via the ISDP Policy exception process. See table below for standard detection tooling, any substitutes need to be approved by UWVM and will need to demonstrate the ability to meet coverage needs, and the ability to relay results to central aggregating and reporting coordinated by UWVM.

Assignment and workflow routing is a core UWVM process, offering a standard that schools and units can adopt directly or meet through their own processes as long as they align with the UWVM baseline. 

Associating vulnerabilities to assets: All vulnerability data produced from detection tooling is required to identify the associated technology resource with an identifying value. Common examples of this value include: hostname, IP address, MAC address, cloud resource ID, or any other value that identifies a technology in a manner that is mutually exclusive to all other technology in use at Harvard. 

Reporting attribution: Vulnerabilities will be reported University-wide based on the school or unit owning the associated asset(s). Additional granularity may be achieved by leveraging further asset detail such as the Hosted_By tag.

Workflow routing: Remediation tasks generated by the UWVM solution may be created in a dedicated workflow management technology.  Generated tasks will be assigned to the most likely remediating team based on the nature of the vulnerability and the ownership of the associated asset. It is the responsibility of each school and/or unit to ensure accuracy and currency of metadata so that tasks can be routed.

Detection will be integrated in a manner that can inform Axonius and downstream processes e.g. ServiceNow, when a previously identified vulnerability is fixed or mitigated. This data flow will support automatic ticket resolution.

Escalating emergency vulnerabilities: Any vulnerability identified as a potential emergency risk must be handled with urgency and managed keeping impact across the entire University in-mind. All members of the UWVM team (including the program team and extended team) are expected to help identify and communicate any emergency cases. At a minimum these include a) any vulnerability deemed exploited within the University, b) any vulnerability carrying a Harvard risk score of 9.5 or higher, and c) any vulnerability deemed as an immediate risk in coordination with the UWVM Program Team. Emergency situations should be communicated immediately to the UWVM team. Mitigating action is at the discretion of the individual schools and units, but the UWVM Program team will coordinate dissemination across the University and will be responsible for coordinating a standard response where appropriate.

Attack Surface Management: All known resources must be captured and catalogued to promote more comprehensive scanning. In addition to traditional discovery methods, units are required to leverage data from various sources of truth via the University’s standard tool (Axonius).

Key Asset Datapoints: 

• criticality
• data_class
• Environment
• hosted_by – consistent identifier for operations team responsible for supporting the host
• product  - a consistent name for the product or platform a host supports 

If servers are not tagged, the most conservative values will be substituted in risk calculations. Exposure to the internet will also be tracked and tagged in Axonius by the UWVM team. Reporting dashboards will be made available for tag comprehensiveness and tag data quality.

Inventory Reporting: Asset inventory will be informed by all available sources of metadata including vulnerability detection tools, configuration management databases (CMDBs), cloud providers, automation platforms, and manual inventories. Axonius is the University tool to report on asset inventory for all IT and OT assets to define the Attack Surface. Where available, and identified as necessary by the UWVM team, Axonius will be connected to platforms and infrastructure components via adapters. 

Note: At this time, Operational Technology (OT) devices and network devices are not  included in the current inventory and calculations.

Scope: OS patching refers to the patching of vulnerabilities impacting the operating system OR components – software, packages, libraries installed as part of the operating system. OS patching must be addressed for ephemeral and non-ephemeral resources alike.

Cadence: In accordance with University-wide policy, at minimum, OS patching must be conducted monthly. 

Patch Set: University-wide policy directs that OS patching be executed with as current a patch set as possible. Patch set source is the responsibility of operations teams charged with supporting the given infrastructure.