Vulnerability Assessment and Security Testing

Introduction

Vulnerability assessment and security testing are essential activities in the security lifecycle. They provide evidence about weaknesses in information assets, the likelihood that those weaknesses will be exploited, and the consequences for confidentiality, integrity and availability. Unlike a simple software scan, a professional assessment combines asset discovery, technical testing, configuration review, human judgement, business context and controlled validation.

The central purpose is not to produce the largest possible list of findings. It is to help an organisation make defensible decisions: which weaknesses require immediate action, which can be accepted temporarily, which need compensating controls, and which results require further investigation. A technically accurate finding that is not prioritised or communicated effectively has limited security value.

Vulnerability assessment must also be distinguished from penetration testing. Vulnerability assessment generally identifies and evaluates weaknesses at scale, often using automated tools. Penetration testing is a controlled attempt to demonstrate whether selected weaknesses can be chained or exploited under an agreed scope. Both activities require authorisation, safety controls and professional reporting.

Learning Objectives

By the end of this chapter, students should be able to:

• discover and classify assets within an authorised environment;
• design a vulnerability assessment and controlled penetration-testing engagement;
• explain the role of CVE, CVSS, configuration standards and threat intelligence;
• interpret scan results and distinguish evidence from scanner assumptions;
• validate findings without causing unnecessary disruption;
• prioritise remediation using exploitability, business impact and risk;
• produce technically sound, ethical and actionable security reports.

1. The Assessment Lifecycle

A mature assessment follows a repeatable lifecycle. The stages are related but not strictly linear because new evidence may require earlier stages to be revisited.

Figure: A continuous vulnerability assessment lifecycle.

1.1 Authorisation and Rules of Engagement

Before technical activity begins, the assessor and asset owner should agree on:

• in-scope networks, applications, cloud accounts, identities and facilities;
• excluded systems, such as safety-critical or fragile industrial equipment;
• testing windows, source addresses and permitted techniques;
• contacts for emergencies and escalation;
• treatment of personal, regulated or commercially sensitive data;
• evidence-retention, encryption and destruction requirements;
• conditions for pausing or terminating testing.

Written authorisation is a core control. Without it, scanning or exploitation may violate criminal law, computer misuse legislation, contractual terms or organisational policy. Authorisation should identify the legal entity, systems, dates, methods and responsible individuals. Third-party hosted systems also require confirmation that the provider permits the activity.

1.2 Discovery and Scoping

Discovery establishes what exists and how it is exposed. Sources include configuration-management databases, cloud inventories, DNS records, certificate transparency records, network-flow data, endpoint agents, passive monitoring and authorised active scanning. No single source is complete. Comparing independent sources reveals unmanaged or unknown assets, often called shadow IT.

Important asset attributes include hostname, IP address, owner, business service, environment, operating system, software versions, trust relationships, data classification, internet exposure and maintenance window. An asset inventory should record confidence and collection date because addresses, containers and cloud resources change rapidly.

Discovery techniques may be passive or active. Passive discovery observes existing traffic, logs or public information and normally has low operational risk. Active discovery sends probes, such as DNS queries, TCP connection attempts or application requests. It is more informative but can trigger alarms, consume resources or affect fragile devices. The choice must follow the rules of engagement.

1.3 Assessment, Validation and Remediation

Scanning identifies possible weaknesses through signatures, version checks, configuration tests and behavioural probes. Results should be validated using multiple evidence sources: service banners, authenticated host data, vendor advisories, configuration files, packet captures, application behaviour and manual review. A scanner result is an assertion, not automatically a confirmed vulnerability.

After prioritisation, remediation may involve patching, configuration change, access restriction, removal of an obsolete service, code correction or deployment of a compensating control. Retesting should determine whether the original condition is resolved and whether the change introduced new weaknesses. Closure requires evidence, not merely a ticket status.

2. Vulnerability Concepts and Classification

A vulnerability is a weakness in design, implementation, configuration or operation that can be used to violate a security property. A threat is a potential cause of harm; a threat actor is an entity capable of acting; an exploit is a technique or code that takes advantage of a vulnerability; and risk combines the likelihood and consequence of an undesirable event.

