We closed the previous module with a map of the terrain at Nimbus Reservas: an inventory of 22 assets, an attack surface measured across five dimensions, the actors who might attack it and a first STRIDE model of its architecture. Now we enter the conflict. But before touring attacks and defences it is worth marking out the field: what cybersecurity is exactly, what it covers, how the discipline is organised and who does what. Without that map, security turns into a disorderly collection of measures — antivirus here, a firewall there — with no way of knowing what is missing. This lesson gives you the structure: the domains the work divides into, the frameworks that organise it (with the NIST Cybersecurity Framework as the backbone), the industry's roles and teams and how they translate into a 38-person company, and the life cycle of an attack, which will be the skeleton on which the next five lessons are built.

1. What cybersecurity is and how it differs from information security
2. The domains of cybersecurity and who owns them in an SME
3. Frameworks: the NIST Cybersecurity Framework
4. Other frameworks on the map: ISO/IEC 27001, CIS Controls and MITRE ATT&CK
5. Roles and teams: Blue Team, Red Team, Purple Team, SOC and CSIRT
6. The life cycle of an attack: Cyber Kill Chain and ATT&CK
7. What cybersecurity is NOT: three expensive myths
8. The map of module 2

In lesson 01-01 we established the distinction between the three terms and settled it; here we simply pick it up again to place the focus of this module.

The word that defines cybersecurity is adversary. Information security also deals with accidents, mistakes and natural disasters. Cybersecurity deals specifically with someone — a person or an automated programme — who wants something to go wrong and who adapts when you put a barrier in the way.

That difference has an enormous practical consequence:

• A disk fault does not change strategy when you add RAID. An attacker does change vector when you close a port.
• That is why cybersecurity is adversarial and evolving: it is not a state you reach, it is a continuous contest against an intelligent opponent who is also learning. This is the "continuous cycle" idea from 01-01, now with a name attached.

In professional practice the three terms are used as synonyms and nobody is going to correct you. What matters is not the vocabulary but leaving no gaps: if Nimbus only thinks about "cybersecurity" understood as systems, it will forget the printed payroll sheet on the desk and the data Rubén dictates over the phone to someone claiming to be a clinic's administrator. This module concentrates on the adversary; paper and the telephone also appear, because the adversary uses them.

The discipline divides into domains: areas of work with their own techniques, tools and professional profiles. In a large company each domain is a team; at Nimbus, with 38 people, each domain is a responsibility assigned to someone who also does other things. That is the realistic translation, and it is what the last column gives.

Three readings of this table that matter more than the table itself:

1. All the names repeat. Lucía appears in five domains. That is not a flaw in the example: it is the reality of an SME and it is itself a risk — the one you already identified as A-21, "Lucía's operational knowledge". The answer is not to hire ten specialists but to prioritise, automate and document so that the knowledge does not live in a single head.
2. No domain can be empty. If nobody is assigned the human factor, nobody designs the defence against the vector most incidents come through. A domain without an owner is a domain without a defence; it is the owner rule from the 01-04 inventory, now applied to functions rather than assets.
3. Domains overlap, and that overlap is where things get lost. Who reviews the IAM permissions on the attachments bucket: the cloud person or the identity person? At Nimbus they are the same person, but as soon as it grows the choice will have to be made explicitly. Breaches usually happen at the seams between domains, not in the middle of any of them.

A framework is a structure that organises security work so that you can answer two uncomfortable questions: what are we missing? and where do we start? Without a framework, security advances in bursts: you buy whatever a salesperson pitched well or whatever frightened you in the news.

The NIST Cybersecurity Framework (CSF), in its 2.0 version, is the most useful place to start because it is not a product list nor a certification: it is a description of the functions any organisation must cover, whatever its size.

The six functions, with the question each one answers and its real state at Nimbus:

Why this framework is so valuable for an SME: the table above, done in an hour on a whiteboard, is already a diagnosis. Nimbus discovers that its weakness is not where it thought — "we need a better firewall", which would be Protect — but in Detect, Respond and Govern. And those are precisely the functions almost no product sells you, because they are not bought: they are organised.

The most common misallocation. Organisations concentrate 90 % of the effort on Protect because that is what comes in product form. But the "assume breach" principle from 01-03 says protection will fail at some point; when it does, the only thing that reduces the damage is how well you detect, respond and recover. A team that detects in 20 minutes and contains in an hour suffers an incident. One that detects after three months suffers a breach.

