Assets, Security Objectives, and Impact

By the end of this lesson, you will be able to...

• Distinguish an asset from the security objective that makes it worth protecting.

• Write a concrete impact statement instead of a generic label such as “high risk.”

• Build a small asset-and-objective table that another team member can challenge and extend.

Idea in one sentence: An asset list becomes useful for threat modeling only when each valuable thing is connected to the property that must hold and to a believable consequence if it does not.

Core Insight

In the previous lesson, the ShareBox team agreed on a narrow system promise: an employee can share a document with an external partner for a limited time and can revoke that access.

Now a sales director uses it to send a renewal proposal to Northwind. The document contains the proposed price, discount limits, account contacts, and an internal note: “Northwind may leave if we cannot close this quarter.” The team writes one line in its security document:

Asset: the renewal proposal. Risk: high.

That line feels responsible. It tells nobody what must remain true, what could fail, or why the failure matters. A developer cannot derive a useful requirement from it. A product owner cannot decide whether a delivery delay is tolerable. A reviewer cannot tell whether the team protected the document, the recipients, or something else entirely.

Threat modeling is about protecting something of value in a particular context. Before looking for threats, make the value and the intended protection explicit.

The Reasonable but Incomplete Inventory

The first model is easy to understand:

An asset is the important file or database record.

It is a good start. The proposal PDF clearly matters. But the model breaks as soon as the team asks why an incident happened.

Imagine that the PDF remains encrypted in storage and is never altered. A copied sharing link is nevertheless forwarded to a competitor, who downloads the original proposal. The file was not destroyed or changed. The product promise still failed.

What else had value?

• The link itself carried the ability to retrieve the proposal.
• The intended recipient’s address connected a person to a business negotiation.
• The access and revocation records determined whether ShareBox could say who had access and whether revocation took effect.
• The fact that a proposal existed, and who shared it with whom, could be sensitive even without the document body.

An asset is therefore anything whose loss, disclosure, alteration, unavailability, or inappropriate use would matter to the people or organization in scope. It can be data, a capability, an identity attribute, a decision record, a service, or a business relationship. “Important” is not a file type.

Do not turn this into an inventory of everything the company owns. The relevant assets are the things that support the specific system promise you chose in lesson 001.

Add the Property That Must Hold

An asset name answers what has value. A security objective answers what must be true about it.

For early threat modeling, the following objectives are useful prompts:

These categories are not a scorecard and are not mutually exclusive. The same asset can need confidentiality and integrity. A recipient address can have both confidentiality and privacy objectives, but for different reasons: secrecy from unauthorized viewers versus appropriate collection and use.

The objective must be specific enough to be challenged. “Keep the proposal secure” hides the property. “Only the intended partner may read this proposal until its expiry or revocation” states a claim that later lessons can test against flows, boundaries, and threats.

A Worked Asset-and-Objective Table

ShareBox’s team creates the following teaching artifact. It is deliberately small; it describes the document-sharing feature, not the whole company.

Notice the discipline in the second and third columns. “The link” is not merely a string. Within this system, it has value because holding it may enable a download. “The service” is not automatically a top-priority asset; its availability matters in relation to the meeting and the promise to the partner.

The table has not selected controls. It has also not declared that every row has the same priority. It establishes the claims that future threat discovery must try to break.

Turn “High Risk” Into an Impact Narrative

An impact statement connects a failed objective to a consequence someone can understand and assess. It is not a probability estimate, a severity number, or a threat description.

Compare these entries:

The stronger statements do three things:

1. They name the failed property: disclosure, failed revocation, or unavailable service.
2. They state who experiences the consequence: the customer, account team, partner, or organization.
3. They retain context that can guide a later priority decision: timing, contractual meaning, business effect, or privacy harm.

An impact narrative can remain uncertain. “May lose negotiating leverage” is more honest than inventing a euro amount without evidence. Lesson 011 will handle prioritization; here the goal is to make the potential harm intelligible before anyone ranks it.

The Compact Model to Carry Forward

For each valuable thing in your scoped system, record this chain:

asset or value  →  security objective  →  failure consequence

For example:

revocation record
    → integrity: it correctly represents whether access is still valid
    → a revoked recipient can keep reading a commercially sensitive proposal