Common vulnerability classes include:

A vulnerability may exist without a publicly assigned identifier and may be exploitable even when no exploit code is available. Conversely, a CVE may describe a product defect that is not reachable in a particular deployment. Assessment therefore requires deployment-specific reasoning.

2.1 CVE and Vulnerability Identifiers

The Common Vulnerabilities and Exposures system provides standard identifiers and descriptions for publicly disclosed vulnerabilities. A CVE record may include affected products, references, description and publication information. Product identification can be difficult because vendors use different names, package versions and backporting practices.

A CVE is not a risk score. It does not by itself state whether an organisation is exposed, whether exploitation is occurring, or how important the affected asset is. Analysts should check the vendor advisory, affected version range, required preconditions, available fixes and local deployment.

Related databases and advisories may add exploitability information, remediation guidance or affected-product mappings. These sources change over time, so records should include retrieval dates and source references.

2.2 CVSS

The Common Vulnerability Scoring System expresses technical severity using standard metrics. The widely used CVSS version 3.1 base score uses exploitability and impact components. At a conceptual level:

Here, C, I and A are the normalised confidentiality, integrity and availability impact values. For the CVSS v3.1 scope-unchanged case, the impact sub-score is:

The exploitability sub-score is:

AV is attack vector, AC attack complexity, PR privileges required and UI user interaction. The values are prescribed by the CVSS specification rather than invented by the assessor. The final base score is calculated from the specification's rounding rules and metric combinations. Scope-changed cases use a different impact expression, so the simplified expression above must not be applied to them.

CVSS also defines temporal and environmental concepts. Temporal metrics account for factors such as exploit-code maturity and remediation level. Environmental metrics adapt severity to an organisation's asset importance and security requirements. CVSS is technically useful but does not replace business risk assessment.

For example, a remotely reachable flaw with no authentication and no user interaction may have high exploitability. If it affects a public payment service, the business priority may be urgent. The same flaw on an isolated, unused test host may receive a lower operational priority, subject to exposure and compensating controls.

3. Vulnerability Scanning and Configuration Assessment

3.1 Scanner Types

Network scanners identify reachable hosts, ports, protocols and service characteristics. Host-based scanners inspect local software, packages, patches, permissions and configuration. Web application scanners test requests, responses, sessions and common application weaknesses. Cloud-security tools evaluate identity policies, storage exposure, network rules and provider configuration. Container and dependency scanners inspect images, manifests and software components.

Unauthenticated scans see what an external observer can infer. Authenticated scans can inspect installed packages, registry settings, file permissions and local security policy, generally producing better coverage and fewer false positives. Credentials must be least-privileged, protected, time-limited and monitored.

3.2 False Positives and False Negatives

A false positive reports a weakness that is absent or not exploitable in the tested context. Causes include inaccurate version banners, vendor backports, unreachable vulnerable code, incomplete product mapping and generic signatures. A false negative fails to identify a real weakness. Causes include incomplete scope, encrypted traffic that cannot be inspected, rate limits, unsupported technologies, authentication failure and safe-scan settings.

A useful conceptual measure is:

TP means true positives, FP false positives and FN false negatives. These measures are meaningful only when a representative ground truth is available. In operational security, the cost of missed critical weaknesses may be much greater than the cost of investigating extra findings; therefore, a single quality measure should not determine scanning policy.

3.3 Configuration Assessment

Configuration assessment compares observed settings with a baseline. Relevant baselines may include secure vendor guidance, CIS Benchmarks, NIST guidance, sector regulation or an organisation's approved standard. Examples include disabling unused services, restricting management interfaces, enforcing strong authentication, preventing unnecessary administrative privileges, enabling central logging and protecting backups.

A baseline is not universally correct. It must be adapted to system function, availability requirements, legacy constraints and documented exceptions. An exception should identify the owner, reason, risk, compensating controls, expiry or review date, and approving authority. Permanent undocumented exceptions create hidden attack surface.

3.4 Interpreting a Scan Result

Each finding should be analysed using at least the following questions:

