The previous two lessons were an inventory of the problem: the technical attacks ordered by phase of the chain, and the human vector with all its variations. This lesson is the inventory of the response. We are going to work through the catalogue of defences that counters what you have seen, organised by the layers of defence in depth you established in 01-03: perimeter and network, endpoint, data, application and development life cycle, and logging and observability. For each measure you will see what it does, when it is used and which specific attack it neutralises; the detailed implementation belongs to module 5 and is only linked to here. And because Nimbus's budget is not infinite, the lesson ends with the most useful thing of all: a table of the twelve highest-return measures with their cost, effort and impact, and a phased 30, 90 and 180-day plan that Marta could approve on Monday.

1. How to choose defences: three criteria before spending a euro
2. Perimeter and network protection
3. Endpoint protection
4. Data protection
5. Protecting the application and the development life cycle
6. Logging and observability as a protection measure
7. Prioritising on an SME budget: the 12 highest-return measures
8. Phased plan: 30, 90 and 180 days

Before the catalogue, the method. The most common way of spending badly on security is buying what is advertised rather than what is missing.

Criterion 1: which specific attack does it neutralise? Every measure must be traceable to an entry in the summary table of 02-02 or in the catalogue of 02-03. If you do not know which attack it stops, you do not know whether you need it.

Criterion 2: which phase of the chain does it act on, and what other layers do I already have there? Remember the Kill Chain from 02-01: if all your measures act on the same phase, you have a defence that is thick on one side and bare on the other.

Criterion 3: what type of control is it? Controls are classified by function, and a healthy defence has all four types:

The typical imbalance you already diagnosed with the NIST CSF in 02-01: almost everything preventive, almost nothing detective. It is comfortable because preventive controls are bought and installed once, whereas detective ones require somebody to look. But when prevention fails — and it will — the only thing that limits the damage is detection.

A fourth criterion, informal but decisive in an SME: does this measure survive a bad day? A defence that demands ten minutes of daily discipline from somebody who is already swamped will not last three weeks. The measures that work at Nimbus are the ones that are on by default, automated or in the natural path of the work.

The classic perimeter has lost weight — half the headcount works remotely and the data is in the cloud — but it has not disappeared: it is still the first line against the mass scanning of 02-02.

On the WAF, precisely, because it is the most misunderstood measure of all: a WAF buys time, it does not fix code. It is extraordinarily useful for three things: holding back the automated background noise, applying a virtual patch while a newly discovered vulnerability is being fixed, and providing visibility of what is being attempted against the API. What it does not do: replace parameterised queries or detect an IDOR, because an IDOR request is perfectly well formed. If Nimbus installs a WAF and relaxes code review as a result, it has made things worse.

What it is. Dividing the network into zones with control between them, so that compromising one does not give access to the others.

Why it is the most cost-effective measure against ransomware. The timeline in 02-02 showed the attacker spending days moving laterally. Segmentation is what turns "they got into a laptop" into "they got into a laptop" rather than "they encrypted the whole infrastructure". Three practical rules for Nimbus:

• The guest wifi touches nothing internal. It is a five-minute control on the router and it removes a whole class of risk.
• The data zone only accepts connections from the application zone. Never from the office and never from the Internet. You already checked this with describe-security-groups in 01-04.
• Administrative access always goes through a single point (a bastion host or a VPN with MFA), which is then the only place that really needs watching.

Against the volumetric kind, the defence is bought in: the cloud provider or a CDN absorbs the traffic before it reaches Nimbus's link. It is one of the few defences that genuinely cannot be built with your own resources, because it requires network capacity.

Against the application-layer kind, the defence is programmed, and you already saw it in 02-02: mandatory pagination, business range limits, rate limiting and a maximum query time. No anti-DDoS service tells an expensive request from a cheap one: to it, both are a legitimate HTTPS request.

With 19 people outside the office, remote access is Nimbus's perimeter.

