Cybersecurity / Basic: defensive concepts and personal-service boundaries / Lesson 1

Assets, threats, and security risk

Describe what a learning portal must protect and connect plausible harm to proportionate defensive decisions.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish assets, threats, weaknesses, controls, and residual risk.
Build an owned, evidence-based risk record.

Start with the service and its dependencies

Cybersecurity protects the ability to perform useful tasks with acceptable risk. For a learning portal, assets include learner records, staff identities, lesson availability, recovery copies, devices, and the people who operate them. An asset inventory should connect each item to an owner, purpose, location, and dependency. A forgotten export or administrator account can matter as much as the main database. Begin with a concrete service and follow its data and decisions rather than collecting an endless list of technologies. Keep uncertainty visible when ownership or location is not yet known.

Describe harm through confidentiality, integrity, and availability

Confidentiality concerns unauthorized disclosure, integrity concerns unauthorized or inappropriate change, and availability concerns timely reliable access. One event can affect all three. A mistaken sharing link may disclose records; an unauthorized grade edit damages integrity; a failed restore delays teaching. Privacy also asks whether collection and use are appropriate, even when access is technically secured. A threat is a potential cause of harm, while a vulnerability is a weakness that may enable it. Avoid using these terms interchangeably because they lead to different questions about prevention, detection, and recovery.

Write a scenario that can be reviewed

A useful risk record states an asset, a plausible event, the consequence, relevant evidence, current defenses, and an accountable owner. The example is an application-defined teaching record, not a NIST template or a compliance assertion. It deliberately names a service outcome instead of merely saying phishing risk. Controls should address the path to harm: stronger authentication can reduce account takeover, narrower permissions can limit damage, and recovery planning can reduce duration. Record what remains uncertain and when the owner will review it. A control’s presence alone does not prove that it works.

json A synthetic service-risk record

{
  "asset": "learner-records",
  "scenario": "staff account used by an unauthorized person",
  "impact": "records disclosed or changed",
  "owner": "portal-maintainer",
  "controls": ["strong-authentication", "limited-access", "reviewed-recovery"],
  "evidenceState": "needs-validation"
}

The labels describe a fictional portal and contain no identities or credentials. evidenceState prevents mistaking a written plan for a verified defense. A real process needs approved ownership and evidence appropriate to its environment.

Prioritize with evidence and explicit uncertainty

Risk assessment considers likelihood, consequence, exposure, existing controls, and confidence in the information. Simple categories can support discussion, but multiplying subjective scores does not create a scientifically precise probability. The small policy function below illustrates that high consequence and missing evidence can require review. It performs no discovery or scanning. A real assessment should explain why a scenario is plausible, what evidence would change the decision, and which action is feasible. Do not let a tidy score hide a critical unknown owner or an untested recovery dependency.

python A local illustrative review policy

def review_priority(impact, evidence_complete):
    if impact not in {"low", "moderate", "high"}:
        raise ValueError("UNKNOWN_IMPACT")
    if impact == "high" or not evidence_complete:
        return "owner-review-required"
    return "scheduled-review"

assert review_priority("moderate", False) == "owner-review-required"

This pure Python example uses declared synthetic facts. It is not a risk calculator, control verifier, or authorization engine. The returned label calls for a decision by an accountable owner rather than automatically changing a system.

Manage risk as a continuing service responsibility

NIST CSF 2.0 organizes outcomes through Govern, Identify, Protect, Detect, Respond, and Recover. These functions are connected rather than a one-time linear checklist. Governance establishes responsibility; inventory informs protection; detection supports response; recovery feeds improvement. Choose a small set of service priorities and review changes in users, dependencies, and threats. A completed course or checklist does not establish professional certification or legal compliance. The practical outcome is an understandable set of owned decisions, tested defenses, remaining risks, and review dates. Start with actions whose purpose and evidence can be explained clearly.

Common errors and fixes

An asset has no accountable owner

Why it happens: Inventory records technology without service responsibility.
How to fix it: Assign and confirm an owner with the relevant authority.
Prevent it next time: Review ownership when services and staff change.

A numerical score is treated as certainty

Why it happens: Subjective inputs are mistaken for precise measurement.
How to fix it: Explain assumptions, evidence, and uncertainty.
Prevent it next time: Use scores to support discussion, not replace it.

A documented control is assumed effective

Why it happens: A plan is confused with operating evidence.
How to fix it: Verify the intended behavior through a safe approved check.
Prevent it next time: Attach evidence and review dates to controls.

Check your understanding

1. A shared folder contains an old learner export. Why include it in the inventory?

Show worked solution

The export is another copy of sensitive information with its own access, retention, and deletion risks. Identify purpose and owner, then review whether it is needed and protected. Protecting the primary database alone does not address that copy.

2. A backup exists but has never been restored. What claim is supported?