Policy, mechanism, assurance and incentives

Four parts split “secure” into questions you can check

Knowing that a system should be “secure” does not tell anyone what to build. The unit’s framework breaks that goal into four parts: 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. Any incident can be traced to a failure in one of the four, so the framework works for investigation as well as design.

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 it, 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 implements policy: encryption for confidentiality, tamper-resistant hardware for physical security, cryptographic hashes for data integrity. Beginners 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 examples: 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. 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 tell you how much 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, and a policy nobody has the incentive to enforce is a document, not a control. When a question asks which part something belongs to, ask whether the statement says 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: one way of achieving that policy, and there could be others.

A bank shows all four parts at work

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 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

Optional 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. They are not reconstructed here; the tables draw on the lecture notes’ prose version of the same case study instead.

The 2013 Target breach failed in every one of the four parts

Attackers installed malware on Target’s point-of-sale systems and gained roughly 40 million customers’ credit and debit card details, plus personal information belonging to up to 70 million individuals.

Try it — worked example

In the 2013 Target breach, attackers got in through an HVAC contractor’s access. Which of the four framework parts (policy, mechanism, assurance, incentives) failed, and how?

Show answer and steps

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.

1. 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.

2. 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.

3. Mechanisms. The technical mechanism worked: Target’s FireEye malware detection tool correctly flagged the attackers’ malware in Target’s point-of-sale systems.

4. 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.

5. 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.

6. 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.

7. Incentives. Target, a large retailer with a large customer base, was breached during the high-volume holiday shopping season, which made it a lucrative target.

8. 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.

Pass-the-hash plus Single Sign-On is contained by least privilege

Pass-the-hash lets an attacker who has captured a credential hash authenticate as that user without 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. SSO needs a supplementary mechanism to contain this: the least privilege principle limits what any single set of credentials can reach. SSO alone widens the blast radius of one stolen credential; least privilege keeps that radius small.

Third-party risk management has since become its own discipline: vendors are commonly required to meet security standards, submit to regular audits, and accept continuous monitoring of their access before an organisation grants it.

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, 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, with nobody having sufficient motive to treat the alert as urgent, is exactly the follow-up question the framework is built to prompt.