1. What asset, interface and software component are affected?
2. What evidence supports the finding?
3. Is the finding confirmed, probable or informational?
4. What preconditions are required for exploitation?
5. Is exploit code or active exploitation known?
6. What data or business service could be affected?
7. Is the asset exposed directly or through a reachable trust path?
8. What remediation and compensating controls are available?
9. How will closure be verified?

Duplicate findings should be consolidated carefully. A single vulnerable library may appear on many hosts, but each host can have different exposure, ownership and business impact. Conversely, separate technical findings may form one attack path and should be explained together.

4. Controlled Penetration Testing

Penetration testing is an authorised, evidence-based simulation of adversarial activity. Its purpose is to establish whether a vulnerability can be used in a defined scenario and to measure the effectiveness of preventive, detective and responsive controls. It is not a licence to attack systems without limits.

Testing approaches include:

• Black-box: little prior information, approximating an external attacker;
• Gray-box: selected information or credentials, often realistic for an insider or compromised account;
• White-box: extensive architecture, code or credential information, supporting deeper coverage;
• External testing: internet-facing services and perimeter controls;
• Internal testing: segmentation, privilege boundaries and internal attack paths;
• Application testing: authentication, authorisation, input handling, session management and business logic;
• Red-team testing: broader objectives and stealth, usually under more stringent governance.

A controlled test normally progresses from reconnaissance to enumeration, vulnerability analysis, limited exploitation, privilege or access-path analysis, impact demonstration and reporting. Exploitation should be minimally invasive. For example, proving read access to a non-sensitive test file is preferable to extracting a production database. Destructive actions, denial-of-service testing, persistence and real data collection require explicit approval, if they are permitted at all.

A professional test records timestamps, source addresses, commands or requests, evidence, affected assets and tester decisions. Sensitive evidence should be minimised, redacted, encrypted and shared only with authorised recipients. Testing should stop when the agreed success condition has been met or when safety thresholds are reached.

5. Risk-Based Prioritisation

Technical severity and business priority are related but not identical. A useful risk model is:

This is a conceptual relationship, not a universal numerical law. Likelihood may be expressed qualitatively or estimated using evidence such as exposure, exploit maturity, required privileges, attacker capability and control effectiveness. Impact may consider confidentiality, integrity, availability, legal obligations, safety, revenue, reputation and recovery cost.

An organisation may use a scoring matrix, provided that its categories are defined consistently. For example, a high-severity vulnerability on an internet-facing identity service, with active exploitation and access to sensitive data, should normally outrank a higher-count collection of low-severity issues on isolated development hosts.

Prioritisation should consider:

• asset criticality and data classification;
• internet exposure and reachable attack paths;
• exploit availability and observed exploitation;
• authentication and user-interaction requirements;
• ease and reliability of exploitation;
• existing preventive and detective controls;
• regulatory or contractual deadlines;
• remediation feasibility and change risk;
• concentration risk, such as one flaw affecting hundreds of assets.

A practical queue can classify actions as emergency containment, urgent remediation, scheduled remediation, risk acceptance or further investigation. Risk acceptance must be explicit, time-bounded and approved by an accountable owner; it is not the same as ignoring a finding.

Worked Prioritisation Example

Consider three findings:

Finding B may have a higher numerical technical score than C, but Finding A is clearly the highest priority because exposure, exploit maturity and business impact combine. The conclusion is not derived from CVSS alone; it follows from contextual risk analysis.

6. Reporting and Remediation Verification

A report should serve both technical and managerial readers. An executive section states the overall exposure, major themes, business consequences and priority actions. The technical section provides reproducible evidence without unnecessarily disclosing secrets.

Each finding should contain:

• title and unique identifier;
• affected asset, location and owner;
• severity and rationale;
• description of the weakness;
• evidence and validation method;
• attack preconditions and plausible impact;
• remediation and compensating controls;
• references, such as vendor advisories or standards;
• confidence level and limitations;
• retest criteria and target date.

Reports must distinguish observation, interpretation and recommendation. For example, “TCP port 8443 accepted a connection from the test network” is an observation. “The service is an administrative interface” is an interpretation requiring supporting evidence. “Restrict the interface to the management network and require MFA” is a recommendation.

