Fundamentals of Social Engineering

The previous topic modeled an attack as a sequence of steps and tried to place a control against each one. In that model the first link in the chain was always technical: an unrecorded account, an open port, an unmonitored connection. This topic asks a different question. When the first link in the chain is a decision made by a person, what can be placed against that decision, and how much of it?

Verifying a request takes time, and every verification item has its own cost. Time pressure is therefore not a matter of style but a measurable constraint: as the seconds left to the decision-maker shrink, the number of verification items available shrinks with them. Trust is measured the same way — an unverifiable internal detail is a shortcut that stands in for an item. This lesson reduces both factors to a single number, the count of usable items, and counts the link at which the chain breaks. Attempting the steps modeled here outside written authorization and a defined scope is both illegal and unprofessional.

• SE1. The request set, verification items, and their durations belong to the subscriber services desk of the fictional regional measurement network. No real request is processed; what is measured is the model built with node.
• SE2. Every verification item has a fixed duration. In reality duration varies by person and by current load; a fixed duration preserves the items’ ranking from cheap to expensive, and that ranking is what the measure rests on.
• SE3. The decision-maker applies items from cheapest to most expensive. This is the most optimistic assumption; a real order is set by intuition and fits fewer items into the same budget.
• SE4. The request’s true class is known in the model. In reality the class is known only after the fact; it is assumed known here so that fake requests that slip through and legitimate work that is delayed can be counted separately.
• SE5. An item either disqualifies a request or it does not. Partial suspicion, asking a second question, and putting a request on hold are not modeled.
• SE6. Time pressure is reduced to a single number: the seconds left for the decision. Factors such as authority, reciprocity, and embarrassment are not modeled separately; all of them are carried as the same number that shortens the budget.

The Moment of Decision Is a Time Budget

The model has three parts. Verification items are listed with their durations; requests are given with their class, type, the time budget left to them, and their amount; and each request carries the items that can disqualify it. The list of disqualifying items is not a guess but the model’s definition: if that item is applied, the request stops; if not, it passes.

Request type is carried as a separate column because the scope of a procedure is drawn by type. There are three types — access, payment, and record — and which type a procedure covers directly determines which chain it breaks; the cost of the one type left out of scope is counted at the end of the lesson.

// decisions.mjs — verification items, request set, and decision chain; model
export const ITEM = { // name: cost of applying the item, in seconds
  'compare amount to threshold': 20, 'compare sender address to record': 40,
  'look up work order number in system': 60, 'find requester in authorization list': 90,
  'check past request record': 120, 'call back on recorded number': 180, 'request supervisor approval': 300,
};
const [A, S, W, L, H, C, P] = Object.keys(ITEM);
export const THRESHOLD = 2000; // fictional payment unit
// [request, class, type, pressure budget (s), amount, items that disqualify the request]
export const REQUEST = [
  ['password reset', 'fake', 'access', 60, 0, [C, L]],
  ['payment account change', 'fake', 'payment', 120, 4800, [C, H]],
  ['urgent payment approval', 'fake', 'payment', 30, 9500, [A, P, C]],
  ['field access outside work order', 'fake', 'access', 90, 0, [W, C]],
  ['subscriber record export', 'fake', 'record', 180, 0, [L, P]],
  ['planned maintenance temporary access', 'legitimate', 'access', 300, 0, []],
  ['new field worker account', 'legitimate', 'access', 600, 0, []],
  ['end-of-period invoice approval', 'legitimate', 'payment', 240, 12000, []],
  ['meter replacement payment', 'legitimate', 'payment', 120, 1500, []],
  ['printer setup at branch office', 'legitimate', 'record', 480, 0, []],
  ['subscriber dispute record lookup', 'legitimate', 'record', 90, 0, []],
  ['temporary authorization for outage crew', 'legitimate', 'access', 45, 0, []],
];
// chain steps: [step, precondition, control that sees the step, item dropped once the step completes]
export const CHAIN = [
  ['gathering task information', 'externally visible task list', null, 0],
  ['building the pretext', 'the name of an internal process', null, 0],
  ['making contact', 'a reachable channel', 'is the channel on record', 1],
  ['signaling trust', 'an unverifiable internal detail', 'is the detail checked against the record', 1],
  ['creating urgency', "the decision-maker's time budget", 'is the time budget fixed by procedure', 2],
  ['requesting the action', 'an authorized decision-maker', 'is callback mandatory', 5],
];
export function items(budget) { // verification items that fit the budget, cheapest to most expensive
  let t = 0; const chosen = [];
  for (const [name, s] of Object.entries(ITEM)) { if (t + s > budget) break; t += s; chosen.push(name); }
  return { chosen, time: t };
}
export const procedureScope = (t) => t[2] === 'access' || (t[2] === 'payment' && t[4] > THRESHOLD);

