Your posture schema is mostly signals a compromised endpoint could compose, and the client's risk owner will not sign. What do you present, and what do you fund?
answer
- classify, do not defend
- three columns: attested, inferred, claimed
- the third column is what survives compromise
- arrive with costed options, not a problem
- the data owner signs the residual, not you
basics
~20 sPresent a signal-by-signal provenance table — attested, inferred, claimed — and state plainly what each survives under a compromised endpoint. Then offer costed choices: fund attesting hardware, shrink what the claimed tier reaches, or keep data off the device.
solid answer
~50 sDo not argue the schema is fine; classify it. For every signal, say what is hardware-rooted, what is implied by design, and what is the device's own word, and say what each would still look like if an intruder held the endpoint. That table is the artefact, and it is usually uncomfortable — most posture schemas are mostly claims. Then convert that into priced decisions: issue managed, attesting laptops for staff touching this client's data; narrow what the claimed-signal tier reaches; or move to rendered access so data never lands on an endpoint you cannot vouch for. Each has an owner and a number — capital, run cost, billable hours lost. Your job is to refuse to launder a claimed signal into the word "verified" and to make sure the residual is accepted knowingly, in writing, by the person entitled to accept it.
go deeper
Know that a posture signal has a provenance — hardware-rooted, implied by design, or self-reported — and that the word verified belongs only to the first two.
Be able to build the table for a real schema and explain, per row, what the signal would look like if an intruder held the endpoint.
Turn the table into design consequences: which tier each provenance class is allowed to authorise, and what the narrowing costs the people doing the work.
Own the meeting. Bring costed options with named owners, refuse to relabel claims as verified, decide whether one client's standard becomes the firm's, and make sure the data owner signs the residual.
## Why this lands on a lead The technical answer — which signals are attestable — is settled and a senior engineer can produce it. What makes this a lead's problem is that the answer is *bad news to somebody who can refuse*, and the resolution costs money that is not in the security budget. A consultancy working inside a client tenancy is the sharpest version: the client's risk owner does not have to trust the firm, and can simply decline. ## The artefact: a provenance table, not a dashboard What you present is one table, per signal, in three columns of meaning. | Signal | Provenance | Under a compromised endpoint | | --- | --- | --- | | Device identity | attested — hardware-held key, unexportable | still true; identity is not health | | Boot chain state | attested — measured at boot, freshly signed | true of boot only; post-boot implant invisible | | Volume unlocked | inferred — key sealed to boot measurements | strong, because the machine would not run otherwise | | Patch level | claimed — agent reads and reports | any value the attacker prefers | | Security agent running | claimed — agent reports on itself | any value the attacker prefers | | Screen-lock policy | claimed | any value the attacker prefers | The row that changes the meeting is the third column. A compliance summary saying "98% of devices meet policy" answers a different question and, presented here, reads as evasion. The provenance table answers the one actually asked: *which of these facts survives the scenario your control exists for?* And for the client-owned laptops the firm cannot enrol, the table has no attested rows at all. Say that first, not last. ## Then give the risk owner priced choices A lead does not arrive with a problem. Three options, each with an owner and a number: **1. Fund attesting hardware for the cohort that touches this data.** Capital cost, a refresh cycle, and lead time before an engagement can start. Buys real attested rows for the boot-state and identity signals — and buys nothing for patch level or agent state, which stay claims on every device forever. Say that too, or you have oversold it. **2. Shrink what the claimed tier may reach.** Free in capital, expensive in billable productivity, and the cost falls on the consultants and on the engagement's delivery schedule. This is the option security teams like and delivery leads resist, so it needs the practice owner in the room, not just the risk owner. **3. Keep the data off the endpoint.** Rendered or streamed access means an untrusted device never holds anything worth stealing, which makes most of the posture schema irrelevant by construction. Costs run spend, latency, and a workflow change people dislike for months. Most real answers are a split by sensitivity: the client's regulated data goes to option 1 or 3, ordinary firm systems live with option 2, and that split is itself the thing the risk owner is being asked to approve. ## What you must not do - **Do not relabel a claimed signal as verified** because it is signed in transit or emitted by a well-regarded agent. Once "verified" appears next to a claim in a sign-off document, the risk owner has approved something that does not exist, and you authored it. - **Do not present a control-coverage percentage as provenance.** Coverage answers how many devices report; provenance answers whether the report means anything. - **Do not let the loudest client set the standard for the whole firm.** If one engagement funds attesting hardware, decide deliberately whether the other eleven inherit the same standard or accept the same residual; drifting into per-client security postures is how a firm ends up with twelve of them and can describe none. - **Do not accept the residual yourself.** You describe it; the person accountable for the data accepts it. That separation is what makes the sign-off worth anything, and it is what protects you when something later goes wrong. ## Producing evidence to someone who does not trust you The deeper skill here is that the firm is being audited by a party with no reason to take its word. The credible move is the same one you are asking of the endpoint: **show what is rooted in something the other side can check, and label the rest as your word.** A firm that volunteers "these six signals are our own assertion and here is what we do about it" is more trusted than one that presents a green dashboard, because the first has demonstrated it knows the difference. That is the answer's real payload, and it is why this is a lead's question rather than an engineer's.
- The client wants a statement that all devices accessing their data are encrypted. What do you write?Two sentences, split by provenance. For the managed fleet: volume keys are sealed to boot measurements, so the device does not operate unless the boot chain is intact — evidence you can demonstrate. For client-owned devices: encryption is self-reported and unverified. Refuse the unqualified sentence they asked for; offer the qualified one plus what you would need to make it stronger, and let them decide whether to fund it.
- You fund attesting hardware for this engagement. What about the other eleven clients?Decide by data sensitivity, not by which client asked. Either the standard becomes the firm's for that class of data — with the funding to match — or the other engagements carry the same residual and someone accepts it explicitly. What you must avoid is twelve per-client postures nobody can describe, because the next client's question will be what everyone else gets.
- How do you stop the provenance table rotting as the schema grows?Make classification a condition of use: a new posture signal is labelled attested, inferred or claimed before any policy is allowed to depend on it, and the label travels with it. It is a small discipline that prevents the slow drift where a convenient new field acquires unearned authority because nobody asked where it came from.
saying these in an interview costs you the question
- Presents a compliance coverage percentage as evidence of provenance
- Calls a self-reported signal verified because it is signed in transit
- Asks for sign-off without naming what cannot be proven
- Accepts the residual risk personally instead of the data owner
- Buys attesting hardware for everyone before scoping which data needs it