Risk Management and Threat Modeling

Risk is the decision, not the artifact

Chapter 3 ended with a claim worth repeating: governance decides who is accountable, and risk is what they are accountable for. This chapter is the machinery that sits underneath that accountability. Every control in the other seven domains, a firewall rule, an encryption key, a background check, a backup policy, exists for one reason: it changes a risk number or a risk rating. The firewall does not make packets safe. It reduces the likelihood and impact of a class of bad events, which is to say it changes the risk that some accountable manager has agreed to carry.

That is the organizing idea of the CISSP and the reason Domain 1 carries more exam weight than any other. The exam is not a technology exam wearing a security costume, and it is not a compliance exam either. It is a risk-management exam. The best answer in a CISSP scenario is almost never the most technical one. It is the one that identifies the risk correctly, treats it through the correct response, assigns the decision to the person with the authority to make it, and keeps the record that proves the decision was made. When you learn that rhythm, you have learned the exam. This chapter gives you the full machinery: the vocabulary, the two registers of analysis, the mathematics of annualized loss, the response decision ladder, the NIST Risk Management Framework that turns assessment into an authorization decision, and the threat-modeling methods that find threats before they become incidents.

Two warnings before we begin. First, precision matters here more than in any other chapter. The exam distinguishes risk, threat, vulnerability, likelihood, impact, and exposure with lawyer-like care, and many questions hinge on a single word. Second, the math is easy arithmetic. What the exam actually tests is your judgment about when the math applies, what it means, and who is allowed to act on it. Keep both in mind and the material reads like a series of familiar decisions rather than a list of formulas.

The vocabulary: five words that carry the whole exam

Standards organizations define these words slightly differently, and the differences are worth knowing because they are the differences the exam exploits. The International Organization for Standardization, in ISO 31000:2018, defines risk as “the effect of uncertainty on objectives.” Note what that definition includes: effect, not just harm; uncertainty, not just threat; and objectives, which means risk only exists relative to something the organization is trying to achieve. A vulnerability in a toy that connects to nothing, holds no data, and serves no objective is not, in that sense, a risk to anything. The definition is deliberately broad, and it is the definition the whole ISO risk family, including ISO/IEC 27001:2022, builds on.

The US federal definition is narrower and more operational. NIST Special Publication 800-30 Revision 1, “Guide for Conducting Risk Assessments,” defines risk as a measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of the adverse impacts that would arise if the circumstance or event occurs and the likelihood of occurrence. That is the definition the exam lives in, because it names the two inputs the exam questions manipulate: likelihood and impact.

The five words that carry the whole exam:

• A threat is any circumstance or event with the potential to cause harm to an asset. Threats come in two broad flavors. A threat source is the actor or natural force that initiates the event, the adversary, the storm, the careless employee. A threat event is the specific thing that happens, the credential theft, the flood, the misconfiguration.
• A vulnerability is a weakness in an asset, a control, or a process that a threat can exploit. Unpatched software is a vulnerability. A badge reader without a mantrap is a vulnerability. A purchase order process with no segregation of duties is a vulnerability.
• Likelihood is how probable a given threat event is, judged against the current controls. The exam sometimes calls this probability and treats them as synonyms; for the math register, treat likelihood as a number between zero and one.
• Impact is the magnitude of harm that occurs when the event happens: financial loss, operational disruption, reputational damage, legal liability, harm to people.
• Risk is the product of the first two considerations, in the exam’s shorthand. If a threat can exploit a vulnerability and the resulting impact matters, there is risk. If any leg is missing, there is no risk to manage. A formula you will see in many places, Risk = Threat × Vulnerability × Impact, is a teaching device, not a computable equation, but it encodes the correct intuition: remove any factor and the risk goes to zero.

Two more terms close out the vocabulary. Exposure is the state of being subject to loss: an asset is exposed if a threat could reach it. Exposure matters because it separates “we could lose this” from “we are losing this,” and it explains why reducing attack surface, the total set of reachable entry points an attacker could use, is such a common control directive. A countermeasure, also called a control or a safeguard, is anything that reduces risk: an action, device, procedure, or policy. The exam uses these words interchangeably, and so should you.

Threat sources: who and what is in the threat model

Risk analysis starts by naming the threats. The exam expects you to recognize the standard taxonomy of threat sources, because different sources imply different defenses and different response economics.

Adversarial sources are actors with intent. Nation-states have the deepest resources and the longest patience, and they tend to target specific organizations for specific purposes: espionage, sabotage, intellectual property theft. Organized crime is opportunistic and financially motivated, and it dominates ransomware, fraud, and credential theft. Hacktivists attack to make a political point, which means their targets are symbolic and their methods favor disruption and defacement. Insiders, employees, contractors, and partners, act with legitimate access, which makes them disproportionately dangerous: their attacks need no vulnerability in the perimeter because the perimeter let them in. The lone or casual attacker rounds out the taxonomy, low sophistication, low resources, often seeking notoriety.