How the Pressure Budget Cuts the Number of Items

// run1.mjs — number of verification items usable under time pressure, and fake requests that pass
import { ITEM, REQUEST, items } from './decisions.mjs';

console.log(`${Object.keys(ITEM).length} verification items, total ${Object.values(ITEM).reduce((a, b) => a + b, 0)} s; ` +
  `${REQUEST.length} requests, ${REQUEST.filter((t) => t[1] === 'fake').length} fake\n`);
console.log(`${'request'.padEnd(39)} ${'class'.padStart(10)} ${'budget'.padStart(6)} ${'items'.padStart(5)} ${'result'.padStart(7)}`);
let passed = 0, stopped = 0;
for (const t of REQUEST) {
  const { chosen } = items(t[3]);
  const stoppedHere = t[5].some((k) => chosen.includes(k));
  if (t[1] === 'fake') { stoppedHere ? stopped++ : passed++; }
  console.log(`${t[0].padEnd(39)} ${t[1].padStart(10)} ${String(t[3]).padStart(6)} ${String(chosen.length).padStart(5)} ` +
    `${(t[1] === 'fake' ? (stoppedHere ? 'stopped' : 'passed') : 'passed').padStart(7)}`);
}
console.log(`\nusable items by pressure budget:`);
for (const b of [30, 60, 120, 180, 300, 600]) {
  const { chosen, time } = items(b);
  console.log(`  ${String(b).padStart(3)} s -> ${chosen.length}/${Object.keys(ITEM).length} items (${time} s), ` +
    `left out: ${Object.keys(ITEM).filter((k) => !chosen.includes(k)).length}`);
}
console.log(`\ndecision without a procedure: fake requests stopped ${stopped}, passed ${passed}`);
console.log(`fake requests that passed: ${REQUEST.filter((t) => t[1] === 'fake' && !t[5].some((k) => items(t[3]).chosen.includes(k))).map((t) => `${t[0]} (${t[3]} s)`).join('; ')}`);

7 verification items, total 810 s; 12 requests, 5 fake

request                                      class budget items  result
password reset                                fake     60     2  passed
payment account change                        fake    120     3  passed
urgent payment approval                       fake     30     1 stopped
field access outside work order               fake     90     2  passed
subscriber record export                      fake    180     3  passed
planned maintenance temporary access    legitimate    300     4  passed
new field worker account                legitimate    600     6  passed
end-of-period invoice approval          legitimate    240     4  passed
meter replacement payment               legitimate    120     3  passed
printer setup at branch office          legitimate    480     5  passed
subscriber dispute record lookup        legitimate     90     2  passed
temporary authorization for outage crew legitimate     45     1  passed

usable items by pressure budget:
   30 s -> 1/7 items (20 s), left out: 6
   60 s -> 2/7 items (60 s), left out: 5
  120 s -> 3/7 items (120 s), left out: 4
  180 s -> 3/7 items (120 s), left out: 4
  300 s -> 4/7 items (210 s), left out: 3
  600 s -> 6/7 items (510 s), left out: 1

decision without a procedure: fake requests stopped 1, passed 4
fake requests that passed: password reset (60 s); payment account change (120 s); field access outside work order (90 s); subscriber record export (180 s)

