5. Cyber Risk Identification and Threat Context

Introduction and Context

Cyber risk management begins before a risk is scored, a control is selected, or an incident is investigated. It begins with knowing what the organisation is trying to protect, why those assets and services matter, how they could be harmed, and which threat actors or conditions could cause that harm. This activity is commonly described as cyber risk identification, but the term should not be misunderstood as the simple production of an asset list or vulnerability register. Identification is an interpretive process that connects technology with business purpose, information value, operational dependency, threat behaviour, and potential consequences.

An organisation may possess thousands of systems, applications, identities, data stores, cloud resources, suppliers, and industrial devices. Only some of them will be critical to a particular business service, yet a seemingly minor component can become important when it supports authentication, payment processing, software deployment, safety functions, or regulatory reporting. Risk identification therefore requires context. A vulnerability in an isolated test server is not equivalent to the same vulnerability in an internet-facing identity service. Similarly, a phishing technique has different implications for a research institution, a hospital, a bank, and a defence contractor.

This chapter develops a defensible method for identifying cyber risk and expressing it through credible risk scenarios. It examines inventories, business impact, data classification, risk taxonomies, threat intelligence, attack trees, cyber kill chains, MITRE ATT&CK, threat modelling, and vulnerability information. The central argument is that useful cyber risk statements are not lists of disconnected threats and weaknesses. They are reasoned explanations of how a threat may exploit a condition affecting a business asset or service and produce a consequence.

Learning Objectives

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

1. Explain why asset and service inventories are foundational to cyber risk identification.

2. Distinguish assets, services, processes, data, vulnerabilities, threats, events, and impacts.

3. Establish business impact context using criticality, dependency, and resilience considerations.

4. Apply data classification and risk taxonomies to organise risk information.

5. Use threat intelligence to develop relevant threat hypotheses rather than generic threat lists.

6. Compare attack trees, kill-chain analysis, MITRE ATT&CK, and structured threat-modelling approaches.

7. Interpret vulnerability information in relation to exploitability, exposure, and business context.

8. Construct defensible cyber risk scenarios for governance, prioritisation, and treatment decisions.

9. Recognise limitations, ethical issues, and common errors in cyber risk identification.

From Inventories to Business Context

The object of identification: more than an asset

An asset is anything that has value to an organisation and requires protection. In cybersecurity, assets may include hardware, software, information, identities, facilities, cryptographic keys, cloud resources, processes, services, and reputational relationships. The traditional asset register often focuses on devices and applications, but a risk practitioner must also identify business services. A customer-payment service, for example, may depend on a web application, payment gateway, identity provider, database, network connection, cloud platform, fraud-detection engine, support staff, and third-party supplier. Protecting each component separately does not necessarily demonstrate that the service as a whole is resilient.

A useful inventory distinguishes at least four related layers:

• Business services: outcomes delivered to customers, citizens, employees, or partners.
• Business processes: activities that create or support those outcomes.
• Technology and information assets: systems, applications, infrastructure, data, and identities enabling the processes.
• External dependencies: suppliers, managed services, telecommunications, utilities, software providers, and shared platforms.

These layers should be linked rather than maintained as isolated spreadsheets. A service map can show which assets support a process, which data flows through it, and which suppliers or trust relationships are involved. This makes impact analysis more realistic and reveals concentration risk, in which many services depend on one identity platform, cloud region, network provider, or software component.

Inventory quality and uncertainty

Inventory completeness is itself a risk consideration. Unknown or unmanaged assets may be more exposed than known assets because they are less likely to receive patches, monitoring, secure configuration, or ownership attention. However, inventory accuracy should not be confused with the collection of maximum technical detail. A register is useful when it supports decisions. Excessive fields that are never maintained create an appearance of precision without reliable knowledge.

At minimum, an inventory should identify an owner, purpose, environment, location or hosting model, data handled, critical dependencies, exposure, lifecycle status, and recovery requirements. The confidence of each record should also be recorded. For example, “confirmed,” “partially verified,” and “inferred” are more informative than silently treating uncertain information as fact. Discovery tools, configuration-management databases, cloud APIs, endpoint platforms, procurement records, architecture documents, and interviews can be combined to improve coverage.

Business impact context

