Subject chapter quiz
Eleven questions across the Subject chapter. Push your thinking on identity, Case C's non-human subjects, baselining, network identifiers, the insider distinction and its guardrails, and the Scope handoff.
Subject chapter quiz
No grades. The point is to push your thinking.
In Case C, rvega's password has been reset and an admin has revoked all of her refresh tokens. Which entity still holds a standing path into her mailbox?
Need a nudge?
Which subject authenticates on something other than her password or her sessions?
The consented application is a separate identity with its own grant. A password reset does not reliably revoke what it holds. Revoking her refresh tokens cuts the tokens it already has (issued access tokens still run until they expire), but the consent grant itself stays until someone removes it, ready for the next token the app obtains. That is why Case C gives the app its own containment line. The replayed session was revoked and refused, and the laptop was examined and cleared: a witness, not a subject. The broader lesson is that identity is plural. Behind any named user sit sessions, application grants, service accounts and federated identities, and Subject profiles all of them, not just the one the alert named.
Review: Subject working example: Case C, the subject with no device
A user's action maps cleanly to their assigned role, so the authorization dimension looks fine at a glance. Why does it still reward a second look?
Need a nudge?
The mapping can be clean while the role is wrong.
'The action maps to the role' answers the shallow question. The deeper ones are whether the role is right for this person now, whether it changed recently, and whether individually reasonable permissions combine into an unsafe pairing. Those gaps sit exactly where the first glance says everything is fine.
A service account suddenly logs in interactively at 02:30. Which entity type pattern does this match?
Service accounts have predictable, non-interactive behavior by design, which makes an interactive login a high-confidence Subject signal: the credential is being used outside its designed lane. It is a signal, not proof. An emergency-access (break-glass) procedure or an admin troubleshooting with the service credential produces the same event, so the next check is who initiated the session and whether a sanctioned reason (a change ticket, an emergency-access record) exists.
An egress alert flags a workstation making sustained connections to an external host on port 443. What is the entity-type question to ask about this network identifier?
Need a nudge?
Attackers choose common ports on purpose.
Port 443 is the most common port on the internet, so rarity carries no signal at all. The signal is protocol/port mismatch: traffic on 443 that is not actually TLS, or DNS on an arbitrary high port, is the classic bypass pattern, because attackers pick common ports precisely to blend in. Reputation helps but does not clear anything; a clean destination means only that it has not been caught yet. And conformance cuts one way only: most command-and-control (C2) traffic rides genuine TLS on 443, so conformant traffic moves the question to destination age, certificate, JA4 TLS client fingerprint and connection periodicity.
In ASSURED's vocabulary, what separates insider risk from insider threat?
The distinction is about intent. Most insider risk is unintentional (mistakes, workarounds, policy violations). Insider threat is intentional, and the methodology reserves that designation for cases where evidence supports it. Two calibrations: the label is a revisable hypothesis, not a verdict (and the split is a practitioner convention: NIST and CISA define insider threat to include acts done wittingly or unwittingly, so map it to your organization's vocabulary), and the label shapes who gets engaged, never whether confirmed harmful activity gets a response. Containment and escalation trigger on act, asset, and impact; intent is resolved in parallel.
An engineer's activity is consistent with their own 90-day baseline but looks nothing like anyone else's in the same role. What is the best reading?
Need a nudge?
Two baselines, one entity, and they disagree. That fact is data.
Per-entity baselining is the framework's headline question, and here it passes. But the framework also runs the peer-group comparison, and when the two disagree, the disagreement is informative: it can mean a legitimately unusual job, or a baseline that was poisoned by long-running compromise before the window began. Neither baseline overrides the other; the gap between them is what deserves the look.
An insider bulk-exports a customer database, then clears their shell history and deletes the staged archive. Under the Insider Threat Matrix, where does the history-clearing evidence belong?
The matrix organizes insider tradecraft into sections: motive (why), means (what made it possible), preparation (setting it up), infringement (the harmful act, here the bulk export), and anti-forensics (concealing or destroying evidence afterward). History-clearing and deleting staged archives are textbook anti-forensics, and their presence upgrades the case: deliberate evidence destruction is among the strongest intent signals available. It still gets verified rather than assumed: scheduled cleanup jobs, retention scripts, and shell configurations that trim history all exist, so the analyst confirms the mechanism was manual before treating the cleanup as a confession.
A marketing team under deadline converted confidential documents into image files to get them past a slow secure file-sharing tool and shared them externally, exposing customer data. What does Subject classify this as?
Need a nudge?
The vocabulary matters. Risk and threat are not interchangeable.
Insider risk is the right label: the workaround was a deliberate act with no intent to harm, aimed at getting work done past a slow tool, not at stealing data. But the label only decides the long-term fix, not the immediate response. Customer data left the boundary through a deliberate control bypass, so the exposure is scoped and contained, the regulatory notification question is asked (a notification clock does not care about motive), and the DLP bypass is recorded as a confirmed policy violation. Holding the response until intent is known gets the order backward: the label can wait, the exposure cannot. What the risk classification changes is what happens after: process improvement, a faster approved sharing path, instead of an enforcement action that would add friction without fixing the cause. (The scenario is an illustrative composite, not a published incident.)
On a developer's macOS laptop, a signed IDE helper process runs with its sandbox disabled and makes encrypted outbound calls. A behavioral EDR rule maps the pattern to Empire-style post-exploitation tradecraft. What should Subject do before reaching a verdict?
A behavioral pattern match alone is not Subject's verdict. The four dimensions plus access scope plus operational risk produce the picture. A signed, MDM-installed, peer-baselined binary running in a documented configuration on a developer workstation reads very differently from the same activity from an unsigned binary in a user-writable directory. Subject's job is to record that distinction defensibly, not to react to the pattern match alone. Even a benign verdict carries caveats: the signature covers the editor, not the extensions, MCP servers and workspace tasks it runs, and developer workstations hide persistence in IDE extensions, dotfiles, and package-manager hooks, so the close records what was checked.
Review: Subject working example: Case B, the developer workstation
An HR referral asks whether a departing engineer's account moved data to personal storage. EDR and the CASB agree on what happened. Which line belongs in the case ticket?
Need a nudge?
Which line would read the same to an HR partner, a judge and the employee's lawyer?
Only observable technical activity, with a timestamp and a source, survives review. Option A wraps the same fact in an intent label nobody has established; that is speculation, and it becomes discoverable the moment it enters a ticket. Option B records personal circumstances the SOC should never hold: HR-held context reaches the case only through the insider-risk route, never as analyst-collected notes. Option C gets the order wrong: the referral's reference, owner and technical questions are all the SOC needs, and the reason for the referral stays with HR and the insider-program lead. The working example's HR referral scenario shows the full record.
Subject hands its entity map to Scope. Which entities belong on it?
Need a nudge?
Think about what Scope would have to redo if the map only listed the suspicious entities.
The map carries three rings (primary entities directly named or implicated, secondary entities connected through trust paths, and downstream entities the implicated identities can reach), each with its authentication, authorization, behavior, and relationships assessment, plus any originating threat infrastructure (sender, domain, IP) tracked alongside as threat entities, not internal identities. Confidence labels ride alongside, using the shared rubric. And ruled-out entities stay on the map, because examined-and-cleared is a finding (Case C's laptop is one): dropping them invites the next phase to spend depth re-answering a question Subject already closed.
Worth revisiting
Technical details verified . Product names, defaults and retention change; check your own tenant.