Vulnerability, Exposure and Threat Intelligence Management

Introduction and Context

Modern information systems are exposed to a continuously changing combination of software defects, insecure configurations, identity weaknesses, supply-chain dependencies, human error and hostile activity. Security management therefore cannot be limited to installing controls or responding to alerts. It must establish a defensible process for discovering assets, identifying weaknesses, estimating risk, validating exploitability, understanding attack paths, prioritising remediation and using intelligence about threats to improve decisions.

This chapter presents vulnerability, exposure and threat-intelligence management as related but distinct activities. Vulnerability management asks, “What weaknesses exist?” Exposure management asks, “Which weaknesses create meaningful attack opportunities in the context of our environment?” Threat intelligence asks, “Who may exploit those opportunities, how, and with what evidence?” Effective practice integrates all three while preserving legal authority, operational safety and evidential integrity.

The chapter is concerned with authorised defensive activity. Scanning, exploitation, social engineering and collection of threat information must be conducted under documented permission, defined scope and appropriate safeguards.

Learning Objectives

After studying this chapter, a learner should be able to:

1. Explain the relationships among assets, vulnerabilities, exposures, threats, exploits and risks.

2. Design an asset-discovery and vulnerability-assessment workflow.

3. Distinguish vulnerability scanning, penetration testing, red teaming and attack-path analysis.

4. Apply risk-based prioritisation rather than relying only on severity scores.

5. Describe the collection, analysis and dissemination of cyber-threat intelligence.

6. Evaluate the limitations of automated tools, vulnerability scores and intelligence sources.

7. Develop an ethical, governed and measurable remediation programme.

1. Conceptual Foundations

1.1 Assets, attack surfaces and attack paths

An asset is anything of value that supports business, operational or information objectives. Assets include servers, endpoints, cloud resources, identities, applications, databases, industrial systems, APIs, data stores and third-party services. A complete inventory also records ownership, business purpose, location, technology, dependencies and criticality.

The attack surface is the set of reachable points through which an adversary might influence, access or damage an organisation. It includes internet-facing services, remote-access portals, exposed APIs, cloud storage, employee identities, unmanaged devices, software dependencies and trusted connections. Attack surfaces are dynamic: a temporary cloud workload, newly published DNS record or forgotten development system may create exposure without appearing in a conventional configuration database.

An attack path is a sequence of conditions that permits an adversary to move from an initial foothold to a valuable objective. For example, a public-facing application vulnerability may provide access to a low-privilege service account; excessive permissions may then enable access to a database; stolen database credentials may provide access to sensitive records. Attack-path analysis is consequently relational. A medium-severity weakness can become strategically important when combined with identity privileges, network reachability and weak segmentation.

1.2 Vulnerability, exposure, threat and risk

A vulnerability is a weakness in design, implementation, configuration, process or human practice that can be exploited or abused. Examples include an unpatched software defect, excessive permissions, insecure cryptographic settings, default credentials and inadequate logging.

Exposure is the condition in which an asset, weakness or capability is accessible or positioned in a way that increases the possibility or consequence of compromise. A vulnerable service bound only to an isolated test network has a different exposure from the same service reachable from the internet and associated with an administrator identity.

A threat is a potential cause of harm. Threat actors may include financially motivated groups, state-sponsored operators, insiders, hacktivists, criminals, competitors or opportunistic attackers. A threat event is an occurrence or attempted occurrence, whereas a threat capability describes what an actor can do.

Risk expresses the possibility that a threat will exploit a vulnerability or exposure and produce an adverse outcome. In qualitative form, risk is often represented as a combination of likelihood and impact:

Risk ≈ Likelihood × Impact

This is a conceptual relationship, not a universal measurement equation. It assumes that likelihood and impact have been defined on compatible scales and that the organisation accepts an approximate model for decision-making. In practice, many organisations use ordinal categories such as low, medium, high and critical rather than numerical probabilities. Multiplying arbitrary ordinal labels can create false precision; the result should therefore support, not replace, expert judgement.

