Insider Threat
Simulation
One real account with legitimate access, run as a specific insider persona. What can it reach, and how much of it do you see?
No perimeter to cross, no exploit to write, nothing that looks like an attack. That is the point. These are the controls that have to work when every individual action is authorized.
What you are buying
We are issued a genuine account and act as an insider who has decided to misuse it. Credentials are given, not taken. Every action would be permitted by your access controls if the real owner performed it.
So the controls under test are different: data loss prevention, user behaviour analytics, privileged access monitoring, log coverage, and whether anyone reads what those systems produce. A perimeter that holds perfectly is irrelevant here.
It also carries the most legal weight of any engagement here. Employment law, privacy regulation and internal policy all apply, so it cannot start without legal and HR in the room before the scenario is picked.
What gets tested
- → Whether exfiltration through sanctioned channels is seen
- → Whether privilege use outside the norm raises anything
- → Whether access is actually scoped to role
- → Whether audit logs would support an investigation
- → Whether anyone reviews what the tools produce
Safety boundaries
- → No real employee is investigated or impersonated
- → Data movement is demonstrated on seeded records
- → The account is decommissioned and evidenced at close
Pick one insider, not five
One persona per engagement. Each exercises a different detection mechanism, and running two at once makes a miss impossible to attribute.
01 · Persona
Departing employee
Normal access, notice period. Collecting source code, customer records and documents at a volume that could plausibly be explained as wrapping up work.
Detection tested
- Repository cloning and bulk export detection
- Mass document and record download thresholds
- Access pattern deviation from the account baseline
- Egress via sanctioned channels: cloud storage, mail, sync clients
02 · Persona
Compromised privileged account
An admin, developer or database account in an attacker's hands. Every action is legitimate for the role. The question is whether the pattern, timing and origin get noticed.
Detection tested
- Privileged session recording and review
- Off-hours and unfamiliar-origin access alerting
- Bulk read and export from production data stores
- Configuration and permission changes made by the account
03 · Persona
Third-party contractor
A scoped external account reaching past its authorization: systems outside the contract, data beyond need-to-know, and access arranged to outlive the engagement.
Detection tested
- Enforcement of the contracted access boundary
- Detection of access outside the agreed system list
- Tooling and integration installation attempts
- Persistence via API keys, OAuth grants, or service accounts
04 · Persona
Slow-and-low collection
A patient insider gathering one specific set of information over weeks. Unremarkable actions spread thin enough that volume rules never trigger. This persona beats threshold detection most reliably.
Detection tested
- Detection that depends on aggregation rather than volume
- Targeted access to strategic, financial, or M&A material
- Cumulative access review across the engagement window
- Whether correlation exists across separate log sources
05 · Persona
Unsanctioned tooling
A well-meaning account moving work into services you never approved: personal cloud storage, personal mail, unreviewed integrations, third-party AI tools handling data that should not leave.
Detection tested
- Discovery of unapproved applications and OAuth grants
- Detection of file sharing outside sanctioned channels
- Data classification enforcement at the egress point
- Policy violation surfacing before it becomes an incident
How it runs
Leadership, legal and HR know. Your security operations team does not, because otherwise the detection result means nothing.
01
Get it authorized
This engagement runs against accounts and behaviour, which makes employment law, privacy regulation and internal policy load-bearing. Legal and HR are involved before a scenario is chosen. We supply draft authorization language for your counsel to adapt.
Output: Signed authorization covering scenario, boundaries, data handling, and the named individuals read in.
02
Pick the persona, issue the account
The persona matches what actually worries you, with a concrete objective: move a seeded record set outside the boundary, reach a system outside its remit, or keep access that survives offboarding. You then issue a real account through your normal process, holding exactly what the persona would hold.
Output: Scenario definition, provisioned account, verified access level, and the seeded dataset standing in for real data.
03
Look around from inside
What is reachable, where sensitive material sits, which controls are visible from the inside. Agents enumerate that reach far faster than a person can click through it, which is what makes a complete map affordable inside the window. This phase alone routinely surfaces over-provisioning nobody had audited.
Output: Internal reachability map from the persona's position.
04
Run it slowly
Days and weeks rather than hours, because detection tuned to catch a rushed actor will miss a patient one. Every action is timestamped as it is taken, so the record can be laid against your logs afterwards.
Output: Action log with timestamps, systems touched, and data reached.
05
Watch what fires
DLP, user behaviour analytics, SIEM correlation, privileged access monitoring. Where your team responds, we record what they did and how long it took. If we are caught, the engagement becomes a response test: was containment fast, correct, and did it actually remove the access. Where nothing happens, that is the finding.
Output: Detection timeline aligned against the action log, or a response evaluation.
06
Reconstruct, report, retest
We walk your logs against our action log with your team, step by step. Every unseen action is classified: the telemetry did not exist, it existed but nothing watched it, or something watched it and the rule did not match. Once rules change, the missed actions are run again.
Output: Per-action gap classification, detection recommendations, debrief, account decommissioning evidence, and a retest report.
Your logs against ours, line by line
That comparison is the central artefact. Everything else in the report hangs off it.
Executive summary
- The persona run and the objective set
- What the account reached, and what left the boundary
- How much of it was seen, and how long that took
- The access changes and detection changes that matter most
Action and detection log
- Every action taken, timestamped, with the system touched
- Your detection record aligned against it
- Per-action classification: telemetry absent, unmonitored, rule miss
- Evidence for each action reaching its objective
Access findings
- Over-provisioning discovered from the persona's position
- Systems reachable that the role should not reach
- Persistence mechanisms available to the account
- Whether offboarding would have removed the access
Detection recommendations
- Specific rules to add, tied to log sources you already have
- Where telemetry must be created before a rule is possible
- Aggregation-based detections for low-volume collection
- Review process gaps, where tooling fired and nobody looked
What we need to quote
Legal and HR involvement is the item that most often sets the timeline. Raise it early.
- →The persona that worries you, and why. A real concern beats a hypothetical one.
- →Whether legal and HR have been consulted, and who owns sign-off.
- →What detection you have: DLP, UBA/UEBA, SIEM, PAM, and who reviews their output.
- →Which systems hold the material that would actually hurt to lose.
- →Whether a seeded dataset can be created, and who can create it.
- →Named individuals to be read in, and confirmation that the SOC is not among them.
- →Duration you can support. Slow-and-low personas need weeks to be meaningful.
When to buy something else
Insider threat simulation fits
- → Sensitive data sits behind normal employee access
- → You have privileged users: admins, DBAs, engineers
- → You run contractors or vendors with production access
- → You have DLP or UBA and want to know if it works
- → Legal and HR are willing to participate in the design
- → A specific insider scenario is a live concern
Start elsewhere if
- → You have no audit logging, so there is nothing to review
- → You have never tested the perimeter: Penetration Testing
- → Your concern is an intruder rather than an account holder: Red Team Engagements
- → Legal or HR are not prepared to be involved
- → You need an access review rather than a detection test
Common questions about insider threat simulations
Still have questions about insider threat simulations? Book a discovery call
How to start
Describe the insider scenario that concerns you and who inside your organization would need to approve testing it. We will tell you what the authorization path looks like before anything is scoped.
Direct: hello@principlebreach.com
Sequence
- Confidential discovery call
- Legal and HR authorization
- Persona and objective selection
- Account provisioning and seeded dataset
- Execution window
- Forensic reconstruction, report, debrief