Foundations capstone

First, the case in brief, because the rest of the module works it hard. Hartley Chambers is a constructed scenario, a mid-sized law firm that grew from ten people to eighty without its security growing at all, but every element in it is drawn from patterns that recur in published breach reports. A phishing email harvested a paralegal's password. That password opened the firm's document management system, which asked for nothing else. The system held credentials for the finance platform in a shared spreadsheet, sat on the same flat network, and logged every access without anyone reading the logs. The intruder read 47 client matters over three months. Containment then took four days, and the Information Commissioner's Office was not notified within the required window. Every one of those sentences maps to a module in this stage, and working through the mapping is the capstone exercise.

What cybersecurity is and is not: The firm treated cybersecurity as something its IT contractor did, rather than as an organisational responsibility with an accountable owner. No CISO or equivalent existed, so nobody could insist on the controls the rest of this list describes. In NIST CSF 2.0 terms the Govern function was entirely absent, and its absence is why the other failures were never noticed, funded or fixed.

Who attacks and why:The attacker fits the commodity pattern that module described: financially motivated, working with phished or bought access rather than bespoke tooling. A working login to a law firm's document store is exactly the kind of foothold an initial access broker sells, and 47 confidential client matters are a saleable asset whether used for extortion, resale or quiet exploitation. The firm was cheap to attack and valuable to breach, which is the pairing the attacker economy is built to find. Section 9.2 takes this lens further.

Risk and outcomes:The document management system's single-factor authentication was a known risk that had not been formally assessed, scored, or assigned an owner. It appeared on no risk register, and the firm had never run the risk appetite exercise that would have flagged client confidentiality as a zero-tolerance area. A risk nobody has scored is a risk nobody has to fix.

Data and integrity: Credentials stored in a shared spreadsheet on a document management platform represent a classification and handling failure. Credentials are assets that should live in a password manager with access controls, not in a shared file carrying no label and no handling restriction.

Networks and transport: The document management system was not segregated from the finance system. A single compromised credential provided lateral movement across both. Defence in depth and network segmentation were absent, so the first failed control was also the last.

CIA triad and simple attacks: The primary violation was confidentiality: 47 client matters were accessed by an unauthorised party. The potential secondary violation was integrity: had the attacker modified documents or financial data, the firm might not have detected it. Availability was never touched, and that is precisely why the breach ran for three months. An intruder who breaks nothing gives an unmonitored organisation no reason to look.

Identity and access: The document management system had no multi-factor authentication despite handling highly sensitive client data. The paralegal's credentials gave access to far more than their role required, a least privilege failure, and no access review process existed to notice the accumulation.

Human factors and phishing: A phishing email successfully harvested credentials. The firm ran no phishing simulation programme, offered staff no easy way to report a suspicious email, and had taught nobody what a credential harvest looks like. The human layer was undefended, not because people were careless but because nobody had built the procedures that make care effective.

Privacy and everyday data protection: Client matter files constitute personal data under the UK GDPR, and the firm failed to notify the ICO within the 72-hour window required by Article 33. The four-day containment response extended the exposure period and turned a security failure into a regulatory one.

Set against the standards this stage has leaned on, none of this is exotic. The two passages below name what was missing, in the standards' own words.

Two threads from earlier in the stage deserve more than an entry in the mapping, because each explains the whole incident on its own terms. The attacker economy explains why Hartley Chambers was attacked at all. The verification procedure explains where the attack should have died. Read together, they point at the same first control.

Start with what the attack cost. The criminal needed a phishing kit, a list of email addresses and a plausible pretext for a login page, all of which are commodities. No zero-day exploit, no bespoke malware, no reconnaissance beyond what the firm's own website offered. The module on who attacks and why taught that modern attack is a supply chain with a division of labour, and this incident slots straight into it: the phished credential is the product an access broker would list for sale, and the affiliate model means the person who harvests a password does not need the skills to exploit what it opens. They can sell it to someone who does.

Now price the other side. Behind that one password sat 47 client matters: litigation strategy, financial details, personal correspondence. To an extortionist those files are pressure; to a fraudster they are a product; to the firm they are its duty of confidentiality made concrete. The asymmetry is the point. A few tens of pounds of attacker effort stood against files whose exposure could end the firm, and when the cost of attack is that low and the value that high, the breach is not bad luck. It is the market working. The defensive conclusion is not to become unattackable, which is not on offer, but to become uneconomic: every control that raises the price of the commodity route pushes the firm out of the cheap-to-attack population that commodity attackers farm.

The second lens is procedural. Walk the attack as a sequence of human checkpoints and count the gates. The email arrived: no simulation programme had taught the paralegal what a credential harvest looks like, and no reporting route existed to raise a hand cheaply. The password was entered on a fake page: nothing challenged it. The real login then came from an unfamiliar network: nothing challenged that either. Three gates, all open. The identity and access module made the deeper point: a password is a single secret, and any procedure that rests on one secret carries a single point of failure by design.

What closes the gap is a check the attacker cannot satisfy from where they sit. Out-of-band verificationforces a sensitive action to be confirmed through an independent channel, and multi-factor authentication is the everyday version of the same idea: possession of a trusted device is something a phished password does not carry. The identity module's comparison of SMS codes, authenticator apps and FIDO2 matters here, because a one-time code can still be phished in real time while a hardware-bound passkey cannot, but any second factor at all would have turned this particular stolen password into a dead end.