Non-adversarial sources matter just as much and get less attention. Natural sources, fire, flood, earthquake, wind, pandemic, are the reason Chapter 5 exists and the reason physical controls sit inside the architecture domain. Accidental sources, human error, misconfiguration, unvalidated input, are statistically the most common cause of outages and data loss. The exam’s scenarios rarely feature a fire, but the correct response to a question about selecting a recovery site or a backup strategy is often grounded in exactly these non-adversarial risks.

When you analyze an adversarial threat, three attributes drive the analysis: capability, intent, and targeting. Capability is what the actor could do, intent is what the actor wants to do, and targeting is whether the actor has chosen this organization specifically. A nation-state with full capability and zero interest in your mid-sized regional bank is not a risk to it; a hacktivist with modest capability and a grudge against your industry might be. This is why threat intelligence matters and why “who is actually coming after us” is the first question of any mature risk conversation. The exam rewards the same discrimination: when a scenario describes a threat, the best answer usually matches the response to the actor’s actual profile rather than applying maximum paranoia everywhere.

The two registers of analysis: qualitative and quantitative

Once threats are named, the organization has to decide how much they matter. There are two registers for doing this, and the exam expects you to know both cold, including when each one is appropriate.

Quantitative analysis works in money and probability. It produces numbers: an asset is worth $400,000, an event has a 0.25 probability per year, the expected annual loss is $25,000. Its outputs are clean inputs for cost-benefit decisions, because you can compare the price of a control against the loss it avoids. Its weakness is data. Reliable loss figures require history, actuarial records, or defensible estimates, and for rare or novel events the numbers become confident-sounding guesses. The classic failure is treating a precise estimate as a precise truth.

Qualitative analysis works in ratings. Analysts or subject-matter experts rate likelihood and impact on scales, high, medium, low, or one to five, and the combination places the risk on a matrix. It is faster, cheaper, and works when history is thin. Its weaknesses are subjectivity and imprecision: two experts can rate the same risk differently, and a rating of “high” does not tell you whether to spend $10,000 or $1,000,000. The Delphi technique, an anonymous, iterative consensus process where experts revise their estimates in rounds until views converge, is a standard tool for improving qualitative rigor.

A middle register exists: semiquantitative analysis assigns numbers to the ratings, 1 to 5 instead of low to high, and multiplies them, which produces ranks without pretending to be money. It is common in risk matrices and entirely acceptable when the goal is prioritization rather than budgeting.

A more rigorous quantitative family deserves a mention because it appears in modern practice and in the exam’s vocabulary: FAIR, the Factor Analysis of Information Risk standard maintained by The Open Group. FAIR decomposes risk into loss event frequency, the combination of how often threats act and how often those actions succeed against the current controls, and loss magnitude, the probable financial consequence. Multiplying the two gives a probable loss range rather than a single false-precision point. FAIR is worth knowing as the answer to “quantitative analysis that models probability honestly,” because it treats uncertainty explicitly instead of hiding it.

The exam question you will see repeatedly is the comparative one: which register for which situation. The answer pattern is stable. When the decision is about spending money, quantitative wins. When the decision must be made quickly with limited data, or when the risk defies monetary valuation, qualitative wins. When a scenario says “the cost-benefit of a control,” the exam wants the quantitative math, and it wants it computed correctly.

The math register: AV, EF, SLE, ARO, ALE

The quantitative core of CISSP risk analysis is a set of four quantities and one rule. Learn the definitions, the formula, and the cost-benefit rule, and the arithmetic questions stop being intimidating.

• Asset value (AV) is the value of the asset, in money, typically replacement cost or the value to the organization of its loss. For a database, AV is not the cost of the hardware alone; it includes the value of the data, the revenue it generates, and the cost of recreating it. The exam uses AV as the baseline for all loss math.
• Exposure factor (EF) is the percentage of the asset value that would be lost in a single occurrence of the threat event. If a fire destroys half the building’s assets, EF is 0.5. EF is always expressed as a fraction of AV, which is why it is called a factor.
• Single loss expectancy (SLE) is the expected loss from one occurrence: SLE = AV × EF. If the asset is worth $800,000 and one flood event destroys 30 percent of it, SLE is $240,000.
• Annual rate of occurrence (ARO) is how many times per year the event is expected to happen. It can be fractional: an event expected once every four years has an ARO of 0.25; an event expected three times in ten years has an ARO of 0.3.
• Annualized loss expectancy (ALE) is the expected loss per year: ALE = SLE × ARO. This is the number that makes risk comparable to control spending.

