Vulnerability Assessment

Network Device Vulnerability Assessment

Structured vulnerability posture analysis for network infrastructure through CVE mapping and CVSS v3.1 scoring. This skill assesses whether network devices are running software versions with known vulnerabilities — it is not generic patch management or endpoint vulnerability scanning.

The procedure follows a threshold-comparison pattern: device software versions are mapped to CPE identifiers, correlated against NVD and vendor advisories, scored using CVSS v3.1, and classified by combined risk (severity × network exposure × exploit availability). The output is a prioritized remediation plan with SLA-driven timelines aligned to organizational risk tolerance.

Covers five vendor platforms using inline labels: [Cisco] (IOS/IOS-XE/NX-OS), [JunOS] (Juniper Junos OS), [EOS] (Arista EOS), [PAN-OS] (Palo Alto Networks PAN-OS), and [FortiGate] (Fortinet FortiOS). Reference references/cli-reference.md for version retrieval commands and references/vulnerability-reference.md for CVSS scoring details and vendor advisory sources.

When to Use

• Scheduled vulnerability assessment of network infrastructure (quarterly, monthly, or triggered by new advisory publication)
• Post-advisory triage — a new CVE is published for a vendor in the environment and you need to determine exposure and remediation priority
• Audit findings requiring proof of vulnerability posture (PCI-DSS 11.2, NIST SP 800-53 RA-5, ISO 27001 A.12.6.1)
• Compliance-driven patching cycles where remediation must be documented with CVSS justification and SLA adherence
• Post-incident investigation requiring assessment of whether known vulnerabilities contributed to a breach or compromise
• Network refresh planning — evaluating which devices on end-of-life software have accumulated critical CVEs requiring hardware replacement
• Change advisory board (CAB) preparation — building the risk case for emergency or scheduled maintenance windows

Prerequisites

• Device access: Read-only CLI or API access to target network devices. SSH with a read-only user role is sufficient for all version retrieval commands. No privileged or configuration-mode access required.
• NVD access: Network connectivity to NVD API (services.nvd.nist.gov). An NVD API key increases rate limits from 5 to 50 requests per 30 seconds. See references/vulnerability-reference.md for API details.
• Vendor advisory access: Network connectivity to vendor PSIRT/advisory portals (Cisco PSIRT, Juniper JSA, Fortinet FortiGuard, Palo Alto Security Advisories, Arista Security Advisories). URLs listed in references/vulnerability-reference.md.
• Device inventory: A list of target devices with hostnames, management IPs, vendor/platform type, and network zone classification (internet-facing, internal, management-only).
• Organizational SLA policy: Agreed remediation timelines per severity tier. If no organizational policy exists, use the default SLA table in the Threshold Tables section.

Procedure

Follow these six steps sequentially. Each step produces artifacts consumed by subsequent steps. The procedure transforms raw device version data into a prioritized, SLA-mapped remediation plan.

Step 1: Inventory Device Software Versions

Collect the running software version from each target device using vendor-specific commands.

[Cisco] — show version returns IOS/IOS-XE/NX-OS version, image filename, uptime, and hardware model. For IOS-XE, also run show install active to identify installed SMU (Software Maintenance Update) packages that may address specific CVEs without a full upgrade.

[JunOS] — show version returns Junos OS version per routing engine and installed packages. Parse the version string (22.4R1-S2.3) for major.minor, release (R), and service release (S) components.

[EOS] — show version returns EOS version, hardware model, uptime, and image details. Check show extensions for installed SWIx extensions.

[PAN-OS] — show system info returns PAN-OS version (sw-version), App-ID signature version, threat content version, and platform model. Content signature versions affect threat detection but not OS-level CVEs.

[FortiGate] — get system status returns FortiOS firmware version and build number. The build number is essential for precise CVE matching as FortiOS does not use granular patching — each build number represents a complete firmware release.

Record for each device: hostname, management IP, vendor, platform model, software version (including patch/service release level), and uptime. See references/cli-reference.md for the complete command reference including hardware identification and uptime commands.

Step 2: Map Versions to CPE Identifiers

Construct CPE 2.3 URIs for each device's software version.

The CPE format is: cpe:2.3:o:<vendor>:<product>:<version>:*:*:*:*:*:<target_hw>:*

Map each vendor's version string to the corresponding NVD CPE naming:

Verify CPE accuracy by searching NVD for the constructed CPE — the API should return known CVEs for that product version. If zero results are returned for a version that should have known CVEs, check CPE formatting (lowercase, correct product name, version separators).

Step 3: Query NVD and Vendor Advisories

For each device's CPE, query the NVD API for matching CVEs:

GET https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=<cpe_uri>

Supplement NVD results with vendor-specific advisory sources:

