In the previous lesson you separated threat from vulnerability and saw that their combination produces risk. Now it is time to fill those two boxes with real content. This lesson is a map: what threats exist and where they come from, what families of malicious software there are and how they differ, what kinds of weakness you are going to find in an environment like that of Nimbus Reservas, and — crucially for day-to-day work — how to read the identifiers the whole industry uses to name and prioritise problems: CWE, CVE and CVSS. Without this map, a security bulletin is noise; with it, you will know within thirty seconds whether something must be fixed this afternoon or next month.

1. Taxonomy of threats by origin
2. Taxonomy of threats by target (which property they attack)
3. Malware families: comparison table
4. Insider threats: the malicious insider and the negligent one
5. Types of vulnerability, with examples from the Nimbus environment
6. The identifier ecosystem: CWE, CVE and CVSS
7. Exposure window and zero-day vulnerabilities
8. The complete chain: threat + vulnerability → risk

Classifying threats by their origin is not an academic exercise: each origin is countered with a different kind of control. You do not defend against a mistake by Sara the way you defend against a flood in the provider's data centre.

Somebody acts with the intention of causing harm or of obtaining a benefit. It is the category that gets the most attention, even though it is not always the most frequent.

In Nimbus: a ransomware group that arrives through a credential belonging to the external consultancy; a competitor trying to obtain the customer list; an opportunistic attacker whose bot spots the open PostgreSQL port.

Key trait: there is an adaptive adversary. Close one door and they try another. That is why controls against deliberate threats are never a one-off: they require continual detection and response.

Nobody meant to cause harm; somebody made a mistake. Statistically, this category causes an enormous share of real incidents.

In Nimbus:

• Lucía marks the S3 attachments bucket as public "just for a moment, to test something" and forgets to revert it.
• Iván accidentally pushes a .env file containing the production connection string to the repository.
• Rubén replies to an e-mail with a CSV of 400 end customers attached and picks the wrong recipient from autocomplete.
• Sara sends one employee's payslip to another because of a mail merge template failure.

Key trait: they are not fixed by "more training" alone. They are fixed by making the mistake hard to make: secure defaults, confirmations for destructive actions, automated secret scanning in the repository.

The system fails by itself, with no human actor behind it.

In Nimbus: a disk on the database server that degrades and corrupts pages; a memory leak that restarts the API container under load; a bug in a library that truncates text fields; the unnoticed expiry of the TLS certificate.

Key trait: they are countered with redundancy, monitoring and testing, not with access controls.

Fire, flood, power cut, fibre cut, excessive temperature. For a cloud company like Nimbus these threats are displaced towards the provider, but they do not disappear: they still exist for the Valencia office, and they still exist for the provider (which can lose an entire availability zone).

In Nimbus: roadworks in the street cut the office fibre; a regional outage at the cloud provider leaves the API without service for hours.

One important nuance: impact does not depend on origin. If Nimbus loses its database, it makes no difference whether it was ransomware, a broken disk or an accidental DROP TABLE: the customers are equally stuck. That is why recovery plans (04-06) are designed by consequence, not by cause.

The second way of classifying is by the CIA triad property they attack. It is useful because it connects directly with the controls from the previous lesson.

Many threats attack several properties at once. Modern ransomware is the perfect example: it encrypts the data (availability), copies it before encrypting it in order to extort by threatening publication (confidentiality) and sometimes alters it (integrity). This "double extortion" model is the norm today.

A third classification you will see in practice, complementary to the two above, is STRIDE — by the property violated — which you will use for threat modelling in lesson 01-04.

Malware (from malicious software) is the umbrella term for any software whose purpose is to damage, spy or take control without consent. The categories are not mutually exclusive: a real piece of malware is usually a trojan that installs a rootkit and deploys ransomware. What distinguishes each family is its propagation mechanism or its objective, not its form.