Work the canonical example end to end. An application server cluster is valued at $800,000. If a ransomware event hits, restoration and downtime cost about 30 percent of that value, so EF is 0.30 and SLE is $800,000 × 0.30 = $240,000. The organization’s incident records show ransomware events hitting similar clusters three times in the last ten years, so ARO is 0.3. ALE = $240,000 × 0.3 = $72,000 per year. That single number, $72,000 a year, is now the budget the organization can reason about: a defensive control that reliably prevents the whole class of event and costs less than $72,000 a year is worth buying on arithmetic alone.

That arithmetic is the cost-benefit rule, and the exam tests it constantly: the benefit of a control is the reduction in ALE it produces, and the control is worth implementing when that annualized benefit exceeds the annualized cost of the control. Extend the example. A proposed backup and recovery hardening would cut the exposure factor from 30 percent to 10 percent, new SLE $80,000, new ALE $24,000, a reduction of $48,000 per year. If the hardening costs $25,000 per year, fully loaded, the net benefit is $23,000 per year and it should be funded. If the same control cost $60,000 per year, the arithmetic says no, and the correct exam answer will say no as well: it is bad business to spend more on a control than the risk it removes.

A few traps lurk in the arithmetic, and they are the exam’s favorite places to hide errors. First, EF is a fraction of AV, not an independent cost: computing SLE as a dollar amount and then multiplying by ARO without first multiplying by AV is the classic mistake. Second, ARO can be fractional, and converting “once every N years” to 1/N is a required move. Third, ALE is annual: cost-benefit comparisons must put control costs on an annualized footing, which is why one-time control purchases get spread across their useful life. Fourth, when a scenario gives you an ALE and asks for the control decision, compute the before and after ALEs and compare the difference to the control’s annual cost. Do not compare the control cost to the before-ALE alone, and do not forget that the reduction, not the remaining risk, is the benefit.

Finally, respect the limits of the math. ALE arithmetic assumes the numbers are real, and for rare catastrophes they rarely are: no actuarial table tells you the ARO of the first targeted state-sponsored intrusion into your industry, and treating a guess as data is how false precision corrupts decisions. This is why mature organizations run both registers, the quantitative one for the spend decisions and the qualitative one for the things the numbers cannot see. The exam wants you to do the arithmetic when it is given and to distrust the arithmetic when the scenario calls for judgment.

From analysis to evaluation: the register, the matrix, and the appetite

Analysis produces numbers or ratings. Evaluation is the step that decides what they mean, and it happens against a backdrop the organization has to establish before the first risk is scored.

ISO 31000:2018 draws the line cleanly: risk assessment comprises risk identification, risk analysis, and risk evaluation. Identification produces the candidate list of risks. Analysis attaches likelihood and consequence to each one, in whichever register the organization chose. Evaluation compares the analyzed risk against the organization’s risk criteria, the appetite, tolerance, and thresholds it has set, and decides which risks need treatment and which can be accepted as they are. Evaluation is the gate: it converts “how big is this risk” into “what do we do about it.”

The two organizational settings that evaluation runs on are risk appetite and risk tolerance, and the exam tests the difference between them. Per ISO 31000:2018, risk appetite is the amount and type of risk that an organization is willing to pursue or retain. It is strategic: a startup building an unproven product has a different appetite than a hospital. Risk tolerance is the acceptable deviation from that appetite. Think of appetite as the target lane and tolerance as the width of the lane. An organization with a low appetite for data exposure can still tolerate small deviations; a regulator with zero tolerance for a particular control gap means the gap has to close regardless of cost-benefit arithmetic. A related concept, the risk threshold, is the point at which a risk becomes large enough that it triggers a decision or a control; thresholds are how tolerance gets operationalized.

Two more terms complete the evaluation toolkit, and they will appear in every scenario question about responses. Inherent risk is the risk that exists before any controls, the exposure in a world where the building has no locks. Residual risk is what remains after controls are applied and risks are transferred: no control removes risk entirely, and the amount that survives is residual risk. The exam’s favorite evaluation question is about residual risk: who acknowledges it, and what the acknowledgment means. The answer is that management, at the level with authority to bear the consequences, formally accepts the residual risk. An analyst identifies risk. The CISO and the security team advise and design treatment. The accountable manager, the one whose budget and charter carry the consequences, signs the acceptance. This is not bureaucracy; it is the governance chain from Chapter 3 in action, and the exam tests it constantly.

The output that carries all of this is the risk register. A risk register is the living record of identified risks: for each risk it holds a description, the asset or process affected, the assessed likelihood and impact, the current risk level, the chosen response, the treatment plan and its status, the risk owner, and a review date. It is not a one-time artifact and it is not a list of controls. It is the working document that tracks risks from identification through treatment to re-evaluation, and it is the first thing an auditor or a new CISO asks to see. Every threat model in the second half of this chapter feeds this register, and every response decision updates it.

The response decision ladder

When evaluation says a risk needs treatment, the organization chooses a response. The classic four options are avoid, mitigate, transfer, and accept, and the exam expects you to assign scenarios to options with precision, because the four words are the four possible answers to a large share of Domain 1 questions.

