Vulnerability Management and Security Testing

Introduction

Vulnerability management is the continuing process of identifying, evaluating, treating and verifying weaknesses in information systems. It is broader than running a scanner. Effective vulnerability management connects technical findings with asset ownership, business criticality, threat intelligence, remediation capability and evidence that risk has actually been reduced.

Security testing provides complementary assurance. Vulnerability assessment seeks to discover and classify weaknesses; penetration testing validates whether weaknesses can be exploited; red teaming examines whether an organisation can prevent, detect and respond to a realistic adversary; and security auditing evaluates conformity with defined requirements. Confusing these activities can produce either false confidence or unnecessary operational risk.

This chapter presents a threat-informed and risk-based approach suitable for enterprise networks, cloud environments, applications, endpoints and operational technology. All testing must be authorised, scoped and conducted within applicable legal, contractual and ethical boundaries.

Learning Objectives

After completing this chapter, students should be able to:

• discover and classify assets and their owners;
• explain the vulnerability-management lifecycle;
• conduct or interpret vulnerability scanning responsibly;
• prioritise findings using business impact, exploitability and threat evidence;
• distinguish vulnerability assessment, penetration testing, red teaming and auditing;
• plan remediation and validate that weaknesses have been resolved;
• apply governance, legal, safety and ethical controls to security testing;
• evaluate the limitations of scanners and testing programmes.

1. The Vulnerability Management Lifecycle

A mature programme is cyclical rather than a one-time project. Its principal stages are:

1. Prepare and govern: define authority, scope, risk appetite, rules of engagement, data-handling requirements and escalation procedures.
2. Discover assets: identify devices, applications, identities, cloud resources, data stores, interfaces and dependencies.
3. Assess exposure: collect configuration, software-version, patch, identity and control information; perform appropriate scanning and testing.
4. Analyse and prioritise: determine whether findings are genuine, exploitable and important to the organisation.
5. Treat risk: remediate, mitigate, transfer or formally accept the risk.
6. Validate: retest the weakness and verify that the corrective action did not create unacceptable side effects.
7. Report and improve: measure performance, identify systemic causes and update controls.

Figure: The vulnerability-management lifecycle is iterative and evidence-driven.

Asset Discovery

An organisation cannot protect what it does not know exists. Discovery should combine several sources:

• network and cloud enumeration;
• endpoint-management and configuration-management databases;
• directory, identity and access-management records;
• DNS, certificate-transparency and externally observable services;
• software inventories and dependency manifests;
• application portfolios and data-classification registers;
• procurement, ownership and business-service records.

Discovery should record an asset identifier, hostname or address, owner, environment, business service, location, technology, data handled, exposure, dependencies and lifecycle status. Passive techniques are preferable during initial reconnaissance because they reduce disruption. Active discovery should be authorised and rate-limited, especially in fragile or operational-technology environments.

Asset inventories decay quickly. Cloud resources may be created automatically, temporary systems may be omitted, and unmanaged devices may connect to the network. Reconciliation, tagging standards, ownership accountability and continuous discovery are therefore essential.

Vulnerability Identification

A vulnerability is a weakness that can be exploited to violate confidentiality, integrity, availability or other security properties. Common sources include:

• missing or ineffective patches;
• insecure default configurations;
• excessive privileges;
• exposed administrative interfaces;
• weak authentication or session management;
• unsafe software dependencies;
• inadequate segmentation;
• insecure application logic;
• secrets embedded in code or configuration;
• unsupported or end-of-life technology.

Scanning may be credentialed or uncredentialed. Credentialed scanning can inspect installed packages, local configuration and patch state more accurately. Uncredentialed scanning approximates the view of an external or less trusted actor but may miss local weaknesses. Neither method proves exploitability by itself.

2. Vulnerability Scanning and Assessment

A vulnerability scanner compares observed conditions with signatures, version data, configuration rules or behavioural tests. A responsible assessment programme defines targets, scan windows, exclusions, authentication methods, traffic limits and emergency contacts before scanning begins.

Types of Assessment

