Vulnerability assessment and management

In short

Vulnerability assessment (VA) is the systematic discovery, classification and scoring of security weaknesses in hosts, applications, networks and configurations; vulnerability management (VM) is the continuous programme that prioritises, remediates, verifies and reports on them. It differs from penetration testing in that VA is broad, largely automated and non-exploitative, while a pen test is narrow, manual and proves exploitability. It matters because almost all mass breaches and ransomware in India exploit known, patchable flaws, and because CERT-In directions, RBI/SEBI/IRDAI cyber frameworks, ISO/IEC 27001:2022 and PCI DSS all mandate periodic VA. It is examined in university "Offensive and Defensive Security" / "Cyber Security Essentials" papers, and asked in every VAPT, SOC-analyst and GRC interview at TCS, Infosys, Wipro, HCLTech, Accenture, Deloitte, KPMG, Tata Elxsi, Qualys and Tenable partners in India.

Explained

Core definitions and the risk equation

• Asset: anything of value - server, endpoint, container, router, web app, OT device, data store. VM is impossible without an accurate asset inventory.
• Vulnerability: a weakness in design, implementation, configuration or operation that can be exploited. Example: unpatched SMBv1, default credentials, world-writable file.
• Threat: an actor or event capable of exploiting the weakness. Exploit: code or technique that actually uses it.
• Risk = function of threat × vulnerability × impact, reduced by controls. VA measures only the vulnerability term; VM converts it into business risk.
• Exposure vs vulnerability: exposure is a configuration or information leak that aids an attacker (verbose banner, open RDP to internet) without itself being a flaw.
• Zero-day: vulnerability with no vendor patch available; n-day: patch exists but is not applied - the vast majority of real incidents.
• Attack surface: the sum of reachable entry points. Attack vector: the path used (network, adjacent network, local, physical).

Classification and standards ecosystem

• CVE (Common Vulnerabilities and Exposures): a unique identifier per public vulnerability, e.g. CVE-2021-44228 (Log4Shell). Run by MITRE with CNAs (CVE Numbering Authorities); it names, it does not score.
• CWE (Common Weakness Enumeration): the *class* of defect, independent of any product. Standard examples: CWE-79 cross-site scripting, CWE-89 SQL injection, CWE-787 out-of-bounds write, CWE-22 path traversal, CWE-287 improper authentication. A CVE is an instance; a CWE is the category - one CWE covers thousands of CVEs.
• CVSS (Common Vulnerability Scoring System): severity scoring, 0.0-10.0. v3.1 is still the most widely deployed; v4.0 (released 2023) is being adopted and splits the score into Base, Threat, Environmental and Supplemental metric groups.
• NVD (National Vulnerability Database, NIST): enriches CVEs with CVSS, CPE and CWE. CPE is the standard naming of product/version. OVAL/SCAP/XCCDF are the automation formats scanners use for compliance checks.
• EPSS (Exploit Prediction Scoring System): probability (0-1) that a CVE will be exploited in the wild in the next 30 days - a likelihood measure, complementing CVSS severity.
• KEV (Known Exploited Vulnerabilities) catalogue: CISA's authoritative list of CVEs with confirmed in-the-wild exploitation; widely used in India as a "patch first" list.
• CVSS severity bands: 0.1-3.9 Low, 4.0-6.9 Medium, 7.0-8.9 High, 9.0-10.0 Critical (0.0 = None).
• Other catalogues: OWASP Top 10 for web risk classes, CIS Benchmarks for secure configuration baselines, NIST SP 800-40 for patch management guidance, ISO/IEC 29147 (disclosure) and ISO/IEC 30111 (handling).

Types of assessment and scanning techniques

• Network/infrastructure VA: host discovery plus port, service and version detection across IP ranges.
• Host/endpoint VA: patch-level and configuration audit on the OS, usually agent-based.
• Application VA: DAST (black-box, runtime), SAST (source code), IAST, and SCA (software composition analysis for third-party libraries, driven by an SBOM in CycloneDX or SPDX format).
• Database, cloud (CSPM), container/image, wireless and OT/ICS assessments - OT needs passive scanning, since active probes can crash PLCs.
• Credentialed (authenticated) vs non-credentialed: credentialed scans log in and read real patch levels - far more accurate, far fewer false positives. Uncredentialed scans see only what the network exposes.
• Agent-based vs network-based: agents cover roaming laptops and need no open ports; network scans cover appliances and unmanaged devices. Mature programmes use both.
• Active vs passive: active sends probes; passive (network sensors, traffic analysis) is safe for fragile and OT networks but less complete.
• Internal vs external: external scans model an internet attacker; internal scans model post-breach lateral movement.
• Safe checks vs intrusive checks: safe checks infer from version/banner; intrusive checks may attempt a benign exploit and can cause denial of service - always get written approval and a change window.

