3.1 Secure Design Principles
3.1 Secure Design Principles
Secure systems do not happen simply because security products are added after deployment. Security must influence requirements, architecture, design, implementation and operation from the beginning.
Secure design principles provide reusable engineering ideas that help reduce attack surface, limit the consequences of compromise and make systems easier to protect.
Design Securely
Build security into architecture and requirements from the start.
DESIGN BEFORE DEPLOYMENTLimit Exposure
Reduce privileges, functionality, trust and unnecessary attack paths.
REDUCE WHAT CAN GO WRONGVerify Continuously
Do not depend on assumptions about users, systems or network location.
VERIFY BEFORE TRUSTThe Big Idea
Secure design is about making security a property of the system rather than an additional feature placed around it.
Secure by Design
Secure by design means security is considered when the system is being conceived and engineered, rather than relying on users or administrators to repair an insecure design later.
Build the application first.
Perform security testing immediately before production.
Add controls afterwards when problems are discovered.
Identify protection needs and threats early.
Define trust boundaries and security requirements.
Design security into the architecture.
A firewall cannot necessarily repair a fundamentally insecure trust model, excessive privileges or poor separation between critical components.
Secure by Design vs Secure by Default
| Concept | Main question | Example |
|---|---|---|
| Secure by Design | Was security engineered into the system? | The architecture separates administrative services from user-facing services. |
| Secure by Default | Is the system secure before users change its configuration? | Administrative interfaces are not internet-accessible by default. |
A new router supports strong authentication and encrypted management protocols.
However, it ships with:
- a known administrator password;
- Telnet enabled;
- remote administration exposed to the internet;
- logging disabled.
The product may contain security capabilities, but its default configuration is insecure.
CISSP 3.1 Secure Design Principles
| Principle | Core idea |
|---|---|
| Threat Modeling | Understand how the design might be attacked. |
| Least Privilege | Give only the access actually required. |
| Defence in Depth | Use multiple complementary layers of security. |
| Secure Defaults | Start from the safer configuration. |
| Fail Securely | Failure should not automatically create insecure access. |
| Segregation of Duties | Separate critical responsibilities. |
| Keep it Simple and Small | Reduce unnecessary complexity and functionality. |
| Zero Trust / Trust but Verify | Do not depend on assumed trust. |
| Privacy by Design | Build privacy protection into the system. |
| Shared Responsibility | Understand where security responsibilities are divided. |
| SASE | Integrate modern network and security access capabilities. |
👾 Threat Modeling Think like an attacker while you can still change the design
Threat modeling is the structured process of identifying how a system could be attacked and determining which security controls should be incorporated into the design.
A mobile banking application communicates with an API.
Threat modeling may identify:
- stolen user credentials;
- API abuse;
- session theft;
- unauthorised transaction modification;
- sensitive information exposure;
- service-to-service impersonation.
Those threats can then influence authentication, authorisation, transaction validation, logging, encryption and architectural boundaries.
Threat modeling also appears in Domain 1.
In Domain 1, think about threat modeling as part of risk management.
In Domain 3, think about using threat information to influence system architecture and engineering.
🔑 Least Privilege Give only the access that is genuinely required
Least privilege means that a user, application, service or process should receive only the permissions required to perform its authorised function.
A payroll employee can process payroll but cannot administer the operating system.
A reporting application receives read-only access to the database rather than database administrator privileges.
A backup service can read required files but cannot create new domain administrators.
Elevated privileges are provided only when an administrative task requires them.
A web application connects to its database using:
Database Administrator
An attacker who compromises the application could potentially inherit those privileges.
The application account can perform only the specific database operations required by the application.
Application compromise now has a smaller potential blast radius.It does not guarantee that compromise will never occur.
It reduces what a compromised user, service or process can do afterwards.
🛡️ Defence in Depth Never depend entirely on one security control
Defence in depth uses multiple complementary security controls so that failure or bypass of one control does not automatically result in complete compromise.
An attacker steals an employee password.
Defence in depth means the stolen password alone may still not be enough because:
- MFA is required;
- device posture is checked;
- least privilege restricts access;
- network segmentation restricts movement;
- sensitive information is separately protected;
- unusual access generates monitoring alerts.
Installing five firewalls that all depend on the same configuration weakness is not necessarily meaningful defence in depth.
⚙️ Secure Defaults Start secure rather than asking users to become secure
Secure defaults mean that the initial configuration of a system should provide appropriate security without depending on the administrator or customer to manually enable every important safeguard.
Access denied unless explicitly permitted.
Strong authentication enabled.
Unnecessary services disabled.
Security logging enabled.
Administrative interfaces not publicly exposed.
Secure protocols preferred over insecure alternatives.
When a system has no explicit rule permitting an action, denying that action is normally safer than permitting it automatically.
A new cloud storage bucket is created.
A secure default would make the bucket private.
Public access should require a deliberate authorised configuration change.
💥 Fail Securely Think about what happens when the control stops working
Systems fail.
Secure engineering therefore asks:
Failure permits access or continued operation.
Failure denies access or preserves the required security state.
A high-security research facility loses connectivity to its central access-control server.
The secure design may require the protected entrance to remain locked.
Failing securely does not mean blindly locking every door during every failure.
Life safety requirements may require emergency exits to permit evacuation during fire or another emergency.
The correct design depends on the asset, threat and safety requirements.
Fail Securely
Fail safely for people. Fail securely for assets.
👥 Segregation of Duties Do not allow one person to control every critical step
Segregation of Duties, or SoD, divides critical responsibilities between multiple people or roles.
The objective is to reduce fraud, abuse, error and excessive individual control.
One employee:
creates a supplier
Another:
approves the supplier
Another:
authorises payment
A developer creates production code.
A reviewer approves the change.
An authorised deployment process releases it into production.
Some highly sensitive actions may require two authorised individuals to participate before the action can occur.
Segregation of Duties and least privilege are related but different.
Least privilege limits how much authority one entity receives.
Segregation of Duties divides critical authority between multiple entities.
🧩 Keep it Simple and Small Complexity is difficult to secure
Every additional feature, service, dependency, interface and exception increases the amount of system behaviour that must be understood and secured.
A production server needs to host one web application.
It does not need:
- an FTP server;
- a development environment;
- three database engines;
- unused remote-access software;
- sample applications;
- unnecessary management interfaces.
Removing unnecessary components reduces the attack surface and makes the system easier to understand.
A small, understandable security mechanism is generally easier to review, test and maintain than an unnecessarily complicated one.
🎯 Attack Surface Reduction Reduce the number of opportunities available to an attacker
The attack surface consists of the interfaces, services, identities, systems and pathways an attacker could potentially interact with.
Close unnecessary ports and services.
Remove unused components and dependencies.
Remove unused accounts and excessive privileges.
Avoid unnecessary public endpoints.
Expose only required methods and functionality.
Restrict management interfaces to authorised paths.
Attack Surface
If you do not need it, do not expose it.
🔍 Zero Trust Network location alone should not create trust
Traditional security architectures often assumed that systems inside the corporate network were more trustworthy than systems outside it.
Zero trust removes this assumption.
Employee laptop + office network = trusted.
The employee's request may be evaluated using:
Access still occurs.
The important distinction is that trust is not granted automatically simply because a user, device or application is located inside a particular network.
Zero trust moves the security decision closer to the resource and the identity requesting access rather than relying primarily on a large trusted internal network.
✅ Trust but Verify Trust relationships should still be validated
Systems frequently depend on trusted users, suppliers, services, devices and software components.
A secure architecture should avoid treating those relationships as permanently trustworthy without validation.
An organisation trusts a cloud provider to operate part of its infrastructure.
That does not mean the organisation should stop:
- reviewing assurance reports;
- monitoring service performance;
- checking security responsibilities;
- reviewing incidents;
- validating contractual requirements.
The more important the dependency, the more important it becomes to understand how that trust is established, constrained and verified.
🕶️ Privacy by Design Do not bolt privacy onto the system afterwards
Privacy by design means considering privacy requirements while the system, product or process is being designed.
A weather application asks for:
full name, exact date of birth, passport number, precise continuous location and contact list.
But its actual requirement is only to provide the local weather forecast.
Privacy by design challenges unnecessary collection before the system is built around it.A database can be extremely well secured against attackers while still collecting or processing more personal information than the business genuinely requires.
🤝 Shared Responsibility Outsourcing technology does not outsource every security responsibility
Modern systems depend heavily on cloud providers, SaaS vendors, managed-service providers and other external services.
Security responsibilities are therefore frequently shared between multiple parties.
Physical infrastructure, some platform technology, service availability and provider-controlled components.
Users, permissions, information, configurations, application security and appropriate use of the service.
An organisation stores sensitive documents in a SaaS collaboration platform.
The provider may operate the infrastructure.
The customer may still need to:
- configure access appropriately;
- manage user identities;
- enable suitable authentication;
- classify information;
- monitor sharing;
- manage retention requirements.
Moving something to the cloud does not mean:
"The cloud provider is now responsible for all security."
Shared Responsibility
Shared does not mean transferred.
☁️ Secure Access Service Edge - SASE Network and security capabilities for distributed environments
Traditional organisations often routed remote users and branch offices back through a central corporate network before allowing access to applications or the internet.
Modern organisations increasingly have:
Secure Access Service Edge, or SASE, brings networking and security capabilities together so access and security policy can be applied closer to distributed users, devices and services.
Software-defined connectivity across distributed locations.
Security policy for web access.
Visibility and policy around cloud-service use.
Identity and policy-focused access to applications and resources.
Traffic policy and filtering delivered as part of the architecture.
Consistent policy across distributed access locations.
London employee working from home:
Home → VPN → London Data Centre → Security Controls → SaaS
London employee working from home:
User → Nearby Security Service Edge → Authorised SaaS
Access and security policy can follow the user rather than depending entirely on traffic returning through one corporate data centre.
Think about the convergence of network connectivity and security services for distributed users and resources.
SASE
SASE = Connectivity + Security at the Edge
Other Secure Engineering Principles
These concepts help reinforce the secure-design ideas above and commonly appear in security architecture discussions.
Access should be checked whenever a protected resource is requested rather than relying indefinitely on an earlier decision.
Security should depend on appropriately protected secrets such as cryptographic keys, not on keeping the entire design secret.
Reduce unnecessary sharing of mechanisms and resources between different users or trust domains.
Separate components so compromise of one does not automatically compromise everything else.
Divide systems and information into controlled areas to limit exposure and blast radius.
Security mechanisms should be practical enough that legitimate users can use them correctly without constantly attempting to bypass them.
Secure design principles work together
Designing a Customer Banking Application
An organisation is designing a new internet-facing banking application.
Consider how the secure design principles could influence the architecture.
Identify credential theft, API abuse, account takeover, data leakage and transaction manipulation threats.
Application services receive only the database permissions they actually require.
Combine MFA, API controls, segmentation, application validation, encryption and monitoring.
New customer capabilities remain disabled until required authentication and enrolment steps are complete.
If transaction authorisation cannot be validated, the transaction is not automatically approved.
No single employee can develop, approve and deploy a sensitive production change alone.
Remove unnecessary APIs, services and dependencies.
Administrative access requires identity, device and policy verification regardless of network location.
Collect only information required for legitimate banking and regulatory purposes.
Document which security responsibilities belong to the cloud provider and which remain with the bank.
🎓 CISSP Scenarios Apply the design principle rather than memorising the definition
An application service needs read access to one database table. The administrator grants it database administrator rights because this is quicker.
Which principle was violated?
Answer: Least Privilege.
An application requires users to manually enable MFA after creating their account.
The architect proposes enabling MFA automatically for privileged accounts.
Which principle is being improved?
Answer: Secure Defaults.
A firewall fails and automatically allows all traffic because administrators do not want an outage.
Which design principle should be reviewed?
Answer: Fail Securely.
The same employee can create a new supplier, approve the supplier and authorise payment.
Which principle is missing?
Answer: Segregation of Duties.
A production web server contains seven unused services, two development frameworks and several sample applications.
Which principle would MOST directly improve the design?
Answer: Keep it Simple and Small / Attack Surface Reduction.
A company assumes every laptop connected to the office network is trusted and permits broad application access without further checks.
Which principle challenges this design?
Answer: Zero Trust.
An application collects exact location continuously even though it needs only the user's country.
Which principle should the architect apply?
Answer: Privacy by Design.
A company assumes its SaaS provider is responsible for user permissions inside the customer's tenant.
Which concept has been misunderstood?
Answer: Shared Responsibility.
A security architecture uses MFA, network segmentation, endpoint protection, application controls and monitoring.
Which principle is BEST demonstrated?
Answer: Defence in Depth.
Before building an API, architects identify trust boundaries, data flows, attackers and possible abuse scenarios.
Which activity are they performing?
Answer: Threat Modeling.
Remote employees access cloud applications through cloud-delivered network and security services rather than routing every connection through the corporate data centre.
Which architectural concept is MOST relevant?
Answer: SASE.
A sensitive application checks the user's permission when they log in but never checks it again when individual protected resources are requested.
Which supporting design principle should be considered?
Answer: Complete Mediation.
How CISSP is likely to test Secure Design
CISSP questions are more likely to present an architectural problem and ask which principle BEST addresses it than simply ask you to recite a definition.
Excessive permissions
Think: Least Privilege
One control protecting everything
Think: Defence in Depth
Unsafe initial configuration
Think: Secure Defaults
Control failure creates access
Think: Fail Securely
One person controls everything
Think: Segregation of Duties
Too much unnecessary functionality
Think: Keep it Simple / Reduce Attack Surface
Internal network automatically trusted
Think: Zero Trust
Unnecessary personal information
Think: Privacy by Design
"The cloud provider handles everything"
Think: Shared Responsibility
Remote users + cloud + distributed services
Think: SASE
⚠️ Common CISSP Mistakes Important distinctions to remember
Design concerns how the system is engineered.
Defaults concern how securely the system starts operating before configuration changes.
Least privilege limits permissions.
Need-to-know asks whether access to particular information is required for an authorised purpose.
Least privilege limits authority.
Segregation of Duties separates authority.
Effective defence in depth uses complementary controls protecting different attack paths and failure modes.
Security architecture must also account for life safety and business requirements.
The important concept is removing inappropriate implicit trust and continuously making access decisions based on relevant context.
Responsibilities change between service models, but the customer retains security responsibilities.
Encrypting personal information does not answer whether the information should have been collected or retained in the first place.
SASE represents a broader convergence of distributed network and security capabilities.
Quick Comparison
| If the problem is... | Think... |
|---|---|
| We do not know how attackers might target the design | Threat Modeling |
| Users or applications have excessive permissions | Least Privilege |
| The organisation depends on one security control | Defence in Depth |
| The system starts in an insecure configuration | Secure Defaults |
| A component failure grants access | Fail Securely |
| One person has end-to-end control | Segregation of Duties |
| The system contains unnecessary complexity | Keep it Simple and Small |
| Network location creates automatic trust | Zero Trust |
| Too much personal information is collected | Privacy by Design |
| Security responsibility between customer and provider is unclear | Shared Responsibility |
| Distributed users need secure access to distributed resources | SASE |
Secure Design Memory Aid
Model. Limit. Layer. Default. Fail. Divide. Simplify. Verify.
The Secure Architect's Questions
Good architecture assumes that something will eventually fail.
Key Takeaways
Security should be engineered into systems rather than added only after implementation.
Threat modeling identifies how the architecture could be attacked while the design can still be changed.
Least privilege limits users, applications and processes to the permissions they genuinely require.
Defence in depth uses multiple complementary security controls so that one control failure does not automatically result in complete compromise.
Secure defaults place systems in an appropriately protected state before users or administrators make configuration changes.
Fail-secure design considers what happens when security components stop working.
Segregation of Duties prevents one person or role from controlling every stage of a sensitive process.
Simpler systems and smaller attack surfaces are generally easier to understand, test and defend.
Zero trust rejects implicit trust based solely on network location, ownership or similar assumptions.
Privacy by design introduces privacy considerations during requirements and architecture rather than treating privacy as an afterthought.
Shared-responsibility models require organisations to understand exactly which party is responsible for each security activity.
SASE combines modern distributed networking and security capabilities to support users and resources that may no longer be located behind one traditional enterprise perimeter.
Secure architecture does not assume that controls will never fail. It designs the system so that failure and compromise have limited consequences.
📚 Sources & Further Reading Authoritative secure architecture guidance
- ISC2 - CISSP Certification Exam Outline
View the current CISSP Exam Outline - NIST SP 800-160 Vol. 1 Rev. 1 - Engineering Trustworthy Secure Systems
View NIST SP 800-160 - NIST SP 800-207 - Zero Trust Architecture
View NIST Zero Trust guidance - NIST SP 800-215 - Guide to a Secure Enterprise Network Landscape
View NIST enterprise network and SASE guidance - NIST SP 1800-35 - Implementing a Zero Trust Architecture
View NIST Zero Trust implementation guidance - CISA - Secure by Design
Explore CISA Secure by Design guidance