1.3 Vulnerability versus weakness and misconfiguration

A vulnerability generally implies a condition that can be exploited to violate a security property. A weakness is broader and may describe a design or coding defect that has not yet been shown to create a practical attack. A misconfiguration is an incorrectly or insecurely configured component, such as unrestricted management access or an exposed storage bucket. Misconfigurations can produce serious exposures even when no software defect exists.

This distinction matters for remediation. Patching may address a software vulnerability, whereas an identity governance problem requires changes to roles, approvals and monitoring. Treating every issue as a patching problem produces incomplete risk reduction.

2. Asset Discovery and Exposure Mapping

2.1 The discovery problem

Organisations cannot protect assets that they do not know exist. Asset discovery should combine authoritative inventories with technical observation. Common sources include configuration-management databases, cloud control planes, endpoint-management platforms, identity directories, DNS records, certificate-transparency data, network-flow records, vulnerability scanners, procurement records and service-owner interviews.

Discovery should identify at least:

• asset identifier and owner;
• business service and criticality;
• network, cloud or physical location;
• operating system, application and version;
• internet reachability and trust relationships;
• identities and privileges associated with the asset;
• data processed or stored;
• dependencies and third parties;
• lifecycle state and expected retirement date.

A useful inventory distinguishes “unknown,” “not applicable” and “not yet verified.” Treating missing information as a negative answer conceals uncertainty.

2.2 Discovery methods

Passive discovery observes existing information without directly interacting with target systems. Examples include analysing DNS, certificates, logs, routing information, cloud inventories and network telemetry. Passive methods generally reduce operational risk but may miss assets that produce no observable records.

Active discovery sends requests or probes to identify hosts, ports, services and applications. It provides more direct evidence but can affect fragile systems, trigger security controls or violate the boundaries of an authorisation. Rate limits, maintenance windows, exclusions and emergency contacts should be defined before active scanning.

Agent-based discovery obtains detailed local information from installed software agents. It can identify packages, configurations and users accurately, but it may not cover unmanaged or transient assets. Agentless methods are valuable for broad coverage but may provide less depth.

Cloud and container environments require special attention. Resources may be created and destroyed rapidly; addresses may be ephemeral; infrastructure can be declared in code; and responsibility is divided between provider and customer. Discovery should therefore integrate cloud APIs, identity relationships, infrastructure-as-code repositories, container registries and orchestration platforms.

2.3 Data quality and reconciliation

Duplicate records, stale ownership, inconsistent naming and unclassified assets undermine risk decisions. Reconciliation should use stable identifiers where possible, such as cloud resource IDs, device serial numbers, application identifiers and certificate subjects. Inventory quality can be evaluated through measures such as coverage, freshness, ownership completeness and reconciliation accuracy. These are management indicators rather than absolute proofs of completeness.

3. Vulnerability Assessment

3.1 Assessment lifecycle

A defensible vulnerability-assessment programme normally follows these stages:

1. Plan: define authority, scope, objectives, exclusions, timing, tools, data handling and escalation procedures.

2. Discover: identify assets, services, versions, configurations and dependencies.

3. Assess: compare observed conditions with vulnerability knowledge, secure baselines and organisational requirements.

4. Validate: confirm important findings using safe evidence and, where authorised, controlled exploitation.

5. Prioritise: combine technical severity with exposure, asset value, threat evidence and compensating controls.

6. Remediate or mitigate: patch, reconfigure, isolate, restrict access, improve detection or accept the risk formally.

7. Verify: retest the affected condition and confirm that the intended risk reduction occurred.

8. Report and improve: communicate results to technical and business stakeholders and update processes.

3.2 Scanning and its limitations

A vulnerability scanner may identify software versions, known vulnerabilities, weak configurations and missing patches. Authenticated scanning generally produces better results because it can inspect local packages and settings rather than infer them remotely. Unauthenticated scanning remains important because it reflects an external attacker’s perspective.

