Threats, Vulnerabilities & Risk.

Security isn't just finding bad things.

Imagine a Northstar Services technician receives three reports: a high-severity software finding on a retired lab computer, a public guest-sharing link for a sensitive document, and a backup job that claims success even though nobody has verified a restore. Which requires attention first?

The useful answer begins with evidence, affected assets and business consequences—not a product name or whichever alert is brightest red. You will learn enough vocabulary to justify a decision, then practice it against unfamiliar scenarios.

Security protects real outcomes—not just devices.

Start with the business purpose. A system matters because people rely on what it provides.

Cybersecurity protects information, systems and services against unwanted access, change and interruption. The classic CIA triad describes three outcomes: confidentiality (only authorized people can see information), integrity (information stays accurate and changes are authorized), and availability (people can use the service when they need it). These are goals, not three pieces of software.

An outage can be a security problem even without stolen data. Likewise, a leaked customer file may be serious even when every server is still online. Defenders must ask which outcome is harmed before picking a safeguard.

Identify the asset before looking for an attacker.

You cannot prioritize protecting something if nobody can describe its purpose, owner or importance.

An asset can be a device, application, account, dataset, service, cloud resource or business process. A workstation is an asset, but so is the signing key that allows an application update, the administrator identity controlling backups, and a supplier's hosted payment system.

An asset inventory should answer: What is it? Who owns it? What does it support? Where is it accessed from? What would happen if it stopped working or its information were exposed? An inventory with only serial numbers and IP addresses misses much of the business impact.

Distinguish the threat source from the threat event.

A threat is a possible cause of harm; it does not mean an attack already succeeded.

A threat source may be a criminal group, malicious insider, careless employee, supplier failure, fire or power loss. A threat event is what could happen, such as an attacker using stolen credentials or an outage interrupting the data center. A threat vector describes the route: a phishing message, exposed remote login, compromised supplier update or physical access.

Do not classify every unusual event as a confirmed attack. Three failed logins from an unfamiliar address show attempted authentication, not proof of compromise. The right next step is to gather evidence, evaluate the account and preserve useful logs.

A vulnerability is a weakness. Exposure describes reachability.

Not every weakness is a software CVE, and an exposed service is not automatically vulnerable.

A vulnerability is a weakness in software, configuration, design or procedure that could be exploited or allow harmful consequences. Examples include an unpatched remotely exploitable bug, a broadly shared administrator account, a public storage bucket with sensitive records, or a backup system with no independent recovery access.

Exposure tells you how reachable the vulnerable condition is. A service accessible from the internet and the same service isolated inside a protected maintenance network have different opportunities for misuse. But isolation alone does not remove the weakness. Record both the weakness and the conditions that make it exploitable.

Connect the pieces: threat, weakness, exploit and harm.

An exploit is a way a weakness is used—not a synonym for the risk itself.

A defender describes a credible path from an asset to a potential consequence: a valuable payroll dataset, an overly broad export permission, a compromised low-privilege identity, an unauthorized bulk download, and the harm from that disclosure. The attack path is a hypothesis until supporting evidence confirms events.

Not every threat needs a software exploit. Stolen credentials can work against a correctly patched service when permissions are too broad. Weak processes, missing approval checks and fragile recovery arrangements are also part of security risk analysis.

Risk joins likelihood with consequences.

Prioritize what could go wrong, how credible the event is, and what it would mean to the business.

Risk represents potential harm given a threat scenario. Two important inputs are likelihood (how plausible the event is under the current conditions) and impact (the harm if it occurs). Business criticality, exposure, attacker capability, ease of misuse and existing safeguards all matter when discussing likelihood or impact.

Do not confuse a vulnerability's technical severity score with the organization's full risk. A high-severity defect on an isolated test system can deserve different handling from a modest misconfiguration on a critical public service. State assumptions and uncertainty; do not claim an exact probability that you cannot support.

A simple risk matrix can start a conversation.

Use a teaching score to compare assumptions—not to manufacture precise risk measurements.

For a first exercise, assign likelihood from 1 (rare under these assumptions) to 5 (very plausible), and impact from 1 (limited disruption) to 5 (severe business harm). Multiply the two to create an ordinal classroom priority score. This simple matrix helps learners compare scenarios, but it is not a probability, a financial loss estimate, a CVSS score or an official NIST rating.

Different organizations define their scales and thresholds differently. A score of 12 does not mean a 12% chance or a predictable dollar loss. Explain the evidence used for each rating, note what is unknown, and revisit ratings when controls, scope or the threat change.

Choose controls by how they change the path to harm.

A security control may prevent, detect, limit, respond to or help recover from an event.

Preventive controls aim to stop or make harmful behavior harder: stronger authentication, least-privilege permissions, patching or appropriate segmentation. Detective controls such as monitored sign-in events and endpoint alerts help teams notice suspicious activity. Corrective or responsive controls address a known problem, such as revoking a compromised session. Recovery controls support returning essential services to an acceptable state.

Controls do not all reduce the same factor. Limiting access might lower the likelihood of unauthorized export. Limiting which records an account can read might reduce the impact of a compromised session. Backups improve recoverability after disruption but do not undo a leak. Every control needs an owner and a way to verify it actually works.

Reduce, avoid, transfer or accept risk—with accountability.

Security decisions involve tradeoffs and named ownership.

Mitigation (reduce) adds or improves safeguards. Avoidance removes the risky activity or exposure. Transfer shares specified financial consequences using arrangements such as insurance or contracts, but it does not transfer away responsibility for preventing and responding to the event. Acceptance documents a remaining risk that the authorized owner chooses to live with within policy.

A technician should not silently accept a serious risk because a ticket is old, nor disable a security control just to make a symptom disappear. Record the scenario, evidence, options, expected effect, residual risk, accountable owner and follow-up date; escalate decisions beyond your authority.

Prioritize with evidence—not alarm colors.

A defensible priority statement explains who could be harmed, why now and what to verify.

When several findings compete, compare the sensitive assets involved, plausible threat paths, actual exposure, observed exploitation, existing safeguards, business impact and time available to respond. A publicly exploited weakness on a critical service often demands attention, but there is no universal single ranking that replaces local context.

Choose the least risky practical next action: collect and preserve evidence, verify reachability and control state, reduce exposure when authorized, assign ownership and schedule validation. A scanner result alone does not prove compromise. A green dashboard alone does not prove safety.

Write a risk statement another technician can act on.

Good security documentation makes the next decision clearer without claiming certainty.

A useful statement follows a plain structure: Because [asset and weakness], [threat event] could cause [harm]. Under current [exposure and safeguards], the team estimates [likelihood and impact] with [uncertainty]. Recommend [control] and validate [specific observable outcome]. This is clearer than writing 'high risk: needs fixing' with no explanation.

Use a fictional change ticket or review record to communicate this first. In this learning path, you will move from these simple risk descriptions to recognizing attacks, interpreting alerts and choosing appropriate incident actions. Start with what is observed, separate it from what is assumed and avoid taking unapproved action.

Can you distinguish the words without hints?

Before moving to Practice, explain this scenario out loud: a vendor account can export confidential records to an external location. Name the asset, a credible threat source and event, the underlying weakness, the possible impact and a control you could verify. Do not claim an incident occurred unless you have evidence.

These distinctions carry forward into Phishing & Social Engineering, Malware & Credential Threats, Security Evidence & Logs, and Incident Response Fundamentals. A strong defender can explain a judgment and revise it when evidence changes.

Where these ideas come from.

These references provide authoritative terminology and a broader risk context. They are optional reading; everything required for this lesson's Practice is taught above.