The lower table gives the lesson’s first number. The desk holds seven verification items, and applying all of them takes 810 seconds. In a thirty-second budget, only one of them can be used; six are left out. Even in a hundred-and-eighty-second budget, only three items are usable; the two most expensive items — the callback and the supervisor approval — only fit into a budget of six hundred seconds. The number of items does not scale in proportion with the budget; it steps up: no new item is added between one hundred twenty and one hundred eighty seconds, because the next item costs ninety seconds and the running total reaches two hundred ten.

The upper table shows the consequence. Four of five fake requests pass, and what they share is that their disqualifying items were left out: an item that would disqualify each fake request exists in the model, but it does not fit into the budget the request was given. The one request that is stopped is the one given the shortest budget — thirty seconds — and it is stopped by the cheapest item. Comparing the amount to a threshold takes twenty seconds and flags a nine-thousand-five-hundred unit payment on its own. This is the measure’s first counterintuitive finding: raising the pressure does not always help the chain, because a budget short enough on its own is conspicuous enough to trigger even the cheapest item.

A decision made without a procedure therefore lets four fake requests through. What is measured is not the decision-maker’s carelessness but the shortness of the budget. The same person can apply six items given six hundred seconds.

The Chain, Its Links, and the Early-Break Gain

// run2.mjs — chain steps, the breakable link, and the callback procedure's three columns
import { REQUEST, CHAIN, ITEM, items, procedureScope } from './decisions.mjs';

const CALLBACK = 'call back on recorded number';
let cum = 0; const cumul = CHAIN.map((a) => (cum += a[3]));
console.log(`${'#'.padStart(2)} ${'step'.padEnd(28)} ${'precondition'.padEnd(34)} ${'control'.padStart(7)} ${'cum. items'.padStart(10)}`);
CHAIN.forEach((a, i) => console.log(`${String(i + 1).padStart(2)} ${a[0].padEnd(28)} ${a[1].padEnd(34)} ` +
  `${(a[2] ? 'yes' : 'no').padStart(7)} ${String(cumul[i]).padStart(10)}`));
const breakable = CHAIN.map((a, i) => (a[2] ? i : -1)).filter((i) => i >= 0);
const early = breakable[0], late = breakable[breakable.length - 1];
console.log(`\nchain has ${CHAIN.length} steps; with a control ${breakable.length}, with no control at all ${CHAIN.length - breakable.length}`);
console.log(`earliest breakable link ${early + 1} -> items dropped by then ${early ? cumul[early - 1] : 0}`);
console.log(`latest breakable link  ${late + 1} -> items dropped by then ${cumul[late - 1]}`);
console.log(`items dropped if never broken ${cumul[CHAIN.length - 1]}; early-break gain ${cumul[late - 1] - (early ? cumul[early - 1] : 0)} items`);

console.log(`\ncallback procedure (${ITEM[CALLBACK]} s, type 'access' or above-threshold 'payment'):`);
let stopped = 0, slipped = 0, delayed = [], extraTime = 0;
for (const t of REQUEST) {
  const scope = procedureScope(t);
  const applied = items(t[3]).chosen.concat(scope ? [CALLBACK] : []);
  if (scope) extraTime += ITEM[CALLBACK];
  if (t[1] === 'fake') { t[5].some((k) => applied.includes(k)) ? stopped++ : slipped++; }
  else if (scope && t[3] < ITEM[CALLBACK]) delayed.push(`${t[0]} (${t[3]} s)`);
}
console.log(`  requests in scope ${REQUEST.filter(procedureScope).length}/${REQUEST.length}, added verification time ${extraTime} s`);
console.log(`  fake requests stopped ${stopped}/5, slipped through ${slipped}`);
console.log(`  slipped through: ${REQUEST.filter((t) => t[1] === 'fake' && !procedureScope(t) && !t[5].some((k) => items(t[3]).chosen.includes(k))).map((t) => `${t[0]} (type ${t[2]})`).join('; ')}`);
console.log(`  legitimate work delayed ${delayed.length}: ${delayed.join('; ')}`);

 # step                         precondition                       control cum. items
 1 gathering task information   externally visible task list            no          0
 2 building the pretext         the name of an internal process         no          0
 3 making contact               a reachable channel                    yes          1
 4 signaling trust              an unverifiable internal detail        yes          2
 5 creating urgency             the decision-maker's time budget       yes          4
 6 requesting the action        an authorized decision-maker           yes          9