False positives occur when a tool reports a weakness that is not actually exploitable or is not present. False negatives occur when a tool fails to identify a real weakness. Causes include inaccurate version banners, custom patches, encrypted traffic, unsupported applications, credentials with insufficient privileges, new vulnerabilities and unusual network paths.

Scanner output is therefore an observation requiring interpretation. A finding should include evidence, affected asset, vulnerability identifier where applicable, conditions, potential impact, confidence, remediation guidance and validation status.

3.3 Severity scoring and contextual risk

The Common Vulnerability Scoring System (CVSS) is widely used to describe technical severity through characteristics such as attack vector, complexity, privileges required, user interaction, scope, confidentiality, integrity and availability impact. A CVSS score is not the same as organisational risk. It does not, by itself, encode whether the affected asset contains regulated data, whether exploitation is active, whether compensating controls exist or whether the system is business-critical.

A practical prioritisation model may classify findings using four questions:

• How technically exploitable is the condition?
• Is the asset reachable and exposed?
• What business value or harm is associated with compromise?
• Is there credible evidence of exploitation or actor interest?

The model should be documented and consistently applied. Quantitative probabilities may be used where reliable data exists, but unsupported numerical precision should be avoided.

4. Penetration Testing and Adversarial Validation

4.1 Purpose and scope

Penetration testing is an authorised attempt to demonstrate whether identified controls or weaknesses can be exploited and what access or impact could result. Its value lies in validating assumptions, not in producing the largest possible list of findings.

Testing may be external, internal, wireless, web-application, API, mobile, cloud, social-engineering or physical. Black-box testing provides limited prior knowledge; white-box testing provides extensive information; grey-box testing uses an intermediate level. The choice should match the question being investigated.

A rules-of-engagement document should define:

• systems, identities and environments in scope;
• prohibited actions and safety limits;
• permitted test windows;
• source addresses and test accounts;
• data-handling and evidence requirements;
• emergency contacts and stop conditions;
• treatment of third-party infrastructure;
• reporting, disclosure and retest arrangements.

4.2 Testing versus red teaming

A penetration test commonly focuses on a defined system or control and seeks to identify exploitable weaknesses. A red-team exercise evaluates an organisation’s ability to prevent, detect and respond to a realistic adversary across multiple stages. Red teaming is broader, more scenario-driven and often involves limited disclosure to defenders. Neither replaces routine vulnerability management.

Safe testing uses non-destructive proof, synthetic data, controlled payloads and explicit limits. Exploitation that changes data, disrupts availability, creates persistence or accesses personal information should be avoided unless essential, specifically authorised and carefully controlled.

5. Attack-Path Analysis

5.1 From isolated findings to attack graphs

Traditional vulnerability lists treat findings independently. Attack-path analysis models relationships among assets, identities, vulnerabilities, network routes, trust relationships and business objectives. A graph may represent nodes such as users, workloads, databases and cloud roles, and edges such as “can authenticate,” “can reach,” “can assume role” or “contains credential.”

The purpose is not to predict every attacker action. It is to identify plausible chains whose disruption would reduce meaningful risk. Common path-enabling conditions include:

• publicly reachable initial access points;
• reusable or overprivileged credentials;
• weak separation between environments;
• insecure service accounts;
• unmonitored administrative actions;
• exposed secrets in repositories or images;
• excessive cloud permissions;
• vulnerable systems connected to high-value assets.

5.2 Prioritising path interventions

The most valuable remediation is not always the first vulnerability in a chain. Restricting network reachability, removing a privilege, rotating a credential or improving authentication may break several paths simultaneously. This is a systems perspective: the objective is to reduce reachable high-impact outcomes, not merely to maximise the number of closed tickets.

Attack-path models are only as reliable as their data. Stale identities, undocumented firewall rules and incorrect asset ownership can create both imaginary and missed paths. Findings should therefore include confidence and be validated with system owners.

6. Risk-Based Remediation and Governance

6.1 Treatment choices

