Chapter 9: Vulnerability Management

Software systems, operating platforms, and network appliances inevitably contain flaws and coding defects. In modern interconnected financial infrastructures, new software vulnerabilities are discovered, published, and weaponized by cyber adversaries on a daily basis. A financial institution cannot maintain security through static, annual audits; it requires a continuous, cyclical Vulnerability Management Lifecycle.

Vulnerability management is defined as the continuous, cyclical process of proactively discovering, cataloguing, categorizing, prioritizing, remediating, and verifying technical vulnerabilities across an organization's computing infrastructure, software applications, and network perimeters.

                    THE 5-PHASE VULNERABILITY MANAGEMENT LIFECYCLE
                                          │
       ┌──────────────────┬───────────────┴───────────────┬──────────────────┐
       ▼                  ▼                               ▼                  ▼
[ 1. DISCOVERY &     [ 2. EVALUATION &       [ 3. PRIORITISATION &   [ 4. REMEDIATION &  [ 5. VERIFICATION
  SCANNING ]              ANALYSIS ]              PLANNING ]              TREATMENT ]         & REPORTING ]
- Authenticated scans- Filter false positives- CVSS base score       - Patch application - Rescanning
- Unauthenticated    - Correlate with CMDB   - Exploit availability  - Virtual patching  - Closed-loop audit
- Agent-based feeds  - Asset criticality     - Threat intelligence   - Compensating ctrl - Executive KPI/KRI

The 5 Phases of Vulnerability Management

1. Discovery and Scanning:
   • Systematically executing automated vulnerability scans across all IP addresses, subnets, servers, cloud workloads, and network devices.
   • Employing both network-based scanners (which probe open ports across the wire) and agent-based scanners (which run directly on endpoints to inspect local registry entries and software package versions).
2. Evaluation and Analysis:
   • Analyzing scan results to eliminate false positives and correlate identified flaws with the enterprise Configuration Management Database (CMDB).
   • Contextualizing vulnerabilities against asset exposure (e.g., an unpatched bug on a public internet-facing server presents vastly higher immediate danger than the identical bug on an isolated, offline internal backup server).
3. Prioritisation and Planning:
   • Ranking identified vulnerabilities using standardized scoring metrics (such as the Common Vulnerability Scoring System - CVSS) and real-world threat intelligence.
   • Establishing remediation priority queues and assigning engineering ownership.
4. Remediation and Treatment:
   • Deploying approved software patches, firmware updates, or configuration modifications to eliminate the flaw.
   • Where immediate patching is impossible due to operational constraints, deploying Compensating Controls (e.g., virtual patching via network IPS, firewall blocks, or disabling unneeded services).
5. Verification and Reporting:
   • Executing follow-up rescans to conclusively verify that the patch successfully resolved the vulnerability and did not introduce secondary configuration errors.
   • Documenting remediation closure in the vulnerability register and reporting performance metrics (e.g., Mean Time to Remediate) to the CISO and Risk Committee.

Security assessments require two complementary technical approaches: automated vulnerability scanning and human-led penetration testing, collectively referred to across Indian financial regulations as VAPT (Vulnerability Assessment and Penetration Testing).

                 VULNERABILITY ASSESSMENT (VA) VS PENETRATION TESTING (PT)
                                             │
         ┌───────────────────────────────────┴───────────────────────────────────┐
         ▼                                                                       ▼
[ VULNERABILITY ASSESSMENT (VA) ]                               [ PENETRATION TESTING (PT) ]
- Automated broad-spectrum scanning                             - Human-led, goal-oriented ethical hacking
- Identifies "potential" flaws across 1000s of hosts           - Actively exploits vulnerabilities to prove impact
- Non-intrusive; low operational risk                           - Emulates real-world cybercriminal TTPs
- Answers: "What potential vulnerabilities exist?"              - Answers: "Can an attacker breach core systems?"

1. Comparative Analysis: VA vs PT

---

2. Common Vulnerability Scoring System (CVSS v3.1 / v4.0)

CVSS provides an open, standardized framework for communicating the technical characteristics and severity of software vulnerabilities:

                            CVSS SCORING ARCHITECTURE
                                        │
           ┌────────────────────────────┼────────────────────────────┐
           ▼                            ▼                            ▼
  [ BASE METRICS ]             [ TEMPORAL METRICS ]         [ ENVIRONMENTAL METRICS ]
  - Attack Vector (AV)         - Exploit Code Maturity (E)   - Modified Base Metrics
  - Attack Complexity (AC)     - Remediation Level (RL)      - Confidentiality Req (CR)
  - Privileges Required (PR)   - Report Confidence (RC)      - Integrity Req (IR)
  - User Interaction (UI)                                    - Availability Req (AR)
  - Scope (S)
  - Confidentiality / Integrity /
    Availability Impact (C/I/A)

