Security Foundations: The 5 Ideas Every Engineer Needs

In early 2025, UnitedHealth confirmed that around 190 million Americans had their health records exposed in a single breach. The attackers did not crack any clever code. They walked in through a remote-access portal that was missing one setting: multi-factor authentication.

That is the uncomfortable truth about security. The biggest disasters almost never come from genius hackers. They come from a missing basic, a confused concept, or a wrong assumption about who was responsible.

So here is the mental scaffolding that every security engineer reasons from. Master these five building blocks, and almost everything else in security turns into a variation on a theme you already understand.

Why this matters

You do not need to memorize ten thousand attacks. You need a small set of stable ideas you can reason from, then slot every new threat into place.

The numbers make the case. IBM’s 2025 report put the global average cost of a data breach at $4.44 million, with the U.S. average hitting a record $10.22 million. And the headline incidents of the past two years, from Change Healthcare to MGM Resorts, did not start with exotic zero-day exploits. They started with people-and-process gaps that any of these foundations would have caught.

Learn the foundations, and you stop guessing. You start seeing the same handful of patterns everywhere.

What “secure” actually means: the CIA triad

The CIA triad (no relation to the spy agency) names the three properties security exists to preserve. Treat it as a checklist. When you read about any attack, ask: which leg does this hit?

• Confidentiality - only authorized people can read the data. It is protected by encryption, access control, MFA, and data classification. A violation is a data breach: information seen by people who should not see it.
• Integrity - data is accurate, complete, and changed only by authorized actions. It is protected by hashing (a fingerprint that changes if even one byte changes), digital signatures, version control, and input validation. A violation is tampering, fraud, or corruption.
• Availability - authorized users can reach the system when they need it. It is protected by redundancy, backups, failover, and DDoS protection. A violation is an outage, a ransomware lockout, or a denial-of-service.

Think of a library. Confidentiality means only members can read the restricted archive. Integrity means nobody secretly rewrites the books. Availability means the doors are open when you arrive.

A real breach for each leg

The 2024 Change Healthcare breach is a textbook confidentiality failure. Attackers entered through a Citrix portal with no MFA, pulled out roughly 4 TB of data, and exposed the records of about 190 million people. One missing confidentiality control opened the door, at a cost of more than $2.45 billion.

Ransomware often breaks two legs at once. The 2023 MGM Resorts attack began with a single voice-phishing call to the IT help desk. Within hours, slot machines, digital room keys, and reservations went dark across 30-plus properties, an availability disaster. Because modern gangs also leak stolen data, they break confidentiality too.

Here is the catch: the three legs are in tension. Perfect confidentiality, a vault with no network, destroys availability. Security engineering is the art of balancing the three according to how valuable the data is.

How access is controlled: AAA

AAA is a three-step framework for controlling access. The order matters.

1. Authentication (AuthN) - “Who are you?” Prove your identity using something you know (a password), have (a phone or token), or are (a fingerprint). MFA means using two or more of these.
2. Authorization (AuthZ) - “What are you allowed to do?” This is decided after authentication, using models like role-based (RBAC) or attribute-based (ABAC) access control.
3. Accounting (Auditing) - “What did you actually do?” Log every action for forensics, billing, and compliance.