The vulnerability management lifecycle

1. Discover / inventory: build and continuously update the asset register with ownership, business criticality and data classification.
2. Categorise and prioritise assets: crown-jewel systems (core banking, UPI switch, PII stores) get tighter scan frequency and SLAs.
3. Scan / assess: scheduled authenticated scans plus continuous agent telemetry; define scope, credentials, bandwidth throttling and blackout windows.
4. Validate and triage: remove false positives, confirm reachability and compensating controls, deduplicate findings per asset.
5. Risk-rank: combine CVSS base, EPSS, KEV status, asset criticality and exposure (internet-facing?) into a single prioritised queue.
6. Remediate: patch, upgrade, reconfigure, or - where patching is impossible - mitigate (WAF rule, segmentation, disable service) or formally accept the risk with sign-off and an expiry date.
7. Verify: rescan to confirm closure; never close on a ticket comment alone.
8. Report and improve: dashboards, trends, MTTR, SLA compliance, exception register; feed root causes back into hardening baselines and SDLC.
9. Vulnerability management vs patch management: patching is one remediation action; VM is the whole risk-decision process, including findings that have no patch.

Tools, and VA versus penetration testing

• Discovery/network: Nmap (-sS, -sV, -O, --script vuln), Masscan for large ranges.
• Vulnerability scanners: Nessus, Qualys VMDR, Rapid7 InsightVM, Tenable.io, OpenVAS/Greenbone (open-source), Microsoft Defender Vulnerability Management, Nikto (web server), WPScan.
• Web/app: OWASP ZAP, Burp Suite Professional scanner, SQLMap for verification; SonarQube/Semgrep (SAST), OWASP Dependency-Check/Trivy/Grype (SCA and container images).
• Config/compliance: CIS-CAT, Lynis, OpenSCAP, Prowler and ScoutSuite for AWS/Azure/GCP.
• Correlation/tracking: DefectDojo, Faraday, or the VM module of a SIEM/ITSM (ServiceNow VR, Jira).
• Key distinction: VA answers "what weaknesses exist and how severe?" - broad, repeatable, low-risk, reported as a ranked list. Pen testing answers "can an attacker actually get in and how far?" - narrow, creative, exploit-driven, reported as attack chains. VAPT in Indian tender language means both delivered together.
• Scanner limitations: false positives and false negatives, no business-logic flaws, blind to custom authorisation errors, version-inference errors, credentialed-scan coverage gaps, inability to judge business impact, and risk of disruption on fragile devices.

Indian standards, law and practice