Avoidance eliminates the risk by eliminating the activity that creates it. Drop the service, exit the market, refuse the contract, don’t build the feature. Avoidance is the only response that makes the risk zero, and it is the correct answer when a risk is far outside appetite and no amount of control spending or transfer brings it inside. Its cost is the lost opportunity: the thing you chose not to do.

Mitigation reduces the risk to an acceptable level by lowering likelihood, lowering impact, or both. This is where controls live: encryption reduces the impact of a data theft, patching reduces the likelihood of an exploit, fire suppression reduces the impact of a fire. Mitigation is the default response and the one the security profession spends most of its time on. Controls are classified by their behavior, and the classes map onto the response logic: preventive controls stop the event (locks, authentication, input validation), detective controls find it (logs, monitoring, alarms), corrective controls restore after it (backups, patching, incident response), deterrent controls discourage it (signage, visible cameras, audits), recovery controls rebuild the capability, and compensating controls substitute for a control that cannot be implemented as designed. The exam will hand you a scenario and ask which class of control fits; the discriminator is the moment in the event timeline the control acts on.

Transfer shifts the financial consequence of a risk to another party. Insurance is the canonical example: the organization pays a premium, and the insurer indemnifies covered losses above the deductible. Outsourcing and contracting can transfer risk as well, when a service provider contractually assumes liability for defined failures, though the exam is careful here: operational risk may move, but accountability for the outcome never fully leaves the organization, which is why the answer to “who ultimately answers for a breach at a vendor” is always the organization that owns the data and the relationship. Transfer does not reduce likelihood or impact; it changes who pays.

Acceptance is the deliberate, documented decision to retain a risk and its consequences. Acceptance is not inaction, and it is not the analyst quietly deciding something is fine. It is a formal decision artifact: the risk is recorded in the register, the residual exposure is approved by management with the authority to bear it, and the decision is reviewed on a schedule or when conditions change. The exam hammers one distinction here: a risk acceptance is never made by the person who found the risk, and it is never made by a security analyst with no authority over the business exposure. It is made by the accountable owner.

When the scenario gives you the raw material, run the ladder in order. Is the risk within appetite as it stands? Then record it and accept it with a review date. Is it outside appetite but avoidable at acceptable opportunity cost? Avoid it. Is it outside appetite but transferable? Transfer what can be transferred. Is it outside appetite and neither avoidable nor transferable, or only partially? Mitigate until it lands inside tolerance, then formally accept the residual. The order is the framework; the exam rewards candidates who can defend the step they chose and, just as often, reject the step they did not.

The Risk Management Framework: where assessment becomes authorization

The vocabulary and the math give you the raw material. The NIST Risk Management Framework gives the exam its procedural skeleton: the seven-step sequence that turns assessment into an authorization decision. It is defined in NIST Special Publication 800-37 Revision 2 (2018), “Risk Management Framework for Information Systems and Organizations,” and it is the process the federal government and a large share of regulated industry use for system-level risk management.

The seven steps, in order:

1. Prepare. The organization and the system prepare for risk management before anything is assessed. At the organization level this means assigning roles and responsibilities and establishing the risk tolerance and strategy; at the system level it means defining the system description, the system boundary, and the supporting risk management processes. The addition of Prepare was the defining change of Revision 2: NIST concluded that assessment was failing without a deliberate setup phase, so it made readiness a formal step.
2. Categorize. The system and the information it processes are categorized according to impact. The categorization standard is FIPS 199, “Standards for Security Categorization of Federal Information and Information Systems,” which defines three security objectives, confidentiality, integrity, and availability, each assessed at one of three impact levels: low, meaning limited adverse effect, moderate, meaning serious adverse effect, and high, meaning severe or catastrophic adverse effect. The system’s overall impact level is the high-water mark: the highest of the three objective ratings. A system with confidentiality high, integrity moderate, and availability moderate is categorized as a high-impact system, and its controls must be chosen accordingly.
3. Select. Controls are selected from NIST Special Publication 800-53, “Security and Privacy Controls for Information Systems and Organizations,” using the baseline that matches the impact level from FIPS 199: a low baseline, a moderate baseline, or a high baseline. The baseline is then tailored, controls are allocated to system components, and compensating controls are documented where a baseline control cannot be implemented as written. The selection step is where FIPS 200, “Minimum Security Requirements for Federal Information and Information Systems,” and its mapping to the control families become relevant.
4. Implement. The selected controls are deployed and the organization documents how each control is implemented, where it is implemented, and what it is supposed to do. Implementation without documentation is a recurring failure, which is why the step produces a control implementation description.
5. Assess. The controls are evaluated to determine whether they are implemented correctly, operating as intended, and producing the desired outcome. The assessment procedures live in NIST Special Publication 800-53A, and the product is a set of assessment findings, one per control. Controls that fail produce deficiencies, and the deficiencies are recorded in the Plan of Action and Milestones, the POA&M, which tracks remediation with owners and dates.
6. Authorize. A senior official, the authorizing official, makes a formal, risk-based decision about whether to operate the system, accepting the residual risk in writing. The product is an authorization to operate, the ATO, and it is a decision, not a certificate: the authorizing official is accepting the documented residual risk on the organization’s behalf. Denials, interim authorizations, and conditional authorizations are all possible outcomes.
7. Monitor. Risk management continues after authorization. The organization implements continuous monitoring, defined in NIST Special Publication 800-137, reassesses controls on an ongoing schedule, tracks changes to the system and its environment, and reports on the security state. Re-authorization happens when the system changes materially, and every significant change to the system or its risk posture feeds back into the framework.