Recommendation for Nimbus: mandatory MFA on remote access (no exceptions, including the consultancy), a bastion host with session logging for administrative access, and just-in-time access with an expiry for third parties instead of the current permanent access of asset A-19. The identity detail goes in 02-05; the network configuration, in 05-04.

The 40 laptops (A-14) are where people work, and therefore where the phishing of 02-03 lands.

Why the difference matters in the Nimbus case. Look back at exercise 3 of 02-03: Rubén's laptop runs a component that establishes an outbound channel and steals the browser cookie. A signature-based antivirus may see nothing, because the file is new and because much of the activity uses legitimate system tools. An EDR sees the pattern: an office process launching a command interpreter, an access to the browser's credential store, an outbound connection to a recently registered domain. And, above all, it allows the machine to be isolated with one click and lets you reconstruct afterwards what happened.

The realistic warning: an EDR whose alerts nobody looks at is an expense, not a defence. Before buying it, you have to decide who attends to it and when. For Nimbus, the sensible option is usually an EDR with a managed monitoring service, or a well-configured EDR with few, highly actionable alerts.

The most underrated of the three is patching. It is not glamorous, it cannot be shown to a customer and it appears in no sales brochure. But two of the biggest incidents in recent history — the ones we will analyse in 02-06 — were known vulnerabilities with a patch available for months. Hardening and endpoint management are studied in detail in 05-06.

The previous layers protect containers. This one protects what is inside, and it is the only one that still helps when the others fail.

You cannot protect differently what has not been classified. You already did it in 01-04 with the four levels (public, internal, confidential, restricted) and their three rules: inheritance upwards, aggregation raising the level, and context defining sensitivity. Classification is not a measure in itself: it is what makes it possible to apply everything else without going bankrupt.

Two clarifications that prevent false senses of security:

1. The provider's encryption at rest protects against theft of the physical medium, not against an attacker with valid credentials. If the attacker has access to the database, the engine returns the data decrypted: that is what the key is for. It does not protect against an IDOR, nor against ransomware operated with stolen credentials.
2. The key is the real asset. Encrypting with a key that sits in the same place as the data is a decorative exercise. Key management — where the keys live, who has access, how they are rotated — is the hard problem, and it is studied in 03-06.

The cryptographic mechanisms are developed in module 3; what matters here is where to apply them.

This is the most important measure in the whole lesson, because it is the only one that gives the business back when everything else has failed.

The 3-2-1 rule:

• 3 copies of the data (production and two more).
• On 2 different media or technologies.
• 1 of them out of reach of the main infrastructure.

The modern extension, 3-2-1-1-0, which is the one that matters against ransomware:

• 1 copy that is immutable or offline.
• 0 errors in the restore test.

Why immutability is the decisive piece. Remember the ransomware timeline from 02-02: on day 20, before encrypting, the attacker deletes the backups. If Nimbus's backups sit in the nimbus-backups-prod bucket (A-03), inside the same cloud account (A-05) and reachable with the same credentials as production, then they are not backups: they are more files that are going to be encrypted.

Target configuration for Nimbus:

The sentence worth internalising: a backup that has never been restored is not a backup, it is a hope. The most common form of failure is not that the backup is missing: it is that the backup existed but was corrupt, incomplete, or nobody knew the procedure. Continuity and recovery time objectives are developed in 04-06.

Minimisation is the measure with the best cost/benefit ratio in this section, and it is almost never applied because it requires saying no to data that "might be useful one day". Data that does not exist does not leak, does not have to be encrypted, does not have to be audited and does not appear in a breach notification.

Note on legal implications: minimisation, pseudonymisation, retention periods and deletion carry specific regulatory requirements, especially when the data can reveal health information, as is the case with clinic diaries. The decisions must be validated with the compliance owner or with legal advice; the handling is covered in 06-03.

The API (A-04) is Nimbus's main surface. This layer shifts security to the left: to the moment the code is written, where fixing is cheap.