Retesting should use the original evidence and test equivalent conditions. A patch-level change may remove a CVE while leaving insecure exposure, weak access controls or a related vulnerable component. Closure should therefore test the control objective, not merely whether a scanner no longer displays the finding.

7. Governance, Ethics and Legal Responsibilities

Security testing can affect availability, privacy and third parties. Ethical practice requires informed authorisation, competence, proportionality, confidentiality, integrity of evidence and respect for system owners and users. Testers should avoid collecting personal data unless necessary and should stop or escalate when unexpected sensitive information is encountered.

Important governance controls include separation of duties, independent review of high-risk tests, secure handling of credentials, documented chain of custody for evidence, conflict-of-interest management and retention schedules. Organisations should align testing with applicable privacy, critical-infrastructure, financial, health or computer-misuse requirements. Laws differ by jurisdiction, and contractual permission from one party may not authorise testing of another party's infrastructure.

Cloud and managed-service environments require special care. A customer may own the data but not the underlying infrastructure. Provider acceptable-use rules, notification procedures and shared-responsibility boundaries must be checked before scanning.

8. Contemporary Practice and AI

Modern environments challenge conventional scanning. Short-lived containers, serverless functions, software-as-a-service platforms, APIs, identity providers and software supply chains change faster than traditional inventories. Continuous exposure management therefore combines asset discovery, attack-surface monitoring, cloud posture review, dependency analysis, identity analysis and threat intelligence.

AI can assist with prioritisation, deduplication, natural-language reporting and pattern recognition. It can also produce incorrect mappings, invent evidence, overlook environmental conditions or expose sensitive scan data to an unauthorised service. AI-generated conclusions must be checked against primary evidence. A defensible workflow records the data source, model use, reviewer, uncertainty and final human decision. Automated exploitation should never be enabled merely because a model recommends it.

Standards and methods evolve. Practitioners should consult current CVSS specifications, vulnerability databases, vendor advisories, secure configuration guidance, application-testing standards and organisational policy rather than relying on obsolete scanner defaults.

Illustrative Case Study: Regional Health Services Portal

Background

A fictional regional health organisation operates a public appointment portal, a remote-access gateway and an internal records application. A quarterly assessment is authorised for external systems and selected internal segments. The rules prohibit denial-of-service testing, persistence and access to real patient records.

Problem

An unauthenticated scan reports a critical vulnerability on the remote-access gateway and several medium configuration findings on the portal. Asset records show two gateway appliances, but DNS and certificate data suggest a third public endpoint.

Analysis

The assessor confirms that the third endpoint is an unregistered cloud load balancer managed by a contractor. The critical result is then checked against the vendor advisory. One gateway is running a vulnerable version; the other has been patched through a vendor backport despite a misleading banner. A safe validation demonstrates that the vulnerable gateway exposes the affected pre-authentication interface, but the assessor does not attempt data extraction or denial of service.

The portal findings include verbose server headers, an outdated TLS configuration and an administrative path restricted only by an easily guessable URL. Manual review confirms that the path still requires authentication, so the risk is lower than the scanner's generic description suggests. The TLS issue is real but does not provide a direct compromise path.

Approach and Solution

The organisation immediately restricts the vulnerable gateway to approved access sources, applies the vendor fix and monitors authentication logs. It inventories the cloud load balancer, assigns an owner and adds it to change-management coverage. The portal team removes unnecessary headers, strengthens TLS according to the approved baseline and places the administrative interface behind network restrictions and MFA. The assessor retests the gateway, verifies the access-control change and checks that monitoring generates an alert for repeated pre-authentication requests.

Outcome

The highest-risk exposure is removed within the emergency window. The assessment also identifies a process weakness—unregistered cloud infrastructure—that would otherwise continue to create exposure. The final report records the scanner false positive caused by vendor backporting and includes evidence for the conclusion.

Learning Points

The case demonstrates that asset discovery is foundational, scanner output requires validation, CVSS does not replace business context, and remediation includes both technical correction and governance improvement. It also illustrates why safe proof is preferable to unnecessary exploitation when sensitive services are involved.

Challenges and Limitations