Two surrounding facts make the framework coherent. NIST Special Publication 800-39, “Managing Information Security Risk,” organizes risk management at three tiers: the organization tier, where governance and strategy live; the mission or business process tier, where risk is considered in the context of what the business is doing; and the system tier, where the RMF operates. The seven-step RMF is the system tier; it assumes the other two tiers exist. And in 2024, NIST released a draft of SP 800-37 Revision 3 that adds a governing step at the front, making the sequence Govern, Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. The seven-step Revision 2 sequence remains the version to know cold, and the draft’s change is worth knowing because it tells you where NIST thinks the framework’s weaknesses are: at the top, in governance.

The RMF is also the clearest illustration of the exam’s manager perspective. Every step has an owner: the categorizer, the control selectors, the assessors, the authorizing official, the continuous monitoring team. The security professional’s job in the framework is not to make the authorization decision; it is to make sure the decision-maker has an accurate, complete picture of the risk, which means the assessment must be honest, the POA&M must be real, and the residual risk must be stated plainly.

Threat modeling: the design-time engine

Risk assessment measures the risk of systems that exist. Threat modeling finds threats before they exist, at design time, and it is the tool that turns “we manage risk” from a review activity into an engineering activity. The distinction matters for the exam: risk assessment and threat modeling are not synonyms. Risk assessment scores known risks against appetite and feeds the register. Threat modeling systematically discovers threats in a system’s design, ranks them, and specifies mitigations that prevent the threats from ever becoming risks in the register. The best organizations run both: threat modeling at design time to shrink the risk, risk assessment through the lifecycle to measure what remains.

The threat-modeling loop has six moves:

1. Define the scope and objectives. What system or feature is being modeled, what is it supposed to do, and what is the business impact if it fails? Scope discipline is the difference between a useful model and a hand-waving exercise.
2. Model the system. Draw the architecture as a data flow diagram (DFD): processes, data stores, external entities, and the flows between them. Then mark the trust boundaries, the lines across which data moves from one level of trust to another, a user’s browser to the application server, the application server to the database, the internal network to the internet. Every trust boundary is a place where spoofing, tampering, or disclosure becomes possible, which makes the DFD the skeleton of the whole exercise.
3. Enumerate threats. For each element in the DFD, ask the threat questions systematically. This is where STRIDE comes in, and it is worth its own paragraph below.
4. Rank the threats. Not all threats deserve the same attention. Rating schemes like DREAD or likelihood-impact scoring produce a priority order, and the highest-ranked threats become the design requirements.
5. Define mitigations. For each ranked threat, specify the control that defeats it or reduces it to an acceptable level: authentication at the trust boundary, validation on every input, logging for repudiation. The mitigations become requirements, user stories, or acceptance criteria.
6. Validate and track. Revisit the model when the design changes, confirm the mitigations actually shipped, and feed the residual findings into the risk register.

STRIDE, introduced by Microsoft engineers Loren Kohnfelder and Praerit Garg in 1999, is the enumeration engine, and the exam treats it as the default answer for “which framework do you use to categorize threats.” Its six categories map one-to-one onto security properties:

• Spoofing is impersonating someone or something else, and it violates authenticity. An attacker forging a user’s identity, or a fake website pretending to be the real one, is spoofing.
• Tampering is modifying data, code, or configuration without authorization, and it violates integrity. A changed transaction amount, an altered log, a patched binary, all tampering.
• Repudiation is the ability to deny having done something, and it violates non-repudiation. When the system cannot prove who did what, an attacker can deny the action and a legitimate user can too. The control for repudiation is reliable attribution: logging, signatures, audit trails.
• Information disclosure is exposing data to parties who should not see it, and it violates confidentiality. A SQL injection that dumps the user table, a misconfigured bucket, a verbose error message, all disclosure.
• Denial of service is exhausting the system so legitimate users cannot use it, and it violates availability. Volume floods, resource exhaustion, crashed workers, all denial of service.
• Elevation of privilege is a low-privileged user gaining higher privilege, and it violates authorization. The classic exploit chain ends here, which is why the exam often treats elevation as the goal that spoofing, tampering, and injection serve.

