Vulnerability Management

PURPOSE:

This Vulnerability Management Policy establishes the standards and procedures for systematically identifying, assessing, remediating, and reporting on security vulnerabilities within Idaho College of Osteopathic Medicine (ICOM) (the “Institution”) information systems, networks, and applications. The purpose of this policy is to proactively reduce the Institution’s attack surface, minimize the risk of exploitation of vulnerabilities by threat actors, protect institutional assets and data, and maintain a secure operating environment. Effective vulnerability management is a critical security control for preventing security incidents, data breaches, and system disruptions. This policy applies to all information systems and software within the institutional environment, including on-premises systems and cloud-based services (including SaaS applications, to the extent applicable and feasible).
 

SCOPE:

This policy applies to all information systems, network devices, applications, and services owned, leased, managed, or used by ICOM, including but not limited to:

• Servers (physical and virtual)
• Workstations and laptops
• Mobile devices (institutionally owned and MDM-managed devices)
• Network infrastructure devices (routers, switches, firewalls)
• Operating systems
• Applications (institutionally managed applications)
• Databases
• Web applications and services
• SaaS Applications (addressing vendor vulnerability management responsibility and institutional verification)
• Cloud infrastructure services (IaaS, PaaS)
• IoT devices (where applicable and institutionally managed)

This policy applies to all individuals responsible for managing, maintaining, securing, and using these systems, including but not limited to:

• IT Department
• System Administrators
• Application Administrators
• SaaS Application Administrators (regarding vendor vulnerability management information)
• Users (regarding awareness of vulnerability reporting and responsible system use).

DEFINITIONS:

• CVSS (Common Vulnerability Scoring System): An industry-standard, open framework for communicating the characteristics and severity of software vulnerabilities. CVSS provides a numerical score reflecting vulnerability severity.
• DAST (Dynamic Application Security Testing): A type of security testing that analyzes a web application in its running state, simulating real-world attacks to identify vulnerabilities that are exploitable from the outside.
• Exploit: A piece of software, a chunk of data, or a sequence of commands that takes advantage of a bug or vulnerability to cause unintended or unanticipated behavior on computer hardware, software, or something electronic (usually computerized).
• Patch (Software Patch/Security Patch): A software update intended to fix a specific problem, improve security, or enhance functionality in a software application or operating system. Security patches are specifically designed to address security vulnerabilities.
• Penetration Testing: A simulated cyberattack performed against a computer system, network, or application to evaluate its security posture and identify exploitable vulnerabilities. Penetration testing is typically conducted by ethical hackers or security professionals.
• Remediation: The process of fixing or mitigating a discovered vulnerability. This may involve applying patches, making configuration changes, or implementing other security controls.
• Risk Assessment: The process of identifying, analyzing, and evaluating potential security risks, including vulnerabilities, to determine their likelihood and potential impact.
• SaaS Application (Software as a Service): A software delivery model in which software is hosted by a vendor and made available to customers over a network, typically the internet, usually on a subscription basis.
• SAST (Static Application Security Testing): A type of security testing that analyzes application source code, bytecode, or binaries to identify potential vulnerabilities without executing the code. Often referred to as "white-box testing".
• Severity Level: A classification assigned to a vulnerability based on its potential impact and exploitability (e.g., Critical, High, Medium, Low).
• Threat Actor: An individual, group, or organization that attempts to exploit vulnerabilities or cause harm to information systems or data.
• Vulnerability: A weakness or flaw in a system, software, hardware, or process that could be exploited by a threat actor to gain unauthorized access, cause harm, or compromise confidentiality, integrity, or availability.
• Vulnerability Management: The systematic process of identifying, classifying, remediating, and mitigating security vulnerabilities in information systems and applications.
• Vulnerability Scanning (Automated Vulnerability Scanning): The process of using automated tools to identify security vulnerabilities in systems, networks, and applications.
• Workaround: A temporary solution or action taken to mitigate the risk of a vulnerability when a permanent fix (patch) is not immediately available.
• Zero-Day Vulnerability: A software vulnerability that is publicly disclosed or actively being exploited before a patch is available from the vendor.