Business impact expresses what would matter if a service or asset were compromised, unavailable, altered, or misused. Confidentiality, integrity, and availability remain central dimensions, but they rarely capture the full organisational consequence. Impact analysis may also consider safety, legal obligations, privacy, financial loss, operational continuity, strategic objectives, customer trust, market position, and dependence on time-sensitive activities.

Impact should be evaluated in relation to duration and scope. A fifteen-minute interruption to an internal collaboration tool may be tolerable, whereas a similar interruption to an emergency dispatch system may be unacceptable. Integrity loss can be more serious than disclosure where incorrect data could lead to unsafe engineering decisions or unauthorised financial transfers. A breach affecting a small number of highly sensitive records may be more consequential than a larger breach involving public information.

Business impact analysis commonly identifies recovery time objectives (RTOs), recovery point objectives (RPOs), maximum tolerable downtime, service-level commitments, and legal or contractual requirements. These measures do not replace professional judgement. They provide a structured basis for discussing priorities with business owners and for determining whether a cyber scenario threatens an important operational outcome.

A mature analysis also examines dependencies. If a service cannot operate without a particular identity provider, certificate authority, DNS service, data pipeline, or supplier, the dependency becomes part of the risk context. A service may have excellent local controls yet remain vulnerable to a common external failure. Dependency mapping therefore supports both cyber risk analysis and resilience planning.

Data Classification and Risk Taxonomies

Classification as a decision mechanism

Data classification assigns information to categories that guide handling, access, retention, sharing, encryption, monitoring, and disposal. Common categories include public, internal, confidential, restricted, and highly restricted, although terminology varies. Classification should be based on the harm that could result from unauthorised disclosure, alteration, loss, or unavailability. It should not be determined solely by the department that owns the data or by the storage location.

Classification is most valuable when linked to controls and business decisions. If “restricted” data requires stronger authentication, reduced administrative access, encryption in transit and at rest, shorter retention, and enhanced monitoring, the label has operational meaning. If labels are applied without corresponding requirements, they become administrative decoration.

The three security properties should be assessed separately. A dataset may have low confidentiality but high integrity requirements. Public transport timetable data, for example, may be openly available but must not be altered maliciously. Conversely, an unpublished acquisition plan may require strict confidentiality but less demanding availability. Privacy assessments should also identify personal data, sensitive personal data, data-subject rights, processing purposes, and cross-border or third-party arrangements where relevant.

Risk taxonomies

A risk taxonomy provides a common vocabulary for grouping and comparing risks. It may classify risks by threat source, business consequence, affected asset, attack technique, control failure, or risk event. A useful taxonomy is neither too broad to guide action nor so detailed that analysts debate labels instead of managing risk.

A governance taxonomy might include external attack, insider misuse, third-party compromise, technology failure, data misuse, fraud, operational error, and physical or environmental disruption. A technical taxonomy might separately record initial access, credential compromise, privilege escalation, persistence, lateral movement, data access, disruption, and exfiltration. These views are complementary. Executives often need consequence and ownership categories, while security engineers need technical attack patterns.

Taxonomies should be versioned and governed. Definitions, ownership, reporting levels, and relationships to risk appetite should be documented. Organisations should also avoid false consistency: a taxonomy can standardise language, but it cannot eliminate uncertainty or substitute for analysis.

Threat Context: From Generic Threats to Plausible Scenarios

Threat, vulnerability, event, and risk

A threat is a potential source of harm, such as a criminal group, malicious insider, compromised supplier, natural event, or software failure. A vulnerability is a weakness or condition that can be exploited or that increases the likelihood or impact of an adverse event. A threat event is an occurrence that may exploit a vulnerability or otherwise cause harm. Risk is the effect of uncertainty on objectives; in cybersecurity practice, it is often expressed through the likelihood and consequence of a harmful scenario.

These concepts must not be collapsed. “Ransomware” is a threat category or event type, not a complete risk statement. “Unpatched server” is a weakness, not the impact. A defensible scenario might state: “A financially motivated actor obtains valid credentials through a targeted phishing campaign, accesses the remote administration service, encrypts the production file environment, and interrupts order fulfilment beyond the organisation’s recovery objective.” This statement connects actor, pathway, asset, event, and consequence.