The STRIDE discipline is mechanical: for each element of the DFD, ask all six questions, and you will rarely miss a threat class. It is also why the exam loves it: the categories are stable, the mapping to properties is stable, and a candidate who can name all six will beat a candidate who can describe the same threats loosely.

Once threats are enumerated, DREAD rates them. DREAD, the Microsoft rating scheme, scores each threat on five factors, usually one to ten: Damage potential (how much harm if it succeeds), Reproducibility (how reliably it works), Exploitability (how hard it is to pull off), Affected users (how many users or assets are hit), and Discoverability (how easy it is to find). The average of the five scores ranks the threat, and the ranking drives mitigation priority. DREAD is subjective and Microsoft itself has walked back its use in favor of simpler approaches, but the exam still treats it as the standard answer for “which scheme rates and prioritizes threats after STRIDE enumerates them.”

Beyond STRIDE and DREAD, the exam touches three other families. Attack trees, popularized by Bruce Schneier, model a single attacker goal as the root and decompose it into the alternative paths that achieve it, with AND branches for steps that must all happen and OR branches for alternatives. They are excellent for thinking like the attacker: find the cheapest path and defend it. The Lockheed Martin Cyber Kill Chain, published in 2011, describes an intrusion in seven phases, reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on objectives, and it is used to plan detection at each phase rather than waiting for the end. MITRE ATT&CK is the modern version of the same idea at industrial scale: a knowledge base of adversary tactics and techniques, organized per platform, with mapped mitigations and detections, and it has largely replaced kill-chain narrative as the working vocabulary of detection engineering. When the exam asks about mapping defenses to specific attacker behaviors, ATT&CK is the answer.

The remaining named approaches round out the landscape, and the exam mostly needs you to recognize them. PASTA, the Process for Attack Simulation and Threat Analysis, is a seven-stage, attack-centric process that starts with business objectives and ends with risk and impact analysis. OCTAVE, developed at Carnegie Mellon’s Software Engineering Institute, is a self-directed approach where the organization’s own teams evaluate organizational risks, assets, and practices, with OCTAVE Allegro as the streamlined variant. VAST, Visual, Agile, and Simple Threat Modeling, scales threat modeling into agile and DevOps pipelines, which is where the discipline lives in modern shops. And LINDDUN is the privacy analog, a framework for privacy-specific threats such as linkability and identifiability, worth naming when a scenario is about privacy rather than security.

Finally, threat modeling needs a scoring language to feed its findings into the register, and that is where CVSS comes in. The Common Vulnerability Scoring System, maintained by FIRST, scores vulnerabilities from 0.0 to 10.0 across base, temporal, and environmental metric groups; version 3.1 bands the scores into none (0.0), low (0.1 to 3.9), medium (4.0 to 6.9), high (7.0 to 8.9), and critical (9.0 to 10.0). CVSS scores drive patching priority and, in many organizations, the risk register itself. The exam wants you to know that CVSS is a scoring standard, that the score is not the risk, and that environmental context, what the system does, what data it holds, always has to be applied on top.

The decision frameworks in action

The machinery only earns its keep when it fires on a scenario. Work one end to end, the way the exam expects you to.

A mid-size organization is about to launch a customer-facing portal that will store payment information. The governance layer has set the appetite: low tolerance for card data exposure, moderate tolerance for availability issues, review required above a defined threshold. The threat model runs first, at design time. The DFD shows the browser tier, the application tier, and the database tier, with trust boundaries between each; STRIDE enumerates per element and finds, among others, injection in the application queries, session spoofing at the login boundary, and repudiation risk because the application logs no attribution for data changes. DREAD ranks injection and session spoofing at the top. The mitigations, parameterized queries, strong session handling with multi-factor authentication, and tamper-evident audit logging, become design requirements, and the residual findings go to the risk register.

At assessment time, the quantitative register prices the card data risk: asset value in fines, reissue, and brand damage, an exposure factor for a breach event, an ARO grounded in industry breach statistics for the payment industry, producing an ALE that lands above the organization’s threshold. Evaluation compares it to appetite: outside tolerance. The response ladder runs. Avoidance is not available; the business has decided to operate the portal. Transfer is partially available: the payment processor contract shifts some liability, and a cyber policy covers part of the loss. Mitigation closes the rest, and the residual risk is formally accepted by the manager whose budget carries it, recorded in the register with a review date.

Meanwhile the system has been walked through the RMF’s categorization: card data makes confidentiality high, and availability moderate, so the system categorizes high-impact under FIPS 199’s high-water-mark rule, which drives the SP 800-53 baseline the control selection starts from. The authorizing official signs the ATO only when the assessment is complete and the residual risk is honestly stated, and the monitoring step picks up from there, watching the register, re-scoring the CVSS findings, and re-running the threat model when the portal changes.

