Security by Design
By the end of this module you will be able to:
- State the five groups of NCSC secure design principles and explain why security must be architectural, not a retrofit
- Apply the methodology to identify threats in a data flow diagram
- Describe with at least three concrete layers of control
- Explain what a Software Bill of Materials is and why Log4Shell exposed supply chain risk
With the learning outcomes established, this module begins by examining security by design principles in depth.
8.1 Security by design principles
Security by design means building security properties into a system from the first design decisions, not controls onto a finished system. The UK NCSC secure design principles (published 2019) and the current OWASP Top 10:2025 both start from the same premise: security that is retrofitted is consistently less effective and more expensive than security that is designed in.
The NCSC does not publish a flat list of principles. It organises them into five groups, each matching a stage at which an attack can be frustrated. Establish the context: work out what you are protecting, from whom, and under what threat model, so that no part of the system is a defensive blind spot. Making compromise difficult: raise the cost of gaining a first foothold. Making disruption difficult: keep the service available while it is under attack. Making compromise detection easier: design so that suspicious activity is visible rather than buried. Reducing the impact of compromise: limit what an attacker can reach once inside. The last two are the most architectural of the five, because detectability and follow from how a system is decomposed, not from any single control bolted on later.
Insecure Design entered the OWASP Top 10 in 2021 as a category separate from implementation errors, and it remains in the current release as A06:2025. It covers risks that come from design and architectural flaws rather than from coding mistakes. Log4Shell is the canonical example: the JNDI feature was architecturally insecure. No amount of patching the surrounding code would have fixed the fundamental design error. It required removing the feature. The 2025 release also adds Software Supply Chain Failures at A03:2025, which is the subject of Section 8.5.
Security as four nested boundaries: Network, Identity, Data, Trust
Each ring carries its own mechanism, firewalls at the network, single sign-on at identity, encryption at data and authorisation at trust, so a perimeter held by the outer ring alone leaves the three inner rings unguarded.
Identity is the ring that ties the others together; trust sits at the centre because the others all defer to it. Source: NIST SP 800-207 Zero Trust; OWASP ASVS 4.0; NCSC Cyber Assessment Framework.
With an understanding of security by design principles in place, the discussion can now turn to threat modelling with stride, which builds directly on these foundations.
8.2 Threat modelling with STRIDE
Threat modelling is the structured process of identifying what could go wrong with a system before it is built. STRIDE, developed by Microsoft in the late 1990s and formalised by Loren Kohnfelder and Praerit Garg, provides six categories of threat that together cover the attack surface of any software system.
Spoofing (S): claiming to be someone you are not. An attacker using stolen credentials to access an API. Mitigated by strong authentication: MFA, short-lived tokens, mutual TLS.
Tampering (T): modifying data without authorisation. An attacker intercepting an API request and changing the transaction amount. Mitigated by integrity controls: digital signatures, TLS in transit, parameterised queries.
Repudiation (R): denying that an action occurred. A user claiming they never placed an order that they did place. Mitigated by non-repudiation controls: audit logs with timestamps, digital signatures on critical actions.
Information Disclosure (I): exposing data to unauthorised parties. An overly verbose error message containing a stack trace with database connection strings. Mitigated by access controls, encryption at rest, minimum necessary data in logs and error responses.
Denial of Service (D): making a system unavailable. Flooding an API with requests until it exhausts connection pools. Mitigated by rate limiting, circuit breakers, auto-scaling, and edge protection (CDN, WAF).
Elevation of Privilege (E): gaining capabilities beyond those granted. An API parameter that allows a customer to access another customer's account by changing an account ID. Mitigated by server-side authorisation checks on every request, principle of .
Threat, control, and evidence form a closed loop
Threats choose controls, controls demand evidence, and the dashed arrow carries evidence back to threats, so a control nobody tests, logs or reviews stays an assumption on the design rather than a defence.
Without the loop closing the design degrades; checklists alone become assumptions. Source: NIST SP 800-30; OWASP Threat Modeling 2024; STRIDE methodology Microsoft 1999.
With an understanding of threat modelling with stride in place, the discussion can now turn to defence in depth, which builds directly on these foundations.
8.3 Defence in depth
Defence in depth is the security principle that no single control should be the only line of defence. If the outer control fails, the inner controls limit the impact. The analogy is a medieval castle: a moat, then a wall, then an inner keep, then the vault. An attacker who crosses the moat has not reached the vault.
In , defence in depth applies across layers. At the network layer: WAF (Web Application Firewall) blocks malicious HTTP patterns; VPC private subnets prevent direct internet access to databases; Security Groups enforce least-privilege network rules between containers. At the application layer: authentication verifies identity; authorisation checks permissions on every request; input validation blocks malformed data before it reaches business logic.
At the data layer: encryption at rest (AES-256) protects data if storage media is stolen; encryption in transit (TLS 1.3) protects data from interception; column-level encryption for PII (Personally Identifiable Information) limits the blast radius of a database compromise. At the operational layer: Security Information and Event Management (SIEM) systems detect anomalous patterns; intrusion detection systems flag unexpected network behaviour.
Log4Shell propagated so rapidly in December 2021 because many systems lacked outbound network controls on their application containers. A container that could not make arbitrary outbound TCP connections to the internet could not complete the JNDI lookup chain. Defence in depth at the network egress layer would have reduced the exploitability of the vulnerability for any system that had it deployed.
Common misconception
“Security can be added after the system is built.”
Log4Shell exists because the JNDI lookup feature was added to Log4j without security review of its misuse potential. The fix required removing the feature, not patching the code around it. Retrofitting security is consistently more expensive: NIST research from 2002 (replicated in 2020) estimates that fixing a security defect in production costs 30 times more than finding it at design time. Security properties that depend on architectural decisions (trust boundaries, data flows, authentication points) cannot be added after the architecture is fixed.
With an understanding of defence in depth in place, the discussion can now turn to and least privilege, which builds directly on these foundations.
8.4 Secure defaults and least privilege
Secure defaults mean that a system is secure in its default configuration. A developer who installs and runs the system without additional configuration should not inadvertently expose an insecure system. Default credentials must not exist. Debug endpoints must not be enabled in production builds. Verbose error messages must not be the default response.
Zero trust architecture extends this principle to network design. Traditional perimeter security assumes that anything inside the corporate network is trusted. Zero trust assumes that no user, device, or service is trusted by default, regardless of network location. Every request is authenticated and authorised, even if it originates from inside the VPC (Virtual Private Cloud). Google's BeyondCorp model, published in 2014, was the first large-scale implementation: Google removed network-level trust entirely and enforced identity-based access for every internal system.
With an understanding of secure defaults and least privilege in place, the discussion can now turn to supply chain security and sbom, which builds directly on these foundations.
8.5 Supply chain security and SBOM
Log4Shell demonstrated that an organisation's attack surface extends to every library in every transitive dependency in every deployed container. The Log4j library was a transitive dependency in hundreds of commercial products: it was present in systems whose developers had never heard of Log4j, because a library they used directly depended on it. The OWASP Top 10:2025 places Software Supply Chain Failures third in its list, at A03:2025.
A is a machine-readable inventory of every software component in a deployed artefact, including transitive dependencies, their versions, and known vulnerabilities at the time of build. The US Executive Order on Improving the Nation's Cybersecurity (May 2021, EO 14028) mandated SBOM production for all software sold to the US federal government from 2022 onward. The EU Cyber Resilience Act (2024) extends similar requirements to products sold in the EU.
Architecturally, SBOM production integrates into the CI/CD pipeline at build time. Tools like Syft (by Anchore) or Trivy generate SBOM documents in SPDX or CycloneDX format from container images, Maven/Gradle dependency trees, or npm lock files. Pairing SBOM generation with a CVE scanner creates a continuous vulnerability monitoring loop: when a new CVE is published for a dependency, the SBOM enables automated identification of every affected service in the fleet.
Common misconception
“Encryption means security.”
Encryption is one control addressing one threat category: Information Disclosure in transit and at rest. STRIDE analysis shows that most attack vectors have nothing to do with encryption. Spoofing (stolen credentials), Elevation of Privilege (broken authorisation), and Tampering (SQL injection) all succeed on fully encrypted systems. Log4Shell is a Remote Code Execution vulnerability that operated over HTTPS. The channel was encrypted; the payload was not validated. Encryption without threat modelling addresses one of six STRIDE categories.
A design review asks which of the five NCSC secure design groups covers keeping a service usable by legitimate customers while an attack is actually under way. Which group is that?
A team argues that its payments service is secure because every connection uses TLS 1.3 and every stored record uses AES-256. Which reply follows from this module's treatment of encryption?
A team describes its architecture as zero trust because the databases sit in private subnets and only the load balancer faces the internet. How should that description be assessed?
Core distinctions
- Security by design means security is a foundational architectural decision, not a retrofit. The OWASP Top 10:2025 keeps Insecure Design as a distinct category from implementation errors, at A06:2025, and adds Software Supply Chain Failures at A03:2025.
- STRIDE provides six threat categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Apply it to each element and relationship in a data flow diagram.
- Defence in depth means no single control is the only line of defence. Network, application, data, and operational layers each provide independent controls that limit blast radius.
- Secure defaults and zero trust: systems should be secure out of the box; every request is authenticated and authorised regardless of network origin.
- Log4Shell propagated via transitive dependencies. A Software Bill of Materials (SBOM) enables automated identification of every service containing a vulnerable component when a CVE is published.
- Encryption addresses one STRIDE category (Information Disclosure). Threat modelling shows that most attacks, including Log4Shell, operate on vectors that encryption does not address.
Standards and sources cited in this module
UK National Cyber Security Centre (NCSC). Secure design principles. ncsc.gov.uk, 2019.
The five groups: establish the context; making compromise difficult; making disruption difficult; making compromise detection easier; reducing the impact of compromise
The authoritative UK government guidance on designing secure systems. The collection is organised into the five groups listed in Section 8.1, each matching a stage at which an attack can be frustrated, and it is the source of the quotation in that section.
A03:2025 Software Supply Chain Failures; A06:2025 Insecure Design
The most widely referenced web application security framework, and the current release. Used in Section 8.1 for the Insecure Design category and in Section 8.5 for supply chain failures.
NIST NVD. CVE-2021-44228 (Log4Shell). nvd.nist.gov.
Vulnerability description, CVSS score, and affected versions
The official vulnerability record for Log4Shell. Provides the CVSS 10.0 score and affected version range used in the terminal simulations.
Kohnfelder, L. and Garg, P. The threats to our products. Microsoft, 1999.
STRIDE framework definition
The original source for the STRIDE threat modelling framework. Used throughout Section 8.2 for the definitions of all six threat categories.
US Executive Order 14028. Improving the Nation's Cybersecurity. Federal Register, May 2021.
Section 4: Enhancing Software Supply Chain Security
The policy mandating SBOM production for federal software suppliers. Referenced in Section 8.5 for the supply chain security context and SBOM regulatory requirement.
OWASP Threat Modelling. Threat Model Manifesto. threat-modeling-manifesto.org, 2020.
The four key questions framework
Quoted in Section 8.2 for the four-question structure of threat modelling. Provides the process framework that STRIDE questions are applied within.
What comes next: Secure architecture needs to reach production safely and frequently. Module 9 covers CI/CD pipelines, the distinction between continuous delivery and continuous deployment, feature flags, , and the DORA metrics that measure elite software delivery performance.
Module 8 of 31 in Foundations