The four-question checklist Iván should apply on every review, already introduced in 02-02:

1. Who are you? — does the endpoint require authentication?
2. Is it yours? — is it filtered by tenant_id and is ownership of the resource verified?
3. Is what you are sending valid? — is there type and range validation?
4. How much does this cost? — is there pagination, are there limits and rate limiting?

The finding of the non-expiring token in 01-04 and the leaked .env in the chained attack of 02-02 have the same root: secrets live where they should not.

A set of instructions to the browser that takes a few minutes to configure and neutralises whole classes of attack from section 6 of 02-02.

An explanation of each one, and which attack it stops:

Details of the CSP that make the difference:

• default-src 'none' as the base. You start from "nothing allowed" and open up only what is strictly necessary. It is the secure by default principle from 01-03 applied to the browser.
• No 'unsafe-inline' and no 'unsafe-eval'. Allowing them cancels most of the CSP's value against XSS. It requires the JavaScript to be in files, not inline.
• report-uri turns the CSP into a detective control: every violation is logged. A spike in CSP reports is usually the first sign of an XSS attempt. It is best deployed first in report-only mode (Content-Security-Policy-Report-Only) so as not to break the SPA.

It has appeared in every section, and for one reason: it is the measure that takes the profit out of most automated attacks — brute force, enumeration, mass export, application-layer DDoS, business logic abuse.

The AppSec details are developed in 05-05.

This is the file Iván would add to the Nimbus repository. It is explained step by step afterwards.

The seven decisions in this file, explained:

1. permissions: contents: read. By default, many workflows receive broad permissions. Declaring the minimum stops a compromised action writing to the repository. It is least privilege (01-03) applied to CI.
2. Actions pinned by commit hash, not by @v4. A tag can be repointed at other code; a hash cannot. It is the defence against the supply chain attack of 02-02.
3. fetch-depth: 0. Without the full history, the secret scan only looks at the last commit and misses exactly what has to be found: the credential somebody uploaded and "deleted" eight months ago.
4. --strict in the dependency scan. Without it, the report gets generated and nobody reads it. With it, the build fails and a decision has to be made: update, or justify the exception in writing. An analysis that cannot block does not change behaviour.
5. -ll in the static analysis. Filtering by severity is what avoids the usual fate of these tools: 400 warnings, nobody looks at them, the tool gets switched off.
6. SBOM. When the next critical vulnerability in a famous library comes out, the question will be "does it affect us?". With an SBOM that is answered in minutes; without one, in days. It is the 01-04 inventory applied to software.
7. if: always() when storing results. The reports from the day something fails are precisely the ones you need to keep.

And a warning about what this workflow does NOT do: it does not find the IDOR, it does not find business logic abuse and it does not find an authorisation design flaw. Automated tools cover the known patterns; human judgement covers the rest. Complementary, not substitutes.

The CSF diagnosis in 02-01 was clear: Nimbus's weakest function is Detect. And without logging there is no possible detection.

The five fields every useful event must have: when (with time zone and a synchronised clock), who (a named identity, not "admin"), what (the specific action), on what (resource and tenant) and from where (IP and agent). A log with no identifiable actor is useless for investigation; a log with no resource is useless for measuring the scope.

This section is as important as the previous one, because a badly designed log creates a security problem instead of solving one.

Why this version makes detection possible and the previous one does not: the record_count field, together with session_id and tenant_id, is exactly what made the detection query in exercise 3 of 02-02 work. Detection is designed when the log is written, not when the incident happens. And the correct log contains fewer personal data than the incorrect one, not more.

1. Centralised. Logs spread across five machines cannot be correlated. What is more, an attacker who compromises a machine deletes its local logs: shipping them off the box in real time is what preserves the evidence.
2. Intact and retained. The append-only audit table from 01-01 — with INSERT but without UPDATE or DELETE for nimbus_api — is this idea in practice. Minimum advisable retention: 90 days hot, one year cold. Many breaches are discovered months later, and without logs the scope cannot be determined, which is exactly what has to be communicated to customers and authorities.
3. With alerts somebody attends to. A log with no alerts is a historical archive. Few alerts and very good ones: for Nimbus, five initial rules are enough.