Note: version 2.0 of the CSF added the Govern function precisely because experience showed that failures are rarely technical at their root: they are failures of decision, of assignment of responsibility, or of oversight of third parties. The regulatory and certification detail is covered in 06-02; here we keep to the map.

There is no single framework, and they do not compete with each other: they answer different questions. Knowing which one serves which purpose saves months spent applying the wrong one.

How they combine in practice, which is what almost never gets explained:

• The CSF tells you which functions to cover → it is the table of contents.
• The CIS Controls tell you what to do first → they are the task list. Their "Implementation Group 1" (IG1) is designed exactly for organisations of Nimbus's size, with limited resources.
• ATT&CK tells you what to check it against → it is the exam. Each technique in the catalogue is a question: "if this happened here, would we see it?".
• ISO 27001 tells you how to prove it → it is the certificate you show a customer.

For Nimbus today, the sensible answer is: diagnose with the CSF, execute with CIS IG1, verify with ATT&CK, and ISO when the market asks for it. Chasing certification before you have the basics is building the roof before the foundations — and it is expensive too.

The vocabulary of teams comes from the military world and appears constantly in the literature and in job adverts. It is worth understanding, and above all it is worth understanding how it translates when you do not have teams.

Two distinctions that are often confused:

• Red Team ≠ penetration test. A penetration test aims to find as many vulnerabilities as possible within a bounded scope and with the organisation forewarned. A red team exercise aims to reach a specific objective ("get to the customer database") while imitating a real adversary, and it assesses both the defences and the detection capability. Developed in 05-03.
• SOC ≠ CSIRT. The SOC watches and detects; the CSIRT responds once an incident is confirmed. In a small company they are the same person, but the separation of functions is still useful, because watching and responding demand opposite mental states: one is sustained routine, the other is crisis.

Nimbus does not have and will not have a SOC. And it does not need one. What it does need is that none of the five functions is at zero. The realistic translation:

The small-team rule: with limited resources, the priority is not to do many things badly but to pick a few and really do them. Ten alerts nobody looks at are worth less than two somebody always attends to. Five policies that are not applied are worth less than one that is.

This section is the most important in the lesson, because it structures the whole module. A real attack is not an instantaneous event: it is a sequence of phases, and that sequence is good news for the defender. If the attacker has to chain seven steps together and you break one, the attack does not complete its objective.

The Cyber Kill Chain, formulated by Lockheed Martin, describes seven phases:

Which defence corresponds to each phase, which is what the model is for:

The three ideas to take away:

1. The defence does not have to be perfect at every phase; it has to work at one. This is exactly the defence in depth of 01-03, now seen along the axis of time instead of the axis of layers.
2. The earlier you break the chain, the cheaper it is. Closing a port (phase 3) takes five minutes. Responding to an exfiltration (phase 7) takes months, money and customers.
3. Detection matters in every phase, not just the last one. Every phase leaves signals. Nimbus's problem is not that there are no signals: it is that nobody looks at them.

The Kill Chain is a linear, simple model, ideal for explaining. It has two limitations: real attacks are not strictly linear (attackers go back and iterate) and the model falls short on everything that happens once inside. That is where MITRE ATT&CK comes in, a catalogue of tactics (the why) and techniques (the how) observed in real incidents.

Notice the imbalance: the last phase of the Kill Chain expands into six ATT&CK tactics. That reflects reality: most of an attacker's work happens after getting in — discovering the network, stealing credentials, moving laterally, collecting data — and it usually lasts days or weeks. That is precisely the window in which a defender with good detection can still win.

The practical use of ATT&CK for Nimbus is not to memorise it but to use it as a detection checklist: take ten techniques relevant to its environment and ask, one by one, "if this happened today, would we see it in any log?". Developed in 05-02.

Myths are not innocent: each one translates into a specific decision that leaves a specific gap.

Why it is false. Look back over module 1: information classification is decided by whoever knows the business, not by whoever administers the server. Verifying a transfer is Sara's job. Whoever spots an odd e-mail is any one of the 38. Whoever decides whether a risk is accepted is Marta.

Consequence of believing it. If Lucía is "the person responsible for security", Sara does not feel responsible for verifying a bank account by phone, and Iván does not feel responsible for validating inputs. Security ends up in the hands of a person who does not control most of the points of failure.

Correct formulation: IT and security are enablers and coordinators; responsibility is distributed and accountability sits with management. That is the CSF's Govern function.

Why it is false. Both are useful controls, and neither covers what happens most:

Consequence of believing it. Product is bought and the problem is declared solved. But the three functions Nimbus is missing most — Govern, Detect, Respond — cannot be bought.

