Vulnerability Management Program Quick Start Guide

Establish Roles & Responsibilities

Guidelines

1. Critical tasks, processes, and procedures related to vulnerability management are identified and documented.
2. Key stakeholders involved in vulnerability management tasks, processes, and procedures, and their roles and responsibilities, are identified and documented.
3. A Vulnerability Response Team is established with representative members from each IT stakeholder with vulnerability management responsibilities.
   • To improve efficiency, membership of this team may be limited to those stakeholders responsible for leading vulnerability analysis, mitigation, and/or remediation efforts within their respective functional area. Other members may be included as deemed appropriate.
   • Team meetings occur at least monthly or every 30 days to review vulnerability scan results and track ongoing mitigation and remediation efforts.
   • Team members agree to meet on-demand in response to publicly disclosed zero-day and known exploited vulnerabilities to perform critical analysis and response.
   • Team members have established methods and processes for rapid information sharing and communication.
4. All identified stakeholders are informed and understand their roles and responsibilities related to the implemented vulnerability management program.

Implement an Asset Management Program

Guidelines

1. An inventory of all supported information systems and devices is developed, maintained, and routinely audited for accuracy. It is recommended that the inventory include the following information for each asset, at a minimum:
   • Hardware information
   • Network information
   • Asset owner(s)
   • Provisioning/installation date
   • Anticipated end-of-life date
   • Assessed criticality rating
2. An inventory of all installed and supported applications is maintained and routinely audited for accuracy.
3. A centralized Asset Management solution(s) is implemented and maintained to store and maintain all asset inventory data.
4. A network discovery scanning solution(s) is implemented to dynamically detect and collect information about new information systems connected to supported PittNet networks and network segments, as well as changes to existing systems. 
5. Network discovery scans are performed at least monthly, or once every 30 days, on all supported PittNet networks and network segments containing information systems with a Critical or High criticality rating.
6. Network discovery scans are performed at least quarterly, or once every 90 days, on all other supported PittNet networks and network segments.
7. A software inventory scanning solution(s) is implemented to detect and inventory all installed software and applications on supported information systems and devices.
8. Hardware asset inventory data is periodically reviewed to identify unneeded, unused, unsupported, or stale information systems and devices.
9. Stale information systems are verified and timely removed from the computing environment as deemed appropriate.
10. Software inventory data is periodically reviewed to identify out-of-date operating systems and applications installed on supported information systems and devices.
11. Software inventory data is updated at least monthly, or once every 30 days, on all supported information systems and devices with a Critical or High criticality rating.
12. When changes occur to an asset, all related hardware and software inventory data is updated in a timely manner.
13. Processes and procedures are implemented to add all newly provisioned assets, including software, to established asset inventory and management solutions.

Assess Asset Criticality

Guidelines

1. All types of data transmitted, stored, or accessed by the information system is identified, classified, and clear data governance standards based on risk are documented. See Pitt IT’s Data Risk Classification and Compliance page for more information.
2. A clearly defined System Criticality Assessment process is established following the guidelines and metrics outlined in the NIST Risk Management Framework (RMF).
3. System Criticality Assessments are performed for all supported information systems and assets that provide production IT infrastructure services, support, or information security services, including servers, appliances, and other platforms as deemed appropriate. 
4. Critically assessment results are documented and readily available to authorized IT personnel.
5. All newly provisioned assets undergo a System Criticality Assessment before release into production environments.

Maintain Threat Landscape Awareness

Guidelines

1. All personnel have completed annual Security Awareness Training, including additional security training based on job role.
2. Appropriate personnel are subscribed to resources and communities used for the disclosure of newly discovered vulnerabilities, and these resources are reviewed frequently. Examples include MS-ISAC, US-CERT, and the NIST National Vulnerability Database. 
3. Appropriate personnel are subscribed to applicable resources and communities used to announce the availability of new or updated security related software and firmware updates, and these resources are reviewed frequently. Examples include the Microsoft Security Response Center (MSRC), Apple’s Security Updates list, Adobe Security Bulletins, and the Google Chrome Releases blog. 
4. Appropriate personnel are subscribed to applicable resources and communities used to publish secure configuration baselines and security best practices, and these resources are reviewed frequently. Examples include DISA STIGs, CIS Benchmarks, and Microsoft Security Baselines.
5. Appropriate personnel are subscribed to resources and communities that publish end-of-support or end of-life information for supported information systems and applications, and these resources are reviewed regularly. Examples include the Microsoft Lifecycle Policy guide or vendor product documentation. 