POLICY:

Vulnerability Identification: The Institution will implement processes for proactively and regularly identifying security vulnerabilities in its systems and applications. Vulnerability identification methods will include:

• Penetration Testing: Conducting periodic penetration testing by qualified internal or external security professionals to simulate real-world attacks and identify exploitable vulnerabilities in systems and applications. Penetration testing frequency will be risk-based, but at least annually.
• Security Audits and Reviews: Conducting regular security audits and reviews of systems, configurations, and security controls to identify potential vulnerabilities or misconfigurations.
• Vulnerability Disclosure Programs: Establishing and promoting a vulnerability disclosure program to encourage internal and external parties to report potential vulnerabilities they discover in the Institution's systems and applications in a responsible manner.
• Monitoring Vulnerability Intelligence Feeds: Actively monitoring vulnerability intelligence feeds, vendor security advisories, and security bulletins from trusted sources to stay informed about newly disclosed vulnerabilities affecting software and hardware used by the Institution.

Vulnerability Assessment and Prioritization: Identified vulnerabilities must be assessed to determine their potential risk to the Institution. Vulnerability assessment and prioritization will include:

• Vulnerability Scoring: Utilizing a standardized vulnerability scoring system (e.g., Common Vulnerability Scoring System - CVSS) to quantify the severity of identified vulnerabilities based on factors such as exploitability, impact, and attack vector.
• Risk-Based Prioritization: Prioritizing vulnerabilities for remediation based on a risk-based approach, considering:
  • Vulnerability severity score.
  • Asset criticality and business impact.
  • Exploitability and likelihood of exploitation.
  • Availability of exploits and active exploitation in the wild.
  • Potential data breach or operational disruption impact.
  • Compliance requirements.
• Categorization of Vulnerabilities: Categorizing vulnerabilities based on severity level (e.g., Critical, High, Medium, Low) to guide remediation timelines and resource allocation. Severity categories will be defined based on risk assessment criteria.

Vulnerability Remediation: Identified vulnerabilities must be remediated in a timely manner, based on their prioritized risk level and established remediation timelines. Vulnerability remediation processes will include:

• Patch Management Policy Integration: Vulnerability remediation will be closely integrated with the Institution's Patch Management Policy. Applying vendor-provided patches and updates is the primary method for remediating software vulnerabilities.
• Remediation Timelines: Establishing defined remediation timelines based on vulnerability severity categories. Example timelines:
  • Critical Vulnerabilities: Remediate within 24-72 hours of identification.
  • High Vulnerabilities: Remediate within 1-2 weeks of identification.
  • Medium Vulnerabilities: Remediate within 60-90 days of identification.
  • Low Vulnerabilities: Remediate as part of routine maintenance or planned upgrades.

Remediation timelines may be adjusted based on specific risk assessments and compensating controls.

• Remediation Methods: Remediation methods may include:
  • Applying vendor-provided patches and updates.
  • Implementing configuration changes to mitigate vulnerabilities.
  • Disabling vulnerable services or features (if feasible).
  • Applying temporary workarounds or compensating controls (when immediate patching is not possible).
  • Retiring or replacing vulnerable systems or software (in extreme cases).
• Testing Remediation Effectiveness: After remediation actions are taken, systems must be re-scanned or re-tested to verify that vulnerabilities have been effectively remediated and are no longer exploitable.

Vulnerability Management for SaaS Applications: Recognizing that vulnerability management for SaaS applications is primarily the responsibility of the SaaS vendor, the Institution will:

