Subject chapter quiz

Modern identity is plural. Behind any named user are typically several non-human identities (service accounts, cloud roles, federated SSO) that share trust paths. The Subject phase profiles all of them, not just the one the alert named.

'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.

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. Break-glass procedures and an admin troubleshooting with the service credential produce the same event, so the next check is who initiated the session and whether a sanctioned reason (a change ticket, a break-glass record) exists.

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.

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 NIST's insider-threat definition includes unwitting actors, so check 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.

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.

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.

Insider risk is the right label: the workaround was about getting work done past a slow tool, not about 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. 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.)

A signature match alone is not Subject's verdict. The four dimensions plus access scope plus operational risk produce the picture. A signed, vendor-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 signature alone.

The map carries three rings: primary entities directly named or implicated, secondary entities connected through trust paths (service accounts, federated identities, peers on the same host), and downstream entities the implicated identities can reach, each with its authentication, authorization, behavior, and relationships assessment. Confidence labels ride alongside in the baselines-and-deviations artifact, using the shared rubric. And ruled-out entities stay on the map, because examined-and-cleared is a finding: dropping them invites the next phase to spend depth re-answering a question Subject already closed.