POSTED: 10/14/1998 | FILED UNDER: coursework, cybersecurity, existential dread
Thinking Inside the Cube
A reflection on the McCumber Cube, the foundations of security, and the principles that hold them together.
Before this discussion I thought of security the way most people do: as a wall. You buy a firewall, you install antivirus, you pick a password nobody can guess, and you are "secure." What the McCumber Cube did was quietly dismantle that idea and replace it with something much less comfortable and much more useful — a model that says security is never one decision, it is a set of intersecting decisions you have to make over and over.
1. New Insights
Security is three-dimensional, not a checklist. The cube's three axes — the goals (confidentiality, integrity, availability), the states of information (storage, transmission, processing), and the safeguards (technology, policy & practice, and education/training/awareness) — multiply out to twenty-seven small cells. Each cell is a real question. "How do I protect the integrity of data while it is being processed using policy?" is a different problem from protecting the confidentiality of the same data sitting in a database. I had never been given a vocabulary that forced me to ask all twenty-seven versions of the question, and once you do, the gaps become embarrassingly obvious.
The people axis is not decoration. My biggest shift in thinking was about the safeguards axis. I would have listed technology, and maybe policy if I was being thorough. Putting education, training and awareness on equal footing with encryption is a statement: an organization with perfect cryptography and untrained staff is not secure. The classic phishing example makes this concrete — no technical control on that axis was breached, because the attacker simply asked a human to open the door.
Availability is a security property, and it can be over-secured. I used to file "the site is down" under reliability, not security. Seeing availability sit beside confidentiality and integrity reframed it. It also made me notice the tension between them: every control I add to protect confidentiality tends to cost availability and usability. Security is not maximization, it is negotiation.
The principles are old, and that is the point. Learning that most of the security principles we still teach — least privilege, defense in depth, fail-safe defaults, separation of duties, economy of mechanism, complete mediation, open design, psychological acceptability — were articulated in the 1970s was genuinely humbling. The technology stack has changed completely and the principles have not. That suggests they describe something about systems and people rather than about any particular machine.
⚠ THE ONE THAT STUCK WITH ME:
Open design. The security of a system should not depend on the secrecy of its design, only on the secrecy of its keys. It is counterintuitive the first time you hear it and obvious the second time. Secrets that many people must know are not secrets; a secret one key holder holds is.
2. Concepts I Want to Read More On
- Threat modeling as a practice. The cube tells me what to consider; it does not tell me which threats are plausible for a given system. I would like to read about STRIDE and attack trees and see how a structured threat model is actually built and reviewed.
- Protecting data in the processing state. Storage and transmission have well-known answers (encryption at rest, TLS). Data in use is the axis I understand least. Homomorphic encryption and trusted execution environments came up briefly and I want to know how practical they really are.
- Risk quantification. If security is a trade-off, someone has to decide how much confidentiality is worth how much availability. I want to understand how risk is actually measured and defended to people who control budgets.
- Zero trust architecture. It sounds like least privilege and complete mediation taken to their logical conclusion, but I would like to see whether it is a genuine architectural shift or good marketing on old principles.
- Security culture. If awareness is one third of the safeguards axis, what does effective training look like? My instinct is that annual compliance videos are not it.
3. Confusions and Challenges
The cells overlap more than the model suggests. When I tried to place a real control into the cube, it refused to sit in one cell. Full-disk encryption is technology, protecting confidentiality, in storage — but it only works because of a key management policy and a user who is trained not to write the passphrase down. The cube is drawn as a grid of discrete boxes and reality behaves more like a smear across them. I am not sure yet whether that is a flaw in the model or a flaw in how I am reading it.
Integrity versus authenticity. I keep collapsing these. Integrity says the data has not been altered; authenticity says it came from who it claims to. A hash gives one, a signature gives both, and non-repudiation seems to sit somewhere nearby. I can recite the distinctions but I cannot yet reliably spot which one a given scenario is testing.
Knowing when "enough" is enough. Defense in depth says add layers. Economy of mechanism says keep it simple. Psychological acceptability says do not make it so painful that users route around it. These three principles point in different directions and nothing in the material told me how to arbitrate between them. I suspect the honest answer is judgment earned through experience, which is not an answer I can study for.
The scale of it. The most uncomfortable realization is that the defender has to be right in all twenty-seven cells and the attacker only has to find one. That asymmetry is motivating and slightly terrifying in equal measure.
Where I landed: the cube is not a solution, it is a checklist for my own blind spots. I would rather have a model that keeps telling me what I forgot than a wall that lets me believe I am finished.
Comments (3) | Trackback | E-mail this page to a friend