• Vendor Security Posture Assessment (Due Diligence): As part of SaaS vendor selection and ongoing vendor management (as per the Third-Party Vendor Management Policy), assess and verify the vendor's vulnerability management practices, security update policies, and vulnerability disclosure procedures.
• Vendor Vulnerability Disclosure Monitoring: Monitor SaaS vendor security advisories, vulnerability disclosures, and security update announcements to stay informed about vulnerabilities affecting the SaaS applications in use.
• Institutional Verification (Where Possible): Where feasible and provided by the vendor, utilize vendor-provided security dashboards, vulnerability reports, or communication channels to verify the vendor's vulnerability remediation efforts and security posture.
• Assume Shared Responsibility and Mitigation Where Possible: Recognize that while SaaS vendors manage infrastructure vulnerabilities, the institution retains responsibility for mitigating risks related to configuration vulnerabilities within SaaS applications (e.g., insecure access controls, misconfigured security settings). Proactively review and harden SaaS application security configurations.

Vulnerability Validation and Exception Management:

• Vulnerability Validation: Before marking a vulnerability as remediated, verification scans or tests must be conducted to validate that the vulnerability is no longer present. Automated vulnerability scanning tools may be used for validation, supplemented by manual verification as needed.
• Vulnerability Exception Process: In limited circumstances where immediate remediation of a vulnerability is not feasible due to technical constraints, operational impact, or other justified reasons, a formal vulnerability exception process will be followed. Vulnerability exceptions must be:
  • Formally requested and documented with clear justification, including a risk assessment and proposed compensating controls.
  • Approved by the Chief Information Officer.
  • Subject to compensating security controls to mitigate the risk of the un-remediated vulnerability.
  • Reviewed and re-evaluated regularly (at least quarterly) to determine when remediation can be implemented.

Reporting and Metrics: Vulnerability management activities and key metrics will be regularly reported to relevant stakeholders to track progress, identify trends, and improve the vulnerability management program. Reporting and metrics will include:

• Vulnerability Scan Reports: Regular reports summarizing vulnerability scan results, including the number of vulnerabilities identified, severity distribution, and trends over time.
• Remediation Tracking Reports: Reports tracking the status of vulnerability remediation efforts, including vulnerabilities remediated, vulnerabilities still outstanding, and remediation timelines.
• Key Performance Indicators (KPIs): Establish and track KPIs related to vulnerability management effectiveness, such as:
  • Average time to remediate critical and high vulnerabilities.
  • Percentage of critical and high vulnerabilities remediated within defined timelines.
  • Number of recurring vulnerabilities.
  • Coverage of vulnerability scanning program (percentage of in-scope assets scanned).
  • Number of vulnerability exceptions granted and their status.
• Executive Summary Reports: Regularly provide executive summary reports on the overall vulnerability management posture and key trends to executive leadership.

Policy Exceptions: Exceptions to this Vulnerability Management Policy may be granted in limited circumstances by the Chief Information Officer or designated authorization authority, with appropriate justification, documented risk assessment, and approved compensating security controls. Exceptions should be rare and subject to periodic review.
 

ENFORCEMENT:

Enforcement of this Vulnerability Management Policy is the responsibility of all managers, supervisors, IT administrators, system administrators, application administrators, under the overall direction of the Chief Information Officer. Failure to adhere to vulnerability management procedures, neglecting timely remediation of critical vulnerabilities, or other policy violations may result in disciplinary actions, up to and including warnings, suspension of system access, and termination of employment or access privileges, and potential legal or financial consequences, particularly in cases of negligence leading to security breaches. The Information Technology Office will monitor compliance with this policy, track vulnerability remediation progress, and investigate reported violations or vulnerability management deficiencies.
 

POLICY REVIEW AND UPDATES:

This Vulnerability Management Policy and associated procedures will be reviewed and updated at least annually, or as needed to reflect changes in technology, vulnerability landscape, vulnerability management best practices, regulations, institutional risk assessments, business needs, or advancements in vulnerability scanning and remediation technologies. The Chief Information Officer is responsible for coordinating policy reviews and updates, in consultation with relevant system and application administrators, and vulnerability management stakeholders.

PRIMARY POLICY OWNER:

Chief Information Officer
 

APPROVAL:

Effective: 7/8/25

Last Reviewed: 7/8/25

Review Requirement: Annual

CROSS REFERENCE AND SUPPORTING DOCUMENTS:

Information and links to other policies or supporting documents referenced within this policy.