Results require triage. A scanner may produce false positives because a version is reported incorrectly, a compensating control exists, or the vulnerable function is not enabled. False negatives arise from incomplete asset coverage, unsupported technologies, encrypted traffic, insufficient credentials or novel attack techniques.

A finding should normally contain an affected asset, evidence, weakness description, affected component, probable attack path, severity, confidence, remediation recommendation, owner and due date. Repeated findings should be deduplicated without losing asset-level accountability.

Standards and Classification

Common Vulnerabilities and Exposures (CVE) identifiers provide a shared reference for publicly known vulnerabilities. The Common Vulnerability Scoring System (CVSS) expresses technical severity using factors such as attack vector, privileges required, user interaction and impacts on confidentiality, integrity and availability. CVSS is not a complete organisational risk calculation: it does not automatically incorporate asset value, business consequences, exposure duration, compensating controls or current exploitation in a particular organisation.

Weakness classifications such as CWE help identify recurring coding or design causes. Software bills of materials can improve visibility into third-party components, but their value depends on accuracy, completeness and timely vulnerability intelligence.

3. Risk-Based Prioritisation

Prioritisation converts technical observations into treatment decisions. A useful decision considers:

• asset criticality: impact on essential services, safety, revenue, legal obligations and sensitive data;
• exposure: internet accessibility, reachable trust paths and network location;
• exploitability: required access, complexity, privileges and user interaction;
• threat evidence: exploitation in the wild, targeted activity, exploit availability and threat-actor interest;
• control context: segmentation, monitoring, backups, application controls and compensating safeguards;
• remediation feasibility: availability of patches, maintenance windows and regression risk.

A high technical score on a laboratory server may deserve less immediate attention than a moderate weakness on an exposed identity provider. Conversely, an apparently low-severity issue can become critical when chained with other weaknesses.

A simple qualitative model is often more defensible than false numerical precision. For example, a finding may be rated critical when it combines internet exposure, credible exploitation, privileged access and major business impact. Organisations may supplement this with a quantitative model, but assumptions and uncertainty must be documented. Risk acceptance should be time-limited, owned by an accountable authority and supported by compensating controls.

Threat-informed prioritisation uses intelligence to ask whether adversaries are exploiting the weakness, whether the organisation resembles known targets and whether the weakness enables a recognised attack path. Frameworks such as the Cyber Kill Chain and MITRE ATT&CK can help describe adversary behaviour, but they do not replace asset-specific analysis.

4. Remediation, Mitigation and Validation

Remediation eliminates or reduces the weakness. Actions include patching, upgrading, changing configuration, removing unnecessary services, correcting code, rotating exposed secrets, strengthening authentication and reducing privileges. Mitigation lowers probability or impact when immediate remediation is impossible. Examples include segmentation, web-application firewalls, temporary access restrictions, enhanced monitoring and disabling vulnerable functionality.

Good remediation tickets specify the affected asset, evidence, risk rationale, action, owner, deadline, maintenance requirements, rollback plan and validation method. Emergency changes may be necessary for actively exploited vulnerabilities, but they still require change records and post-implementation review.

Validation should be independent enough to avoid confirmation bias. It may include:

• rescanning with a current detection method;
• checking the installed version and configuration;
• repeating a safe proof of vulnerability;
• reviewing logs and access controls;
• testing dependent services for regression;
• confirming that the original attack path is closed.

A scanner reporting “fixed” is not always sufficient. The patch may be applied to only one node, a vulnerable service may remain exposed through another interface, or a compensating control may fail under realistic conditions. Closure evidence should be retained according to organisational policy.

5. Distinguishing Security Testing Activities

These activities overlap but are not interchangeable. A penetration test has defined targets and technical objectives. A red team may use social engineering, physical access or cloud identities, but only if specifically approved. Auditing evaluates conformity against criteria such as policy, contract, regulation or a control framework. A clean audit does not prove that an organisation is resistant to attack, and a penetration test does not establish broad regulatory compliance.

Penetration-Test Lifecycle