A vulnerability may be treated by:

• remediation: correcting the underlying weakness;
• mitigation: reducing likelihood or impact without fully correcting it;
• avoidance: discontinuing the exposed function or service;
• transfer: shifting contractual or financial consequences, without eliminating technical risk;
• acceptance: formally acknowledging residual risk within delegated authority.

Risk acceptance should be time-limited, owned by an accountable business authority and supported by rationale, compensating controls, review date and exit conditions. Silence or ticket closure is not risk acceptance.

6.2 Remediation prioritisation

A sound programme combines technical information with business context. For example, an actively exploited medium-severity vulnerability on an internet-facing identity service may require faster action than a critical-severity defect on an isolated, disposable laboratory host.

Useful prioritisation inputs include asset criticality, exposure, exploit availability, observed exploitation, ease of exploitation, privilege gained, data sensitivity, control effectiveness, remediation effort and change risk. Remediation service-level objectives should be differentiated by risk class rather than assigning one deadline to every finding.

6.3 Verification and metrics

Verification should confirm more than the disappearance of a scanner result. It should establish that the vulnerable component was updated or reconfigured, the exposure was removed, dependent services still operate, and the attack path is no longer feasible or is adequately mitigated.

Metrics should support decisions. Examples include time to remediate by risk tier, percentage of critical assets with current assessment coverage, age of overdue findings, recurrence rate, verified closure rate, inventory freshness and proportion of high-impact attack paths disrupted. A reduction in findings can be misleading if scanning coverage has declined or assets have been removed from scope.

7. Threat Intelligence Management

7.1 Definition and intelligence levels

Threat data is a raw observation, such as an IP address, malware sample or reported incident. Threat information adds context and interpretation. Threat intelligence is analysed information that supports a decision or action.

Strategic intelligence addresses trends, actors, sectors, geopolitical developments and business implications. Operational intelligence concerns campaigns, objectives and likely methods. Tactical intelligence describes techniques, tactics and procedures. Technical intelligence includes indicators such as domains, hashes, URLs and network artefacts. These levels have different audiences, lifetimes and confidence requirements.

7.2 The intelligence cycle

An intelligence programme commonly follows:

1. Direction: define intelligence requirements linked to decisions.

2. Collection: obtain information from internal telemetry, trusted communities, vendors, public sources, incident investigations and authorised exchanges.

3. Processing: normalise, deduplicate, enrich and classify data.

4. Analysis: assess relevance, credibility, confidence, implications and alternative explanations.

5. Dissemination: deliver timely, audience-appropriate outputs.

6. Feedback: determine whether the intelligence changed a decision or improved detection and response.

Collection without direction produces volume rather than intelligence. For example, a security team may require intelligence about exploitation of a particular remote-access product, while a board may require the likely business consequences of a campaign targeting the organisation’s sector.

7.3 Intelligence quality and indicator limitations

Indicators of compromise are useful but imperfect. An IP address may be shared, a domain may be repurposed, a hash may change after recompilation, and an attacker may use legitimate services. Blocking an indicator without understanding context can disrupt business activity or cause false confidence.

Intelligence assessments should record source, collection time, confidence, reliability, relevance, expected lifetime and handling restrictions. Analytic discipline benefits from separating facts from judgements and identifying assumptions. Structured techniques such as confidence statements, competing hypotheses and confidence levels can reduce confirmation bias.

Standards and information-sharing formats can improve interoperability, but technical standardisation does not guarantee analytical quality. Sharing must also respect privacy, contractual obligations, classification, data-protection law and sector rules.

8. Ethics, Law and Professional Responsibility

Authorisation is the primary boundary between defensive testing and unlawful access. Written permission should identify the responsible authority, target scope, methods, time period and limitations. Third-party systems require appropriate contractual or provider permission; an organisation’s ownership of data does not automatically authorise testing of another party’s infrastructure.