Every piece of this chapter fired in that one scenario: vocabulary, both registers, the math, evaluation, the ladder, the RMF, and the threat model. That is the exam, in miniature.

A set of heuristics will keep you oriented on the real exam:

• When a question offers four responses, the discriminator is usually the direction of the risk: zeroed out (avoid), reduced (mitigate), moved to someone else (transfer), or deliberately kept (accept).
• “Who accepts the residual risk” is answered by management with the authority to bear it, never by the analyst, never by the tool.
• A risk acceptance without a signature, an owner, or a review date is not an acceptance; it is neglect.
• When the scenario gives you AV, EF, and ARO, do the arithmetic: SLE equals AV times EF, ALE equals SLE times ARO, and the control is worth it when its annual cost is below the ALE reduction.
• When a scenario hands you a system, the categorization question is FIPS 199: high-water mark across confidentiality, integrity, and availability.
• When a scenario describes design-time analysis of a new system, the answer is threat modeling; when it describes measuring a live system against appetite, the answer is risk assessment.
• When a scenario lists threat categories, STRIDE is the enumeration and DREAD is the ranking; they are complementary, not interchangeable.
• When a scenario asks why controls exist, the answer is residual risk management: controls exist to bring risk inside tolerance, and the leftover risk is accepted deliberately.

Practice questions

1. An application server cluster is valued at $800,000. A ransomware event would cost about 30 percent of that value in restoration and downtime. Records show ransomware events hitting similar clusters three times in the last ten years. What is the annualized loss expectancy?

   A. $21,600 B. $72,000 C. $240,000 D. $800,000

2. An application database has an asset value of $600,000 and an exposure factor of 60 percent under current controls, with an annual rate of occurrence of 0.5. A proposed control would cut the exposure factor to 20 percent at a fully loaded cost of $40,000 per year. Based purely on annualized cost and benefit, what should the organization do?

   A. Reject the control: it costs $40,000 per year and reduces no risk. B. Accept the control: it reduces the ALE by $120,000 per year, a net benefit of $80,000. C. Accept the control: it reduces the ALE by $60,000 per year, a net benefit of $20,000. D. Reject the control: the exposure that remains after the control is still $120,000.

3. An organization purchases a cyber liability policy that will indemnify covered breach costs above a deductible. Which risk response does this represent?

   A. Avoidance B. Mitigation C. Transfer D. Acceptance

4. Which statement best describes qualitative risk analysis?

   A. It expresses risk in monetary terms so controls can be justified by return on investment. B. It uses relative ratings such as high, medium, and low, typically from expert judgment, and is faster but more subjective than quantitative analysis. C. It is always more precise than quantitative analysis because it ignores probability. D. It is required by ISO/IEC 27001:2022 for every risk treatment decision.

5. After controls are implemented and risks are transferred where possible, the risk that remains must be formally acknowledged and accepted. Who makes that acceptance?

   A. The analyst who identified the risk. B. The CISO, who owns the security program. C. Management at the level with authority to bear the consequences. D. The external auditor, who verifies the register.

6. A system is categorized under FIPS 199 with confidentiality rated high, integrity moderate, and availability moderate. What is the system’s overall impact level?

   A. Low B. Moderate C. High D. Cannot be determined without the annualized loss expectancy.

7. In the NIST SP 800-37 Revision 2 Risk Management Framework, which step immediately follows the selection of controls?

   A. Categorize B. Implement C. Assess D. Authorize

8. During threat modeling, a team draws a data flow diagram and marks the boundary between the external browser-facing tier and the internal database tier. What have they defined?

   A. A trust boundary B. An attack tree C. A control baseline D. A residual risk

9. An attacker exploits a flaw to modify rows in a shared database, and the application logs nothing, so the modification cannot be attributed to any party. Which two STRIDE categories best describe this threat?

   A. Spoofing and denial of service B. Tampering and repudiation C. Elevation of privilege and information disclosure D. Information disclosure and tampering

10. A team uses DREAD scores to rank the threats enumerated during threat modeling. What is DREAD used for?

A. Enumerating threat categories for each element of a data flow diagram. B. Rating and prioritizing threats by damage potential, reproducibility, exploitability, affected users, and discoverability. C. Mapping threat actors to the attack techniques they use. D. Calculating the annualized loss expectancy.

11. Which statement best describes the purpose of a risk register?

A. It is a one-time deliverable produced when a system receives its authorization to operate. B. It is the living record of identified risks with their owners, responses, status, and review dates. C. It is the list of controls in the SP 800-53 baseline for the system’s impact level. D. It is the annual report to the board summarizing insurance coverage.

12. Under ISO 31000:2018, which statement best describes risk tolerance?