A professional test includes pre-engagement, reconnaissance, controlled discovery, vulnerability analysis, exploitation where authorised, post-exploitation limited to agreed objectives, cleanup, reporting and retesting. Rules of engagement should define source addresses, targets, prohibited actions, test times, data handling, emergency stop conditions, communication channels and evidence requirements.

Testing should avoid destructive payloads, uncontrolled denial of service, unnecessary access to personal data and persistence that could remain after the engagement. Credentials and captured data must be protected, minimised and securely destroyed when no longer required.

Red-Team and Blue-Team Learning

Red-team success is not measured only by obtaining access. Meaningful measures include whether defenders detected relevant behaviours, escalated correctly, contained activity and recovered within agreed objectives. Purple teaming combines offensive and defensive personnel to test specific detections and improve them iteratively. This can provide more repeatable learning than an infrequent, opaque exercise.

6. Case Study: Illustrative Online Retailer

Background

A fictional online retailer, Northstar Retail, operates a public web application, a cloud identity platform, warehouse systems and a payment service provider. Its monthly scanner reports 2,400 findings, including many medium-severity software issues. The security team cannot remediate all findings within existing maintenance windows.

Problem

The organisation treats scanner severity as the queue order. Internet-facing assets are incompletely inventoried, ownership is unclear, and closure occurs when a ticket is marked complete. A recently disclosed vulnerability is being actively exploited against internet-facing edge devices.

Analysis

The team first reconciles DNS, cloud inventories, certificates, endpoint records and business-service maps. It identifies an unregistered administration interface connected to the identity platform. Threat intelligence shows exploitation of the edge-device vulnerability, while the identity platform contains privileged accounts and supports all major services. The combination of exposure, threat evidence and business impact makes these findings urgent, even though some internal servers have higher raw scanner scores.

Approach and Solution

Northstar establishes emergency change authority, isolates the administration interface, applies the vendor fix to redundant edge devices and validates the fix from an external test location. It rotates credentials that may have been exposed, reviews authentication logs and adds detection for the relevant attack behaviour. It then assigns owners to all critical services, introduces authenticated scanning, and replaces the single severity queue with a risk-based matrix. Findings without sufficient evidence are returned for triage rather than automatically assigned to engineers.

A controlled penetration test checks whether the original access path remains viable. A purple-team exercise tests detection and response for suspicious administrative access. Risk accepted for legacy warehouse systems is documented with compensating segmentation, monitoring and a replacement deadline.

Outcome

The number of open findings initially increases because discovery improves. This is not programme failure; it indicates better visibility. High-risk exposure is reduced, remediation ownership becomes measurable, and validation evidence is attached to closure decisions. Management receives service-level measures rather than a misleading count of scanner findings.

Learning Points

1. Asset visibility is a prerequisite for meaningful vulnerability metrics.
2. Threat activity and business context can outweigh a generic severity score.
3. Remediation requires ownership and validation, not merely ticket closure.
4. Testing should examine both attack paths and defensive response.
5. More findings after improved discovery may represent improved governance.

7. Metrics and Programme Governance

Useful measures include asset-discovery coverage, percentage of assets with owners, authenticated-scan coverage, mean time to remediate by risk class, overdue-risk acceptance, recurrence rate, validation success rate and age of the oldest critical exposure. Metrics should distinguish volume from risk. A declining number of findings may mean effective remediation—or declining scan coverage.

Governance should define accountability among security teams, system owners, change managers, risk owners, suppliers and executive leadership. Exceptions require justification, compensating controls, expiry dates and review. Third-party contracts should address notification of vulnerabilities, testing permission, evidence sharing, remediation obligations and supply-chain dependencies.

8. Ethical, Legal and Safety Considerations

Authorisation is the foundation of ethical testing. Written permission should identify the organisation, systems, dates, methods, testing team and limits. Testing another party’s system without permission can violate computer-misuse, privacy, telecommunications or contractual law, even when the intention is defensive.

Professionals must protect personal data, avoid unnecessary collection, maintain confidentiality, preserve evidence integrity and disclose serious findings responsibly. Safety is especially important in healthcare, industrial control, transport and other environments where service interruption can cause physical harm. Testers should use representative test data where possible, establish stop conditions and coordinate with operational personnel.