Correct formulation: tools are necessary and not sufficient. The healthy proportion in an SME is roughly one third tools, one third configuration and process, one third people.

We already took this one apart in 01-04 with the chain of the opportunistic attack. Here we add the four arguments that close it for good:

1. Scanning is mass-scale, cheap and continuous. Scanning the entire IPv4 address space for a particular port is a matter of hours and a ridiculous cost. A freshly assigned public IP starts receiving automated probes within minutes. Nobody decided to attack Nimbus: a programme found a port.
2. The economics favour the small. A large company has a security team, a budget and detection. An SME has valuable data, total dependence on its systems and far fewer defences. For a ransomware group operating at scale, a hundred small, poorly defended victims are better business than one large, well-defended one.
3. SMEs are the way in to the large ones. Nimbus serves clinics and academies, and a consultancy has remote access. An attacker who wants to reach a particular customer can come in through the supplier. It is the supply chain pattern we will analyse in 02-06 with real cases.
4. The relative impact is greater. A large company absorbs a three-day outage. Nimbus, with a SaaS that clinics' live diaries depend on, cannot: every hour of downtime means clinics that cannot see patients and contracts that do not get renewed.

Conclusion of myth 3: the right question is not "are we interesting?" but "are we reachable and exploitable?". The first question is answered by ego; the second, by a scanner.

With the vocabulary and the models now in place, this is the route through the five lessons ahead, articulated around the Kill Chain:

• 02-02 works through the technical attacks ordered by phase of the chain.
• 02-03 stops at social engineering, which is the dominant delivery phase in real incidents.
• 02-04 presents the catalogue of defences that counters all of the above, layer by layer.
• 02-05 goes deeper into identity and access control, because when the perimeter blurs, identity is the new perimeter.
• 02-06 analyses real incidents and closes with a complete Nimbus case.

Common mistakes:

• Adopting a whole framework in one go. Trying to implement the 18 CIS controls or to get ISO 27001 certified within a quarter guarantees you will give up. Frameworks are used in parts and iteratively.
• Confusing a framework with a product. No vendor "gives you" the NIST CSF. The framework organises your work; tools cover specific parts of it.
• Concentrating all the effort on Protect. It is the most common allocation and the most unbalanced. Detect and Respond are the functions that decide how big the damage is.
• Copying a large company's org chart. Nimbus does not need a SOC or a full-time CISO; it needs the functions to have owners, even if the owner does three other things.
• Using the Kill Chain as if it were linear and strict. Attackers iterate, go backwards and skip phases. The model is a reasoning tool, not a literal description.
• Believing ATT&CK has to be learned by heart. It is a reference catalogue. It is used for specific techniques relevant to your environment, not from memory.
• Treating the myths as somebody else's ignorance. The myths survive because they are comfortable: they let you avoid spending, avoid changing processes and avoid taking responsibility.

Tips:

• Build the table in section 3 for your real organisation, with the six functions and an "honest situation" column. It is the best diagnosis per hour invested that exists.
• Assign a named owner to each domain in section 2, even if it is the same person for several. A domain without a name attached is a domain without a defence.
• When you evaluate a new measure, ask yourself which phase of the chain it acts on. If all your measures act on the same phase, you have a thick, brittle defence.
• Book security time in the calendar, not in your intentions. What is not scheduled does not happen in a 38-person company.
• Start reading ATT&CK with a single tactic — Initial Access — and compare it with the attack surface you measured in 01-04.

Using everything accumulated in module 1 (inventory A-01…A-22, discovery findings, STRIDE modelling), place each of these seven facts in the CSF function it affects, state whether it is a gap or a strength, and propose one concrete improvement action.

1. The python -m http.server had been running for 94 days and nobody noticed.
2. The nimbus_api role has no DELETE permission and no access to the payroll table.
3. Backups of the nimbus-backups-prod bucket exist, but a full restore has never been tested.
4. Nobody knows who should be called if the servers are encrypted at three in the morning.
5. The external consultancy has permanent administrative remote access, with no expiry date and no contract detailing what it may do.
6. Attachments are served through signed URLs that expire after 120 seconds.
7. The security group had port 22 open to 0.0.0.0/0 and it was found by chance while reviewing the inventory.

Marta asks you to propose a formal allocation of security responsibilities among the five people in the management and technical team (Marta, Iván, Lucía, Rubén and Sara), knowing that nobody can devote more than 10 % of their time to security. For each of the ten domains in section 2, state: the main owner, what they would concretely do in their 10 % and what is outsourced.

