This project starts with a simple idea: an attack does not succeed just because a message is convincing. It succeeds when a request makes it through a chain of controls and produces a real effect.
- Requestemail, text, call, meeting
- Actionenter, approve, run
- Capabilitysession, permission, payment
- Effectaccess, leak or fraud
What I want to understand
I am not interested in sorting people into “careful” and “careless”. I would rather look at what the system still requires after an ordinary human mistake.
A defence becomes useful when it asks for proof that persuasion alone cannot provide. But that proof must match the real action: authenticating a person does not necessarily prove that they are authorising the right device, payment or contact.
A series, not one long paper
Each module isolates one mechanism. Incidents are here to compare paths, not to hand out blame. The diagrams show where the chain continues and where it stops.
Where it comes from
The starting point is my ENG251 paper on social-engineering techniques and their defences. Here, I keep the ideas and sources but drop the academic format: less continuous prose, more paths, comparisons and concrete questions.
This is an evolving collection. Future modules may cover account recovery, out-of-band payment approval, ClickFix and the real place of security awareness.