Responsible disclosure requires clear communication, reasonable remediation opportunity and careful handling of technical details. Organisations should not conceal material risk from affected stakeholders, but public disclosure must also avoid enabling immediate harm.

9. Contemporary Developments and the Role of AI

Cloud-native systems, containers, infrastructure as code, APIs, software supply chains and ephemeral workloads require assessment during development and deployment, not only after production release. Continuous integration pipelines can combine secret scanning, dependency analysis, infrastructure-configuration checks and application testing. These controls must be tuned to avoid alert fatigue.

AI can assist with finding deduplication, asset classification, code analysis, attack-path hypothesis generation and natural-language reporting. However, AI-generated findings may be inaccurate, omit context or expose confidential data to an external service. Human review, provenance, access controls and reproducible evidence remain necessary. AI should support, not replace, authorised expert judgement.

Challenges and Limitations

No assessment provides absolute assurance. Unknown vulnerabilities, configuration drift, incomplete inventories, zero-day exploitation, supply-chain compromise and human error remain possible. Scanners can be noisy; penetration tests are time-bounded; audits depend on evidence quality; and red-team results may be influenced by the selected objectives and rules. Excessive testing can disrupt systems or create sensitive evidence that itself requires protection.

A mature programme therefore combines preventive engineering, secure design, patch and configuration management, threat intelligence, monitoring, incident response and recovery. Vulnerability management is a risk-reduction discipline, not a contest to achieve zero findings.

Best-Practice Checklist

• Maintain a continuously reconciled asset inventory.
• Assign every important asset and service an accountable owner.
• Use authenticated and unauthenticated assessment appropriately.
• Prioritise using business impact, exposure, exploitability and threat evidence.
• Separate scanner severity from organisational risk.
• Define remediation service levels and time-limited exceptions.
• Validate fixes independently and test for regression.
• Authorise penetration tests and red-team exercises in writing.
• Protect test data, credentials and personal information.
• Measure coverage, timeliness, recurrence and risk reduction.
• Integrate security testing into development, cloud deployment and change management.

Chapter Summary

Vulnerability management is a continuous lifecycle of governance, asset discovery, assessment, prioritisation, treatment, validation and improvement. Reliable programmes combine passive and active discovery, authenticated and unauthenticated scanning, human triage and accurate ownership. Technical severity alone is insufficient: exposure, business impact, exploitability, threat intelligence and compensating controls must inform treatment decisions.

Vulnerability assessment, penetration testing, red teaming and auditing answer different questions and produce different forms of assurance. All require clear authorisation, safe rules of engagement and protection of sensitive evidence. Remediation must be demonstrated through validation, while governance should measure coverage and risk reduction rather than merely counting findings. Cloud change, software supply chains and AI-assisted analysis make continuous, human-supervised testing increasingly important.

Key Terms

Asset discovery: The process of identifying systems, services, applications, data and dependencies.

Attack surface: The collection of points through which an asset or service may be reached or influenced.

CVE: A public identifier for a known cybersecurity vulnerability.

CVSS: A framework for communicating the technical severity of vulnerabilities.

CWE: A classification of common software and hardware weaknesses.

False negative: A vulnerability that exists but is not detected by an assessment.

False positive: A reported vulnerability that is absent or not applicable.

Mitigation: A measure that reduces risk without necessarily removing the underlying weakness.

Penetration testing: Authorised testing that attempts controlled exploitation of selected weaknesses.

Purple teaming: Collaborative improvement involving offensive and defensive security teams.

Red teaming: Adversary emulation designed to test organisational prevention, detection and response.

Remediation: Action that removes or materially reduces a vulnerability.

Risk acceptance: A documented decision to retain a known risk under defined conditions.

Rules of engagement: Written limits and procedures governing a security test.

Security audit: A systematic evaluation against specified requirements or control criteria.

Threat-informed security: Security decision-making guided by evidence about adversaries and their behaviour.