Ransomware. Not because Nimbus is a chosen target, but because ransomware almost always arrives by generic routes: a reused credential belonging to the consultancy that provides remote support, the laptop of somebody working remotely, an attachment opened by Sara. There are three factors that determine whether an SME survives ransomware, and none of them is an antivirus: backups out of the attacker's reach (immutable or offline), segmentation (so that a compromised machine cannot reach the servers) and a rehearsed response plan (module 4).

Cryptominer in the cloud. This is the most underestimated threat for a company like Nimbus. If a cloud provider access key ends up by mistake in a public GitHub repository, there are bots that detect it within minutes and spin up dozens of compute machines. The first symptom is not a security alert: it is a bill for 14,000 € at the end of the month. And there is extra damage: if Nimbus does not find out, it does not know what else that key did.

This course is defensive. At no point are we going to write, compile or distribute malware, nor analyse real samples outside a controlled environment. What you need to know as a professional is how it gets in, what it does and how it is detected and contained. Detection is covered in 05-02 and containment in 04-05.

An insider threat is one that comes from somebody who already has legitimate access: employees, former employees, interns, contractors and — highly relevant at Nimbus — the external consultancy with remote access to systems.

They are especially difficult because the attacker does not need to break in: they are already inside, their credentials are valid and their actions look like their day job.

There is also a third figure: the compromised insider. They are neither malicious nor meaningfully negligent: their credentials have simply been stolen. From the system's point of view, the attacker's activity is indistinguishable from that of a legitimate employee — which is why the traceability from the previous lesson and behavioural anomaly detection matter so much.

The Nimbus case to watch: the systems consultancy has remote access with elevated privileges. It is an insider for all practical purposes, but one outside HR's control: Nimbus does not know who works there, when somebody leaves that consultancy or whether they share credentials. Third-party risk is developed in lesson 04-04; note it down right now as one of the company's three or four biggest exposures.

Remember the definition: a vulnerability is a weakness that a threat can take advantage of. Unlike a threat, it is on your side and therefore you can close it. They are classified as follows:

a) The S3 attachments bucket publicly accessible (configuration)

How to read that output: the error does not say "you do not have permission", it says that a public access block configuration does not exist. In other words, nothing prevents a policy or an ACL from opening the bucket to the world. On a bucket that stores scanned medical reports of clinic patients, this is a critical vulnerability. The immediate fix:

The four parameters cover two distinct exposure routes: inherited ACLs (the first two) and bucket policies (the last two). Enabling only two of the four leaves the door ajar.

b) An out-of-date dependency (software)

Every line is a potential vulnerability: being out of date does not mean being vulnerable, but it does mean you have not found out whether you are. pyjwt is the most worrying one here, because it is the library that validates the API's session tokens: a validation flaw in the token library amounts to an authentication flaw across the whole application. The tools that cross-reference these versions against known vulnerability databases are covered in 05-01.

c) The database port exposed (design/configuration)

How to read it: 0.0.0.0:5432 means PostgreSQL is listening on all network interfaces, not just the private one. If the cloud provider's security group allowed inbound traffic on that port from 0.0.0.0/0, the Nimbus database would be listening to the Internet. What you would want to see is 10.0.2.15:5432 (internal network only) or 127.0.0.1:5432 (local only). A complete diagnosis requires looking at two layers: the system's (ss) and the provider's firewall.

Notice a pattern: of the three vulnerabilities, two are configuration issues, not code issues. In organisations like Nimbus, most real breaches do not come from an exotic flaw in a library, but from something badly configured, forgotten or opened "temporarily". That is good news: they are the cheapest to close.

When a security advisory arrives, it comes packed with acronyms. Each one answers a different question.

The relationship in one sentence: a CVE is a concrete instance of a class of weakness (CWE) present in a product, and its severity is expressed with CVSS.

This is how you read a record (a fictitious example, built for this lesson around a hypothetical component that Nimbus might use):

How Iván interprets it in five steps:

1. Does it affect me? Look at the version range. If Nimbus uses reservalib 3.2.0, it is inside the range: yes, it does. This step is impossible without a dependency inventory (SBOM), which we will see in 04-04.
2. What class of flaw is it? CWE-89, SQL injection. That tells him what to look for in the code and what temporary mitigation makes sense.
3. How severe? 9.8, critical. And the detail matters more than the number: it is broken down in the next section.
4. Is it being exploited? "Public exploit since the 14th". This changes the urgency radically: a theoretical 9.8 is not the same as a 9.8 with an automated tool in circulation.
5. What do I do while I update? The temporary mitigation buys hours if the deployment cannot be immediate.

The vector is the part almost nobody looks at and the one that carries the most information. Take the one from the example:

You read it from left to right; each pair is Metric:Value.

The first four metrics describe how easy it is to exploit; the last three, what the attacker gets out of it. Our vector says, in plain language: anybody, from the Internet, with no account, without tricking anyone and with no special conditions, obtains full read and write access and the ability to take the service down. Hence the 9.8.

Compare it with a very different vector that could also turn up in a bulletin:

Translation: you need to be on the machine physically or with a local session, to be an administrator, to have another user do something specific as well, and even then you only obtain a partial disclosure of information. Same kind of document, radically different urgency.

Score ranges (CVSS v3.x):

The CVSS base score is not your risk. It is a measure of technical severity in the abstract, with no knowledge of your environment. Two nuances change everything:

• A critical (9.8) vulnerability in a component that Nimbus has switched off or unreachable from outside may be a low risk for Nimbus.
• A medium (6.5) vulnerability in the component that authenticates every user, with a public exploit and exposed to the Internet, may be the most urgent risk of the week.

That is why mature organisations prioritise by combining CVSS + known active exploitation + the asset's real exposure + the asset's criticality. There are complementary metrics for this (temporal, environmental, and systems such as EPSS that estimate the likelihood of exploitation); the formal risk calculation is tackled in 04-01.

The exposure window is the length of time during which a vulnerability exists in your systems and can be taken advantage of. It is the metric that genuinely matters, because it is the one you can shrink.

Two concepts are defined along that timeline:

• Zero-day vulnerability (0-day): one that is known and exploited by attackers before a patch exists (often before the vendor even knows about it). It is called "zero day" because the defender has zero days to prepare. Patching is no use against a 0-day — there is no patch; what helps is defence in depth, segmentation and detection of anomalous behaviour.
• n-day vulnerability: one that already has a published patch but still has not been applied. It is, by a wide margin, the most exploited kind in practice: attackers automate the hunt for unpatched systems because they know exactly what to look for and how.

The figure that changes priorities: a 0-day is expensive, scarce and reserved for valuable targets. An SME like Nimbus is almost never the victim of a 0-day; it is the victim of an eight-month-old n-day in an exposed service. That is why the control with the best cost-benefit ratio at Nimbus is not a sophisticated detection tool: it is a disciplined update process.

How the window is shrunk at Nimbus:

Everything above comes together in a single causal chain. This diagram is the summary of the lesson:

Three readings you should take away from this diagram:

1. The threat is not eliminated; the vulnerability is. There is no control you can put in place at Nimbus that makes ransomware groups disappear. All your controls act on the bottom-left box (vulnerability) or on the right-hand one (impact).
2. With no vulnerability there is no risk, however many threats there are. And with no threat there is none either: a vulnerability in a completely isolated, worthless system carries a risk close to zero. Both boxes have to be filled.
3. There are two ways of reducing risk. Reduce the likelihood (close the vulnerability) or reduce the impact (backups, segmentation, insurance, response plan). When you cannot do the first — the 0-day case — you still have the second. In fact, the organisations that survive serious incidents have usually invested in the second column.

None of this turns into a number yet. Quantifying likelihood and impact in a matrix, deciding what is accepted and what is mitigated and with what budget, is the work of lesson 04-01.

Common mistakes:

