Secure design principles I: threat modeling, least privilege and defense in depth

Domain 3 of the CISSP, Security Architecture and Engineering, is where security stops being a set of policies and becomes a property of the systems an organization builds and buys. In the exam outline that has applied since April 2024 it carries about 13 percent of the weight, and it is famously broad: design principles, formal security models, hardware security features, vulnerabilities in every kind of system from a smart thermostat to a supercomputer, cryptography from the mathematics of key spaces to the management of certificates, and the physical design of buildings and server rooms. This course works through all nine sub-domains in twelve lessons. Always check the current exam outline on the ISC2 website before you book your exam.

This first lesson and the next cover sub-domain 3.1, research, implement and manage engineering processes using secure design principles. These principles are not rules for one product; they are habits of thought that a security architect brings to every design review. They also explain why many controls covered later exist at all. When you understand that least privilege, separation of duties and defense in depth are the reasons behind a control, you can answer scenario questions about controls you have never seen before.

Security is designed in, not bolted on

The cheapest moment to fix a security flaw is before it is built. A design change on a whiteboard costs minutes; the same change after a product has shipped can mean patches, recalls, breach notifications and lost customers. Studies of software defects have long shown that the cost of fixing a flaw grows sharply the later it is found, and security flaws follow the same pattern. That is why secure development life cycles place threat modeling and security requirements at the start of a project, and why the CISSP treats architecture as a management responsibility as much as a technical one. A manager who signs off a design without security review has accepted risk on the organization's behalf, whether or not they realized it.

Security by design also means designing for the whole life of the system: how it will be patched, how keys will be rotated, how logs will be collected, how it will be decommissioned and how its data will be destroyed. A system that is secure on the day it goes live but cannot be updated safely is not secure. The principles in this lesson apply at every one of those stages.

Threat modeling

Threat modeling is a structured way of asking four questions about a system: what are we building, what can go wrong, what are we going to do about it, and did we do a good job? It produces a picture of the system, usually a data flow diagram that shows processes, data stores, external entities and the flows between them, with trust boundaries drawn wherever data crosses from one level of trust to another. Most attacks happen at or across those boundaries, so they are where the analysis concentrates.

Several methods help teams find threats systematically. STRIDE, developed at Microsoft, gives six categories to check for each element: spoofing identity, tampering with data, repudiation, information disclosure, denial of service and elevation of privilege. Each maps to a property that a control should protect: authentication, integrity, nonrepudiation, confidentiality, availability and authorization. PASTA, the Process for Attack Simulation and Threat Analysis, is a seven-stage, risk-centered method that starts from business objectives and ends with residual risk. Attack trees break an attacker's goal into the alternative ways of reaching it, which makes it easy to see where one control would block many paths. Older scoring schemes such as DREAD rated threats on damage, reproducibility, exploitability, affected users and discoverability, but they are now seen as subjective, and many teams use CVSS or their own risk matrix instead. MITRE ATT&CK, a knowledge base of real attacker techniques, is useful for checking that a model reflects how attacks actually unfold.

Threat models are living documents. They should be updated when the design changes, when a new type of attacker appears or when an incident reveals a path nobody had considered. A model that was produced once for an audit and never revisited gives false comfort.

Least privilege and need to know

The principle of least privilege says that every user, process and system should have only the access it needs to do its job, for only as long as it needs it. It limits the damage a mistake, a malicious insider or a compromised account can do. In practice it shows up as role-based access, separate administrator accounts, service accounts with narrowly scoped permissions, just-in-time elevation that grants administrator rights for an hour and then removes them, and software that drops privileges after starting. Need to know is a closely related idea from the world of classified information: even a person cleared to Secret does not see every Secret document, only those their duties require.

Privilege tends to grow over time. People change roles and keep their old access; temporary permissions become permanent; projects end but their accounts remain. This privilege creep is why periodic access reviews, covered in the identity domain, are a design concern too: a system that makes it easy to see and revoke access supports least privilege far better than one where permissions are scattered across many places.

Defense in depth

Defense in depth, sometimes called layered defense, means relying on several independent controls so that the failure of one does not expose the asset. A database of customer records might be protected by a firewall, network segmentation, hardened servers, strong authentication, application access controls, encryption at rest, monitoring and backups. An attacker who gets past the firewall still faces authentication; one who steals credentials still meets segmentation and monitoring. The layers should be diverse, mixing preventive, detective and corrective controls and administrative, technical and physical ones, because identical layers tend to fail together. Two firewalls from the same vendor running the same rules add less than a firewall plus endpoint protection plus logging.

Defense in depth is not an excuse to pile on controls without thought. Each layer has costs, including complexity, which can itself introduce flaws. The architect's job is to choose layers that cover different failure modes at a reasonable cost.

Secure defaults and failing securely

Secure defaults means that a system should be safe in its out-of-the-box configuration. Default passwords, open administrative ports, sample applications and verbose error messages have been the root cause of countless breaches because many installers never change them. Good design ships with strong settings and makes weakening them a deliberate, logged choice. Regulators increasingly expect this: legislation on connected devices in several countries now bans universal default passwords, and secure-by-design guidance from national cyber agencies asks manufacturers to take responsibility for safe defaults rather than leave them to customers.

Fail securely, also called fail safe or fail closed in an access control context, means that when a component fails it should deny access rather than grant it. A firewall that crashes should block traffic; an authentication service that cannot reach its directory should refuse logins, not accept them. There is an important exception where human life is involved. A door controlled by a card reader on an emergency exit route must unlock if the power fails, because people must be able to escape a fire. This is called fail safe in the life-safety sense, and the CISSP expects you to know that the safety of people always comes first. Architects therefore separate the questions of what happens to data and what happens to people when something fails.

Separation of duties and keeping it simple

Separation of duties divides a sensitive task among two or more people so that no single person can complete it alone. The person who creates a vendor in the payment system should not be the person who approves payments to that vendor; the developer who writes code should not be the one who deploys it to production unreviewed. Dual control and two-person integrity are stronger forms in which two people must act together, for example to open a vault or to use a root signing key. Job rotation and mandatory vacations support the same aim by making it harder to hide fraud over long periods. Separation of duties is costly in small organizations, so compensating controls such as independent review of logs are sometimes used instead.

Keep it simple, or economy of mechanism, recognizes that complexity is the enemy of security. Every additional feature, interface and configuration option is something that can be misunderstood or misconfigured. Simple designs are easier to review, test and operate. Related principles include minimizing the attack surface by removing unneeded services and code, complete mediation, which means checking every access to every object rather than relying on a check made earlier, and open design, the idea that a system should remain secure even if its design is public, so that security rests on keys and secrets rather than on obscurity.

Thinking like a manager

Exam questions in this area usually describe a design decision and ask what should happen first or which principle is being applied. When a question asks what to do before building something, the answer is often to perform threat modeling or define security requirements. When a question describes one person able to complete a sensitive process alone, the issue is separation of duties. When it describes a door that locks people in during a power failure, life safety overrides security. And when several answers would each improve security, prefer the one that addresses the root cause in the design rather than adding a compensating control later.