Secure Design Principles

The Principles Behind Every Good Security Decision

Every firewall rule, access policy, and encryption standard traces back to a small set of design principles. These are not abstract academic concepts — they are the reasoning framework that determines whether a system fails safely or catastrophically. The CISSP exam tests whether you can apply these principles to real architectural decisions, not simply recite them.

Design principles are the “why” behind every control. When the exam gives you a scenario you have never seen, these principles are what you reason from.

This module covers CISSP exam objective 3.1: research, implement, and manage engineering processes using secure design principles. ISC2 expects you to recognize when a design violates a principle and which principle should guide the correction.

Defense in Depth

Defense in depth means no single control bears the entire security burden. If the firewall fails, network segmentation limits lateral movement. If segmentation fails, host-based controls contain the damage. If those fail, encryption protects data at rest.

This principle operates across multiple dimensions:

• Administrative — Policies, procedures, background checks, security awareness training
• Technical — Firewalls, encryption, access controls, intrusion detection
• Physical — Fences, locks, guards, cameras, environmental controls

The management value: defense in depth makes explicit that no vendor, product, or control type provides complete protection. Budget decisions that concentrate spending on a single layer — “we bought the best firewall, so we are secure” — violate this principle.

Least Privilege

Every subject — user, process, service account — receives only the minimum permissions required to perform its assigned function. Nothing more. This limits the damage any single compromised account can cause.

Least privilege applies at every layer:

• User accounts — Standard users do not get administrator rights
• Service accounts — A web application connects to its database with read permissions on the tables it needs, not database admin rights
• Network access — Systems only reach the network segments they need to reach
• Physical access — Badge access limited to the floors and rooms a person’s role requires

The failure pattern to recognize: privilege creep. Employees change roles but retain old permissions. After five role changes over ten years, an employee may hold permissions across departments that no single role should have. Periodic access reviews are the governance control that prevents this.

Separation of Duties

No single person should control all phases of a critical transaction. Splitting responsibilities across multiple individuals prevents both fraud and honest mistakes from going undetected.

Classic examples:

• The person who requests a purchase should not approve their own purchase
• The developer who writes code should not promote it to production
• The backup administrator should not also control the restore process without oversight
• The person who creates user accounts should not also approve access requests

Separation of duties is often confused with dual control, but they address different risks. Separation of duties splits a process so no one person can complete it alone. Dual control requires two or more people to act simultaneously — like two keys needed to open a safe deposit box. The exam distinguishes between them.

Fail-Safe and Fail-Secure

When a system fails, its failure state matters as much as its operational state. Secure design specifies what happens when things break.

• Fail-safe — The system defaults to a state that protects people and property. A fire door that unlocks when the fire alarm system loses power is fail-safe: it prioritizes human safety over access control.
• Fail-secure (fail-closed) — The system defaults to denying access or blocking traffic. A firewall that drops all traffic when its rule table corrupts is fail-secure: it prioritizes security over availability.
• Fail-open — The system allows all access when it fails. This is appropriate when availability outweighs security — a hospital corridor door that opens when power fails so patients can evacuate.

The exam tests your judgment about which failure mode is appropriate for a given scenario. The choice depends on what is being protected: human life favors fail-safe/fail-open; data confidentiality favors fail-secure/fail-closed.

Zero Trust

Zero trust eliminates the assumption that anything inside the network perimeter is trustworthy. Every access request is verified regardless of where it originates — inside the corporate network, from a VPN, from a branch office, or from a coffee shop.

Zero trust operates on three core ideas:

1. Never trust, always verify — Every request is authenticated and authorized, every time
2. Assume breach — Design as if an attacker is already inside the network
3. Verify explicitly — Make access decisions based on all available signals: identity, device health, location, behavior patterns, data sensitivity

Zero trust is not a product you install. It is an architecture and a philosophy. It includes micro-segmentation, continuous authentication, conditional access policies, and data-centric protection. The exam wants you to understand that zero trust shifts the trust boundary from the network perimeter to each individual resource.

Privacy by Design

Privacy by design means building privacy protections into systems from the start, not bolting them on after a regulator complains. Ann Cavoukian’s seven foundational principles guide this approach:

1. Proactive not reactive — Prevent privacy incidents rather than responding to them
2. Privacy as the default — Personal data is automatically protected; users should not have to take action to protect their own privacy
3. Privacy embedded in design — Privacy is integral to the system architecture, not an add-on
4. Full functionality — Privacy and functionality are not trade-offs; both can be achieved
5. End-to-end security — Data is protected throughout its entire lifecycle
6. Visibility and transparency — Operations remain visible and verifiable by independent parties
7. Respect for user privacy — User interests are kept paramount in design decisions

For the CISSP exam, privacy by design connects directly to regulatory requirements like GDPR, which mandates “data protection by design and by default.” When a scenario describes a system collecting more personal data than it needs, or retaining it longer than necessary, the violated principle is privacy by design.

Security Defaults

Systems should ship in a secure state. Out of the box, unnecessary services are disabled, default passwords are changed or absent, and permissions are restrictive. Users opt in to less security, not out of it.

This principle is violated constantly in practice:

• Applications that install with administrative accounts using “admin/admin” credentials
• Cloud storage buckets that default to public access
• Databases that listen on all network interfaces by default
• Services that enable every feature rather than starting minimal

Security defaults intersect with least privilege: the default configuration should provide the minimum access and functionality needed. Adding capabilities is a conscious decision that requires justification.

Trust but Verify

Some level of trust is necessary for systems and organizations to function. You trust your employees, your vendors, and your partners — but you verify that trust through monitoring, auditing, and accountability mechanisms.

Verification takes many forms:

• Logging and monitoring — Recording actions so they can be reviewed and attributed
• Auditing — Independent review of whether controls are operating as intended
• Access reviews — Periodic validation that permissions still match roles
• Background checks — Verification before granting trust, not only after a problem occurs

Note the tension with zero trust: traditional “trust but verify” assumes a baseline of trust and adds verification. Zero trust inverts this by starting from no trust and requiring verification for every action. The exam may present scenarios where you need to identify which philosophy is more appropriate — typically zero trust for technical architecture, trust but verify for personnel and partner relationships.

Pattern Recognition

Secure design principle questions on the CISSP follow these structures:

• Design flaw identification — A scenario describes a system architecture. You identify which principle was violated. Look for: single points of failure (defense in depth), excessive permissions (least privilege), one person controlling everything (separation of duties).
• Failure mode selection — A system fails. You determine the correct failure behavior. Human safety drives the answer: if lives are at stake, fail-safe/fail-open; if data is at stake, fail-secure.
• Principle application — A new system is being designed. You recommend which principle should guide a specific design decision. The answer matches the risk: fraud risk points to separation of duties, breach impact points to defense in depth.
• Zero trust vs. perimeter — A scenario describes a network design assumption. You identify whether the architecture reflects perimeter-based trust (outdated) or zero trust (modern). Look for blanket trust based on network location.

Trap Patterns

Watch for these wrong answers:

• “Defense in depth means buying more security products” — It means layering different types of controls (administrative, technical, physical), not stacking similar products from different vendors.
• “Least privilege is only about user accounts” — It applies equally to service accounts, processes, network access, and physical access. Any answer that limits it to one domain is incomplete.
• “Zero trust replaces all other controls” — Zero trust is an architecture philosophy, not a replacement for firewalls, encryption, or access management. It changes how trust decisions are made, not which controls exist.
• “Fail-secure is always the correct default” — When human safety is the priority, fail-safe or fail-open is correct. Fire exits should never fail-closed.
• Confusing separation of duties with dual control — Separation splits a process across people; dual control requires simultaneous action. They solve different problems.

Scenario Practice

Question 1

A financial institution’s database administrator has the ability to create user accounts, assign permissions, modify transaction records, and delete audit logs. Management has not assigned anyone to review the DBA’s activities.

Which secure design principle is MOST directly violated?

A. Defense in depth
B. Least privilege
C. Separation of duties
D. Trust but verify

Question 2

A hospital is redesigning its access control system for the emergency department. During normal operations, doors require badge access. The architect must decide what happens when the access control system loses power.

What failure mode should the architect select for the emergency department doors?

A. Fail-secure — doors remain locked until power is restored to prevent unauthorized access
B. Fail-safe — doors unlock to allow free movement for patient care and evacuation
C. Fail-open with a manual override that requires a key to lock
D. Maintain current state — doors that were locked stay locked, doors that were open stay open

Question 3

A company migrates to a cloud-based architecture. The security team proposes that all internal services should authenticate and authorize every request, regardless of whether the request originates from the corporate network or the internet. The network team objects, arguing that traffic within the internal VPC is already trusted.

Which design philosophy should guide this decision?

A. Trust but verify — allow internal traffic but log it for review
B. Defense in depth — add a second firewall between internal services
C. Zero trust — network location should not be a basis for trust; verify every request
D. Least privilege — restrict which services can communicate with each other

Key Takeaway

Secure design principles are a decision framework, not a checklist. The exam gives you scenarios with imperfect information and competing priorities. Your job is to identify which principle applies and how it changes the design decision. Defense in depth addresses single points of failure. Least privilege limits blast radius. Separation of duties prevents concentration of power. Fail-safe protects people. Zero trust eliminates implicit trust. When you cannot determine the answer from specific technical knowledge, reason from principles — that is exactly what ISC2 is testing.