• Treating CVSS as if it were risk. This is the most widespread error. A 9.8 in a component you do not use must not displace a 6.5 in your Internet-facing authentication system.
• Ignoring the vector and looking only at the number. The vector tells you whether privileges, user interaction or local access are needed — information that often rules the vulnerability out for your case.
• Obsessing over 0-days. They absorb a disproportionate amount of attention. The overwhelming majority of real compromises in SMEs use vulnerabilities that have had a patch available for months.
• Thinking malware gets in "through e-mail viruses". Today it mostly gets in through stolen valid credentials and through third-party access. That difference changes where you invest.
• Confusing CVE with CWE. If you write "we have CWE-2026-01234" in a report, you are mixing them up: CWEs do not carry a year.
• Forgetting human and process vulnerabilities. They show up in no scanner and they are the ones that allow the most expensive incidents: failing to revoke accesses on departure, having no payment approval procedure.
• Assuming "the cloud patches everything". The provider patches its infrastructure; the container images, Iván's dependencies and Lucía's configuration belong to Nimbus.

Tips:

• When reading an advisory, always ask yourself the five questions from section 6.1, and in that order. The first one ("does it affect me?") rules most of them out.
• Write your findings using the chain from section 8: actor → threat → vulnerability → asset → impact → control. A finding with a missing box is usually badly framed.
• Prioritise by exposure before severity: whatever faces the Internet comes first.
• Automate the dependency inventory before the scanning: you cannot prioritise what you do not know you have.

For each Nimbus situation, state (a) the origin of the threat (deliberate human, accidental human, technical failure, natural/environmental) and (b) the target in CIA triad terms:

1. Iván accidentally pushes to the public GitHub repository a file containing the cloud provider access key; 11 minutes later there are 30 compute machines running and mining cryptocurrency.
2. Roadworks in the street outside the Valencia office cut the fibre for 8 hours.
3. A former developer, whose account was never deactivated, gets into the repository and modifies a billing script so that it rounds amounts in his favour.
4. A disk on the database server starts returning read errors and some rows of the bookings table become unreadable.

Three advisories land on Lucía's desk on the same Monday. Rank them by their real urgency for Nimbus and justify your order, stating what each vector means.

For each finding from an internal Nimbus review, state the type of vulnerability (software / configuration / cryptographic / design / human / physical) and propose a control that reduces it. Then write up finding 4 using the complete chain from section 8.

1. The legacy_users table stores passwords with unsalted MD5.
2. The database security group allows inbound traffic on port 5432 from 0.0.0.0/0.
3. When somebody leaves Nimbus, Sara sends a chat message saying "when you get a chance, take away their accesses" and there is no list of systems to review.
4. The laptops of the 19 remote employees do not have disk encryption enabled.

Solution 1