Practitioners should minimise collection of personal data, protect credentials and evidence, avoid unnecessary service disruption, disclose serious findings responsibly and preserve confidentiality. Results should be shared on a need-to-know basis, with secure storage and retention controls.

Governance should address separation of duties, independent review, conflict of interest, supplier oversight, exception management and escalation. Regulatory obligations may require timely reporting of incidents or vulnerabilities, protection of personal data and evidence of reasonable security practices. Legal requirements vary by jurisdiction; professional teams should obtain qualified legal advice rather than treating a technical policy as a substitute for law.

9. Automation, AI and Contemporary Developments

Automation improves asset enumeration, configuration comparison, prioritisation, ticket creation and intelligence enrichment. However, automated actions can magnify errors. A scanner may generate duplicate findings; an orchestration platform may isolate a production asset incorrectly; an AI model may infer a relationship that is unsupported by evidence.

AI can assist with vulnerability triage, code analysis, attack-path summarisation, natural-language reporting and correlation of large intelligence collections. It should not be treated as an autonomous authority for exploitation or high-impact remediation. Human review is required for scope, evidence, confidence, privacy, bias, false positives and operational consequences. Organisations should record data provenance, model limitations and approval decisions.

Contemporary exposure-management programmes increasingly unify external attack-surface management, cloud-security posture, identity exposure, endpoint telemetry, software supply-chain analysis and vulnerability data. The advantage is contextual prioritisation; the risk is dependence on incomplete integrations and opaque scoring. Continuous discovery should complement, not eliminate, periodic assessment and human governance.

10. Illustrative Case: Meridian Health Services

Background

Meridian Health Services is a fictional regional healthcare provider operating hospitals, outpatient clinics and a cloud-based patient portal. Its security team maintained a vulnerability scanner and a configuration-management database, but the two systems used different asset identifiers. The organisation also relied on a monthly patch cycle.

Problem

A routine external assessment identified a high-severity vulnerability in a remote-access appliance. The scanner showed that the appliance was exposed to the internet, but it did not identify that the appliance was connected to an identity synchronisation service. The service account used for synchronisation had excessive privileges in the cloud environment. Threat-intelligence reporting indicated active exploitation of the appliance class by a criminal group targeting healthcare organisations.

A separate critical vulnerability existed on an internal test server, but the server contained no sensitive data and was isolated from production systems.

Analysis

The technical score alone might rank the internal critical vulnerability first. Contextual analysis produced a different conclusion:

• The remote-access appliance had direct external exposure.
• Exploitation could provide an initial foothold.
• The synchronisation account created a privilege-escalation path.
• Threat intelligence indicated active exploitation.
• Healthcare availability and confidentiality impacts were high.

The test server had greater nominal severity but low reachability, low asset value and effective isolation.

Approach and solution

Meridian authorised an emergency response under its vulnerability-management policy. It first restricted external access to the appliance through temporary network controls, preserved relevant logs and verified whether exploitation had occurred. The appliance was patched and its configuration hardened. The synchronisation account was replaced with a least-privilege identity, credentials were rotated, and privileged actions were placed under stronger authentication and monitoring.

The team then mapped the identity and network relationships in an attack-path model. It discovered two additional appliances with similar configurations and applied the same controls. The internal test server was scheduled for remediation in the normal maintenance window, with its isolation verified.

Threat intelligence was converted into detection rules and a short executive briefing. The briefing explained the affected service, evidence, decisions, residual risk and required investment rather than merely listing indicators.

Outcome

The immediate external exposure was removed, the privilege-escalation path was disrupted and monitoring was improved. Retesting confirmed that the original path was no longer feasible. The case also led Meridian to reconcile inventory identifiers, establish an emergency patch process for actively exploited vulnerabilities and review service-account privileges across the environment.

Learning points

1. A vulnerability score does not determine organisational priority by itself.

2. Asset, identity and network context can transform a technical weakness into a major business risk.

3. Threat intelligence is valuable when it changes a decision or defensive action.

4. Remediation should be verified through attack-path and control testing.