Threat intelligence and relevance

Threat intelligence is information processed to support decisions about threats. Strategic intelligence addresses trends, motivations, geopolitical developments, and sector exposure. Operational intelligence concerns campaigns, targeting, and adversary behaviour. Tactical or technical intelligence includes indicators, malware characteristics, tools, domains, hashes, and observed techniques. Intelligence becomes useful when it is evaluated for reliability, relevance, timeliness, and applicability to the organisation.

A list of indicators copied from a feed is not automatically intelligence. Indicators may be outdated, shared widely, or unrelated to the organisation’s technology. Strong analysis asks questions such as:

• Which threat actors have demonstrated interest in this sector or service?
• What access paths and techniques do they use?
• Are those techniques feasible against the organisation’s architecture?
• What evidence would indicate preparation, compromise, or attempted execution?
• Which controls or dependencies would influence the outcome?

Threat intelligence should generate hypotheses and improve monitoring, scenario design, and prioritisation. It should not be used to claim certainty about an attacker’s intent or to justify indiscriminate collection of personal information.

Analytical Models for Threat and Attack Understanding

Attack trees

An attack tree represents an attacker’s objective as a hierarchy of subgoals. The root might be “fraudulently transfer funds.” Lower branches could include “obtain privileged payment access,” “alter transaction approval,” or “compromise an authorised endpoint.” Subgoals may be connected through AND or OR relationships. An AND relationship means that several conditions are required; an OR relationship means that alternative routes may achieve the objective.

Attack trees are valuable for examining alternatives and identifying control points. They encourage analysts to consider more than the most familiar attack path. Their limitations include maintenance difficulty, oversimplification of human behaviour, and the temptation to treat all branches as equally probable. They are strongest when combined with asset knowledge, threat intelligence, and evidence about attacker capability.

Cyber kill-chain analysis

The cyber kill chain describes an intrusion as a sequence of stages, commonly including reconnaissance, weaponisation, delivery, exploitation, installation, command and control, and actions on objectives. The model encourages layered detection and disruption: an organisation may prevent delivery, detect exploitation, block command and control, or limit actions on objectives.

Its linear character is both a strength and a limitation. It provides a clear narrative for an intrusion, but real attacks may be iterative, branch into parallel activities, or begin with valid credentials rather than an exploit. It is therefore more useful as a communication and defensive-planning model than as a complete representation of every attack.

MITRE ATT&CK

MITRE ATT&CK is a knowledge base describing adversary tactics and techniques based on observed behaviours. Tactics express the adversary’s goals, such as initial access, execution, persistence, privilege escalation, defence evasion, credential access, discovery, lateral movement, collection, command and control, exfiltration, and impact. Techniques describe ways of achieving those goals.

ATT&CK supports threat-informed defence by helping organisations map observed or plausible behaviours to preventive, detective, and corrective controls. It can also structure purple-team exercises, detection engineering, security metrics, and scenario analysis. It should not be treated as a probability model, a complete catalogue of threats, or evidence that every listed technique applies to the organisation. Mapping must be contextual: the same technique may be low relevance in one architecture and highly significant in another.

Threat modelling

Threat modelling is a systematic process for identifying how a system could be misused or compromised and for deciding how risks should be reduced. Common approaches include data-flow diagrams, trust-boundary analysis, misuse cases, STRIDE categories, attack trees, and attack-surface analysis. A model should identify actors, entry points, assets, trust relationships, data flows, assumptions, and security objectives.

Threat modelling is particularly effective during system design because architectural changes are less expensive before deployment. Nevertheless, it remains valuable for legacy systems, cloud migrations, application changes, and major supplier integrations. The output should be connected to requirements, test cases, monitoring, and risk acceptance rather than stored as an isolated document.

Vulnerability Information in Context

Vulnerability information includes weaknesses identified through advisories, scanning, penetration testing, code review, configuration assessment, incident evidence, and vendor notifications. A vulnerability identifier and severity score provide useful reference points, but they do not determine organisational risk by themselves.

Interpretation requires consideration of exposure, exploit availability, authentication requirements, privileges, affected asset value, compensating controls, exploit maturity, attacker relevance, and remediation feasibility. A high-scoring vulnerability on an isolated, non-production asset may be less urgent than a medium-scoring weakness in an exposed identity service supporting a critical process. Conversely, a vulnerability with no known exploitation may still deserve prompt action when the affected asset is highly consequential and remediation is straightforward.