1. Origin: accidental human (Iván's mistake) — even though the subsequent exploitation is deliberately human. It is important to see the chain: a deliberate threat takes advantage of a vulnerability created by accident. Target: mainly availability (resources consumed, service degradation and cost), but a compromise of confidentiality must also be assumed: that key could have done far more than mine, and until the provider's activity log has been reviewed there is no way of knowing.
2. Origin: natural/environmental. Target: availability — of the office. Since half the headcount already works remotely and the systems are in the cloud, the impact on the customer-facing service is low: a good example of architecture already acting as a control.
3. Origin: deliberate human, insider (specifically a former employee with unrevoked access; the underlying vulnerability is human/process). Target: integrity first and foremost (alteration of the billing logic) and, derived from it, financial fraud. If he also read data, there is confidentiality as well.
4. Origin: technical failure. Target: integrity (corrupted data) and, if the server stops responding, availability. Nobody is attacking anybody and the damage is real: remember that impact does not depend on origin.

Solution 2

Order of urgency: B → C → A.

• B, first. Vector: AV:N (from the Internet), AC:L (no special conditions), PR:N (no prior account), UI:N (nobody has to be tricked), C:H (high disclosure), I:L, A:N. Although its score (8.2) is lower than A's, it is the only one that combines real exposure + critical component + public exploit. It is the library that validates the sessions of the public Nimbus API: a flaw here is an authentication flaw across the whole product. It gets fixed today, with a temporary mitigation if the deployment takes time.
• C, second. Vector: AV:L (local access needed), AC:H (difficult conditions), PR:H (being an administrator), UI:R (somebody has to cooperate), C:L (minor disclosure). An attacker who is already administrator of Lucía's laptop has much bigger problems in store than this one. It goes into the normal update cycle. It comes before A only because the component is actually in use.
• A, last, despite the 9.8. The component is decommissioned: the service is not running and the port is closed. With no exposure there is no possible exploitation. That said, this is not "do nothing": the right action is to uninstall the package, because a forgotten service that somebody carelessly reactivates turns a nil risk into a critical one. This exercise is exactly the case that illustrates why CVSS is not risk.

Solution 3

1. Cryptographic. MD5 is a broken function for this use and, without a salt, it allows precomputed tables to be used. Control: migrate to a password derivation algorithm with a cost factor (bcrypt, scrypt or Argon2), rehashing at each user's next log-in, and delete the legacy_users table once it is empty. The technical detail is covered in 03-04.
2. Configuration (with a design component: it should not even be possible to open it to the Internet). Control: restrict the source to the VPC's private range or to the API's security group; administrative access only over VPN or through a bastion host; automatic alert if the rule is opened again.
3. Human / process. Control: a formal offboarding procedure with a closed list of systems — cloud provider, GitHub, e-mail, VPN, password manager, support tool — a maximum revocation deadline (same day), an assigned owner and a record of its execution. Ideally, centralised accounts so that a single deactivation cuts off every access.
4. Physical (with a configuration component). Control: mandatory full disk encryption, verified centrally, with the recovery keys held in escrow.

Finding 4 written up with the complete chain:

Threat actor: opportunistic common crime (theft or loss of equipment). Threat: access to the contents of the disk of a stolen laptop. Vulnerability: absence of full disk encryption on the 19 laptops of remote staff. Asset: the local information on those machines — end customer exports, credentials saved in the browser, SSH keys granting access to the infrastructure. Exploit: no sophisticated one is required: booting from external media or removing the disk is enough. Impact: leak of personal data (possibly health data, in the case of clinic exports), potential access to the infrastructure via the stored keys, and probable obligation to notify the supervisory authority. Risk: high, given the high likelihood of loss or theft while travelling and the severe impact. Controls: mandatory full disk encryption, remote wipe, session expiry, a ban on storing local exports, and infrastructure keys protected with a passphrase and given a short lifetime.

Note on legal implications: the obligation to notify a personal data breach, its deadlines and its recipients depend on the nature of the data and on the specific case. The references in this course are indicative and for training purposes: always validate these decisions with your compliance lead or with a legal professional.

Now you have the map. You know how to classify threats by origin — deliberate human, accidental human, technical failures and environmental ones — and by target, according to which CIA triad property they attack, and you have confirmed that impact does not depend on origin: an accidental DROP TABLE and a ransomware attack leave Nimbus customers equally stuck. You have gone through the malware families, telling them apart by their propagation mechanism, and you have identified the two that should worry an SME like Nimbus most: the ransomware that arrives through valid credentials and the cryptominer that arrives through a leaked cloud key. You have seen that insider threats break down into malicious, negligent and compromised, and that the external consultancy with remote access is, in practice, an insider beyond HR's reach.

On the weakness side you have reviewed the six types of vulnerability with concrete Nimbus cases — the bucket with no public access block, the out-of-date token library, PostgreSQL listening on 0.0.0.0 — and you have drawn out the lesson that pays best: most real breaches are born of configuration, not of exotic code. And you have learned to read the common language of the industry: CWE for the class, CVE for the instance, CVSS for the severity, breaking the vector down metric by metric and understanding why a score of 9.8 does not always beat one of 8.2. You close with the distinction between 0-day and n-day, and with the idea that the exposure window is the variable you can genuinely act on.

You know what can happen to you and how. What is missing is knowing how a system is built so that it does not happen. In the next lesson, Principles of Information Security (01-03), we will look at the design rules that will guide every decision in the rest of the course: least privilege, defence in depth, fail-safe defaults, separation of duties, zero trust and the "assume breach" mindset — each one applied to a real decision in the Nimbus architecture.