5. Inventory quality is a prerequisite for reliable exposure management.

Challenges and Limitations

Vulnerability and exposure management face persistent uncertainty. Inventories become stale, cloud resources change rapidly, proprietary systems resist scanning and asset owners may dispute findings. Technical severity models may encourage queue management instead of risk reduction. Penetration tests provide a point-in-time view and cannot prove the absence of vulnerabilities. Threat intelligence can be delayed, biased, duplicated or strategically manipulated.

Operational constraints also matter. Patching may threaten availability, legacy systems may lack vendor support, and remediation may compete with business deadlines. These constraints justify transparent risk treatment and compensating controls, not silent postponement. Finally, excessive data collection can create privacy and retention risk. A mature programme therefore values evidence quality, context, proportionality and accountability over tool volume.

Best-Practice Principles

• Maintain a continuously reconciled, owner-assigned asset inventory.
• Link vulnerabilities to exposure, identity, data and business service context.
• Use authenticated and unauthenticated assessment appropriately.
• Validate high-impact findings safely and under written authorisation.
• Prioritise active exploitation and meaningful attack paths.
• Treat risk acceptance as an accountable, time-bound decision.
• Preserve evidence, confidence and provenance in assessment and intelligence records.
• Measure verified risk reduction, not merely ticket closure.
• Integrate vulnerability, identity, cloud, configuration and threat-intelligence data.
• Keep humans responsible for scope, judgement and high-impact actions.

Chapter Summary

Vulnerability, exposure and threat intelligence management form an integrated decision system for defensive security. Asset discovery establishes what must be protected, while exposure mapping reveals reachability, trust and privilege relationships. Vulnerability assessment identifies weaknesses, but scanner results require validation and contextual interpretation. Penetration testing provides authorised adversarial evidence; red teaming evaluates broader organisational resilience; and attack-path analysis explains how individually moderate weaknesses may combine into a serious route to a business objective.

Risk-based remediation combines technical severity with asset value, exposure, threat activity, control effectiveness and operational consequence. Threat intelligence becomes useful when it is directed by decisions, analysed for confidence and delivered to the right audience. Ethical authorisation, privacy, legal compliance, evidence protection and human accountability are essential throughout the lifecycle. Mature programmes continuously reconcile inventories, verify remediation, measure meaningful risk reduction and use automation or AI as controlled aids rather than substitutes for professional judgement.

Key Terms

Asset: A resource of value to an organisation, including systems, data, identities and services.

Attack surface: The set of reachable points through which an adversary may influence or compromise an environment.

Attack path: A sequence of relationships and conditions connecting an initial foothold to an objective.

Exposure: A condition that increases the accessibility or consequence of a weakness.

Vulnerability: A weakness that can be exploited or abused to violate a security property.

Threat: A potential cause of harm or an actor capability capable of causing harm.

Risk: The possibility of adverse impact arising from threats exploiting weaknesses or exposures.

Asset discovery: The process of identifying, classifying and recording organisational assets.

Vulnerability assessment: The systematic identification and evaluation of weaknesses.

Authenticated scan: An assessment using authorised credentials to inspect internal system state.

False positive: A reported finding that is not actually present or exploitable as described.

False negative: A real weakness that an assessment fails to identify.

Penetration test: An authorised attempt to demonstrate exploitable weaknesses and consequences.

Red team: An adversarial exercise designed to evaluate prevention, detection and response against a realistic scenario.

Attack graph: A model representing relationships and possible routes among assets, privileges and objectives.

Threat intelligence: Analysed threat information intended to support a decision or action.

Indicator of compromise: An observable artefact associated with possible malicious activity.

Risk acceptance: A formally accountable decision to retain identified residual risk.

Compensating control: An alternative safeguard that reduces risk when the preferred control is unavailable.

Review Questions

Short Answer Questions

1. Distinguish a vulnerability from an exposure.

2. Why is asset discovery a prerequisite for vulnerability management?

3. What is the purpose of a rules-of-engagement document?