Vulnerability management should therefore combine technical severity with business context. Useful prioritisation questions include:

1. Is the asset reachable from an untrusted network or trust zone?

2. Does exploitation require valid credentials, local access, or special conditions?

3. Is there credible evidence of exploitation or targeting?

4. What data or service could be affected?

5. Are monitoring, segmentation, backups, or other controls likely to reduce impact?

6. What is the exposure window and what is the remediation or mitigation option?

This approach prevents both vulnerability-count inflation and dangerous reliance on a single numerical score.

Constructing Defensible Risk Scenarios

A risk scenario should be sufficiently specific to support a decision while avoiding unsupported precision. A practical structure is:

Threat source + capability or motivation + attack path + affected asset or service + vulnerability or enabling condition + event + business consequence.

For example: “A criminal group seeking financial gain uses stolen employee credentials and an exposed remote-access service to enter the finance environment, escalates through excessive privileges, and alters supplier bank details, causing fraudulent payments and delayed procurement.”

The scenario can then be analysed through likelihood dimensions such as opportunity, capability, exposure, control effectiveness, and historical or intelligence evidence. Consequence can be considered across confidentiality, integrity, availability, safety, legal, financial, and reputational dimensions. The purpose is not to manufacture an exact probability when evidence is weak. A range, confidence statement, or qualitative rationale may be more honest and useful.

Scenario quality improves when assumptions are explicit. Analysts should state what is known, inferred, uncertain, and excluded. They should identify early warning signals, preventive controls, detection opportunities, response actions, recovery dependencies, and residual risk. A scenario should also have an owner who can make or sponsor treatment decisions.

An Illustrative Case: Northbridge Health Network

Background

Northbridge Health Network is a fictional regional healthcare provider operating hospitals, outpatient clinics, diagnostic laboratories, and a patient portal. Its clinical services depend on an electronic health-record platform, identity services, laboratory interfaces, imaging systems, telemedicine applications, and several technology suppliers. Patient records are classified as highly restricted because disclosure could cause privacy harm, legal exposure, and loss of trust. Clinical integrity and availability are also critical because inaccurate or unavailable information may affect treatment decisions.

Situation and problem

The security team receives intelligence that healthcare organisations are being targeted through stolen credentials and exploitation of exposed remote-access technologies. A vulnerability scan identifies a medium-severity weakness in a remote administration appliance used by an infrastructure supplier. The appliance is not directly connected to the clinical database, but it provides a management path into a network segment containing diagnostic systems. Asset records are incomplete, and the supplier’s emergency contact and recovery responsibilities are unclear.

A simple vulnerability-based report would rank the finding as medium and assign it to infrastructure operations. Senior management, however, needs to know whether the weakness creates a material risk to patient care.

Analysis

The team first maps the clinical services and discovers that the diagnostic reporting service depends on the remote administration appliance, the supplier’s privileged accounts, a directory service, and a data exchange interface with the electronic health-record platform. The appliance is classified as a supporting asset with high availability and integrity significance, even though it does not store patient records.

Threat intelligence suggests that credential theft and remote management abuse are plausible techniques for the sector, but it does not prove that Northbridge is being targeted. The team develops an attack tree with the objective “disrupt diagnostic reporting.” Alternative branches include exploiting the appliance vulnerability, using stolen supplier credentials, compromising a supplier workstation, or abusing a poorly restricted management interface. ATT&CK mapping identifies likely behaviours involving external remote services, valid accounts, privilege escalation, discovery, and impact.

The analysis identifies several enabling conditions: incomplete asset ownership, excessive supplier privilege, insufficient network segmentation, limited logging of administrative sessions, and uncertain restoration procedures. The vulnerability itself is only one part of the scenario.

Approach and strategy

Northbridge applies immediate compensating controls by restricting management access to approved source networks, disabling unused accounts, requiring phishing-resistant multifactor authentication for supplier access, and increasing monitoring of privileged sessions. The appliance is scheduled for urgent remediation after testing. The network team validates that diagnostic systems cannot be used as a route into broader clinical infrastructure.