• CERT-In (Indian Computer Emergency Response Team, MeitY) is the national nodal agency under Section 70B of the Information Technology Act, 2000. Its Directions of 28 April 2022 require reportable cyber incidents (including unauthorised access and vulnerability exploitation) to be reported to CERT-In within 6 hours of noticing, mandate synchronisation with NIC/NPL NTP, and require logs to be retained 180 days within India.
• CERT-In empanelled auditors: government bodies and most regulated entities must have VAPT performed by a CERT-In empanelled information-security auditing organisation; the panel list is revised periodically.
• NCIIPC (under Section 70A, IT Act) protects critical information infrastructure - power, banking, telecom, transport, defence - and issues guidelines and advisories.
• RBI: cyber-security frameworks for banks, UCBs, NBFCs and payment operators require periodic VA/PT, prompt patching and board-level reporting; the Master Direction on IT Governance, Risk, Controls and Assurance Practices (effective 1 April 2024) requires a documented VA/PT policy and tracking to closure. Specific timelines differ by circular - check the current text before quoting.
• SEBI CSCRF (Cyber Security and Cyber Resilience Framework, 2024) consolidates earlier circulars for market intermediaries, with VAPT and periodic audit requirements.
• Digital Personal Data Protection Act, 2023: obliges a Data Fiduciary to take reasonable security safeguards and to notify the Data Protection Board and affected Data Principals of a personal-data breach; rules operationalising it have been notified in stages, so check current status for timelines.
• ISO/IEC 27001:2022 Annexure A controls that drive VM: A.8.8 management of technical vulnerabilities, A.8.9 configuration management, A.8.32 change management, A.5.7 threat intelligence. PCI DSS v4.0 requires internal and external scans at least quarterly, external scans by an ASV, and a clean/passing scan after remediation.
• Unauthorised scanning is an offence - scanning systems you do not own or have written authorisation for can attract Section 43 (civil liability) and Section 66 (computer-related offences) of the IT Act, 2000. Always hold a signed scope and authorisation letter ("get-out-of-jail" letter) before any scan.
• Bug-bounty and coordinated disclosure practice is growing (NCIIPC's Responsible Vulnerability Disclosure Programme; private programmes by Indian fintechs).

Key points

• Vulnerability assessment - broad, automated identification and scoring of weaknesses; no exploitation and no proof of impact.
• Vulnerability management - the continuous lifecycle: discover, assess, prioritise, remediate, verify, report.
• CVE - unique identifier for a specific public vulnerability; CWE - the weakness class; CPE - product naming; NVD - enrichment database.
• CVSS - 0-10 severity; Base metrics are AV, AC, PR, UI, Scope (v3.1) and the CIA impacts; v4.0 adds Threat, Environmental and Supplemental groups.
• EPSS - probability of exploitation in 30 days; KEV - list of CVEs confirmed exploited. Severity ≠ likelihood ≠ risk.
• Credentialed scanning - logs into the host, reads true patch state, drastically reduces false positives.
• False positive - reported but not real (wasted effort); false negative - real but missed (dangerous). Validation step exists for both.
• Risk-based prioritisation - CVSS alone over-floods the queue; combine exploitability, internet exposure and asset criticality.
• Compensating control - WAF signature, segmentation, disabling a feature, when no patch exists.
• Risk acceptance - documented, time-bound, owner-signed exception; not an excuse for indefinite deferral.
• MTTR / SLA - the headline VM metrics: typical Indian enterprise targets are Critical 7-15 days, High 30 days, Medium 60-90 days (policy-dependent).
• Scan window and throttling - scans are load events; schedule off-peak and exclude fragile OT/legacy devices or use passive methods.
• SBOM + SCA - the only practical way to find vulnerable third-party libraries like Log4j in your own builds.
• CERT-In - nodal agency under Section 70B, IT Act 2000; 6-hour incident reporting, 180-day Indian log retention (2022 Directions).
• Authorisation letter - mandatory before scanning; unauthorised scanning risks Sections 43 and 66 of the IT Act, 2000.
• Verification rescan - a vulnerability is closed only when a rescan confirms it; closure on claim is the commonest audit failure.
• Patch management ≠ vulnerability management - patching is one treatment option inside a wider risk process.

Formulas and examples

Example 1 - CVSS v3.1 base score for an unauthenticated remote RCE. Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

• Weights: AV:N = 0.85, AC:L = 0.77, PR:N = 0.85, UI:N = 0.85.
• Exploitability = 8.22 × 0.85 × 0.77 × 0.85 × 0.85 = 3.887.
• ISS = 1 − (1−0.56)³ = 1 − 0.44³ = 1 − 0.085184 = 0.914816; Impact = 6.42 × 0.914816 = 5.873.
• Sum = 3.887 + 5.873 = 9.760 → Roundup to one decimal = 9.8 (Critical). This is the classic "9.8" seen on Log4Shell-class flaws.

Example 2 - risk-based prioritisation of a 2,000-finding backlog.

Order of work: A, C, D, B. Note that C (Medium severity) outranks B (Critical severity) - the point of risk-based VM. Patching A and C first removes the two highest-risk items while touching only 2 of 4 change tickets.

Example 3 - false positive rate and precision. A credentialed Nessus scan of 500 Linux servers reports 1,250 High/Critical findings. Manual validation confirms 1,000 real, 250 not real; a later pen test finds 50 real High issues the scan missed.

• FP rate = 250 ÷ (250 + 1,000) × 100 = 20%.
• Precision = 1,000 ÷ 1,250 = 0.80 (80%).
• Recall = 1,000 ÷ (1,000 + 50) = 0.952 (95.2%).
• Vulnerability density = 1,000 ÷ 500 = 2.0 valid findings per server.

Example 4 - SLA compliance and MTTR. Twelve Critical vulnerabilities closed in a quarter; SLA = 15 days. Closure ages (days): 3, 5, 7, 8, 10, 12, 14, 15, 18, 22, 30, 36.

• Σ = 3+5+7+8+10+12+14+15+18+22+30+36 = 180 → MTTR = 180 ÷ 12 = 15.0 days.
• Within SLA (≤15 days) = 8 of 12 → compliance = 8 ÷ 12 × 100 = 66.7% (fails a typical 95% target).
• Median = (12 + 14)/2 = 13 days - better than the mean, showing four long tail breaches drag MTTR up. Report both.

Example 5 - scan effort and window planning. A bank must scan 3,000 hosts. A single scanner engine handles 20 hosts in parallel, averaging 6 minutes per credentialed host.

• Throughput = 20 ÷ 6 = 3.333 hosts/minute = 200 hosts/hour.
• Total = 3,000 ÷ 200 = 15 hours - exceeds a 6-hour nightly window.
• Needed engines = 15 ÷ 6 = 2.5 → 3 scanner engines (or split into three nightly batches of 1,000 hosts each, 5 hours per night).

Where it is used

• BFSI: RBI-regulated banks, NBFCs and payment aggregators run quarterly/continuous VA on core banking, UPI and card systems; PCI DSS ASV scans for anyone handling card data.
• IT services and GCCs: TCS, Infosys, Wipro, HCLTech, Tech Mahindra, LTIMindtree and Accenture staff large VM/VAPT practices delivering managed vulnerability services to global clients.
• Government and PSUs: NIC, UIDAI, state data centres and e-governance portals require VAPT by CERT-In empanelled auditors before go-live and after major change; NCIIPC oversight for critical sectors.
• Product and cloud security: DevSecOps pipelines at Indian SaaS firms (Zoho, Freshworks, Razorpay, Zerodha) gate builds on SAST/SCA/container-image scans and SBOM checks.
• Telecom and OT: Jio, Airtel and power utilities use passive and credentialed assessment for network elements and SCADA, where active scanning is restricted.
• Job roles: VAPT analyst, vulnerability management engineer, SOC L1/L2, application security engineer, cloud security engineer, IT auditor and GRC consultant; certifications valued are CEH, OSCP, CompTIA Security+/PenTest+, eJPT, and vendor tracks from Qualys/Tenable.

Interview questions

• Q: Difference between vulnerability assessment and penetration testing? A: VA broadly identifies and scores weaknesses, mostly automated and non-exploitative; a pen test selectively exploits them to prove real impact and attack chains.
• Q: What is the difference between CVE, CWE and CVSS? A: CVE is the unique ID of a specific vulnerability, CWE is the class of weakness behind it, and CVSS is the numeric severity score assigned to it.
• Q: Why is CVSS alone a poor prioritisation method? A: It measures intrinsic severity, not likelihood or business context; combining it with EPSS, KEV status, internet exposure and asset criticality produces a far smaller, truer priority queue.
• Q: Why do credentialed scans give better results? A: They authenticate and read actual package versions, registry and configuration, instead of inferring from banners - so both false positives and false negatives drop sharply.
• Q: What would you do about a Critical finding with no vendor patch? A: Apply compensating controls - virtual patching at the WAF, disabling the vulnerable feature, network segmentation, tighter monitoring - and raise a time-bound, owner-signed risk acceptance until a patch arrives.
• Q: How do you handle a false positive? A: Validate manually (check version, configuration, reachability), document the evidence, mark it as a false positive with a review date, and tune the scan policy or plugin so it does not recur.
• Q: Can a vulnerability scan cause an outage? A: Yes - intrusive plugins, aggressive timing or fragile OT/legacy devices can crash services; mitigate with safe checks, throttling, change windows and passive scanning on OT.
• Q: Which metrics would you present to management? A: Open findings by severity and age, MTTR against SLA, SLA compliance percentage, trend of new vs closed, internet-facing and KEV-listed exposure, and the open exception register.
• Q: What is a zero-day versus an n-day, and which hurts Indian enterprises more? A: A zero-day has no patch; an n-day has one that is unapplied. N-days cause most real incidents because patching lags.
• Q: What is an SBOM and why does VM need it? A: A machine-readable inventory of components in a build (CycloneDX/SPDX); without it you cannot answer "are we affected?" for a library flaw like Log4Shell.
• Q: What legal clearance do you need before scanning in India? A: A signed scope and authorisation from the asset owner (and cloud provider rules where applicable); unauthorised scanning can attract Sections 43 and 66 of the IT Act, 2000.
• Q: How soon must a cyber incident be reported to CERT-In? A: Under the CERT-In Directions of 28 April 2022, within 6 hours of noticing a reportable incident, with logs retained 180 days within India.
• Q: When do you consider a vulnerability closed? A: Only after a verification rescan (or retest) shows it absent; a remediation claim or closed ticket is not evidence.

Common mistakes

• Treating a scanner report as the deliverable - no validation, no deduplication, no risk ranking, and no business context.
• Confusing CVE with CVSS, or quoting a severity band wrongly (7.0-8.9 is High; 9.0-10.0 is Critical).
• Running uncredentialed scans and then arguing about the resulting false positives instead of fixing the credentials.
• Equating vulnerability management with patching, and having no process for findings that have no patch.
• Closing tickets without a verification rescan, so the same finding reappears next quarter as "new".
• Scanning out of scope or without written authorisation - an exam answer that ignores authorisation loses marks, and in the field it is an offence.
• Quoting a single unqualified SLA or statistic as universal - remediation timelines are set by the organisation's policy and its regulator, so state the source.
• Scanning OT/SCADA or legacy medical devices actively, and causing the outage the programme was meant to prevent.

Related topics

Ethical hacking and penetration testing · Web application security (OWASP Top 10) · Security operations: SOC and SIEM · Threat intelligence and MITRE ATT&CK · Incident response and threat hunting · Security governance, risk and compliance (ISO 27001, PCI DSS)