Policy, mechanism, assurance and incentives
The four-part framework the unit uses to design and investigate distributed system security, applied to a bank and to the 2013 Target breach.
- Define policy, mechanisms, assurance and incentives, each with its own example.
- Apply the framework to a case study, and say which part failed when a breach happens.
- Trace the 2013 Target breach to specific failures in each of the four parts.
14 min read
Intuition
Knowing that a system should be “secure” does not tell anyone what to build. The unit’s framework breaks that vague goal into four parts that can each be checked separately: what are we trying to achieve, what machinery achieves it, how much do we trust that machinery, and who is motivated to attack or defend it. When an incident happens, it can always be traced back to a failure in one of these four, which is what makes the framework useful for investigation as well as design.
Mechanism
Policy defines what security means for the system; mechanisms are the machinery — encryption, tamper-resistant hardware, cryptographic hashes — that implement it; assurance is how much reliance those mechanisms warrant; incentives are what motivates defenders to maintain the system and attackers to break it. The lecture's bank example runs all four: a policy of correct account balances, mechanisms of bookkeeping and anomaly detection, assurance strongest against outsiders and weakest against insiders, and incentives that cut both ways.
Policy defines what security means for the system, without saying how to achieve it. Higher management usually sets policy, driven by business continuity and regulatory compliance. “Customer data must be stored only within our data centres” and “Only authorized employees must be able to access the personal information of clients” are both policies: they state a goal, not an implementation.
Mechanisms are the machinery that implement policy: encryption for confidentiality, tamper-resistant hardware for physical security, cryptographic hashes for data integrity. Beginners in security engineering tend to think mechanisms are the whole subject. They are one part of it.
Assurance is how much reliance a mechanism deserves, and how well several mechanisms hold up together. The lecture’s own example: how long would it take to break RSA encryption at current computing capacity, or to brute-force a 10-character password? A mechanism considered secure today can stop being secure as computing power changes — the lecture notes that breaking RSA-2048 would take a classical computer trillions of years, but a quantum computer roughly ten seconds.
Incentives are the motive defenders have to do their job, and the motive attackers have to defeat the policy. Depending on the target, an organisation may face state actors, cybercriminal or ransomware groups, script kiddies, or hacktivists. Working out which threats matter and prioritising defences against them is threat modelling. Security costs money, and incentives are what tell you how much of it to spend, and where.
Exam detail
The four parts are interconnected, not a checklist run once. A working mechanism with no assurance behind it is a guess, not a defence — and a policy nobody has the incentive to enforce is a document, not a control. When a question asks which part of the framework something belongs to, the test is usually: does this statement say what the system must do (policy), how it does it (mechanism), how much to trust that (assurance), or why anyone would bother (incentives)?
Pitfall
Policy and mechanism are the pair most often confused. “Only authorised employees can access client data” is a policy — it says nothing about how. “Employees must authenticate with a smart card and PIN before the system grants access” is a mechanism — it is one way of achieving that policy, and there could be others.
The framework applied to a bank
Banks run many security-critical systems at once, with many people working together — a large attack surface and real potential for insider attacks. The lecture works through all four parts of the framework for a retail bank.
Policy
| Point | Detail |
|---|---|
| Overall goal | Maintaining correct account balances |
| Sub-goals | Safeguard the integrity, confidentiality and availability of ATMs and online banking; ensure the accountability of bank-to-bank transfers |
Mechanisms
| Mechanism | Purpose |
|---|---|
| Strong bookkeeping and access control | Especially in the backend |
| Anomaly detection | Flagging unusual transactions |
| Four-eyes principle | Large transfers need at least two people to authorise them |
| Strong cryptographic protocols | ATM authentication |
Assurance
| Point | Detail |
|---|---|
| Depends on | How effective the mechanisms actually are, and how well they work together |
| Biggest perceived threat | Insiders — employees committing petty theft, who are familiar with the bank’s own systems |
| Anomaly detection limits | Not every unusual transaction is illegitimate; the bank must balance sensitivity against disrupting genuine customer activity |
Incentives
| Party | Motive |
|---|---|
| Attackers | Obtain customer money without detection, or run a series of transfers that obscures the money’s trail |
| Guards and admins | May be tempted to use their position for personal advantage, so screening and vetting matter |
Aside
The slide deck presents the bank’s mechanisms, assurance and incentives as two tables rather than the four above. Two of its bullet points did not survive PDF extraction and print as garbled text in the slide source — one under mechanisms, one under assurance. They are not reconstructed here; the tables above draw on the lecture notes’ clean prose version of the same case study instead.
The 2013 Target breach, as a framework failure
Worked example
AnswerEvery one of the four parts failed somewhere: policy on vendor access, incident response on the mechanism side, unverified assurance on IDS/IPS, and misaligned incentives during the holiday season.
Policy. Target had no policy requiring third-party vendors to meet a security standard before being granted network access. It gave network access to Fazio Mechanical Services, an HVAC contractor, without verifying the contractor’s security practices.
Attackers stole the contractor’s credentials and used them to reach Target’s network — a direct consequence of the missing policy, not of any broken mechanism.
Mechanisms. The technical mechanism worked: Target’s FireEye malware detection tool correctly flagged the attackers’ malware in Target’s point-of-sale systems.
What Target lacked was an incident-response mechanism to act on that alert. The attackers continued operating for weeks after FireEye’s warning. Credit-card fraud detection, separately, also worked as intended.
Assurance. FireEye’s reliability is confirmed by the outcome — it did detect the malware. Whether Target’s other defences, such as its intrusion detection and prevention systems, worked as expected is not known, largely because Target did not act on the alerts it did receive.
The attackers used a pass-the-hash technique, reusing a captured credential hash rather than a plaintext password. This exposed a limitation in Target’s Single Sign-On mechanism: SSO without a supplementary mechanism such as least privilege lets one compromised credential reach further than it should.
Incentives. Target — a large retailer with a large customer base, breached during the high-volume holiday shopping season — was a lucrative target for attackers.
On the defence side, it is unclear whether Target’s own security team had sufficient incentive to act promptly: the notes state Target’s management appears to have prioritised holiday operations over timely notification once the breach was discovered.
Attackers gained access to roughly 40 million customers’ credit and debit card details, and personal information belonging to up to 70 million individuals, by installing malware on Target’s point-of-sale systems.
Threat
Pass-the-hash lets an attacker who has captured a credential hash authenticate as that user without ever learning the plaintext password. Combined with Single Sign-On, one compromised credential can reach every system the SSO trusts, not just the one it was captured from.
Control
SSO needs a supplementary mechanism to contain this: the least privilege principle limits what any single set of credentials — compromised or not — can reach. SSO alone widens the blast radius of one stolen credential; least privilege is what keeps that radius small.
Recall
A company detects an intrusion with a working monitoring tool but takes three weeks to respond. Which part of the framework failed, and which part worked?
The mechanism worked — detection happened. What failed sits on the mechanism side too, but in a different piece of machinery: there was no incident-response mechanism to act on the alert. Whether that gap traces back further to incentives — nobody having sufficient motive to treat the alert as urgent — is exactly the kind of follow-up question the framework is built to prompt.
Because organisations learned from this incident, third-party risk management has since become its own discipline: vendors are now commonly required to meet security standards, submit to regular audits, and accept continuous monitoring of their access before an organisation grants it.
Source
Week 1 Notes PDF