Also justify a hard decision: who should be ultimately responsible for security at Nimbus, and why?

An attacker runs the following sequence against Nimbus:

1. Finds, in a public GitHub repository, an old configuration file uploaded by mistake, containing the name of the internal subdomain admin-old.nimbusreservas.example.
2. Checks that the subdomain still resolves and that it serves an obsolete administration panel with no MFA.
3. Tries against it a list of passwords leaked from other breaches, together with team e-mail addresses found on public professional profiles.
4. Gets in with the old account of an employee who left a year ago and whom nobody deactivated.
5. From that panel, extracts an API token with broad permissions.
6. Uses the token against the production API to export customer data over three weeks, in small batches.

Required: (a) assign each step to its Kill Chain phase; (b) for each step, give one measure that would have broken it; (c) point out at which step it would have been cheapest to break and at which it would have been most likely to be detected.

Solution 1

Reading the set as a whole: both strengths are in Protect, and the serious gaps are in Detect, Respond and Govern. Nimbus is a textbook case of the imbalance described in section 3: it knows how to build defences, but it does not know whether they are working or what to do when they fail.

Solution 2

The hard decision. Ultimate responsibility should sit with Marta (CTO), not Lucía, for three reasons: (a) security involves accepting risks, and accepting a risk is a business decision that requires authority, not technical knowledge; (b) if the person responsible is the one who administers the systems, they are judging themselves — that breaks the separation of duties from 01-03; (c) the most important outstanding decisions (the consultancy's contract, budget, policy, customer communication) are not technical. Lucía is the operational owner; Marta, the ultimately accountable one. And it is worth writing down, because a responsibility that is not written down dissolves as soon as there is delivery pressure.

Solution 3

(c) Where to break it:

• Cheapest: step 2. Deleting an obsolete DNS record takes a minute and needs no tooling at all. Without that subdomain, steps 3 to 6 do not exist. It is the perfect illustration of why reducing surface is the most cost-effective investment.
• Most likely to be detected: steps 3 and 6. A burst of failed authentication attempts against a panel is a very visible signal in any log; so is a sustained, anomalous export over three weeks, if somebody looks. The fact that the attack lasted three weeks does not indicate a sophisticated attacker: it indicates the absence of the Detect function.

Final observation: none of the six steps requires a software vulnerability or an exploit. The whole attack rests on hygiene: a file uploaded by mistake, a forgotten subdomain, reused passwords, a badly executed leaver process and a permanent token. That is the usual shape of real incidents, and the reason the basics pay off disproportionately.

You now know what ground you are standing on. Cybersecurity is distinguished by its object: an adversary who adapts, and hence a discipline that is adversarial and evolving rather than a state you reach. You have seen that it is organised into domains — networks, applications, data, identity, operations, cloud, physical, human factor, continuity and governance — and that in a 38-person company each domain is not a team but a responsibility with a name attached; what must not happen is for a domain to be left without an owner. The NIST Cybersecurity Framework has given you the table of contents with its six functions — Govern, Identify, Protect, Detect, Respond and Recover — and, applied to Nimbus, it has produced an uncomfortable but useful diagnosis: what is missing is not better defences but the ability to know whether they are working and to react when they fail. Alongside it you have placed CIS Controls as the task list, ATT&CK as the detection exam and ISO 27001 as the proof you show third parties.

You have learned the vocabulary of teams — Blue, Red, Purple, SOC and CSIRT — and, more importantly, its realistic translation: you do not need an operations centre, you need none of those functions to be at zero. And you have taken on board the model that structures everything that follows: the life cycle of an attack, with its seven Kill Chain phases and its mapping to the ATT&CK tactics, together with the idea that makes it valuable for the defender: you do not need to win at every phase, breaking one is enough, and the earlier you break it, the cheaper it is. Finally you have dismantled the three myths that leave specific gaps: that security is IT's job, that an antivirus and a firewall are enough, and that nobody attacks a small company — when the right question is not whether you are interesting, but whether you are reachable.

With the map complete, it is time to look closely at the adversary. In the next lesson, Types of Cyber Attacks (02-02), we will work through the technical attacks ordered by the phases of the chain you have just learned: reconnaissance, network attacks, credential attacks, the ten most frequent web application flaws — including the IDOR you already fixed in 01-01 — ransomware with double extortion, supply chain and API abuse. Each one with its minimal example on the Nimbus architecture, its detection signal and the defence that neutralises it.