The three previous lessons have given you the vocabulary, the catalogue of threats and the design principles. All of that is inapplicable until you answer a prosaic question: what exactly does Nimbus Reservas have? You cannot protect what you do not know exists, you cannot reduce a surface you have not measured, and you cannot prioritise without knowing who might attack you and with what means. This lesson closes the module by building those three pieces — asset inventory, attack surface and threat actors — and joins them with a first analysis tool: STRIDE applied to a data flow diagram of the Nimbus architecture itself. By the end you will have the complete picture of the terrain we will be working on across the remaining six modules.

1. What an asset is and why the inventory is control number one
2. Types of asset and the Nimbus Reservas inventory
3. Information classification: public, internal, confidential, restricted
4. Discovering what you already have: technical inventory with system tools
5. The attack surface and its five dimensions
6. Techniques for reducing the surface
7. Threat actors: who, why and with what capability
8. A practical introduction to threat modelling with STRIDE
9. Closing the module

An asset is any element that has value for the organisation and that therefore deserves protection.

The key word is value, and value is not only financial. A log file is not worth money, but without it Nimbus cannot investigate an incident or prove what happened: its value is evidential. Reputation appears on no balance sheet, but it is what makes a clinic renew the contract.

Why the inventory comes first in every serious list of controls:

• You cannot protect what you do not know exists. The test server Iván spun up eight months ago "for a demo", with a copy of real data and unpatched ever since, is on no list. It is exactly what an automated scan finds.
• You cannot prioritise without criticality. If every system looks equally important, they all get protected equally badly.
• You cannot respond to an incident without knowing what is there. The first question in a breach is "what data could they have accessed?". Without an inventory, the honest answer is "we don't know", which in front of a customer or a regulator is the worst possible answer.
• You cannot apply any patch with confidence. When the CVE from lesson 01-02 comes out, the question "does it affect us?" is only answered quickly with an inventory.

An uncomfortable fact from the industry: in most significant SME breaches, the entry point was an asset the organisation had forgotten it had. An old subdomain, a test environment, a former employee's account, a disconnected integration with a live credential.

The four fields that turn a list into a useful inventory:

Assets are not just servers. A practical classification distinguishes six types:

The last two are systematically forgotten and they are decisive. Lucía is an asset: she is the only person who knows how to restore the complete infrastructure. If Lucía leaves or is unreachable during an incident, Nimbus has an availability problem as real as a server going down. And reputation is an asset: most of the financial damage of a breach in a SaaS business does not come from the fine, it comes from the customers who do not renew.

Three observations about this table that are worth more than the table itself:

1. A-05 (the cloud provider account) is the asset almost every other one depends on. Compromising that account cancels most of the controls simultaneously. In the language of lesson 01-03: it is the point that brings down several defensive layers at once, and that is why it deserves disproportionate protection.
2. A-19 (the consultancy's access) has critical criticality and Marta as owner, not Lucía. That is deliberate: the risk of that asset is contractual and governance-related, not technical. It is developed in 04-04.
3. A-22 appears with a classification of "to be reviewed". That is honest and it is what usually happens: nobody is sure whether pre-production holds real data. An inventory that reflects the doubts is more useful than one that hides them; that cell is, in fact, the first security task of the week.

How an inventory is kept alive. The inventory is not a document, it is a process. Three practical rules: (a) define the infrastructure as code, so that the repository is the inventory; (b) require an owner and a classification for any new asset from day one; (c) a short quarterly review looking specifically for what is surplus — accounts, environments, integrations and subdomains that are no longer in use.

Classifying means deciding how much protection each piece of data deserves. Without classification, either everything gets maximum protection (expensive, unsustainable and counter-productive) or nothing gets it consistently.

Four levels are enough for a company like Nimbus. More levels do not add precision: they add confusion.

Rule 1: classification is inherited upwards. A file containing a single restricted item is restricted. An aggregate report mixing internal and confidential data is confidential. Sets take the classification of their most sensitive element.

Rule 2: aggregation can raise the level. The history of a single appointment is a restricted item. The complete table of 400,000 physiotherapy clinic appointments is qualitatively worse: it does not merely add up, it becomes a map of people with medical complaints. That change of nature is what makes mass exports deserve controls of their own (you designed them in exercise 3 of the previous lesson).

Rule 3: context defines sensitivity. "Ana Ruiz, 15/03, 17:00" looks innocuous. In the diary of a rehabilitation clinic it indirectly reveals health data. Nimbus cannot say "I only manage diaries": it manages diaries whose content is, by context, sensitive.

Note on legal implications: the category of "data that reveals health information" and the associated obligations (lawful bases, reinforced measures, impact assessments) have a specific regulatory treatment that is addressed in lesson 06-03. The concrete categorisation of your organisation's data must be validated with your compliance lead or with a legal professional.

An information asset that is no longer needed stops being an asset and becomes purely a risk liability. The CSVs Rubén generated a year ago, the database dumps on Iván's laptop, the five-year-old backups: they add zero value and all the risk. The retention policy — how long each thing is kept and when it is destroyed — is part of classification, not an appendix.

The documented inventory is always checked against reality, because reality always holds surprises. Let us start with asset A-01: the database server.

Important: every command in this lesson is run against systems Nimbus owns, with authorisation. Scanning somebody else's systems without express permission is illegal; the ethics and legal framework of these activities are covered in 06-06.

Anatomy of the command, option by option:

Output on the Nimbus database server:

How to read this, line by line:

• Lines 1 and 2 (postgres, port 5432): it listens on 127.0.0.1 (the machine itself only) and on 10.0.2.15 (the private VPC IP). This is correct: 0.0.0.0 does not appear, so it is not listening on public interfaces. Compare it with the finding in lesson 01-02, where it was.
• Line 3 (sshd, port 22): it listens on 0.0.0.0, that is, on all interfaces. Here you have to look at the second layer: even if the system listens on all of them, the provider's security group can restrict the source. If it does not, this is a finding: administrative access should only arrive via a bastion host or a VPN.
• Line 4 (node_exporter, port 9100): monitoring metrics, listening on all interfaces. It exposes detailed system information with no authentication. A typical and very frequent finding: it is installed for monitoring and nobody restricts it.
• Line 5 (python, port 8000): what is a Python process doing listening on the database server? This is exactly the kind of surprise that justifies the exercise. It could be an old demo script, a forgotten development server or something worse. It requires immediate investigation.
• Line 6 (systemd-resolve, port 53 on 127.0.0.53): the local DNS resolver. Local only: correct.

The golden rule for reading this output: look at the local address first, not at the port. 127.0.0.1 is local only (no exposure). A private IP (10.x, 192.168.x, 172.16-31.x) is internal exposure. 0.0.0.0 or :: means all interfaces, and that is where the work begins.

Translation: Iván spun up a static HTTP server on the day of a demo and it has been running for 94 days, serving the contents of /var/tmp/demo to anybody who reaches port 8000. It is an uninventoried asset, with no declared owner, unpatched and with unknown content. In lesson 01-02 we would call it a configuration vulnerability; here it is what illustrates why the inventory is control number one.

The system is only half the story. The other half is the provider's firewall:

The complete diagnosis only appears when you cross the two layers. Port 5432 was listening on the private IP and is also restricted to the VPC: two correct layers. Port 22, by contrast, listens on all interfaces and is open to 0.0.0.0/0: any bot on the Internet can try to authenticate against the SSH of the Nimbus database. That is a high-priority finding.

Specialised discovery and scanning tools are covered in 05-01 and 05-03; what matters here is the method: look at your own systems first, with what you already have installed.

The attack surface is the set of all the points through which an attacker could try to get in, extract data or affect the system.

It is a measurable and reducible property, and that is the good news: unlike threats, the surface is under your control. Every point you eliminate is a point that never has to be defended, monitored or patched again.

The surface is not static: it breathes. Every deployment by Iván can add endpoints. Every hire adds a person. Every new integration adds a third party. That is why it is measured continually and not once a year.

Exposed surface ≠ total surface. Three things need distinguishing:

• External surface: what is reachable from the Internet without credentials. It is the most urgent, because anybody in the world can touch it.
• Authenticated surface: what is reachable with a valid account (including a free trial account, if there is one).
• Internal surface: what is reachable after the first compromise. This is what determines how far an incident spreads.

Nimbus tends to look only at the first. But remember the "assume breach" principle from the previous lesson: the internal surface is what decides whether a compromised laptop ends up as an anecdote or as ransomware across the whole infrastructure.

Reducing the surface is, by a wide margin, the cheapest way of improving security: what does not exist cannot be attacked, does not have to be patched, does not have to be monitored and does not turn up in the next audit.

What has been reduced and why it matters:

• A two-stage build: the compilers and the installation tools stay in the first stage and never reach production. An attacker cannot compile anything.
• A distroless image: there is no sh, no bash, no curl, no apt. Many post-exploitation techniques assume a shell is available; here, quite simply, there is not one.
• USER 10001: the process does not run as root. Arbitrary code execution does not grant control of the container.
• A valuable side effect: fewer packages means fewer CVEs to review every week. Reducing the surface also reduces the maintenance workload.

The details of container security are developed in 05-07; here it is enough to see the principle in action.

A threat actor is whoever turns a threat into reality. Knowing them matters because motivation determines the objective and capability determines how far they can go — and both decide where you invest.

This is the most important point in this section, because it corrects the most expensive mental error in an SME: "nobody is going to attack us, we're not interesting".

The premise is false because the opportunistic attacker does not choose victims: they find systems. The process is entirely automated:

Nothing in this chain requires anybody to have heard of Nimbus. Three practical consequences:

1. Exposure weighs more than appeal. What decides whether you get compromised is not how interesting you are, but whether you have something open and unpatched. That SSH on 0.0.0.0/0 from section 4.3 receives authentication attempts every few minutes, every day, without anybody knowing what Nimbus is.
2. Basic controls pay off disproportionately. Patching, closing what is not used, MFA on every administrative account and backups out of reach neutralise the vast majority of these actors. You do not need a security operations centre to defend yourself from a bot.
3. Initial access gets resold. There are brokers who compromise systems and sell the access on to ransomware groups. That is why "they only mined some cryptocurrency, it's not serious" is a dangerous conclusion: whoever got in may have left a door open, and whoever uses it next may have other plans.

Against an APT, the honest conclusion is different: if a group with state resources decided to attack Nimbus specifically, Nimbus cannot stop it. What it can do is detect and limit the reach, which is exactly the "assume breach" approach from lesson 01-03. And there is a relevant nuance: Nimbus could be an intermediate target — not for its data, but for being a supplier to others. Supply chain attacks turn small companies into bridges towards large ones.

Threat modelling is a structured exercise for answering, against a concrete design: what can go wrong here? It is done before building (security by design) or when reviewing what exists, and it requires no tooling: a diagram and a method are enough.

STRIDE is the most widely used method for getting started. It is a list of six threat categories, each associated with the security property it violates:

You will recognise all six: they are the properties from lesson 01-01 seen from the attacker's side. That is the whole trick of STRIDE — it turns a list of properties into a list of questions.

Modelling is done against a diagram, not against the whole application. A DFD has four elements: external entities (actors outside your control), processes (your code), data stores and flows. And a fifth element that is where nearly all the value of the exercise lives: the trust boundaries, lines separating zones with different levels of trust.

How to draw a useful DFD (this will help you with the exercise):

1. Start with the external entities: everything you do not control. That is where the unexpected enters.
2. Add your processes and data stores.
3. Draw the flows and number them: the numbers let you enumerate threats in an orderly way and not forget any.
4. Draw the trust boundaries. Rule of thumb: every time data crosses a boundary, it has to be analysed. That is where the threats concentrate.
5. Do not draw the whole company. A DFD of one specific flow, done well, is worth more than a giant diagram nobody looks at.

You walk through the diagram element by element asking the six questions. An extract from the Nimbus analysis:

Three rules for making the exercise productive:

• Do not hunt for all six letters in every element. Some do not apply. That is normal and it is not a failure of the method.
• Prioritise the boundaries. The flows that cross a trust line (F1, F2, F8, F11) concentrate the most relevant threats.
• Every threat must end in a decision: mitigate, accept, transfer or eliminate. A modelling exercise that produces a pretty list and no decisions has achieved nothing. Formalising those decisions — with likelihood, impact and a matrix — is done in 04-01.

This is the point at which the four lessons come together:

You have the map of the terrain. From here on, each module goes deeper into one part: how attacks work and how to defend against them (2), how information is protected with mathematics (3), how risk is managed and incidents are answered (4), what tools are used (5), what regulation requires (6) and how to apply it all to a complete case (7).

Common mistakes:

• Confusing an inventory with a list of servers. The inventory includes data, SaaS services, domains, people and third parties. The assets that are not servers are the ones most often forgotten and the ones that cause the most incidents.
• Doing the inventory once. An inventory from a year ago describes a company that no longer exists.
• Inventorying with no owner. An asset with no responsible person does not get patched, does not get classified and does not get retired. If you had to pick a single field, pick owner.
• Classifying everything as confidential. If everything is confidential, nothing is: the team stops distinguishing and treats everything with the same (low) care.
• Forgetting the internal surface. Many organisations measure themselves only from the outside. The internal surface is what determines the reach of a compromise.
• Believing "we're not a target". Opportunistic attacks do not choose; they find. It is the most expensive reasoning error in an SME.
• Threat modelling with no trust boundaries. A DFD with no boundaries turns the exercise into a pretty drawing. The boundaries are where the threats are.
• Finishing the modelling with no decisions. A list of threats with no assigned mitigation and no owner changes nothing.

Tips:

• Start the inventory with what faces the Internet and with what holds restricted data. That already covers the bulk of the risk.
• Spend one hour per quarter exclusively on looking for what is surplus: subdomains, environments, accounts, integrations and unused credentials. It is the most profitable security hour of the quarter.
• When you review a server, always cross-check two layers: what the system is listening on (ss) and what the provider's firewall allows. A single layer gives a false diagnosis.
• Do your first STRIDE modelling on a single flow — the booking one, for instance — and finish it. A small, completed model teaches more than an ambitious, abandoned one.
• Keep the DFD next to the code, in the repository. That way it gets updated when the architecture changes and does not become a dead document.

During a review, five Nimbus assets turn up that were not in the table in section 2.1. For each one, state: type, reasonable owner, criticality, classification and one immediate action.

1. The server demo.nimbusreservas.example, spun up 94 days ago by Iván, serving static files on port 8000 from the database server.
2. A spreadsheet shared by Sara with the names, DNI numbers, salaries and bank accounts of the 38 employees, in a cloud folder with an "anyone with the link can view" share.
3. A GitHub service account named nimbus-deploy-bot with a personal token that has no expiry and write permissions on every repository.
4. A NAS in the Valencia office where the databases used to be copied until two years ago; it is still switched on and nobody remembers the administration password.
5. The WhatsApp group "Nimbus Urgent Support", where Rubén shares screenshots of customer issues.

This is the result of sudo ss -tulpn on the Nimbus application server. For each line, state whether it is acceptable or not, what risk it introduces and what concrete surface-reduction action you would apply.

Nimbus is going to launch a new feature: SMS reminders. The flow is:

1. Clinic staff enable reminders from the web panel.
2. A worker queries PostgreSQL every hour for the appointments in the next 24 hours.
3. For each appointment, it calls the API of a new SMS provider (a third party) sending the patient's phone number and a text with the date, the time and the name of the service ("Knee rehabilitation").
4. The provider returns a message identifier which is stored in the sms_messages table.
5. The provider sends a webhook to the Nimbus API when the SMS is delivered or fails.

You are asked to: (a) draw the DFD in mermaid with its trust boundaries; (b) identify at least one threat for each letter of STRIDE, stating the affected element or flow; (c) propose a mitigation for each one.

Solution 1

Key comments:

• Case 2 is the most serious in personal data terms and probably the most frequent in real life. An "anyone with the link" share is publication: links get forwarded, indexed and leaked.
• Case 3 illustrates surface reduction in the supply chain: a token with no expiry and full access to every repository is a master key that never expires.
• Case 4 shows why the inventory must include retirement: a forgotten asset remains a risk liability for as long as it is switched on.
• Case 5 is a reminder that the human surface and the third-party surface do not always run through corporate systems.

Solution 2

The decision rule that sums up the exercise: for every listening service, ask yourself whether anybody needs it; if nobody needs it, remove it; if somebody needs it, restrict who can reach it. By applying just that, this machine goes from six open doors to one, controlled.

Solution 3

(a) DFD of the SMS reminders flow:

(b) and (c) STRIDE threats and mitigations:

A cross-cutting threat worth adding (good practice when modelling): the flow introduces a new third party into the supply chain, with access to patients' phone numbers and, if the content is not minimised, to information about their health. This requires supplier assessment, a data processing agreement, and a decision about what happens to that data when the relationship ends. That is the subject of 04-04 and 06-03.

Note on legal implications: this exercise touches on the processing of personal data and its disclosure to a third party, with data that may reveal health information. The concrete decisions — lawful basis, information to the data subject, contract with the processor, need for an impact assessment — must be validated with your compliance lead or with a legal professional. What is set out here is for training purposes only.

You have closed the module with the most practical of the four lessons. You know that an asset is anything of value — information, software, hardware, services, people and intangibles such as reputation — and you have built the Nimbus inventory with the four fields that make it useful: owner, criticality, classification and dependencies. That inventory has revealed two things no tool would have told you: that the cloud provider account is the asset almost every other one depends on, and that there are cells with doubts in them — such as the classification of pre-production — which are, precisely, the first job outstanding. You have learned to classify information into four levels and the three rules that prevent the usual mistakes: classification is inherited upwards, aggregation can raise the level and context defines sensitivity — which is why a physiotherapy diary is not "just a diary".

You have checked the paperwork against reality using ss -tulpn and discovered a forgotten server that had been running for 94 days, and you have learned the rule that makes that output useful: look at the local address before the port, and always cross-check the system layer with the provider's firewall layer. On top of that picture you have measured the attack surface in its five dimensions — network, software and APIs, human, physical and supply chain — and you have seen that reducing it is the most profitable investment there is: what is not there cannot be attacked, patched or watched. You have met the threat actors and corrected the most expensive reasoning error in any SME: the opportunistic attacker does not choose victims, they find systems, and that is why exposure weighs more than appeal. And you have taken your first steps with STRIDE over a Nimbus data flow diagram, learning that the value of the exercise lies in the trust boundaries and in ending every threat with a decision.

That closes module 1. You have the vocabulary, the catalogue of threats, the design principles and the exact map of what has to be protected at Nimbus. From here on we stop describing the terrain and enter the conflict. In Module 2: Cybersecurity we will define the scope of the discipline and its reference frameworks, work through the types of attack executed against systems like the Nimbus one, study social engineering and phishing in depth — the route through which most real incidents arrive — look at the protective measures that counter them, go deeper into identity, authentication and access control, and analyse case studies of real incidents to draw out the lessons that repeat again and again. We begin with Definition and Scope of Cybersecurity (02-01).