No assessment provides complete assurance. Testing is constrained by scope, time, credentials, visibility, system change and the possibility of unknown vulnerabilities. A clean scan may mean that the tool could not observe the weakness. Penetration testing samples attack paths and cannot prove that no attack is possible. Automated tools may miss business-logic flaws, insecure assumptions, chained weaknesses and vulnerabilities in custom integrations.

Testing can also create risk. High request rates may affect availability; authenticated scanning may modify sessions; exploit payloads may trigger defensive controls or corrupt data; and evidence may contain regulated information. These risks should be addressed through staging environments where possible, throttling, snapshots, backups, monitoring, emergency contacts and explicit stop conditions.

The strongest programme combines multiple methods: continuous inventory, authenticated scanning, secure configuration assessment, dependency management, code review, threat modelling, penetration testing, detection validation and incident-response exercises. Results should feed patch management, architecture decisions, procurement, training and risk governance.

Best-Practice Checklist

• Obtain written authorisation and define scope before testing.
• Maintain an owner-based, continuously updated asset inventory.
• Use passive discovery before active probing where appropriate.
• Prefer authenticated, least-privileged assessment for internal systems.
• Record tool versions, scan profiles, dates and limitations.
• Validate important findings using primary evidence.
• Interpret CVE and CVSS in deployment and business context.
• Prioritise active exploitation and critical attack paths.
• Minimise sensitive data collection and protect evidence.
• Use compensating controls and time-bounded risk acceptance when patches are delayed.
• Retest the original control objective and document closure.
• Review methods as technologies, standards and threat conditions change.

Chapter Summary

Vulnerability assessment and security testing provide structured evidence about weaknesses and exposure. Effective practice begins with authorisation and accurate asset discovery, continues through scanning, configuration assessment and controlled validation, and ends with risk-based remediation and retesting. CVE supplies a common vulnerability identifier, while CVSS expresses technical severity; neither independently determines organisational priority. False positives, false negatives, incomplete inventories and changing cloud environments require professional judgement. Penetration testing must be proportionate, minimally invasive and governed by explicit rules. The most valuable output is not a long scan list but a defensible set of actions linked to business impact, exploitability, ownership and verification.

Key Terms

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

Attack surface: The collection of reachable assets and interfaces that may be targeted.

Authenticated scan: A scan using authorised credentials to inspect internal state and configuration.

CVE: A standard identifier for a publicly disclosed vulnerability.

CVSS: A standard framework for expressing technical vulnerability severity.

Exploit: A method or code that takes advantage of a vulnerability.

False negative: Failure to report a vulnerability that is present.

False positive: Reporting a vulnerability that is absent or not applicable.

Penetration test: An authorised, controlled attempt to demonstrate exploitability or attack paths.

Risk acceptance: Formal approval to retain a known risk under defined conditions.

Rules of engagement: Written limits, permissions, methods and safety requirements for testing.

Scope: The assets, methods, dates and objectives included in an assessment.

Shadow IT: Technology used without appropriate organisational visibility or governance.

Threat actor: An entity capable of causing harm through deliberate or accidental action.

Vulnerability: A weakness that can compromise a security property.

Vulnerability assessment: Systematic identification and evaluation of security weaknesses.

Vulnerability chaining: Combining multiple weaknesses to achieve a larger effect.

Retest: A follow-up assessment that verifies remediation.

Review Questions

Short Answer Questions

1. Why is written authorisation necessary before active security testing?
2. Distinguish a CVE identifier from a CVSS score.
3. What is the difference between a false positive and a false negative?
4. Why are authenticated scans often more accurate than unauthenticated scans?
5. State two factors, apart from technical severity, that affect remediation priority.

Long Answer Questions

1. Explain the complete vulnerability assessment lifecycle, including the relationship between discovery, validation, remediation and retesting.
2. Compare black-box, gray-box and white-box penetration testing and identify an appropriate use case for each.
3. Explain how CVSS should be combined with business context when prioritising vulnerabilities.
4. Discuss the ethical, legal and governance controls required for a penetration test involving cloud services.
5. Evaluate the strengths and limitations of automated vulnerability scanners in a modern enterprise.