The organisation then updates the service inventory, records the supplier and recovery dependencies, classifies the diagnostic service according to clinical impact, and agrees an RTO with the clinical owner. A tabletop exercise tests whether the organisation can isolate the management appliance, contact the supplier, operate on contingency procedures, restore trusted configurations, and communicate with clinicians and patients.

Outcome

The scenario is escalated from a routine technical finding to a material service risk because the business context demonstrates potential impact on clinical operations. No compromise is asserted. Instead, the organisation records a plausible threat scenario with moderate confidence, high consequence, and urgent treatment requirements. The case also reveals governance weaknesses that would not have been visible in a vulnerability register alone.

Learning points

The case illustrates five principles. First, supporting assets can be business-critical even when they do not hold sensitive data. Second, threat intelligence informs plausibility but does not establish certainty. Third, vulnerability severity must be interpreted alongside exposure and service impact. Fourth, supplier access and recovery dependencies belong in the risk scenario. Finally, a good scenario leads to controls, monitoring, exercises, ownership, and decisions rather than merely producing a score.

Common Failure Modes and Limitations

One frequent mistake is beginning with tools rather than services. Automated discovery and scanning are valuable, but they cannot determine business criticality, acceptable downtime, or the consequences of data alteration. A second mistake is treating the inventory as permanently correct. Cloud resources, temporary environments, software components, and supplier relationships change rapidly.

Another failure is producing threat catalogues without relevance. Listing every possible actor or ATT&CK technique creates noise and weakens prioritisation. Analysts should distinguish plausible scenarios from merely conceivable ones and record the evidence supporting each judgement. Overconfidence is also dangerous: threat intelligence may be incomplete, adversaries may change methods, and absence of observed activity does not prove absence of risk.

Organisations sometimes equate compliance classification with risk analysis. A regulatory label can establish minimum obligations, but it may not capture operational dependency, safety, strategic importance, or concentration risk. Similarly, vulnerability scores can create false precision when asset ownership, exposure, or compensating controls are unknown.

Attack trees and kill chains have modelling limitations. They may imply linearity, omit insider or supply-chain routes, or encourage analysts to focus on technically elegant attacks rather than probable ones. Threat models can also become obsolete after architecture, suppliers, or business processes change. Reviews should therefore be triggered by material change, incidents, new intelligence, and periodic governance cycles.

Governance, Ethics, and Professional Responsibilities

Risk identification involves access to sensitive architecture information, personal data, employee activity, supplier arrangements, and intelligence about suspected actors. Analysts must apply purpose limitation, data minimisation, access control, retention rules, and appropriate legal authority. Monitoring should not become unrestricted surveillance merely because it is technically possible.

Professional judgement must be transparent. Analysts should distinguish evidence from assumption, document uncertainty, avoid sensational claims, and present alternative interpretations where appropriate. Threat intelligence involving personal data or information obtained from questionable sources requires careful legal and ethical review. Offensive validation, penetration testing, and red-team activity must be authorised, scoped, and conducted in ways that minimise operational harm.

Governance also requires clear accountability. Business owners should validate service criticality and consequences; technology owners should explain architecture and control conditions; security professionals should provide analysis; procurement and legal functions should address supplier obligations; and senior leadership should decide on risk acceptance within the organisation’s authority and appetite.

Technology, Automation, and Emerging Practice

Modern organisations increasingly use automated asset discovery, cloud-security posture management, attack-surface monitoring, software composition analysis, vulnerability prioritisation, and security-information-and-event-management platforms. These technologies can improve timeliness and reveal relationships that manual registers miss. Graph-based platforms can connect identities, assets, vulnerabilities, data flows, suppliers, and attack techniques to highlight paths to critical services.

Artificial intelligence can assist with summarising threat reports, correlating indicators, generating candidate attack paths, classifying assets, and identifying anomalous relationships. However, generated analysis requires human validation. AI systems may propagate inaccurate intelligence, infer sensitive attributes, overstate confidence, or recommend actions without understanding operational consequences. Sensitive architecture and incident information should not be entered into external systems without appropriate contractual, privacy, and security controls.