• [Cisco] — Query the Cisco OpenVuln API by IOS version or check PSIRT advisories at sec.cloudapps.cisco.com
• [JunOS] — Search Juniper JSA advisories by Junos version at supportportal.juniper.net
• [EOS] — Check Arista Security Advisories at arista.com/en/support/advisories-notices/security-advisories
• [PAN-OS] — Search PAN-SA advisories at security.paloaltonetworks.com
• [FortiGate] — Search FG-IR advisories at fortiguard.com/psirt

Cross-reference NVD results against the CISA Known Exploited Vulnerabilities (KEV) catalog. Any CVE appearing in KEV has confirmed active exploitation and should be treated as Critical regardless of CVSS base score.

Record for each CVE: CVE ID, CVSS v3.1 base score, attack vector, exploit maturity, affected versions, fixed version, and KEV status.

Step 4: Score Using CVSS v3.1

For each CVE, evaluate the CVSS v3.1 base score from NVD. Apply temporal and environmental adjustments where applicable.

Base score evaluation: The NVD provides pre-calculated base scores. Verify the score components (AV, AC, PR, UI, S, C, I, A) match the vulnerability's characteristics for network devices. Network devices typically have AV:Network for remotely exploitable CVEs.

Temporal adjustments: Modify the base score based on current exploit maturity (E), remediation level (RL), and report confidence (RC). A CVE with a functional exploit (E:Functional) and no available fix (RL:Unavailable) has higher effective risk than the base score suggests.

Environmental adjustments: Apply modified metrics based on the device's role and deployment context. A Critical-rated CVE on an internet-facing border router has higher environmental impact than the same CVE on an isolated management switch.

See references/vulnerability-reference.md for the complete CVSS v3.1 metric breakdown and scoring tables.

Step 5: Classify by Combined Risk

Calculate a combined risk classification using three factors:

Factor 1 — CVSS severity tier: Critical (9.0–10.0), High (7.0–8.9), Medium (4.0–6.9), Low (0.1–3.9). See the CVSS Severity Tiers table below.

Factor 2 — Network exposure: Internet-facing devices have the highest exposure; internal network devices have moderate exposure; management-only devices have the lowest exposure. See the Exposure Multiplier table below.

Factor 3 — Exploit availability: CVEs with known active exploitation (CISA KEV), functional public exploits, or proof-of-concept code have higher effective risk than CVEs with no known exploit.

Combine the three factors to determine the effective risk level:

• CVSS Critical + Internet-facing + Active exploit = Immediate (P1)
• CVSS Critical + Internal + No exploit = Urgent (P2)
• CVSS High + Internet-facing + Any exploit status = Urgent (P2)
• CVSS High + Internal + No exploit = Planned (P3)
• CVSS Medium + Any exposure = Scheduled (P4)
• CVSS Low + Any exposure = Routine (P5)

Step 6: Generate Prioritized Remediation Plan

Map each CVE finding to a remediation action with an SLA-driven timeline.

For each device, produce:

1. CVE inventory: All CVEs affecting the current software version
2. Risk-prioritized list: CVEs sorted by combined risk (P1 → P5)
3. Remediation action: Upgrade target version that resolves the CVE (from vendor advisory "fixed in" data)
4. SLA deadline: Based on severity tier and exposure, per the Remediation SLA table
5. Consolidation opportunities: Where multiple CVEs on the same device are resolved by a single version upgrade, consolidate into one maintenance action

Group remediation actions by maintenance window:

• Emergency (P1): Immediate out-of-cycle maintenance
• Urgent (P2): Next available maintenance window (within 72 hours)
• Planned (P3): Next scheduled maintenance window (within 7 days)
• Scheduled (P4): Standard change management cycle (within 30 days)
• Routine (P5): Next quarterly maintenance window (within 90 days)

Threshold Tables

CVSS Severity Tiers

Remediation SLA by Severity

Exposure Multiplier

Decision Trees

Patch vs Schedule vs Accept Risk

CVE identified on device
├── CISA KEV listed (active exploitation)?
│   ├── Yes → IMMEDIATE: Patch within 24 hours regardless of CVSS
│   │   └── No maintenance window available?
│   │       ├── Emergency change process → Patch now
│   │       └── Compensating control available?
│   │           └── Apply control + schedule patch within 48 hours
│   └── No → Continue to CVSS evaluation
│
├── CVSS base score ≥ 9.0 (Critical)?
│   ├── Internet-facing device?
│   │   ├── Yes → IMMEDIATE: Emergency patch within 24 hours
│   │   └── No → URGENT: Patch within 72 hours
│   └── Functional exploit publicly available?
│       ├── Yes → Treat as IMMEDIATE regardless of exposure
│       └── No → Standard Critical SLA (24 hours)
│
├── CVSS base score 7.0–8.9 (High)?
│   ├── Internet-facing + exploit available?
│   │   ├── Yes → URGENT: Patch within 72 hours
│   │   └── No → PLANNED: Next maintenance window (7 days)
│   └── Compensating controls in place?
│       ├── Yes → Document controls, schedule within 7 days
│       └── No → Prioritize within 72 hours
│
├── CVSS base score 4.0–6.9 (Medium)?
│   └── SCHEDULED: Standard change management (7–30 days)
│       └── Consolidate with other pending patches if possible
│
└── CVSS base score 0.1–3.9 (Low)?
    └── ROUTINE: Next quarterly maintenance window (30–90 days)
        └── Track in vulnerability register