A. The amount and type of risk an organization is willing to pursue or retain. B. The acceptable deviation from an organization’s risk appetite. C. The point at which a single loss event requires a new control. D. The maximum annualized loss expectancy the organization can sustain.

Answers and rationales

1. B. SLE = AV × EF = $800,000 × 0.30 = $240,000. ARO = 3 events in 10 years = 0.3. ALE = SLE × ARO = $240,000 × 0.3 = $72,000 per year. Option C is the SLE, not the ALE, and option A is the result of dividing the SLE by the wrong factor; the annualized figure is $72,000.

2. B. Current SLE = $600,000 × 0.60 = $360,000, and current ALE = $360,000 × 0.5 = $180,000. With the control, SLE = $600,000 × 0.20 = $120,000, and ALE = $120,000 × 0.5 = $60,000. The ALE reduction is $120,000 per year, and the control costs $40,000 per year, a net benefit of $80,000, so the arithmetic says implement it. The benefit is the reduction in ALE, not the remaining exposure.

3. C. Insurance indemnifies the organization for covered losses, which shifts the financial consequence of the risk to the insurer. That is the defining signature of transfer. Avoidance would eliminate the activity, mitigation would reduce likelihood or impact, and acceptance would retain the risk without shifting it.

4. B. Qualitative analysis works in relative ratings, typically assigned by expert judgment, and trades precision for speed. It does not express risk in monetary terms, it is not more precise for ignoring probability, and ISO/IEC 27001:2022 requires a risk assessment process but does not mandate the qualitative register for treatment decisions.

5. C. Residual risk is accepted by management at the level with authority to bear the consequences, the risk owner in the register. The analyst reports, the CISO advises, and the auditor verifies; none of them owns the business exposure, and an acceptance made without authority is not an acceptance.

6. C. FIPS 199 assesses confidentiality, integrity, and availability at low, moderate, or high impact, and the system’s overall level is the high-water mark, the highest of the three ratings. With one objective rated high, the system is a high-impact system regardless of the other two ratings.

7. B. The SP 800-37 Revision 2 sequence is Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. Selection hands off to implementation of the selected controls, after which assessment evaluates how well they were implemented.

8. A. The boundary between elements that hold different levels of trust is a trust boundary, and marking it is a core act of the modeling step in threat modeling. Every trust boundary is where spoofing, tampering, and disclosure become possible, and STRIDE is applied per element with boundaries in view.

9. B. Modifying data without authorization is tampering, and the absence of attribution means no party can be proved to have done it, which is repudiation. Spoofing, denial of service, elevation of privilege, and information disclosure are not the direct description of modifying rows with no attribution trail.

10. B. DREAD rates each threat on damage potential, reproducibility, exploitability, affected users, and discoverability, and the score ranks threats for mitigation priority. STRIDE does the enumeration; DREAD does the ranking; ATT&CK maps actors to techniques; and ALE is a quantitative risk calculation, unrelated to DREAD.

11. B. The risk register is the living record that tracks each risk from identification through treatment, carrying the owner, response, status, and review dates. It is not produced once at authorization, it is not a control baseline, and it is not an insurance summary; it is the working document the whole risk process maintains.

12. B. ISO 31000:2018 defines risk tolerance as the acceptable deviation from risk appetite, which is itself the amount and type of risk an organization is willing to pursue or retain. Option A is the definition of appetite, not tolerance; the distinction between the two is a recurring exam discriminator.

Risk management on one page

When the detail blurs, hold the shape. Risk is the effect of uncertainty on objectives, and in exam terms it is the meeting of likelihood and impact. Threats exploit vulnerabilities in exposed assets, and controls exist to change the math. There are two registers: qualitative, which rates and ranks fast, and quantitative, which prices in money, SLE = AV × EF, ALE = SLE × ARO, and a control is worth buying when its annual cost is less than the ALE it removes. Evaluation compares the analyzed risk against appetite and tolerance, separates inherent risk from residual risk, and assigns every risk an owner in the register.

Four responses cover every decision: avoid to zero it out, mitigate to shrink it, transfer to move it, accept to keep it deliberately, and the residual risk that remains after treatment is accepted only by the management that can bear it. The Risk Management Framework is the seven-step procedure that makes it all happen in order: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor, with FIPS 199 categorization at the front, SP 800-53 baselines in the middle, and the ATO decision as the payoff. Threat modeling finds the threats first, at design time, with data flow diagrams and trust boundaries as the map, STRIDE as the enumeration, DREAD as the ranking, and attack trees, the kill chain, and ATT&CK as the deeper vocabularies.

Chapter 5 takes the same machinery and points it at continuity: the business impact analysis that values recovery, the RTO and RPO that set the targets, and the recovery strategies that the risk responses in this chapter authorize. Before you go, hold the one rule that organizes everything: the security professional’s job is to make the risk visible and the decision accountable, never to make the decision alone. That rule, not any formula, is what the exam is really scoring.