Guidelines

1. Clear processes and procedures are established and documented for the periodic installation of security-related software updates (i.e., patches) on supported information systems and devices.
2. Stakeholders, roles, and responsibilities for the installation of patches on all supported systems, components, and devices are clearly identified, documented, and communicated.
3. Central patch management solutions have been implemented to enable the rapid identification, acquisition, installation, and verification of operating system and application security updates on supported information systems and devices.
4. All supported systems and devices are enrolled in a patch management solution for status and compliance monitoring. 
5. Systems and devices excluded from patch management enrollment are reviewed and approved per an established exception process.
6. Patches addressing zero-day or known exploited vulnerabilities are installed on all applicable systems and devices within 14 days of release.
7. Patches with a CVSS score (or vendor-defined severity) of Critical or High are installed on all applicable systems and devices within 30 days of release.
8. Other patches, including those with a CVSS score (or vendor-defined severity) of Medium or Low, are installed on all applicable systems and devices within 90 days of release.
9. An exception review and approval process has been established and documented for information systems and devices that cannot be patched with zero-day, known exploited, Critical, or High severity security updates within acceptable timelines.
10. Processes and procedures are established and documents for responding to unexpected technical issues caused by the installation of patches, including rollback procedures.
11. Processes and procedures are implemented to periodically assess the effectiveness of patching efforts, including the identification and troubleshooting of unpatched endpoints.
12. Processes and procedures are established and documented to identify and upgrade operating systems and applications on supported systems and devices before reaching “end-of-life” (i.e., becoming unsupported by the vendor).
13. Organizational and technical barriers to implementing effective patch management processes and procedures are identified, documented, and clearly communicated with stakeholder leadership.

Guidelines

1. Vulnerability scanning solutions with capabilities to perform all defined scan types have been implemented and leverage industry-recognized and trusted vulnerability definitions and metrics.
2. Privileged internal vulnerability scans are performed on all supported information systems with a System Criticality Rating (SCR) of Critical or High at least once every 14 days.
3. Privileged internal vulnerability scans are performed on all supported information systems with an SCR of Moderate or Low at least once every 30 days.
4. Internal vulnerability scans are performed on all supported endpoint devices at least once every 90 days. If this is not possible, a representative sample of supported endpoint devices may be scanned. This representative sample should be no less than 1% of the total number of supported devices. 
5. If scanning a representative sample, endpoint devices targeted for scanning should be rotated each scan cycle to produce more accurate sampling and results.
6. External vulnerability scans are performed on all Internet-accessible websites hosted by supported information systems at least once every 90 days.
7. Privileged internal vulnerability scans are performed on all newly provisioned assets, including new or updated reference images, virtual machines, and containers, before use in production. 
8. All Critical or High vulnerabilities detected on new assets are remediated prior to deployment into production environments.
9. When performed on behalf of another stakeholder, vulnerability scan results are shared with responsible stakeholders as soon as possible to facilitate proactive remediation efforts.

Guidelines

1. Detected vulnerabilities are analyzed by applicable stakeholders within 14 days of scan completion.
2. Metrics, methods, and processes used to assess the severity and risk of detected vulnerabilities are clearly defined and documented.
3. Metrics, methods, and processes used to assess the compliance of supported information systems are clearly defined and documented.
4. Information regarding outstanding vulnerabilities, non-compliant information systems, and outstanding risks are timely shared with the Vulnerability Response Team and relevant stakeholders.

Guidelines

1. Detected and analyzed vulnerabilities are prioritized based on their assessed Vulnerability Risk Rating (VRR).
2. Processes and procedures are implemented to apply required mitigations and remediations on supported information systems and devices, and these processes include formal testing and change management procedures.
3. Processes and procedures are implemented to assess and, if necessary, accept the risks associated with implementing temporary mitigations for detected vulnerabilities.
4. Exception review and approval processes are implemented for supported information systems and devices with detected vulnerabilities that cannot apply required remediations or mitigations.
5. Processes are implemented to track and monitor ongoing mitigation and remediation efforts across all supported information systems and devices.
6. Information regarding non-compliant assets, compliance timelines, and the consequences for continued non-compliance are communicated to responsible stakeholders.
7. Processes and procedures are implemented to report and respond to technical issues caused by vulnerability mitigations and remediations.
8. Organizational and technical barriers to effective vulnerability mitigation and remediation efforts are documented and understood by organizational and stakeholder leadership.