Human Risk in Cloud Security

Why this page is on a cloud security site

Because in cloud the gap between "an attacker persuaded someone" and "an attacker has your data" is unusually short. There is no network boundary doing quiet second-line work. A valid session token obtained by social engineering looks, to every control downstream, exactly like the legitimate user it was taken from: right identity, plausible device, normal working hours. The controls this site spends most of its time on assume a technical failure to detect. Here there is none.

The other reason is that our Friday sessions kept returning to it. Five of the twelve recaps in the summer of 2026 were substantially about the human layer, and the technical half of that material already lives on this site while the behavioural half had nowhere to go.

Role is a first draft, not a finding

At the 2026-08-28 session, Stryker, Director of Threat Analysis at Fable Security, presented a talk called "The Meeple Problem." A meeple is the single-colour wooden playing piece from board games like Carcassonne: one shape, one move, one thing it can ever do. That abstraction is right for a board game and wrong for a person, yet security programs routinely reduce an employee to one variable, usually job title or seniority, and then treat that first draft as final.

Her argument was not that role is useless. Role is a reasonable starting hypothesis when designing access controls, and assumptions built on experience are genuinely valuable. The problem is that the first draft almost always becomes the final one, and acting on an untested hypothesis is a different thing from acting on a measurement.

She gave two reasons the shortcut persists. The first is organisational logic: in principle access follows function and controls follow access, so a role-level generalisation looks defensible. "All developers handle production data, therefore all developers need the sensitive-data reminder" is coherent right up until you check, and find they do not all have that access. The second is regulatory framing. NIST, GDPR, NYDFS and the state regimes in New York, Texas and California all describe role-based controls and role-based training, which quietly installs role as the primary variable in any program written to satisfy them.

What the behaviour data shows

Drawing on the first volume of her AI Behavior Index at Fable Security, an older executive survey, and her own in-house phishing analysis, Stryker showed several places where role and seniority fail to predict what people do:

• Seniority showed no correlation at all with who clicked a phishing link. This is worth sitting with, because a great deal of program design assumes the opposite in both directions, either that executives are the risk or that they are the exception.
• Tenure did show a signal, pointing the unintuitive way. The newest hires failed phishing simulations most. That is actionable in a way an average is not.
• Role buckets varied so widely internally that the reported average concealed most of the signal. A department mean can be produced by a uniform population or by a small high-risk group inside an otherwise careful one, and the two need completely different responses.
• AI-enabled employees held their technical controls better and their volitional ones worse. They were more likely to have the configuration right and more likely to make a judgement call that bypassed it.

The group pushed back throughout on what the data could and could not support, which was largely the point of the talk: the failure mode being described is treating a first-pass grouping as a settled fact, and a room accepting one speaker's numbers uncritically would have reproduced it.

How the attacks actually arrive

Four shapes account for most of what our sessions discussed. They are not equally well defended by the usual controls.

Phishing, and why the old advice expired

Advice built around spotting bad grammar, generic greetings and odd formatting was training people to detect production quality rather than intent, and production quality is exactly what got cheap. At the 2026-07-10 session Daniel walked the group through the stages of an AI-assisted campaign: models scan for viable targets and tailor each message to its recipient, which makes a mass campaign behave like spear phishing. Autonomous follow-up replies are technically possible and were described as still emerging rather than routine. What survives is verification of the request itself, through a channel the message did not choose.

Business email compromise

BEC is the case where technical controls have least to work with. The message carries no link to detonate and no attachment to scan, and it often arrives from a genuinely compromised mailbox, inserted into a real conversation about a real invoice. At the 2026-07-31 session the group worked through a small law firm's exposure and agreed that technical controls alone cannot prevent these attacks and that strong processes and user training are essential. The controls that do work are procedural: verify payment-detail changes out of band, on a number you already had.

Rented infrastructure

At the 2026-06-19 session Thomas raised a phishing-as-a-service offering that automates Microsoft 365 account compromise for roughly $250 a month, including automatically scanning captured mailboxes for wire-transfer opportunities and sending contextual replies to victims. That is an end-to-end BEC pipeline rented by the month, and it collapses the skill required to run one. The group noted a partial consolation: rented infrastructure is reused across many targets, so the resulting volume can make campaigns easier to detect than a bespoke one.

The help desk