Analytical / Application Questions

1. A public authentication gateway has a high CVSS score, active exploitation is reported, and the affected organisation stores regulated data behind it. A higher-count medium-severity issue affects isolated development systems. Construct and justify a remediation order.
2. A scanner reports a critical vulnerability based on a product banner, but the vendor states that the organisation's package includes a security backport. Design a validation plan and specify the evidence required before closing or confirming the finding.
3. During an authorised test, a tester discovers an unregistered cloud endpoint connected to a healthcare application. Explain the immediate safety, governance, technical and reporting actions that should follow.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes vulnerability assessment from penetration testing?

A. Vulnerability assessment identifies and evaluates weaknesses, while penetration testing attempts controlled validation of selected weaknesses.

B. Vulnerability assessment is always manual, while penetration testing is always automated.

C. Vulnerability assessment requires exploitation of every finding, while penetration testing never uses tools.

D. Vulnerability assessment is illegal without a court order, while penetration testing needs no authorisation.

Correct Answer: A. Vulnerability assessment identifies and evaluates weaknesses, while penetration testing attempts controlled validation of selected weaknesses.

Question 2

What does a CVE primarily provide?

A. A business-impact ranking for an organisation

B. A standard identifier and description for a publicly disclosed vulnerability

C. A guarantee that exploitation is possible in every deployment

D. A replacement for asset inventory and configuration review

Correct Answer: B. A standard identifier and description for a publicly disclosed vulnerability

Question 3

Which condition most commonly improves the coverage of an internal vulnerability scan?

A. Disabling all logging during the scan

B. Using least-privileged authenticated access where appropriate

C. Scanning only systems that appear in public DNS

D. Using a generic unauthenticated scan profile for every device

Correct Answer: B. Using least-privileged authenticated access where appropriate

Question 4

A false positive occurs when a scanner:

A. Fails to detect a real vulnerability

B. Reports a vulnerability that is absent or not applicable in context

C. Finds the same vulnerability on two different hosts

D. Identifies a vulnerability without assigning a CVE

Correct Answer: B. Reports a vulnerability that is absent or not applicable in context

Question 5

Which factor should normally increase the priority of a vulnerability?

A. The affected asset is isolated and unused

B. The finding is unsupported and has no evidence

C. Active exploitation is reported against an internet-facing critical service

D. The vulnerability appears only on a retired host

Correct Answer: C. Active exploitation is reported against an internet-facing critical service

Question 6

What is the main purpose of rules of engagement?

A. To guarantee that no findings will be reported

B. To define authorised scope, methods, safety limits and escalation procedures

C. To replace the need for technical evidence

D. To permit unrestricted exploitation of third-party systems

Correct Answer: B. To define authorised scope, methods, safety limits and escalation procedures

Question 7

Which statement about CVSS is most accurate?

A. It automatically determines an organisation's final remediation deadline

B. It is a technical severity framework that should be interpreted with environmental and business context

C. It identifies every asset affected by a CVE

D. It proves that a vulnerable product is reachable from the internet

Correct Answer: B. It is a technical severity framework that should be interpreted with environmental and business context

Question 8

Why should penetration testers minimise proof-of-impact actions?

A. Because evidence is never useful in a security report

B. Because exploitation can create unnecessary availability, privacy or data risks

C. Because authorised testing cannot use any network traffic

D. Because remediation is impossible after a finding is validated

Correct Answer: B. Because exploitation can create unnecessary availability, privacy or data risks

Question 9

Which item is most appropriate in a high-quality vulnerability finding?

A. Only the scanner's product name

B. Affected asset, evidence, impact, remediation and retest criteria

C. An unverified assumption that compromise occurred

D. A list of unrelated vulnerabilities from other systems

Correct Answer: B. Affected asset, evidence, impact, remediation and retest criteria

Question 10

What should a formal risk acceptance record normally include?

A. The vulnerability's deletion from all reports

B. An accountable owner, justification, compensating controls and review or expiry conditions

C. A promise that the vulnerability cannot be exploited

D. Permission for all future testing without new authorisation

Correct Answer: B. An accountable owner, justification, compensating controls and review or expiry conditions