chain has 6 steps; with a control 4, with no control at all 2
earliest breakable link 3 -> items dropped by then 0
latest breakable link  6 -> items dropped by then 4
items dropped if never broken 9; early-break gain 4 items

callback procedure (180 s, type 'access' or above-threshold 'payment'):
  requests in scope 8/12, added verification time 1440 s
  fake requests stopped 4/5, slipped through 1
  slipped through: subscriber record export (type record)
  legitimate work delayed 1: temporary authorization for outage crew (45 s)

The chain has six steps, and the first two carry no control at all. This is not because those steps are harmless but because they sit outside the defense’s field of view: a task list being visible from the outside and the name of an internal process being known are preparation steps that never touch any record. The chain’s first two links are therefore uncountable, only narrowable.

The four breakable links begin at the third step, and at that point no item has dropped yet. Breaking at the sixth step comes after four items have already dropped. The difference between the two is the early-break gain: four items. If the chain never breaks, the count reaches nine, meaning that letting the final step through costs five items on its own. Read together, these three numbers turn where a defense should invest from an opinion into a ranking.

The callback procedure shows this across three columns. The procedure covers eight of the twelve requests and stops four of the five fake ones; a decision without a procedure had stopped only one. The one request that slips through falls outside scope: a record-type export request is neither access nor an above-threshold payment, so the procedure never touches it. This is where the measure shifts to detection rather than the chain breaking: for this request there is no link to break — the request passes, but the export can still be counted afterward.

The cost is written in two items. Adding one hundred eighty seconds to each of eight requests produces a total of 1,440 seconds of added verification. Exactly one piece of legitimate work is delayed, and which one matters: the request for temporary authorization for the outage crew arrives with a forty-five-second budget, the callback takes one hundred eighty seconds, and the work does not fit inside the procedure. The only legitimate work the procedure delays is the most urgent one. This is not a flaw but the unavoidable result of the procedure’s design: any procedure that turns time pressure into a control also routes genuinely urgent work through that same control.

Summary

• All 7 verification items together take 810 seconds. A 30-second budget allows 1 item, a 180-second budget allows 3, a 600-second budget allows 6; the item count rises in steps, not in proportion to the budget.
• In a decision without a procedure, 4 of 5 fake requests pass. An item that would disqualify each one exists in the model, but it does not fit into the budget given; the one request stopped had the shortest budget, and the cheapest item stopped it.
• The chain has 6 steps; 4 carry a control, and the first 2 touch no record at all. These two links cannot be counted, only made harder by narrowing what is visible from outside.
• The earliest breakable link is step 3, where 0 items have dropped; breaking at step 6 means 4 items have already dropped. The early-break gain is 4 items, and the cost of never breaking the chain is 9 items.
• The callback procedure covers 8 of 12 requests and stops 4 of 5 fake ones; the 1 request outside its scope breaks no link, and the measure shifts to detection.
• The procedure’s cost is 1,440 seconds of added verification and 1 piece of delayed legitimate work — the most urgent request, whose budget is shorter than the procedure’s own duration.

Next Step

In this lesson a request was assumed to have already reached the decision-maker, and what was measured was the decision itself. The chain’s third link — making contact — was passed over in a single line, yet the message that contact carries is itself a measurable object. What separates a legitimate message from a fake one in a message set is not tone but countable indicators: a sender never seen before, a reply address that diverges from the sender, a link target that differs from the displayed text. The next lesson’s question is this: how many distinguishing indicators can be counted in a message set, how many fake messages does the chosen threshold miss, how many legitimate messages does it flag by mistake — and why does the indicator count fall as the target narrows.