Voice-based social engineering against IT support is the path that bypasses the strongest authentication you own. An attacker who calls the help desk, impersonates an employee and obtains an MFA reset never has to defeat the existing factor. Phishing-resistant authentication does not help, because the attack does not touch the old credential at all. The defence is a process control at the help desk: a defined proof-of-identity step applied without exception, which is organisationally harder than deploying hardware keys and considerably cheaper.

Why this is a cloud problem

Three properties make the cloud consequences worse than the equivalent on-premises compromise.

• The session is the prize. Token theft after a successful phish gives an attacker something that replays without any further authentication, often past MFA entirely, and often for longer than anyone intends because refresh lifetimes are rarely audited.
• Mailbox access is lateral movement. A compromised mailbox in a cloud productivity suite is also a password-reset channel for every SaaS application the person uses, an internal-trust channel for the next phish, and a searchable archive of exactly the finance conversations BEC needs.
• The blast radius is an API call away. On-premises, an attacker with a user's credentials still has to move. In cloud, a single over-permissioned identity plus a valid session can reach production data without touching a network the defender monitors.

Detecting it with signals you already have

The useful reframing from the 2026-08-28 session was to treat this as threat hunting applied to people rather than as an awareness problem. Most of the inputs already exist in a normal cloud estate:

• Non-interactive sign-in logs. The gap that matters for token replay, and easy to overlook because the interactive log looks clean.
• Mailbox rule creation and forwarding changes. The single highest-signal BEC indicator: an attacker who has taken a mailbox almost always hides the evidence from its owner first.
• Impossible travel and unfamiliar-device sign-ins, understood as inputs to a hunt rather than as alerts to close.
• Help desk credential-reset events, correlated against subsequent sign-in location and device. Almost nobody reviews these, and they are where the vishing path becomes visible.
• Endpoint unsafe-browsing telemetry, which most EDR products already emit and few teams route anywhere useful.
• Whatever measures AI use in your environment, whether a gateway, a CASB, or SaaS app discovery.

Stryker's closing recommendation was specifically to pair the EDR unsafe-browsing signal with the AI-usage signal, on the grounds that together they describe volitional behaviour in a way neither does alone. Cohorts built from those signals will not match your org chart, which is the point.

Building the program

A workable progression, ordered so that each step produces something the next one needs:

1. Measure before you group. Collect the behavioural signals above for a quarter without acting on them. The purpose is to find out whether your role buckets have any internal consistency, which is a question with a real answer and usually a surprising one.
2. Build cohorts from behaviour, then check them against role. Where they agree, role was a fine proxy and you have saved effort. Where they diverge, you have found the population your previous program was missing.
3. Fix the process controls first. Out-of-band verification for payment changes and identity proofing at the help desk stop entire attack classes and need no behavioural data at all. Doing them first means the measurement work is not load-bearing while it matures.
4. Target the interventions. New hires in their first ninety days is a defensible cohort on the tenure finding alone. Heavy AI users are a different cohort needing different guidance, not more of the same.
5. Re-measure, and let cohorts dissolve. A person who has moved out of a high-risk pattern should stop being treated as high-risk, or you have rebuilt the meeple with more steps.

The physical and hybrid-work side

The 2026-06-26 session covered the part that predates cloud and did not go away: tailgating, badging, laptop locks, and how to extend any of it to home offices now that the home office is permanent for a large share of staff. Drawing partly on Stryker's time in the Marine Corps, the discussion landed on a constraint worth keeping in view when writing policy of any kind: security awareness has to be teachable and livable. A home-office policy nobody can follow produces no security and a measurable amount of contempt for the next policy you write.

The same session traded notes on password managers, including the practical difficulty of moving a 75-year-old family member from one to another. It is a small example of a general point, which is that usability is part of the threat model rather than a concession made against it.

Pitfalls

• Treating the annual training completion rate as the metric. It measures whether people clicked through a course, which is not correlated with whether they will click through a phish.
• Publishing click rates by department. It produces exactly the average that conceals the signal, and it teaches people to under-report rather than to report.
• Punitive framing. The single most valuable behaviour in this entire domain is a fast report from someone who has just realised they clicked something. Anything that raises the cost of that report is a net loss, however satisfying it feels.
• Assuming executives are the target and juniors are not. Whaling is real, and it is not what the click data says about who actually falls for things.
• Buying a tool before you have a question. Most of the signals above come from products you already run. The gap is usually routing and correlation, not acquisition.