Security advice often begins with a product: buy this scanner, turn on that firewall, install one more agent. The harder question comes first. What would actually hurt if it were exposed, changed, or unavailable—and which failure is plausible enough to act on now?

Cybersecurity is the work of managing that risk to information, systems, and the people who depend on them. It cannot make risk disappear. It can make the important risks visible, assign them to someone, and reduce them deliberately.

The CIA Triad

The CIA triad is a compact way to describe three security objectives.

Confidentiality

Information should be available only to authorized people, services, and devices. Common controls include access control, encryption, data classification, and careful logging.

Confidentiality is contextual. A public web page is meant to be read widely, while its unpublished drafts and administrator credentials are not.

Integrity

Information and systems should not be changed in an unauthorized or undetected way. Integrity controls include digital signatures, message authentication codes, database constraints, version control, checksums used in a trusted process, and tamper-evident logs.

A cryptographic hash is not a unique fingerprint in the mathematical sense; collisions exist. An ordinary unkeyed hash also does not stop an attacker from changing both a file and its published hash. A trusted signature, MAC, or independently protected reference value is needed when an active attacker is in scope.

Availability

Authorized users should be able to obtain the service and data they need within an acceptable time. Redundancy, capacity planning, tested backups, monitoring, rate limits, failover, and incident response all contribute.

Availability cannot be guaranteed absolutely. The practical goal is to define acceptable downtime and data loss, then design and test for those targets.

Other Useful Properties

The triad does not cover every concern:

  • Authenticity: Is an identity, message, or artifact what it claims to be?
  • Accountability: Can important actions be traced to an actor or process?
  • Privacy: Is personal data collected and used fairly, lawfully, and proportionately?
  • Safety: Could a security failure cause physical or environmental harm?
  • Resilience: Can the organization continue or recover when a control fails?

Threat, Vulnerability, Likelihood, and Impact

These terms are related but not interchangeable.

  • An asset is something worth protecting.
  • A threat is a circumstance or actor that could cause harm.
  • A vulnerability is a weakness that could be exploited or triggered.
  • A control changes likelihood, impact, or both.
  • Risk combines uncertainty about a harmful event with its consequences.

A common shorthand is:

risk≈likelihood×impact\text{risk}\approx\text{likelihood}\times\text{impact}

That expression is a prioritization aid, not a precise universal equation. Scores may be ordinal, estimates may be uncertain, and a rare catastrophic event needs more thought than simple multiplication suggests.

Risk Responses

“Risk mitigation” is only one possible response:

  • Avoid: stop the activity that creates the risk;
  • Reduce or mitigate: add controls that lower likelihood or impact;
  • Transfer or share: use contracts, insurance, or service arrangements to move part of the financial or operational burden;
  • Accept: document the residual risk and monitor it.

Transfer does not erase accountability or operational harm. An insurer may pay part of a loss, but it cannot restore trust, reverse a privacy violation, or run an unavailable service.

Every accepted risk should have an owner, a reason, a review date, and a trigger for reassessment.

Threat Modeling

Threat modeling is a design activity. It asks how a system could fail or be abused before those paths become expensive to change.

A useful session can follow this sequence:

  1. Define the system, assets, users, trust boundaries, and important data flows.
  2. State security and privacy objectives.
  3. Identify threats, abuse cases, and dangerous assumptions.
  4. Choose mitigations and assign owners.
  5. Record what remains and revisit the model as the design changes.

STRIDE—spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege—is one prompt for finding threats. Attack trees, misuse cases, and MITRE ATT&CK can help in other contexts. DREAD appears in older material, but it is not a current universal scoring standard and often creates false precision.

Threat modeling is not the same as vulnerability scanning. A scanner tests a running artifact for known patterns; a threat model can reveal missing authorization boundaries, unsafe business workflows, and design assumptions that a scanner cannot infer.

Security Controls and Defense in Depth

Controls are often grouped as:

  • preventive: reduce the chance of an event;
  • detective: reveal that something happened;
  • responsive or corrective: contain harm and restore operation;
  • deterrent: make misuse less attractive;
  • compensating: provide an alternative when the preferred control is not possible.

Defense in depth means that one failure does not immediately become a complete compromise. It does not mean piling on products. Several controls that depend on the same identity provider, network path, or administrator account may share one failure mode.

Vulnerability Management

Vulnerability management is a continuing operational process:

  1. maintain an asset and software inventory;
  2. discover weaknesses through scanning, testing, advisories, and reports;
  3. verify and prioritize findings using exposure, exploitability, asset value, and current threat information;
  4. remediate or mitigate them;
  5. verify the fix;
  6. measure exceptions and overdue work.

A CVSS score is useful context, not an automatic priority. An Internet-facing flaw with known exploitation may deserve attention before a higher-scoring issue on an isolated lab machine. CISA’s Known Exploited Vulnerabilities catalog is one useful source of exploitation evidence.

Penetration testing is a scoped assessment that attempts to demonstrate exploitable paths. It complements—not replaces—secure design, code review, configuration management, continuous scanning, and remediation tracking.

A Small Example

Imagine an internal payroll application.

  • Asset: employee bank and salary data.
  • Threat: an attacker uses a stolen manager session.
  • Vulnerability: the application does not require recent authentication before changing bank details.
  • Impact: redirected payments and personal-data exposure.
  • Controls: phishing-resistant MFA, short privileged sessions, reauthentication for sensitive changes, dual approval, notifications, and anomaly monitoring.
  • Residual risk: a compromised privileged endpoint may still perform a legitimate-looking change.

This description is more actionable than “install a firewall,” because it connects the control to a specific failure path.

Conclusion

Security fundamentals are less about memorizing acronyms than about asking disciplined questions. What are we protecting? From whom? How could it fail? Which control changes that path? How will we know the control still works? The later parts of this series build on those questions rather than replacing them with tools.

References