Notice where the two lenses converge. The economy lens says raise the attacker's cost above the commodity threshold. The gate lens says insert a check a stolen secret cannot pass. Multi-factor authentication on the document management system does both at once, which is why it, and not a bigger firewall or a larger training budget, is the first control a CSF-aligned response would have reached for. The next section widens the view from that single control to the whole programme.

Applying the NIST CSF 2.0 functions to the Hartley Chambers scenario shows clearly which functions were absent. The framework's February 2024 revision added Govern to the original five precisely because incidents like this one keep tracing back to ownership rather than technology, so it is fitting that the mapping starts there.

Govern: a board-level risk owner for client data confidentiality would have driven MFA deployment, access reviews, and incident response planning as non-negotiable baseline controls.

Identify: a formal asset inventory would have flagged the document management system as a high-value target housing confidential client data, triggering a risk assessment and MFA requirement.

Protect: MFA on all systems handling client data, least-privilege access scoped to matter-level rather than platform-level, and credential storage in a managed password vault rather than a shared spreadsheet.

Detect: active log review with automated alerts for unusual access patterns would have detected the three-month intrusion within days rather than weeks. The security logs existed; they were simply not being monitored.

Respond: a pre-written incident response plan with a designated responder, a containment checklist, and a 72-hour ICO notification workflow would have compressed the response from four days to hours.

Recover: post-incident review of all 47 affected matters, client notifications, and a lessons-learned exercise feeding back into the Govern function to prevent recurrence.

It is worth pausing on what this list does not say. It calls for no new products and almost no new spending: nearly every line is process wrapped around technology the firm already owned. That observation is where the most common misreading of incidents like this one falls apart.

A reasonable question at this point: would certification have prevented the breach? The honest answer has two halves. A scheme like Cyber Essentials would very likely have blocked this specific attack path, and an assessment against the CAF would have exposed the governance gaps behind it. Neither would have made the firm secure, because assurance schemes are floors, and a floor only protects you while you keep standing on it.

Cyber Essentials is the UK government-backed baseline scheme, built on five technical control themes: firewalls, secure configuration, security update management, user access control and malware protection. Its user access control theme requires multi-factor authentication on accounts for cloud services, which would have covered the hosted document management system, and the Plus variant adds independent technical testing rather than relying on verified self-assessment. For a firm of eighty people it is the natural first target precisely because it is narrow: five themes, renewed annually, with no pretence of covering governance, detection or incident response.

The NCSC's Cyber Assessment Framework sits at the other end of the scale. It is outcome-based rather than checklist-based, organised into four objectives: managing security risk, protecting against attack, detecting security events and minimising the impact of incidents. It was written for operators of essential services, but reading Hartley Chambers against it is instructive anyway. The firm fails objective A before any technology is examined, because nobody owned the risk, and fails objective C on the plain fact that logs existed and nobody read them. Both schemes get their full treatment in the regulation and assurance module in the practice and strategy stage.

The reason to treat certification as a floor rather than a finish line is documented, not rhetorical. When the WannaCry ransomware spread through the NHS in May 2017, the National Audit Office investigation that followed found that the infected NHS organisations were running unpatched or unsupported Windows systems, that the patch closing the vulnerability had been available since March 2017, and that national alerts recommending it had gone out in the weeks before the attack. Policies existed; the practice behind them did not. No NHS organisation paid the ransom, but thousands of appointments were cancelled and services were disrupted for days. Certification and policy describe a state at a point in time. Controls either operate on the day of the attack or they do not.

Before progressing to the Applied Cybersecurity stage, check yourself honestly against the following. The point is not to feel ready but to find gaps while they are cheap to fix: if any line feels shaky, revisit the corresponding module.

Definitions and scope: You can explain what cybersecurity covers and does not cover, and why the NIST CSF 2.0 has six functions rather than five.

Attackers and evidence: You can describe the ransomware-as-a-service division of labour, tell the four attacker classes apart by motivation, and challenge a headline threat statistic by asking what population it counts.

Risk: You can apply the likelihood-times-impact formula, distinguish threat from vulnerability from exploit, and explain risk appetite using a realistic example.

Data: You can classify data under HMG GSC, identify the three data states and their appropriate controls, and explain how SHA-256 provides integrity verification.

Networks: You can distinguish stateful from stateless firewalls, explain why TLS 1.3 is preferred over TLS 1.2, and describe what defence in depth means in practice.

CIA and STRIDE: You can give a real-world example of each CIA property being violated and map a given attack to a STRIDE category.

Identity: You can compare SMS OTP, TOTP, and FIDO2, explain the principle of least privilege, and describe what access creep is.

Human factors: You can classify phishing variants, identify which Cialdini principle is being exploited in a scenario, and evaluate a proposed awareness training programme.

Privacy: You can apply the seven UK GDPR lawful bases, including recognised legitimate interests added by the Data (Use and Access) Act 2025, explain the 72-hour breach notification obligation, and describe data minimisation in system design terms.

The exercises below are the final check. The drag challenge tests whether the investigation sequence has stuck, and the baseline tool turns the whole stage into a personal audit you can act on this week.