CVSS Severity Rating Scale:

• None: Score 0.0
• Low: Score 0.1 – 3.9 (Minor local flaws requiring high privileges)
• Medium: Score 4.0 – 6.9 (Moderate impact; user interaction often required)
• High: Score 7.0 – 8.9 (Severe flaws allowing privilege escalation or data theft)
• Critical: Score 9.0 – 10.0 (Remote Code Execution without authentication; immediate emergency action required)

---

3. Configuration Baselines and System Hardening (CIS Benchmarks)

Out-of-the-box, commercial operating systems and network devices are configured for maximum usability and convenience, featuring open ports, unneeded services, and default credentials.

• System Hardening: The process of securing a system by reducing its attack surface—disabling unnecessary services, closing unused network ports, enforcing strong password policies, and restricting administrative privileges.
• CIS Benchmarks: The Center for Internet Security (CIS) publishes globally recognized, consensus-based configuration baselines for operating systems (Windows Server, RHEL, Ubuntu), cloud platforms (AWS, Azure), databases, and network switches. Regulated entities enforce automated CIS compliance checks to prevent configuration drift.

Patch management represents the critical operational bridge between vulnerability discovery and threat neutralization. In high-availability financial market infrastructures where system downtime can halt market trading, applying software patches requires disciplined change governance, emergency zero-day response capabilities, and rigorous management reporting.

                      STRUCTURED PATCH MANAGEMENT CADENCE
                                       │
     ┌───────────────────┬─────────────┴─────────────┬───────────────────┐
     ▼                   ▼                           ▼                   ▼
[ 1. VENDOR RELEASE] [ 2. TEST LAB ]         [ 3. CAB APPROVAL ] [ 4. PROD ROLLOUT &
- Vendor announces   - Staging replication   - Risk evaluation     ROLLBACK PLAN ]
  security patch     - Regression testing    - Scheduled change  - Scheduled maintenance
- CVE / CVSS review  - Compatibility check     window              - Health verification
                                                                 - Immediate rollback if
                                                                   instability arises

1. Patch Management Governance and Change Advisory Boards (CAB)

Deploying a security patch can occasionally break software dependencies, corrupt database schemas, or degrade trading performance. Therefore, patching must follow disciplined Change Management (ITIL) procedures:

1. Testing in Non-Production Staging: Patches must be deployed and tested in an isolated staging environment replicating production architecture to verify compatibility and eliminate operational regressions.
2. Change Advisory Board (CAB) Review: Formal review of proposed patches by representatives from IT operations, development, cybersecurity, and business units. CAB evaluates change risk, scheduling, and operational impact.
3. Mandatory Rollback Plans: Every change request must include a documented, pre-tested rollback procedure. If the patch induces software instability or failure during production rollout, engineers can restore the previous operational state within minutes.
4. Statutory Remediation Timelines (SLA):
   • Critical Vulnerabilities (CVSS $\ge$ 9.0): Must be remediated or mitigated within 24 to 48 hours.
   • High Vulnerabilities (CVSS 7.0 – 8.9): Must be remediated within 7 to 15 days.
   • Medium Vulnerabilities (CVSS 4.0 – 6.9): Remediated within standard monthly patch cycles (30 days).

---

2. Managing Zero-Day Vulnerabilities and Emergency Patching

A Zero-Day Vulnerability is a software flaw that is actively exploited in the wild or publicly disclosed before the software vendor has developed and released an official security patch (i.e., the vendor has had "zero days" to fix it).

• Compensating Safeguards: Because official vendor patches do not exist, security teams must deploy alternative defensive countermeasures:
  • Virtual Patching: Writing custom regex signatures for Web Application Firewalls (WAF) or Network Intrusion Prevention Systems (IPS) to intercept and drop exploit payloads before they reach the vulnerable server.
  • Service Disablement: Disabling the vulnerable module, protocol, or feature if not critical to immediate business operations.
  • Network Isolation: Restricting access to the vulnerable system exclusively to trusted management subnets via firewall rules.

---

3. Executive Vulnerability Metrics and Governance Reporting

The CISO must communicate vulnerability exposure to Senior Management and the Board of Directors using clear, risk-informed metrics: