Secure Design Principles: Building Cybersecurity Like a Bank Vault, an Apartment Block, and an Airport Checkpoint

A bank does not protect its vault with one oversized padlock.

An apartment building does not give every resident a master key.

An airport does not wave passengers through security because they were checked during their previous journey.

These physical systems work because protection is designed into the environment: entrances are controlled, responsibilities are separated, failures are anticipated, and suspicious activity remains visible.

Secure design principles apply the same thinking to applications, cloud platforms, networks, identities, data, and business processes.

They help architects answer questions such as:

• What could go wrong?
• Who genuinely needs access?
• What happens when a component fails?
• Who is accountable for each control?
• Can one mistake expose the entire system?
• Are we making the secure action the easiest action?

The current Certified Information Systems Security Professional (CISSP) exam outline places threat modelling, least privilege, defence in depth, secure defaults, fail securely, Segregation of Duties, simplicity, Zero Trust, privacy by design, shared responsibility, and Secure Access Service Edge within Domain 3.1.

This article expands those Domain 3.1 concepts into a reusable architecture and exam-thinking framework.

1. Why Secure Design Principles Are Needed

Security teams often inherit systems after the important decisions have already been made.

The application is live.

The cloud environment is connected.

The data model is fixed.

The privileged roles have accumulated permissions.

The deadline has passed.

At that point, security becomes a renovation project inside an occupied building. Doors must be replaced without stopping business. Wiring must be rerouted while customers are using the service. Emergency exits must be added after people have already moved in.

Secure design principles change the order.

Instead of asking, “Which security product should we add?”, the organisation first asks:

“How should this system behave so that common mistakes, attacks, and failures do not become major incidents?”

That shift matters because insecure design is not merely a missing firewall or an unpatched library. It can be a flawed trust assumption, an unsafe workflow, an overpowered service account, an unprotected failure mode, or an architecture that gives one person too much control.

The Open Worldwide Application Security Project (OWASP) describes threat modelling as a structured and repeatable process for understanding a system, identifying applicable threats, and deciding how those threats should be addressed. OWASP recommends performing it during design and maintaining it as the system evolves.

Secure design creates value in four ways:

It prevents expensive rework.
A missing security requirement is easier to fix on a diagram than after thousands of users depend on the system.

It limits blast radius.
When an account, control, or component fails, the damage remains contained.

It makes accountability visible.
Teams know who configures, approves, monitors, tests, and responds.

It supports business resilience.
The organisation can continue operating even when individual safeguards fail.

Think of it as architectural gravity: every later security decision is influenced by the assumptions made during design.

2. Core Secure Design Principles Explained Simply

Threat Modelling: Inspect the Blueprint Before Construction

Technical definition

Threat modelling is a structured process for identifying assets, data flows, trust boundaries, threats, vulnerabilities, attack paths, and appropriate controls while a system is being designed.

It asks four practical questions:

1. What are we building?
2. What could go wrong?
3. What will we do about it?
4. Did we do enough?

These questions closely align with OWASP’s threat-modelling guidance.

Everyday example

Before constructing an apartment block, an architect reviews:

• Public entrances
• Emergency exits
• Underground parking access
• Delivery areas
• Windows reachable from the street
• Access to electrical and water systems

The architect is not predicting one specific burglar. The architect is identifying possible paths through which harm could occur.

Technical example

A team designing an authentication service maps:

User
  |
  v
Login Page ---> Identity Provider
  |                    |
  v                    v
Session Token ---> Application ---> Customer Database

The team identifies several attack paths:

• Credential stuffing against the login page
• Token theft from an insecure browser session
• Privilege escalation within the application
• Direct database access by an overprivileged service account

Controls can then be added before deployment, such as multifactor authentication, rate limiting, short-lived tokens, role validation, and restricted database permissions.

CISSP mindset

When a question asks what the architect should do first to identify potential attacks, begin with threat modelling—not tool selection.

Least Privilege: Give Each Person the Smallest Necessary Key

Technical definition

Least privilege means users, processes, devices, applications, and services receive only the permissions necessary to perform authorised tasks.

Access should be limited by:

• Resource
• Action
• Time
• Environment
• Business purpose

Everyday example

An apartment resident receives a key to:

• Their apartment
• The main entrance
• Approved common areas

They do not receive keys to every apartment, the management office, the electrical room, and the building safe.

Technical example

A backup service account may:

• Read designated production files
• Write encrypted backups to an approved storage location

It may not:

• Create users
• Change firewall rules
• Delete security logs
• Modify application code

If the account is compromised, the attacker inherits a narrow capability rather than control of the entire environment.

CISSP mindset

Least privilege answers:

“How much access is genuinely required?”

It is usually the best answer when the question focuses on limiting the impact of a compromised identity.

Zero Trust: Check Every Entry Request

Technical definition

Zero Trust is a security model that does not grant implicit trust based only on network location, device ownership, or previous access.

Each access request is evaluated using factors such as:

• Identity
• Device condition
• Requested resource
• Authentication strength
• Location
• Behaviour
• Risk
• Current policy

The National Institute of Standards and Technology (NIST) explains that Zero Trust shifts protection away from static network perimeters and towards users, assets, and resources. It assumes that network location alone is not sufficient evidence of trust.

Everyday example

An airport does not admit a passenger to a restricted gate because they passed security last month.

Their identity, ticket, baggage, and current travel authorisation are checked for the present journey.

Technical example

An employee accessing a finance application must:

• Authenticate with phishing-resistant multifactor authentication
• Use a managed and compliant device
• Request access from an approved region
• Hold an appropriate finance role
• Reauthenticate when risk conditions change

Being connected to the corporate network is not enough.

CISSP mindset

Zero Trust does not mean “trust nobody forever.”

It means:

Never treat trust as permanent, automatic, or based solely on location.

Trust but Verify: Allow the Action, Then Validate It

Technical definition

Trust but verify allows an authorised entity to act while monitoring, logging, reviewing, or auditing its behaviour.

Everyday example

A building manager may approve maintenance expenses, but invoices and receipts are independently reviewed.

Technical example

A privileged administrator can change production configurations, but:

• Commands are logged
• Sessions are recorded
• Changes require tickets
• Alerts detect unusual actions
• Reviews confirm the change matched the approved purpose

CISSP mindset

Trust but verify is most relevant after access has already been granted.

Zero Trust decides whether the request should be allowed. Trust but verify checks whether the resulting activity remains legitimate.

Defence in Depth: Use Locks, Cameras, Guards, and Alarms

Technical definition

Defence in depth uses multiple independent and overlapping controls so the failure of one safeguard does not expose the entire system.

Everyday example

A bank uses:

• Entrance controls
• Security guards
• Cameras
• Alarms
• Locked internal doors
• A reinforced vault
• Silent incident notifications

No single control carries the entire burden.

Technical example

A customer application may use:

Internet
   |
Web Application Firewall
   |
Authentication + MFA
   |
Authorisation Checks
   |
Application Validation
   |
Encrypted Database
   |
Logging + Detection

A stolen password does not automatically expose the database because other controls remain active.

CISSP mindset

When a question asks how to remain protected after one control fails, choose layered and complementary safeguards.

Fail Securely: Keep the Door Locked During Failure

Technical definition

Fail securely means a system moves into or remains in a protected state when an error, outage, or unexpected condition occurs.

This is sometimes described as failing closed, although the appropriate response depends on safety and business requirements.

Everyday example

If the electronic controller on a high-security storage room loses communication, the door remains locked rather than opening automatically.

Technical example

An application requests an authorisation decision.

The authorisation service times out.

The application should not interpret “no answer” as “access approved.” It should deny access, restrict functionality, or use a carefully designed safe fallback.

Important nuance

Availability and human safety can change the design.

For example, a fire exit may need to unlock during an emergency. The correct secure state must therefore be defined through risk analysis rather than assumed blindly.

CISSP mindset

When authorisation cannot be verified, the preferred answer is normally to deny access and preserve protection.

Secure Defaults: Deliver the Building Locked

Technical definition

Secure defaults mean systems begin in a protected state. Expanding access or weakening controls requires an intentional and authorised decision.

Everyday example

A new safe is delivered locked.

The customer must deliberately configure who can open it. The safe does not arrive with its door open and a note asking the customer to secure it later.

Technical example

A newly deployed cloud service begins with:

• No public access
• No administrator permissions for standard users
• Encryption enabled
• Logging enabled
• Unused services disabled
• Restrictive network rules
• Mandatory password replacement or unique initial credentials

CISSP mindset

Secure by default means the customer should not need expert knowledge to avoid basic exposure.

The Cybersecurity and Infrastructure Security Agency (CISA) advises manufacturers not to ship products with shared default passwords and recommends secure configurations that avoid exposing administrative interfaces to the internet.

Segregation of Duties: Separate the Requester, Approver, and Reviewer

Technical definition

Segregation of Duties (SoD) divides critical activities among multiple people or roles so one individual cannot independently initiate, approve, execute, and conceal a sensitive action.

Everyday example

One employee prepares a high-value payment.

A second employee approves it.

A third function reconciles the account.

Technical example

For a production change:

Engineer requests change
          |
          v
Manager approves change
          |
          v
Deployment pipeline executes change
          |
          v
Security or operations reviews evidence

The same administrator should not be able to create an unapproved change, deploy it, erase the logs, and approve the result.

CISSP mindset

SoD primarily reduces fraud, conflicts of interest, abuse, and undetected errors.

Shared Responsibility: Know Whether the Landlord or Tenant Owns the Lock

Technical definition

Shared responsibility distributes security duties among multiple parties, with each party accountable for explicitly defined controls.

Everyday example

A landlord maintains:

• The building structure
• Shared entrances
• Lifts
• Fire systems

The tenant manages:

• Their apartment key
• Visitors
• Personal belongings
• Whether the apartment door is locked

Assuming the other party is responsible creates gaps.

Technical example

In a cloud service:

The provider may secure:

• Physical facilities
• Hardware
• Core infrastructure
• Managed-service platform components

The customer may remain responsible for:

• Identity permissions
• Data classification
• Application configuration
• Public exposure
• Endpoint security
• Workload-specific logging

The exact division depends on the service and contract.

CISSP mindset

When several parties are involved, the first step is to define and document who owns each security responsibility.

Keep It Simple and Small: Fewer Doors, Fewer Keys, Fewer Mistakes

Technical definition

Keep it simple and small means minimising unnecessary components, features, integrations, permissions, interfaces, and code.

Everyday example

A building with three well-monitored entrances is easier to protect than one with 47 doors, several forgotten service tunnels, and five different locking systems.

Technical example

A microservice designed only to generate invoices should not also contain:

• User administration functions
• Remote shell access
• Unused database drivers
• Legacy protocols
• Experimental management interfaces

Every unnecessary feature becomes another configuration, dependency, maintenance task, and possible attack path.

CISSP mindset

Complexity is not automatically sophistication.

The best design is usually the simplest one that fully satisfies business and security requirements.

Privacy by Design: Decide What Information the Reception Desk Really Needs

Technical definition

Privacy by design embeds privacy requirements into architecture, workflows, data models, and system behaviour from the beginning.

It includes decisions about:

• What personal data is collected
• Why it is needed
• How long it is retained
• Who can access it
• Where it is stored
• How it is deleted
• How individuals exercise privacy rights

Everyday example

A visitor form asks for the information required to grant building access.

It does not request salary, medical history, family details, and personal interests “in case they are useful later.”

Technical example

A registration service:

• Collects only necessary personal information
• Separates identity data from analytics
• Encrypts sensitive fields
• Applies purpose-based access
• Defines automatic deletion periods
• Prevents production data from being copied casually into testing environments

CISSP mindset

Privacy begins during requirements and design—not after deployment when a compliance review finds excessive collection.

Secure Access Service Edge: Apply the Same Checkpoint Wherever Users Enter

Technical definition

Secure Access Service Edge (SASE) combines network connectivity and security capabilities into an integrated architecture delivered close to distributed users, devices, applications, and resources.

Common capabilities can include:

• Identity-aware access
• Secure web access
• Cloud access controls
• Firewall services
• Data protection
• Wide-area network connectivity

Everyday example

Imagine a property company with buildings in many countries.

Instead of every building inventing its own visitor process, a unified security service applies consistent entry rules regardless of which entrance is used.

Technical example

A remote employee accessing a Software as a Service application is routed through a unified security service that evaluates:

• User identity
• Device health
• Destination
• Data sensitivity
• Threat indicators
• Access policy

This makes policy enforcement less dependent on a traditional corporate network boundary.

CISSP mindset

SASE is an architecture for consistent connectivity and security across distributed environments. It is not merely a remote-access product.

3. Real-World Case Study

Failure Case: The Default Password That Became a Critical-Infrastructure Risk

Situation

CISA and partner agencies reported malicious activity involving Unitronics programmable logic controllers used in sectors including water and wastewater.

Their guidance highlighted dangerous design and deployment conditions such as default passwords and internet-exposed administrative interfaces. CISA urged manufacturers to avoid shared default credentials, require safer first-use configuration, support multifactor authentication, and make products secure out of the box.

Impact

The lesson is larger than one device type.

A default credential creates a predictable entry point. An exposed administration interface makes that entry point reachable. Weak segmentation can then allow a local device compromise to affect a broader operational environment.

Several secure design principles had to work together:

• Secure defaults: Do not ship with predictable credentials.
• Least privilege: Limit the device’s authority and communications.
• Defence in depth: Add segmentation, monitoring, authentication, and restricted management access.
• Keep it simple and small: Remove unnecessary internet-facing management functions.
• Shared responsibility: Clarify what the manufacturer, integrator, and operator must each secure.
• Threat modelling: Identify remote administrative compromise during design.

Lesson

The failure was not simply “somebody forgot to change a password.”

That framing places all responsibility on the customer.

The architectural question is:

Why could an unsafe default remain usable, reachable, and powerful enough to create serious risk?

Secure design removes predictable failure paths instead of assuming every customer will configure every product perfectly.

Success Case: A Composite Secure Design Review

Consider a composite example based on common enterprise architecture practices.

A financial-services company plans a new cloud-based payment platform.

Before writing production code, the team conducts a threat-modelling workshop involving architects, developers, fraud specialists, privacy representatives, operations staff, and incident responders.

They discover that the initial design allows one service account to:

• Read customer records
• Submit payments
• Change beneficiary details
• Access production logs

The team redesigns the platform.

• Payment submission and customer-record access use separate service identities.
• High-risk changes require independent approval.
• Administrative access uses temporary privileges.
• The authorisation service denies requests when it cannot make a decision.
• Personal information is minimised.
• Public access is disabled by default.
• Transactions are monitored for unusual behaviour.
• Each cloud and customer responsibility is documented.
• Security tests validate the threat-model controls before release.

Result

No single control makes the platform “secure.”

The success comes from combining multiple principles so that one mistake does not become a catastrophic event.

Lesson

A mature security architecture does not ask:

“Which principle should we use?”

It asks:

“How do the principles reinforce one another?”

4. Action Framework: Prevent → Detect → Respond

Secure design must move from theory into repeatable decisions.

Use this framework during architecture reviews.

                 SECURE DESIGN WORKFLOW

      PREVENT               DETECT                RESPOND
         |                     |                     |
 Threat model          Log critical actions    Define safe failure
 Secure defaults       Monitor trust changes   Contain identities
 Least privilege       Detect privilege use    Revoke sessions
 SoD approvals         Validate controls       Preserve evidence
 Privacy controls      Identify anomalies      Restore securely
 Simple design         Review responsibilities Learn and redesign

Prevent

Before implementation:

• Model assets, data flows, actors, dependencies, and trust boundaries.
• Identify credible misuse and failure scenarios.
• Remove unnecessary services and interfaces.
• Apply deny-by-default access.
• Assign the minimum permissions needed.
• Separate sensitive initiation, approval, execution, and review duties.
• Minimise personal data collection.
• Document provider, customer, supplier, and internal responsibilities.
• Define what the system must do during failure.
• Establish measurable security requirements.

Detect

During testing and operation:

• Log authentication, authorisation, configuration, and privileged activity.
• Monitor changes in device, identity, and session risk.
• Alert on attempts to use forbidden paths.
• Review temporary and elevated privileges.
• Validate that controls work against identified threats.
• Reconcile actual configurations with approved architecture.
• Detect responsibility gaps when systems or suppliers change.
• Update threat models as features and dependencies evolve.

OWASP treats threat modelling as a maintained activity rather than a one-time workshop.

Respond

When something fails:

• Revoke compromised credentials and active sessions.
• Isolate affected workloads or segments.
• Preserve logs and evidence.
• Move the system into its defined secure state.
• Use layered controls to keep critical services protected.
• Confirm which party owns each recovery action.
• Restore using secure configurations.
• Feed incident lessons back into requirements, architecture, and threat models.

Immediate application challenge

For your next architecture review, ask these six questions:

1. What is the most valuable asset?
2. What is the easiest attack path?
3. Which identity has more access than necessary?
4. What happens when authorisation becomes unavailable?
5. Can one person complete and conceal a critical action?
6. Which security responsibility currently has no clear owner?

5. Key Differences to Keep in Mind

Zero Trust vs Trust but Verify

Difference: Zero Trust evaluates whether access should be granted; trust but verify monitors whether authorised activity remains appropriate.

Scenario: Device posture and identity determine whether an administrator can connect. Session recording then verifies what the administrator does.

Least Privilege vs Segregation of Duties

Difference: Least privilege limits how much one identity can do; Segregation of Duties divides a critical process among multiple identities.

Scenario: A payment clerk can prepare payments but cannot approve them. Their restricted preparation access is least privilege; requiring another person to approve is SoD.

Secure Defaults vs Fail Securely

Difference: Secure defaults define the initial protected configuration; fail securely defines protected behaviour during errors and outages.

Scenario: A new application starts with public access disabled. Later, if its authorisation service fails, requests are denied.

Defence in Depth vs Zero Trust

Difference: Defence in depth creates multiple protective layers; Zero Trust governs explicit, contextual access decisions.

Scenario: Zero Trust checks the user and device before access, while encryption, segmentation, application controls, and monitoring provide additional layers.

Privacy by Design vs Security by Design

Difference: Security protects systems and information against threats; privacy governs appropriate collection and use of personal information.

Scenario: Encryption protects customer records, while data minimisation determines whether those records should have been collected in the first place.

Shared Responsibility vs Segregation of Duties

Difference: Shared responsibility distributes accountability between parties; SoD prevents one party or role from controlling a sensitive end-to-end process.

Scenario: A cloud provider secures infrastructure while the customer secures identities. Inside the customer organisation, separate staff request and approve privileged access.

SASE vs Zero Trust

Difference: SASE is an integrated connectivity and security architecture; Zero Trust is a trust and access philosophy that can be implemented through multiple architectures.

Scenario: SASE provides the distributed enforcement point, while Zero Trust principles determine how access decisions are made.

6. Summary Table

7. 🌞 The Last Sun Rays…

So, what do bank vaults, apartment blocks, and airport checkpoints teach us about secure design principles?

A bank vault teaches us defence in depth. One lock is never enough.

An apartment block teaches us least privilege and shared responsibility. Residents need the right keys, and both the landlord and tenant must understand their duties.

An airport teaches us Zero Trust. Previous approval does not replace verification for the current request.

The most important CISSP lesson is that secure design principles are not isolated vocabulary terms.

They form a decision system:

• Threat modelling asks what could go wrong.
• Least privilege limits what an identity can do.
• Zero Trust challenges automatic trust.
• Defence in depth prepares for control failure.
• Secure defaults make protection the starting point.
• Fail securely preserves protection during uncertainty.
• Segregation of Duties prevents unilateral control.
• Simplicity reduces avoidable attack paths.
• Privacy by design limits unnecessary personal-data risk.
• Shared responsibility prevents accountability gaps.
• SASE supports consistent enforcement across distributed environments.
• Trust but verify checks whether authorised activity remains legitimate.

For CISSP questions, remember the order:

Identify the risk first, design the architecture second, define responsibility clearly, and select technology only after the requirements are understood.

For real systems, use the same mindset.

Do not ask only whether a security control exists.

Ask whether the architecture still protects the organisation when that control fails, an identity is compromised, a provider assumption is wrong, or an operator makes an ordinary mistake.

Which secure design principle would expose the biggest weakness in your current architecture review tomorrow?

Frequently Asked Questions

1. What are secure design principles?

Secure design principles are reusable rules that help architects build systems that resist attacks, limit damage, protect data, and remain secure when components or people fail. Examples include least privilege, defence in depth, secure defaults, threat modelling, and fail-secure behaviour.

2. Which secure design principles are covered in CISSP Domain 3.1?

The CISSP outline includes threat modelling, least privilege, defence in depth, secure defaults, fail securely, Segregation of Duties, keep it simple and small, Zero Trust or trust but verify, privacy by design, shared responsibility, and Secure Access Service Edge.

3. What is the difference between least privilege and Zero Trust?

Least privilege determines how much access an identity receives. Zero Trust determines whether a particular access request should be trusted based on current identity, device, resource, and risk context.

Zero Trust normally uses least privilege, but the two terms are not interchangeable.

4. Why should threat modelling happen before implementation?

Threat modelling helps teams identify risky trust assumptions, data flows, dependencies, and attack paths while the design can still be changed efficiently. OWASP recommends beginning during design and updating the model throughout the system lifecycle.

5. What does fail securely mean?

Fail securely means the system remains protected or moves to a defined safe state when an error or outage occurs. For an access-control service, this commonly means denying access when authorisation cannot be confirmed.

6. Is Zero Trust a product?

No. Zero Trust is a set of security principles and architectural assumptions. NIST describes it as an approach that focuses protection on users, assets, and resources rather than treating network location as sufficient evidence of trust.

7. How does SASE relate to Zero Trust?

SASE can provide distributed network and security enforcement, while Zero Trust supplies the principles used to make identity- and context-aware access decisions. An organisation may use the two together, but they solve different architectural questions.

Surya

By profession, a CloudSecurity Consultant; by passion, a storyteller. Through SunExplains, I explain security in simple, relatable terms — connecting technology, trust, and everyday life.