This is not yet a threat model in full. It does not identify how the record could be changed, who might try, or which control would stop them. It gives those later questions a target. In the next lesson, you will trace the data flows and trust boundaries through which the objective might be violated.

A Boundary and a Trade-off

Teams sometimes respond to this exercise by listing every possible objective for every row. That produces a large spreadsheet but little judgment.

Instead, start with the promise and the credible consequence. If ShareBox is an internal sandbox for non-sensitive demonstrations, a brief interruption may have little impact. If it is the agreed channel for a timed commercial negotiation, availability has a clearer business objective. The context changes the claim; the category label alone does not.

There are also real tensions. A detailed sharing-history record supports investigation and revocation confidence, but it also contains personal and commercially sensitive relationship data. Keeping it forever may make one future question easier while expanding the privacy exposure. This lesson does not prescribe retention policy or logging controls. It makes the trade-off visible so the later design can be intentional.

Common Confusions

• “An asset is only data.” A capability such as a sharing link, a service, an identity attribute, and a decision record can all matter because of what their failure enables or prevents.
• “Integrity means no one may ever change it.” Legitimate changes can be necessary. The objective is that changes are authorized and leave the information correct for its purpose.
• “Privacy is just another word for secrecy.” Confidentiality asks who can learn information. Privacy also asks whether collection, use, retention, and sharing fit the stated purpose.
• “Impact is a number.” A number can later summarize a decision, but it cannot replace the explanation of what happens, to whom, and under what conditions.
• “An asset inventory is the threat model.” It is only the value-and-objective part of the model. Flows, boundaries, actors, threats, controls, and evidence still follow.

Check Your Understanding

1. A customer portal stores a delivery address. Which description is stronger?

   • “Address: confidential.”
   • “The address is used only to complete the delivery and is not disclosed to unauthorized viewers or reused for unrelated marketing.”

   The second one is stronger: it states both confidentiality and purpose-limited use.

2. An employee is allowed to correct a proposal’s meeting date. Does that violate integrity?

   No. Integrity is not immutability. The concern is whether the change is authorized, accurate, and represented correctly to the recipient.

3. A team labels a document “critical” but cannot explain the result of an outage. What is missing?

   An impact narrative. Ask which promise fails, who is affected, and what consequence makes the loss of availability matter.

Practice: Make the Value Argument

A clinic adds a portal where a patient can download a test result before a follow-up appointment. Create a four-row table for this feature. Include at least the result itself, an access capability, one item of patient-related metadata, and the portal service.

For each row, write:

1. why it has value in this narrow feature;
2. one or two security objectives; and
3. a one-sentence consequence if an objective fails.

Then review the table with this rubric:

• Can a reader tell the difference between the asset and its required property?
• Does each consequence name a person, organization, or real-world process affected?
• Have you avoided choosing controls or guessing attack techniques too early?
• Does the table stay within the portal feature rather than becoming a company-wide inventory?

If a row says only “sensitive,” “high risk,” or “must be secure,” rewrite it until another person could ask a precise follow-up question.

Connections

• The system scope in Lesson 001 tells you which assets belong in this analysis and why.
• Lesson 003 will show how the values and objectives travel through data flows, entry points, and trust boundaries.
• application-security-and-secure-design later turns selected objectives into implementation-level design and secure-coding decisions; this track deliberately stays at the threat-modeling level.

Resources

• [PROJECT] OWASP Threat Modeling Project
  • Focus: Use its four-question frame to keep assets, assumptions, threats, actions, and review in the right order.
• [GUIDE] OWASP Threat Modeling Cheat Sheet
  • Focus: Consult its system-modeling guidance when extending the small table into a shared threat-model representation.
• [LEARNING PATH] Microsoft Threat Modeling Security Fundamentals
  • Focus: Use it for a guided follow-up on modeling system elements and security concerns.

Key Takeaways

• An asset is anything whose inappropriate disclosure, alteration, unavailability, or use would matter within the chosen system scope.
• A security objective names the property that must hold; an impact narrative explains the consequence if it does not.
• Write asset → objective → consequence before you search for threats or choose controls.
• Specific, challengeable claims make the next analysis possible; generic labels such as “high risk” do not.