4. Name the major stages of the threat-intelligence cycle.

5. Why should CVSS or another technical severity score not be used as the sole basis for prioritisation?

Long Answer Questions

1. Explain how asset value, network reachability and identity privilege combine to influence risk.

2. Compare vulnerability scanning, penetration testing and red teaming in terms of purpose, scope and evidence.

3. Describe a complete vulnerability-management lifecycle from planning through verification.

4. Discuss the benefits and limitations of attack-path analysis.

5. Explain the ethical, legal and governance requirements for authorised security testing and intelligence handling.

Analytical / Application Questions

1. An internet-facing application has a medium technical severity rating but is actively exploited and connected to a privileged database account. An isolated laboratory server has a critical rating but no production connectivity. Which should be prioritised first, and what evidence would you seek before deciding?

2. Design an intelligence requirement and collection plan for a university migrating its remote-access service to the cloud. Identify the audience, sources, processing steps, analytic outputs and feedback mechanism.

3. A scanner reports that a production server is vulnerable, but the owner claims that a vendor backport fixed the defect. Explain how you would validate the finding safely, document confidence and decide on remediation or risk treatment.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes exposure from vulnerability?

A. Exposure is always a software coding defect

B. Exposure describes accessibility or context that can increase the significance of a weakness

C. Exposure is a synonym for a threat actor

D. Exposure can exist only on internet-facing systems

Correct Answer: B. Exposure describes accessibility or context that can increase the significance of a weakness

Question 2

What is the primary purpose of asset discovery?

A. To replace penetration testing

B. To identify and classify resources that require protection

C. To assign legal liability to system owners

D. To guarantee that no vulnerabilities exist

Correct Answer: B. To identify and classify resources that require protection

Question 3

Why can a CVSS score not, by itself, determine remediation priority?

A. CVSS applies only to physical assets

B. CVSS does not describe software versions

C. It generally does not include full business context, asset value or current threat activity

D. CVSS is used only after remediation

Correct Answer: C. It generally does not include full business context, asset value or current threat activity

Question 4

Which activity most directly validates whether a weakness can produce the claimed impact?

A. Unauthorised public scanning

B. Authorised penetration testing

C. Deleting the vulnerability ticket

D. Changing the asset name

Correct Answer: B. Authorised penetration testing

Question 5

What is a central purpose of attack-path analysis?

A. To count the number of installed applications

B. To identify plausible chains from an initial foothold to a valuable objective

C. To eliminate the need for asset ownership

D. To create indicators without evidence

Correct Answer: B. To identify plausible chains from an initial foothold to a valuable objective

Question 6

Which is an example of risk mitigation rather than full remediation?

A. Correcting the vulnerable code

B. Removing the affected service permanently

C. Restricting access and adding monitoring while the underlying defect remains

D. Ignoring the finding

Correct Answer: C. Restricting access and adding monitoring while the underlying defect remains

Question 7

What is the first stage of a typical threat-intelligence cycle?

A. Dissemination

B. Direction

C. Processing

D. Feedback

Correct Answer: B. Direction

Question 8

Which statement about an indicator of compromise is most accurate?

A. It proves that an attack occurred in every context

B. It is always permanent and unique

C. It is an observable artefact that requires context and confidence assessment

D. It is the same as a vulnerability score

Correct Answer: C. It is an observable artefact that requires context and confidence assessment

Question 9

Which practice best supports safe penetration testing?

A. Testing without notifying any responsible authority

B. Using a written rules-of-engagement document with scope and stop conditions

C. Collecting all available personal data

D. Allowing unlimited destructive exploitation

Correct Answer: B. Using a written rules-of-engagement document with scope and stop conditions

Question 10

Which metric best reflects whether remediation produced actual risk reduction?

A. Number of tickets created

B. Number of scanner alerts generated

C. Verified closure of findings and disruption of relevant attack paths

D. Total number of security tools purchased

Correct Answer: C. Verified closure of findings and disruption of relevant attack paths