From the CIA Triad and formal security models to Zero Trust and ISO/IEC 19249 — a practitioner's guide to foundational security thinking.
Before any principle, model, or control makes sense, you have to ask a foundational question: who are you protecting against? The threat model shapes everything. Defending against a curious teenager is a very different problem than defending against a nation-state actor targeting proprietary designs worth millions. Applying the same controls to both scenarios is at best wasteful and at worst dangerously naive.
One more ground truth before we begin: perfect security does not exist. No system is 100% secure. The goal is to raise the cost and complexity of an attack until it exceeds what your adversary is willing or able to spend. With that framing, let's build the foundation.
When evaluating whether any system is "secure," you need a framework for what security actually means. The industry-standard lens is the CIA Triad — three properties that together define the security posture of a system.
Only intended recipients can access the data. Unauthorized disclosure is a failure of confidentiality.
Data cannot be altered without detection. If alteration occurs, we can identify it. Unauthorized modification is a failure of integrity.
Systems and services are accessible when needed. Disruption of legitimate access is a failure of availability.
These three properties exist in tension. Pushing confidentiality and integrity to extremes often restricts availability. Maximizing availability can erode confidentiality and integrity. Good security design finds the right balance for the context — and the emphasis doesn't have to be equal. A university's public announcement needs strong integrity but almost no confidentiality.
Confidentiality: Your credit card number goes only to the payment processor. A breach disclosing it violates confidentiality. • Integrity: If an attacker can alter your shipping address, the system's integrity is compromised. • Availability: If the store's checkout is unavailable during purchase, availability has failed — and you'll shop elsewhere.
Confidentiality: Healthcare providers are legally required to protect medical records. Unauthorized disclosure is a compliance failure and a legal liability. • Integrity: Altered medical records can lead to wrong treatment — a potentially life-threatening outcome. • Availability: A paperless clinic with an unavailable EHR system cannot deliver care effectively.
Two additional properties extend the CIA Triad into territory the original three don't fully cover:
Authenticity — The assurance that a document, file, or message is genuinely from its claimed source. Not a forgery or counterfeit.
Nonrepudiation — The property that prevents the original source from later denying they were the source. Critical for commerce, banking, healthcare, and any system where accountability matters. If a purchase order arrives for 1,000 vehicles, you need to know it's authentic and that the sender cannot later claim they never placed it.
In 1998, security consultant Donn Parker proposed extending CIA into a more complete framework: the Parkerian Hexad — six elements covering the full security surface.
The two additions that CIA misses:
Utility — Information in a form you cannot use has no utility. A laptop with encrypted storage and a lost decryption key is available in a physical sense, but the data is useless. Utility captures whether information is actually accessible in a meaningful form.
Possession — Control of the physical or logical medium holding the information. Ransomware attacks are a textbook loss of possession: your data still exists on your drives, but you no longer control it.
Every meaningful attack on a system targets one or more elements of the CIA Triad. The inverse framework — the DAD Triad — maps these attacks directly.
Attack on Confidentiality. Stealing and publishing medical records. Dumping credentials. Exfiltrating PII.
Attack on Integrity. Modifying patient records. Tampering with financial transactions. Changing configuration files.
Attack on Availability. Ransomware making systems unreachable. DDoS attacks. Deleting databases.
Understanding DAD helps practitioners think like attackers: what is the adversary actually trying to accomplish? That framing drives more effective control selection.
Principles tell us what we want to achieve. Security models provide formal structures — mathematical rules — for how to achieve them. Three foundational models every security practitioner should know:
Developed by David Elliott Bell and Leonard J. LaPadula at the MITRE Corporation under contract to the U.S. Air Force, with guidance from Roger R. Schell, to formalize the Department of Defense's multilevel security policy. The model was published in 1973 and became the foundational reference for mandatory access control in government and military systems.
The model is summarized as "write up, read down." You can share information upward to higher-clearance subjects; you can receive information from lower-clearance subjects. Think Top Secret researchers — they can write to TS files but cannot create public files. They can read Secret documents but not Top Secret if not cleared.
Where Bell-LaPadula protects confidentiality, Biba is the integrity counterpart. Its rules are intentionally the inverse.
The Biba summary: "read up, write down." The opposite of Bell-LaPadula — by design, since they serve opposite goals.
Designed for commercial environments, Clark-Wilson enforces integrity through well-formed transactions and separation of duties rather than simple access labels.
Other notable models worth exploring independently: Brewer-Nash (Chinese Wall), Goguen-Meseguer, Sutherland, Graham-Denning, and Harrison-Ruzzo-Ullman.
No single control stops every attacker. Defence in Depth — also called Multi-Level Security — is the principle of stacking multiple independent security layers so that failure at any one layer doesn't mean total compromise.
The analogy is simple: a locked drawer inside a locked room inside a locked apartment inside a gated building. Each layer slows the attacker, increases their risk of detection, and forces them to spend more resources. The combination protects far more than any single lock.
In practice: network segmentation, endpoint controls, identity verification, application-layer filtering, logging and detection, and physical access controls all working together — not as backup for each other, but as independent barriers.
The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) jointly published ISO/IEC TS 19249:2017 — a catalogue of architectural and design principles for building secure products, systems, and applications. The standard was confirmed again in 2024, meaning it remains current guidance.
ISO/IEC TS 19249:2017 provides a catalogue of architectural and design principles that can be used in the development of secure products, systems, and applications, together with guidance on how to use those principles effectively. It does not establish requirements for evaluation or certification — it is a design guidance document.
Related components are grouped into domains with shared security attributes. Domains communicate only over controlled, well-defined channels. Example: x86 ring levels — kernel at ring 0, user applications at ring 3.
Systems are structured in abstract levels. Security policies can be imposed and validated at each layer independently. The OSI network model is the canonical example. Directly relates to Defence in Depth.
Low-level implementations are hidden behind controlled interfaces (APIs). Prevents direct manipulation of internal data. Like OOP's private fields — you call increment(), you don't access the variable directly.
Supports both availability and integrity. Dual power supplies, RAID 5 arrays, geographic failover. If a component fails — or is tampered with — the system continues functioning and can detect the discrepancy.
Sharing hardware across multiple isolated operating systems. Provides sandboxing, improved security boundaries, and the ability to safely detonate and observe malicious code in isolated environments.
Grant only the minimum permissions necessary to complete a task — nothing more. A user needing read access gets read only. Limits blast radius when credentials are compromised.
Every unnecessary service, port, or feature is a potential attack vector. Harden by disabling anything you don't need. A smaller surface means fewer opportunities for exploitation.
All user and system input should flow through a single, centralized validation library. Prevents injection attacks, DoS from malformed input, and remote code execution from inconsistent validation across the codebase.
Centralize authentication, authorization, and auditing rather than implementing them independently across subsystems. Reduces inconsistency and simplifies policy enforcement — though single-points-of-failure must be mitigated.
Design systems to fail safe. A crashed firewall should block all traffic, not allow all traffic. Error messages should never leak internal state or sensitive data. Plan for the unexpected — it will happen.
Trust is unavoidable at scale — but how you extend it defines your security posture. Two contrasting principles frame the modern debate.
Trust is extended to entities — users, systems, devices — but continuously monitored. Verification happens through logging, anomaly detection, and automated controls like IDS/IPS and proxies. The phrase originates from a Russian proverb; it gained currency in security circles through its use in Cold War arms negotiation framing. In practice, verifying everything manually isn't feasible — automation carries the load.
Treats trust itself as a vulnerability. The framework — coined by John Kindervag at Forrester Research in 2010 — operates on "never trust, always verify." No user or device is implicitly trusted based on network location or ownership. Every access request requires authentication and authorization. Microsegmentation is a key implementation pattern: network segments can be as small as a single host, requiring verification to cross any boundary. Particularly effective at containing insider threats and limiting lateral movement.
Zero Trust doesn't require discarding existing controls. It's an architectural philosophy applied incrementally. There is a practical ceiling — applying it too aggressively can impede business operations — but the principle should be stretched as far as feasible.
These three terms are frequently conflated. They are distinct concepts and conflating them produces muddled risk conversations.
| Term | Definition | Example |
|---|---|---|
| Vulnerability | A weakness in a system, process, or control that could be exploited. | A showroom with standard plate glass windows. A database running an unpatched version with a known CVE. |
| Threat | The potential danger associated with exploiting a vulnerability. | The glass windows can be broken. A proof-of-concept exploit for the CVE has been published publicly. |
| Risk | The likelihood that a threat actor exploits the vulnerability, combined with the resulting business impact. | How likely is smash-and-grab at this location? What business damage would a successful database breach cause? |
Your hospital uses a specific database system for all medical records. A security advisory reveals that system is vulnerable — and a working proof-of-concept exploit has been publicly released. The vulnerability is confirmed. The threat is real (working exploit exists). Now you must assess the risk: how likely is exploitation in your environment, and what is the impact if patient records are altered, disclosed, or made unavailable? That risk assessment drives your response — patching timeline, compensating controls, incident response readiness.
As organizations increasingly rely on cloud services, one additional principle becomes essential: the Shared Responsibility Model. Security in the cloud is not the cloud provider's problem alone — it is explicitly divided between provider and customer based on the service model.
An IaaS customer controls the operating system, applications, and data — and is responsible for securing all of it. A SaaS customer has no access to the underlying infrastructure, so their responsibilities are narrower — but they still own identity management, data classification, and access control configurations. Neither party can simply assume the other is handling it. Both must know where their responsibility begins and ends.