The five alerts to start with tomorrow:

Monitoring and detection techniques are developed in 05-02.

Nimbus cannot do everything. This is the table that turns the catalogue into decisions. Cost is money, effort is the team's time, impact is real risk reduction.

Three observations about this table:

• Eight of the twelve measures have zero or low financial cost. What Nimbus lacks is not budget: it is decision and allocated time. It is the most repeated conclusion in SME security and the hardest one to accept.
• The only one with a real medium cost is the EDR (#12), and it comes last on purpose: without MFA, without immutable backups and without logging, an EDR is a badly placed luxury.
• None of the twelve is a perimeter security product. There is no new firewall on the list, and that is not an oversight: Nimbus's risk is not there.

Everything that can be done with no budget, no supplier and no project.

How this is sustained over time: a one-hour quarterly review looking for what is left over (01-04), one simulation per quarter, one restore test per quarter and an access recertification every six months. Four routines, all of them in the calendar. What is not scheduled does not happen.

Note: the deadlines in this plan are indicative and must be adjusted to each organisation's reality. The formal obligations of policy, documented control and auditable evidence are covered in 04-02, 04-03 and 06-04.

Common mistakes:

• Buying before closing. Acquiring a WAF or an EDR while SSH is open to the Internet is investing in the roof with the foundations unfinished.
• Relying on the WAF so as not to fix the code. The WAF buys time; it does not fix an injection and it does not see an IDOR.
• Calling something a backup when it has never been restored. The most common failure is not the absence of backups but their uselessness at the moment of truth.
• Keeping the backups in the same account and with the same credentials as production. Modern ransomware looks for them and deletes them: that is not a backup.
• Logging full request bodies. It turns the logging system into a store of tokens and personal data, and multiplies the impact of any leak.
• Generating a hundred alerts nobody looks at. Worse than having no alerts, because it produces a feeling of coverage.
• Deploying CSP straight into blocking mode. It breaks the SPA and ends up switched off forever. Report mode first.
• Leaving the CI analysis with no ability to block. A report that stops nothing changes nobody's behaviour.
• Encrypting and considering it solved. Encryption at rest does not protect against stolen credentials or against an authorisation flaw.
• Writing the plan with no owner and no date. A task with no name and no day is an intention.

Tips:

• Always start with point 3 of the table: close what is already open. Zero cost, maximum impact, and it reduces future work too.
• For every measure you put in place, write down how you would check that it is still working in six months' time. Defences degrade silently.
• Prefer what works by default over what demands daily discipline. In a 38-person company, discipline runs out; configuration stays.
• When torn between two measures, pick the one that reduces the damage of a failure over the one that tries to prevent one more failure. The first works even when you get things wrong.
• Turn every incident and every simulation into one new alert. It is the zero-cost purple team from 02-01.
• Review the phased plan with Marta every 30 days, ticking off what is done and renegotiating what is not. A plan that is not reviewed dies in phase 1.

For each of these eight attacks from lessons 02-02 and 02-03, state: the main measure that neutralises it, a second layer independent of the first, the type of control each one is (preventive, detective, corrective or deterrent) and the phase of the chain they act on.

1. Password spraying against the team's accounts.
2. SQL injection in the customer search box.
3. Ransomware that encrypts the infrastructure and deletes the backups.
4. IBAN change fraud for a supplier, sent to Sara.
5. Slow data exfiltration using a stolen token.
6. Stored XSS in the "notes" field of a booking.
7. SSRF through a clinic's logo URL.
8. A compromised third-party CI action.

This is the Nimbus API's current logging code:

Required: (a) identify the problems on each marked line and explain the specific risk of each; (b) rewrite the code with correct logging; (c) state which three alerts you could build on the corrected log and which attack each would detect; (d) explain why the correct log contains fewer personal data than the incorrect one and still allows more to be detected.

Marta gives you 6,000 € a year and one day a week of the team's time for security during the first half of the year. A salesperson has offered her a 5,500 € package that includes a next-generation firewall for the Valencia office and an antivirus for the 40 laptops.

Required:

1. Argue, with evidence from this module's lessons, why that purchase is not the best allocation of Nimbus's budget.
2. Propose your alternative allocation of the 6,000 € and of the weekly day, with concrete line items.
3. Identify the three zero-cost measures that should be done in the first two weeks, and justify the order.
4. Explain which risk you consciously accept by not spending on the perimeter, and how you would communicate it to Marta in writing.
5. Define three indicators you would present at six months to demonstrate that the investment has paid off.

Solution 1

The pattern that emerges: in all eight cases, the second layer is of a different nature from the first — if the first is in code, the second is configuration or detection. That is defence in depth properly understood: layers that do not fail for the same reason. Two layers that both depend on Iván remembering something are, in practice, a single layer.

Solution 2

(a) Problems on each line:

(b) Corrected code:

Three decisions worth commenting on:

• email_hash instead of the address on failures. It allows attempts against the same account to be correlated without accumulating a list of valid e-mail addresses in the logs. It is minimisation applied to detection.
• jti instead of the token. The jti is the token's identifier: it serves to correlate the session and to revoke it, but it does not allow anyone to be impersonated. Detailed in 02-05.
• A uniform error message. "Incorrect credentials" whether the address does not exist or the password is wrong: it avoids the user enumeration of 02-02.

(c) Three alerts you can build:

(d) Why fewer data allow more to be detected. The incorrect log accumulates content (passwords, tokens, patient names) that is no use for detecting anything: nobody builds an alert on a patient's name. The correct log accumulates structured metadata — who, what, how much, from where — which is exactly what gets queried and aggregated. The consequence is twofold and very elegant: you detect more and you reduce the impact of a leak of the logs themselves, which stop being a valuable target. Logging well is simultaneously a detection improvement and a data protection measure.

Solution 3

1. Why the proposed purchase is not the best allocation. Four arguments, backed by the module:

• It does not attack Nimbus's real risk. The main surface is the API in the cloud and identities, not the Valencia office network. An NGFW in the office protects neither the 19 remote employees, nor the cloud account (A-05), nor the API, nor the buckets.
• A signature-based antivirus does not cover what actually happens. Look back at the myth 2 table in 02-01: it does not stop credential phishing, nor the IDOR, nor the misconfigured bucket, nor the consultancy's credential without MFA, nor CEO fraud.
• It consumes 92 % of the budget, leaving measures 1 to 8 of the table in section 7 unfunded — the ones with very high impact and low or zero cost.
• Nimbus has known, unresolved problems today — open SSH, Redis without authentication, a permanent token, untested backups, zero detection — that neither piece of the package fixes. Spending on what is missing before closing what is open is the mistake from the common mistakes section.

2. Alternative allocation:

The weekly day is allocated as follows: the whole of phase 1 in the first four weeks (all zero cost), then alternating implementation (logging, alerts, CI) with routine (reviewing alerts, patching, the quarterly review of what is left over).

3. The three zero-cost measures for the first two weeks, in order:

1. Close the exposed surface (SSH 0.0.0.0/0, Redis without authentication, http.server, node_exporter, snmpd). It goes first because it is exploitable right now by a bot without anybody deciding to attack Nimbus: it is active risk, not potential risk.
2. MFA on all administrative accounts, including the consultancy's. It goes second because it neutralises spraying, stuffing and most credential phishing in one stroke, and that is the dominant vector.
3. Rotate the permanent token and put an expiry on every token. It goes third because it closes link 2 of the chained attack in 02-02, and because a leaked token makes MFA irrelevant.

4. The risk accepted and how to communicate it. By not investing in the office perimeter, a residual risk on the Valencia local network is accepted: a compromised device in the office would have more freedom of movement than is desirable. It is partly mitigated at no cost with segmentation on the existing router (guests isolated, data zone closed) and with EDR on the laptops.

The communication to Marta must be written, explicit and dated:

"Accepted risk (date, review in 6 months): the Valencia office perimeter will not be reinforced this half-year. Reason: 100 % of customer data is in the cloud and half the headcount works outside the office, so the physical perimeter is not the main vector. Mitigation applied: segmentation with the current equipment, EDR on every laptop and disk encryption. To be reviewed if the architecture changes or if the office headcount grows. Approved by: Marta Solves."

This is not bureaucracy: it is the difference between accepting a risk (a conscious, documented, reviewable decision) and ignoring it (which is what gets discovered after an incident). The formalisation of this process is studied in 04-01.

5. Three indicators at six months:

A fourth, very visual indicator for management: the number of services exposed to the Internet, which should fall from six to one in the first month. It is the one that communicates progress best to somebody non-technical.

You have the catalogue of the response. You have learned first the method for choosing: which specific attack each measure neutralises, which phase of the chain it acts on, what type of control it is — preventive, detective, corrective or deterrent — and whether it will survive a bad day in a 38-person company. In perimeter and network you have seen the types of firewall and the precision that avoids the most expensive mistake: a WAF buys time and gives visibility, but it does not fix code and does not see an IDOR; you have understood segmentation as the most cost-effective measure against lateral movement, the dual nature of anti-DDoS defence — volumetric, which is bought in, and application-layer, which is programmed — and the evolution of remote access from the all-or-nothing VPN towards just-in-time access with an expiry. In endpoint you have distinguished antivirus from EDR by what really separates them — behaviour, telemetry and the ability to isolate — and you have put patching in its place: the least glamorous measure and one of those that would have prevented the most serious incidents.

In data protection you take away three ideas that hold everything else up: that encryption at rest does not protect against valid credentials and that the key is the real asset; that the 3-2-1 rule extended with immutability and a restore test is the only defence that gives the business back when everything has failed, because modern ransomware seeks out and deletes the backups; and that minimisation is the measure with the best cost/benefit ratio, because what does not exist does not leak. In application and development life cycle you have worked through code review with its four questions, secrets management with its rule of rotating first and investigating afterwards, HTTP headers with a CSP built from default-src 'none', rate limiting as the universal profit-remover, and a real CI workflow whose seven decisions — minimal permissions, actions pinned by hash, full history, an analysis that blocks, filtering by severity, SBOM and preserving the reports — turn a decorative report into an effective control.

In logging and observability you have learned what to log, with its five essential fields, and above all what must never be logged; and you have confirmed in the exercise the most counter-intuitive conclusion of the lesson: the correct log contains fewer personal data than the incorrect one and allows far more to be detected, because detection is built on structured metadata, not on content. And you have finished with the most useful thing for an SME: the twelve highest-return measures — eight of them with zero or low financial cost, none of them a perimeter product — and a 30, 90 and 180-day plan with an owner and a verification for every task, sustained by four quarterly routines in the calendar.

Of those twelve measures, number one was MFA, and several of the rest revolve around the same thing: who you are and what you can do. That is no coincidence. When the perimeter blurs — cloud, remote working, third parties, mobiles — identity becomes the new perimeter. In the next lesson, Identity, Authentication and Access Control (02-05), we will study it in depth: the life cycle of an identity and orphaned accounts, what the current guidance says about passwords, the forms of MFA ordered by phishing resistance, SSO and the identity protocols with the exact difference between OAuth 2.0 and OpenID Connect, sessions and JWTs with their correct validation as against the naive one, the DAC, MAC, RBAC, ABAC and ReBAC authorisation models with Nimbus's concrete design, and privileged accounts, just-in-time access and recertification.