Emerging practice is moving toward continuous exposure management: risk identification is updated as internet exposure, identities, cloud configurations, software dependencies, and threat evidence change. This does not eliminate the need for periodic risk assessment. Continuous data collection still requires governance, interpretation, ownership, and decisions about treatment.

Best-Practice Principles

A defensible identification programme should:

• begin with business services and critical processes, then trace supporting assets and dependencies;
• assign accountable owners and record confidence in inventory information;
• classify data according to consequences and connect classifications to handling requirements;
• use a governed risk taxonomy that supports both executive and technical communication;
• combine threat intelligence with architecture, exposure, vulnerability, and control evidence;
• use attack trees, kill chains, ATT&CK, and threat modelling for different analytical purposes rather than treating them as interchangeable;
• prioritise vulnerabilities according to exploitability, exposure, business impact, and available mitigation;
• express risks as specific scenarios with assumptions, uncertainty, indicators, and consequences;
• review scenarios after material change, incidents, new intelligence, and supplier or architectural change; and
• ensure that risk analysis leads to accountable treatment, monitoring, response preparation, and informed acceptance.

Chapter Summary

Cyber risk identification is the disciplined connection of business objectives, services, assets, data, dependencies, threats, vulnerabilities, and consequences. Asset inventories are necessary but insufficient; they must be linked to service maps, ownership, business impact, recovery requirements, and external dependencies. Data classification and risk taxonomies establish consistent language and help connect information value with controls and reporting.

Threat intelligence adds relevance by describing actors, motivations, targeting, and behaviours, but it must be assessed for reliability and applicability. Attack trees explore alternative routes to an attacker objective, kill-chain analysis structures an intrusion narrative, MITRE ATT&CK maps adversary behaviours, and threat modelling examines system architecture, trust boundaries, and misuse. These approaches complement rather than replace one another.

Vulnerability information becomes meaningful only when interpreted through exposure, exploitability, asset criticality, control effectiveness, and business impact. A defensible risk scenario identifies a plausible threat source, pathway, enabling condition, affected service, event, and consequence while documenting uncertainty. Effective practice is supported by governance, ethical handling of sensitive information, automation with human oversight, and continuous review as systems and threats change.

Key Terms

Asset: Anything of value that requires protection, including systems, information, identities, services, and facilities.

Business service: An organisational outcome delivered to customers, employees, citizens, or partners.

Business impact: The operational, financial, legal, safety, privacy, strategic, or reputational consequence of an adverse event.

Data classification: Assignment of information to categories that determine handling and protection requirements.

Dependency: A system, process, supplier, utility, or service required for another service to operate.

Threat: A potential source of harm, such as an attacker, insider, failure, or environmental event.

Threat intelligence: Processed information about threats that supports security decisions.

Vulnerability: A weakness or condition that may be exploited or increase potential harm.

Threat event: An occurrence that exploits a weakness or otherwise creates an adverse condition.

Risk scenario: A structured description linking a threat, pathway, asset or service, event, and consequence.

Attack tree: A hierarchical model showing alternative and combined routes to an attacker objective.

Cyber kill chain: A staged model describing major phases of an intrusion.

MITRE ATT&CK: A knowledge base of adversary tactics and techniques based on observed behaviour.

Threat modelling: A structured examination of how systems may be attacked or misused.

Attack surface: The set of exposed interfaces, services, identities, and components through which an attack may occur.

Recovery time objective: The targeted maximum time within which a service should be restored.

Recovery point objective: The acceptable amount of data loss measured in time.

Compensating control: An alternative safeguard that reduces risk when a preferred control is absent or impractical.

Residual risk: Risk remaining after controls and treatments have been applied.

Review Questions

Short Answer Questions

1. Why should a cyber risk programme inventory business services as well as technical assets?

2. Distinguish a threat, a vulnerability, and a threat event.

3. What is the purpose of data classification?

4. How does threat intelligence differ from a raw indicator feed?

5. Why should vulnerability severity not be used as the sole basis for prioritisation?

Long Answer Questions

1. Explain how business impact analysis and dependency mapping improve cyber risk identification.

2. Compare attack trees, cyber kill-chain analysis, and MITRE ATT&CK in terms of purpose and limitation.

3. Describe a structured method for developing a defensible cyber risk scenario.

4. Discuss how data classification and risk taxonomies support governance and control decisions.