Validation: Evidence-based confirmation that remediation worked and did not create unacceptable regression.

Vulnerability: A weakness that may be exploited to compromise a security property.

Vulnerability assessment: Systematic identification and evaluation of potential weaknesses.

Review Questions

Short Answer Questions

1. Why is asset discovery foundational to vulnerability management?
2. Distinguish a false positive from a false negative.
3. What information should a remediation ticket contain?
4. Why is CVSS not a complete organisational risk measure?
5. State two safeguards required before penetration testing begins.

Long Answer Questions

1. Explain the vulnerability-management lifecycle and the relationship between its stages.
2. Compare vulnerability assessment, penetration testing, red teaming and security auditing.
3. Discuss how business criticality and threat intelligence should influence prioritisation.
4. Explain why remediation validation is necessary even after a scanner reports a fix.
5. Evaluate the ethical and legal responsibilities of a professional security-testing team.

Analytical / Application Questions

1. An internet-facing identity server has a moderate technical score and a privately hosted database has a critical score but no reachable path from outside the network. Which should be investigated first, and what additional evidence would you request?
2. A company’s open findings increase by 40% after it introduces cloud discovery. Analyse whether this necessarily indicates deteriorating security and identify suitable programme metrics.
3. Design a safe testing plan for a healthcare organisation that includes public web applications, clinical devices and third-party cloud services. Specify scope, safety controls, evidence handling and validation methods.

Multiple Choice Questions with Answers

Question 1

Which activity primarily evaluates whether controls conform to defined requirements?

A. Security auditing

B. Red teaming

C. Vulnerability scanning

D. Exploit development

Correct Answer: A. Security auditing

Question 2

What is the most important reason for maintaining an asset inventory?

A. To eliminate all false positives

B. To identify what must be protected and assessed

C. To guarantee that every vulnerability has a CVE

D. To replace incident response

Correct Answer: B. To identify what must be protected and assessed

Question 3

Which factor is not automatically represented by a technical CVSS score?

A. Attack vector

B. Privileges required

C. Business service criticality

D. User interaction

Correct Answer: C. Business service criticality

Question 4

What is a false negative?

A. A real vulnerability reported twice

B. A reported issue that is not applicable

C. A real vulnerability missed by the assessment

D. A risk formally accepted by management

Correct Answer: C. A real vulnerability missed by the assessment

Question 5

Which action best demonstrates remediation validation?

A. Closing the ticket when a patch is requested

B. Repeating an appropriate test and checking for regression

C. Increasing the scanner’s severity rating

D. Deleting the original finding

Correct Answer: B. Repeating an appropriate test and checking for regression

Question 6

What distinguishes red teaming from ordinary vulnerability assessment?

A. Red teaming never requires authorisation

B. Red teaming emulates an adversary to test organisational response

C. Red teaming only reviews written policies

D. Red teaming cannot involve detection controls

Correct Answer: B. Red teaming emulates an adversary to test organisational response

Question 7

Which is an example of mitigation rather than direct remediation?

A. Applying the vendor patch

B. Removing the vulnerable service

C. Segmenting the system while a permanent fix is prepared

D. Correcting the vulnerable source code

Correct Answer: C. Segmenting the system while a permanent fix is prepared

Question 8

Why should active scanning of operational technology be carefully controlled?

A. It always produces no results

B. It may disrupt fragile or safety-critical systems

C. It cannot identify network addresses

D. It is prohibited in every jurisdiction

Correct Answer: B. It may disrupt fragile or safety-critical systems

Question 9

Which practice improves the quality of vulnerability prioritisation?

A. Ordering findings only by scanner score

B. Ignoring asset ownership

C. Combining exposure, business impact and threat evidence

D. Treating all findings as equally urgent

Correct Answer: C. Combining exposure, business impact and threat evidence

Question 10

What is a key limitation of AI-assisted security analysis?

A. It can never process security data

B. Its output may be inaccurate and requires human review

C. It removes the need for authorisation

D. It guarantees reproducible evidence

Correct Answer: B. Its output may be inaccurate and requires human review