The single most common conceptual mistake in all of security is confusing the first two. Authentication is identity (“you are Alice”). Authorization is permission (“Alice may view order #42 but not #43”).

The web’s number one risk, Broken Access Control, is an authorization failure. The classic case is an IDOR (Insecure Direct Object Reference): you change /order?id=42 to id=43 and see a stranger’s order, because the server checked who you are but never whether this record is yours.

How to build safely: core design principles

Most of these come from a 1975 paper by Saltzer and Schroeder, and they are still taught 50 years later. Treat them as trade-off lenses you hold up while designing, not boxes to tick.

• Defense in depth - layer multiple independent controls so one failure is not fatal. A castle has a moat, a wall, a gate, and guards.
• Least privilege - give every user, process, and service the minimum rights it needs. This limits the blast radius when something is compromised, and it is core to Zero Trust.
• Fail securely - when something errors, default to deny, not allow. Access should require an explicit “yes.”
• Separation of duties - no single person can abuse the system alone. The person who requests a payment must not also approve it.
• Complete mediation - check authority on every access, every time. Never cache a “yes” and trust it forever.
• Secure defaults - ship locked down. Users should opt into risk, not out of safety. Default passwords and open storage buckets are anti-patterns.
• Economy of mechanism - keep the design as small and simple as possible. Complexity hides bugs.
• Open design - security must not depend on the design being secret. As Kerckhoffs put it in 1883, a system should stay secure even if everything but the key is public.
• Psychological acceptability - if security is too painful, people route around it. The secure path must be the easy path. Usability is a security property.

Two warnings worth internalizing. First, “failing open” by accident is everywhere: a door that unlocks when power fails, or an auth check that crashes and lets the request through, is failing insecurely. Second, hiding your source code is not security. DVD copy protection relied on secrecy and broke the moment someone reverse-engineered it.

This is exactly why OWASP added “Insecure Design” to its 2025 Top 10: many flaws are architectural, not coding bugs. You cannot patch your way out of a bad design.

The vocabulary you must never blur

These five words get used interchangeably, and that confusion leads straight to bad decisions.

• Asset - anything of value worth protecting: data, money, systems, reputation. You cannot secure what you have not inventoried.
• Vulnerability - a weakness that could be exploited, like a missing patch or absent MFA. Public ones are catalogued as CVEs.
• Threat - an actor or event that could exploit a weakness: a ransomware gang, a flood, a careless insider. Threats exist whether or not you happen to be vulnerable.
• Exploit - the actual technique or code that takes advantage of a specific vulnerability. A zero-day is an exploit for a flaw that has no patch yet.
• Risk - Likelihood times Impact. This is what executives actually manage. Risk can be reduced but rarely hits zero; what is left over is accepted, insured against, or avoided.

Picture a house. A cracked window is the vulnerability. A burglar in the neighborhood is the threat. Their crowbar method is the exploit. “How likely they break in, and how bad it would be” is the risk. The jewelry inside is the asset.

One pattern to notice: the biggest blind spot is usually human. Both MGM and Change Healthcare began with people and process gaps, not clever code.

How to think: the security mindset

Bruce Schneier described the security mindset in 2008. Where normal engineering asks “how do I make this work?”, security professionals instinctively ask “how can this be made to fail or be abused?” You think like an attacker and distrust assumptions. The good news: it is learnable, not innate.

Two ideas anchor it.

Attack surface is the sum of every point where an attacker could try to get in or pull data out: every input, API, open port, dependency, employee, and third party. The goal is to shrink it.

Trust boundary is any line where the level of control changes: user to app, app to database, your code to a third-party API. Data crossing a boundary must be validated and authenticated. Zero Trust takes this to its logical end: “never trust, always verify,” assuming the boundary is already breached.

        TRUST BOUNDARY        TRUST BOUNDARY        TRUST BOUNDARY
            |                     |                     |
 Internet --|-->  Your App  ------|-->  Database  ------|--> 3rd-party API
 (untrusted)|   (validate &        |   (authZ each      |   (verify certs,
            |    sanitize all      |    query, least    |    scope tokens,
            |    input here)       |    privilege)      |    least trust)

 An attacker probes EVERY arrow (the attack surface). Validate at EVERY '|'.

Who owns security in the cloud

In the cloud, security is split between provider and customer. The mantra: the provider secures “of the cloud” (hardware, hypervisor, datacenter), and you secure “in the cloud” (your data, your access configuration, your app code). The split shifts by service model.

• IaaS (raw servers): the provider secures hardware and virtualization; you secure the operating system and everything above it.
• PaaS (managed platform): the provider also secures the OS and runtime; you secure app code, data, and access config.
• SaaS (finished app): the provider secures almost everything; you still own data classification, identity governance, and access control.

The dangerous assumption is that the provider secures your data. Gartner projected that through 2025 about 99% of cloud security failures would be the customer’s fault, almost always misconfiguration. That is why “Security Misconfiguration” climbed to second place in OWASP’s 2025 Top 10. The cloud does not make you secure. It redraws the trust boundaries you own.

Common misconceptions

• “Encryption alone means secure.” Encryption protects confidentiality. It does nothing for integrity or availability. Ransomware encrypts your data against you.
• “Threat and risk are the same thing.” A threat is a possibility. Risk is that possibility weighed by likelihood and impact. You manage risk; you cannot manage away every threat.
• “Hidden code is safe code.” Obscurity can be a thin extra layer, never the actual control. Assume your design is public.
• “The cloud provider protects my data.” They protect their infrastructure. Your configuration is yours.
• “We will add security at the end.” You cannot bolt on what should have been designed in. Architectural flaws survive every patch.

How to use this

Turn the foundations into habits you apply on every feature.

1. Run the CIA check. For each feature, ask which leg (confidentiality, integrity, availability) it touches and how you protect that leg.
2. Default to deny. Make access require an explicit “yes.” Never grant it by accidental fall-through.
3. Apply least privilege everywhere. Users, services, and machine accounts all get the minimum they need, no more.
4. Guard every trust boundary. Validate and authenticate all data that crosses one. Treat the other side as hostile.
5. Shrink the attack surface. Fewer open ports, fewer features, fewer dependencies, less to defend.
6. Make the secure path the easy path. If security is painful, people will route around it, and they will be right to.
7. Log enough to investigate. You cannot detect or explain what you never recorded.

These map directly onto the frameworks teams use at scale. The OWASP Top 10:2025 (led, again, by Broken Access Control) and NIST CSF 2.0 (which added a central Govern function in 2024) are simply these foundations written down for whole organizations.

Conclusion

If you remember one thing, make it this: security is not a wall you build once, it is a set of trade-offs you balance every day. Five lenses carry almost all of it. What you protect (CIA), how you control access (AAA), how you build (design principles led by least privilege), how you describe danger (asset, vulnerability, threat, exploit, risk), and how you think (the attacker’s mindset).

Notice how often the failures here did not begin with code at all. They began with a phone call, a missing checkbox, a wrong assumption about who was responsible. Which raises the question worth chasing next: if humans are the softest target, how exactly do attackers turn one helpful employee into a 30-property outage? That is the world of social engineering, and it is where these foundations meet the messy reality of people.