End-of-Life Device Decision

Device running EOL software (no further patches available)
├── Critical or High CVEs present?
│   ├── Yes → Compensating controls feasible?
│   │   ├── Yes → Apply controls + initiate hardware refresh
│   │   │   └── Document risk acceptance with CISO approval
│   │   └── No → IMMEDIATE: Isolate device, expedite replacement
│   └── No further vendor patches → Replacement timeline required
│
├── Replacement hardware available?
│   ├── Yes → Schedule migration within remediation SLA
│   └── No → Document risk, enforce compensating controls:
│       ├── ACL restrictions to limit attack surface
│       ├── Enhanced monitoring for exploit indicators
│       └── Network segmentation to isolate EOL device
│
└── Budget approved for replacement?
    ├── Yes → Proceed with procurement and migration
    └── No → Formal risk acceptance required (CISO sign-off)

Report Template

NETWORK DEVICE VULNERABILITY ASSESSMENT REPORT
================================================
Assessment Scope: [device count] devices across [zone count] network zones
Assessment Date: [timestamp]
Assessor: [operator/agent]
NVD Data Date: [last NVD query timestamp]

EXECUTIVE SUMMARY:
- Devices assessed: [count]
- Total unique CVEs identified: [count]
- Critical: [n] | High: [n] | Medium: [n] | Low: [n]
- Devices requiring immediate action (P1): [count]
- CISA KEV matches: [count]

CRITICAL CVE TABLE:
| CVE ID | CVSS | Device(s) | Exposure | Exploit | SLA |
|--------|------|-----------|----------|---------|-----|
| [CVE-YYYY-NNNNN] | [score] | [hostnames] | [level] | [status] | [deadline] |

DEVICE-BY-DEVICE FINDINGS:
Device: [hostname] ([vendor] [model])
  Version: [running version]
  CPE: [constructed CPE URI]
  Zone: [network zone] | Exposure: [level]
  CVEs: [count] (Critical: [n], High: [n], Medium: [n], Low: [n])
  Highest Risk: [CVE ID] (CVSS [score], [exploit status])
  Recommended Upgrade: [target version]
  SLA Deadline: [date based on highest severity + exposure]

REMEDIATION TIMELINE:
| Priority | Action | Devices | Target Version | Deadline |
|----------|--------|---------|----------------|----------|
| P1 | Emergency patch | [list] | [version] | [date] |
| P2 | Urgent patch | [list] | [version] | [date] |

NEXT ASSESSMENT: [based on findings — Critical present: 30 days,
High present: 60 days, Medium/Low only: 90 days]

Troubleshooting

Version String Parsing Failures

Different software trains use different version formats. If CPE construction fails, verify the version format: [Cisco] IOS-XE uses dots (17.06.03a) while IOS uses parentheses (15.9(3)M7). [JunOS] uses R and S suffixes. Normalize to the format NVD expects before querying — NVD CPEs use lowercase with no parentheses.

CPE Matching Returns Zero Results

Verify the CPE vendor and product strings match NVD's naming convention exactly. Common mismatches: paloaltonetworks (no hyphen/space), fortinet + fortios (not fortigate), arista + eos (not arista_eos). Use the NVD CPE Dictionary search to validate the correct CPE product name before querying CVEs.

Vendor Advisory Source Unavailability

If a vendor advisory portal is unreachable, rely on NVD as the primary CVE source and note the advisory gap in the report. NVD aggregates vendor-published CVE data but may lag 24–48 hours behind vendor publication. For time-sensitive assessments, check vendor RSS feeds or Twitter/social channels for early disclosure.

False Positives from EOL Version Detection

Devices running end-of-life software accumulate CVEs because the vendor no longer publishes fixed versions. Distinguish between: (a) CVEs with no fix available (EOL) — require migration planning, and (b) CVEs with fixes in newer versions — require upgrade. Flag EOL devices separately in the report with a migration timeline rather than a patching SLA.

NVD API Rate Limiting

Without an API key, NVD limits requests to 5 per 30 seconds. For large device inventories (>50 unique versions), register for an NVD API key to increase the limit to 50 per 30 seconds. Implement request pacing in automation scripts to avoid HTTP 403 rate-limit responses.