Assets as Security Properties Rather Than Components

An inventory that lists “the API server, the database, the object store, the load balancer” is a list of equipment. It cannot answer the question a threat model actually asks, which is what an adversary gains by reaching a given point. Two systems with identical equipment lists can have completely different exposure, because exposure is a property of what the components hold and what happens when each holding is wrong, not of how many boxes appear in the diagram.

The unit of an asset is a property of a thing, not the thing

An asset is a resource whose loss, alteration, or unavailability causes harm to someone with a stake in the system. That definition forces decomposition: a single database holds several assets that fail independently and matter to different parties. A table of session tokens is a confidentiality asset (disclosure enables impersonation) and an availability asset (loss of the table logs everyone out). An audit log is an integrity asset first and a confidentiality asset second, since a forged log destroys its evidentiary value while a leaked one may be less damaging than a missing one. A signing key is a confidentiality asset, and its loss is not recoverable by restoring a backup, which distinguishes it from the session table.

FIPS 199 formalizes this by categorizing information types and information systems separately against confidentiality, integrity, and availability, each at one of three levels, and then taking the high-water mark across the three for the system. The structural insight is worth more than the three-level scale: the same system carries multiple assets, each of which may rate differently on each property, and the system rating is a maximum rather than an average. An average would let a large volume of low-sensitivity data dilute one high-sensitivity record, which is exactly backwards, since a single record can be the whole loss.

Decomposing a system into property-assets

The practical procedure is to walk the data flow diagram and its trust boundaries and, for each data store and each flow that carries a distinct kind of data, ask three questions separately: what happens if an unauthorized party reads this, what happens if an unauthorized party writes it, and what happens if it is unavailable for an hour, a day, and a week. Each answer that names a harm is an asset.

Reading and writing are separate assets because they are attacked by different means and defended by different controls. Read protection is about confidentiality of storage and transport, authorization on queries, and the absence of copies. Write protection is about authentication of the writer, validation of what is written, and detection of the write after the fact. A system with excellent read controls and no write controls is a system where an adversary who obtains a token can corrupt data without being able to exfiltrate it, and the reverse configuration is just as reachable: an append-only log with weak read authorization leaks everything it records.

The three questions also expose assets that no component owns. A derived aggregate, such as a daily count, a recommendation model, or a search index, can leak the data it was computed from even when the source is protected, because aggregation removes the per-record authorization checks that the source enforced. A cache is a second copy of an asset with a different lifetime and often a different access policy. A backup is a third copy, usually with weaker access controls than the primary because it is written by an automated job and read rarely. Each copy is a distinct confidentiality asset whose compromise does not require touching the original, which is why “the data is encrypted at rest” answers a narrower question than it appears to.

Impact is a statement about a party, not a severity label

Naming an asset without naming who is harmed makes the next step impossible, because the acceptable cost of protection depends on whose loss it is. A threat model that records “customer payment data: high” has compressed three facts into one adjective: the data belongs to customers, the harm is theirs, and the organization’s obligation is partly contractual and partly regulatory. That compression is why mitigation arguments stall. Spending is justified against the party bearing the harm, and the party bearing the harm is usually not the party paying.

A workable asset record has four fields: the property at risk, the data or capability at stake, the party harmed, and the time horizon over which the harm materializes. The horizon matters more than it is usually credited. Disclosure of a credential is harmful from the moment of disclosure; disclosure of a mailing list is harmful when it is used, which may be years later; unavailability of a payment endpoint is harmful within minutes, while unavailability of an internal report generator is harmful within a quarter. Different horizons imply different detection requirements, since a control that notices a breach in thirty days is adequate for the slow case and useless for the fast one.

What counts as an asset beyond data

Restricting the inventory to stored data misses assets that adversaries actually pursue. Three categories recur.

Capability assets are the authority a component holds rather than the data it stores: the ability to send mail as the organization, to spend money through a payment processor, to sign code, to reset another user’s password. These are the real targets in most account-takeover scenarios, since the attacker wants the capability and not the credential that carries it. They are also the assets most often omitted, because they are represented in the diagram as arrows rather than boxes.

Availability assets are the system’s ability to serve at a stated rate, which is not the same as its ability to serve at all. A service that degrades to a tenth of its capacity under load has lost an availability asset even though every component is up. Modeling this requires a stated commitment in requests per second and latency percentile, because “availability” without a number cannot be threatened or defended in any concrete way.

Reputation and trust assets are the standing the organization holds with parties who can withdraw cooperation: customers, regulators, upstream providers whose terms of service constrain use. These are hard to quantify and easy to dismiss, and they are frequently the largest actual loss in an incident that leaks little data but becomes public. A model that ignores them produces risk rankings that no decision-maker will accept, which is a modeling failure even when the technical analysis is correct.

Ranking without inventing numbers

Once assets are enumerated, they need an order, and the temptation is to assign currency values. For data with a market price, such as a card number or a credential, that is defensible. For most assets it is not, and a fabricated figure propagates into every downstream calculation.

Two ordinal techniques avoid the fabrication. The first is comparison within a class: rank assets against each other on a single axis at a time, which is a reliable human judgment even when absolute values are not. The second is a threshold framing: for each asset, state the level of harm at which the organization would have to disclose the event publicly, notify a regulator, or halt a service. Thresholds are observable and defensible, and they convert a vague severity into a decision boundary that mitigation can be measured against.

A third technique, used where a numeric answer is genuinely required, is to derive the number from a contract rather than an estimate: the penalty stated in a service agreement, the notification cost per record set by a regulation, the revenue attributable to an hour of downtime taken from a published rate card. These are defensible because they are documented obligations rather than guesses about adversary behavior, and they bound the analysis without pretending to precision. The distinction to preserve is that such figures price the consequence of an event, not the likelihood of one; multiplying the two produces a number whose second factor is invented.

The output of this stage is a list where every entry names a property, a party, and a horizon, and where the ordering comes from stated thresholds rather than adjectives. That list is what the adversary analysis is applied to. An adversary is interesting only relative to something worth taking, so the next step, establishing what different classes of attacker can actually reach, is meaningless until the assets have been separated from the equipment that holds them.