5. Explain the role of threat modelling across the lifecycle of a cloud-based application.

Analytical / Application Questions

1. An organisation discovers a critical vulnerability on a server that supports a low-value test environment and a medium-severity vulnerability on an exposed identity provider used by a critical payment service. Which should receive priority, and what additional evidence would you seek?

2. Construct an attack tree for the objective “disrupt an online examination service.” Identify at least two alternative attack paths and three potential control points.

3. Using the Northbridge Health Network case, develop a revised risk scenario after the supplier introduces phishing-resistant multifactor authentication but network segmentation remains incomplete. Explain how the likelihood and consequence assessment should be reconsidered.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes a defensible cyber risk scenario?

A. A list of all vulnerabilities detected during the latest scan

B. A general statement that ransomware is a threat to the organisation

C. A reasoned link between a threat, attack path, affected service, enabling condition, and consequence

D. A numerical score assigned automatically to an asset

Correct Answer: C. A reasoned link between a threat, attack path, affected service, enabling condition, and consequence

Question 2

Why should business services be linked to supporting assets in an inventory?

A. To eliminate the need for technical scanning

B. To show how disruption of components may affect an organisational outcome

C. To ensure every asset receives the same protection level

D. To replace business owners with automated ownership records

Correct Answer: B. To show how disruption of components may affect an organisational outcome

Question 3

Which example most clearly represents a vulnerability rather than a threat event?

A. A criminal group seeking financial gain

B. Unauthorised encryption of production files

C. An exposed remote administration interface with weak access restrictions

D. Loss of customer access to an online service

Correct Answer: C. An exposed remote administration interface with weak access restrictions

Question 4

What is the primary value of MITRE ATT&CK in risk identification?

A. It calculates the exact probability of every cyberattack

B. It maps adversary behaviours to tactics and techniques that can inform defence

C. It replaces asset inventories and business impact analysis

D. It proves that every listed technique is active in an organisation

Correct Answer: B. It maps adversary behaviours to tactics and techniques that can inform defence

Question 5

An attack tree is most useful for which analytical purpose?

A. Showing alternative and combined routes to an attacker objective

B. Assigning legal ownership of personal data

C. Calculating recovery time objectives automatically

D. Replacing vulnerability remediation testing

Correct Answer: A. Showing alternative and combined routes to an attacker objective

Question 6

Which factor most strongly explains why a medium-severity vulnerability may require urgent treatment?

A. The vulnerability has a long technical name

B. The affected asset supports a critical service and is externally exposed

C. The vulnerability appears in a vendor newsletter

D. The asset has a recently updated inventory record

Correct Answer: B. The affected asset supports a critical service and is externally exposed

Question 7

What is a key limitation of a cyber kill-chain model?

A. It cannot be used to discuss defensive controls

B. It may imply a linear attack sequence even though real attacks can branch or iterate

C. It only applies to physical security incidents

D. It excludes all forms of reconnaissance

Correct Answer: B. It may imply a linear attack sequence even though real attacks can branch or iterate

Question 8

Which action best demonstrates contextual use of threat intelligence?

A. Importing every indicator from a public feed into the risk register

B. Assuming that an organisation is compromised whenever a sector is targeted

C. Assessing whether reported actor techniques are feasible against the organisation’s architecture

D. Discarding intelligence that does not include a malware hash

Correct Answer: C. Assessing whether reported actor techniques are feasible against the organisation’s architecture

Question 9

In the Northbridge case, why was the remote administration appliance treated as significant even though it did not store patient records?

A. All network devices automatically have the highest classification

B. It supported diagnostic services whose availability and integrity affected clinical operations

C. The appliance was owned by an external supplier

D. The vulnerability scanner assigned it the highest possible severity

Correct Answer: B. It supported diagnostic services whose availability and integrity affected clinical operations

Question 10

Which practice best supports ethical and professional threat analysis?

A. Presenting assumptions as confirmed facts to obtain faster remediation

B. Collecting all available employee data regardless of purpose

C. Documenting evidence, uncertainty, authority, and proportionality in monitoring and testing

D. Using artificial intelligence recommendations without human review

Correct Answer: C. Documenting evidence, uncertainty, authority, and proportionality in monitoring and testing