Security by Design
By the end of this module you will be able to:
- State the NCSC Secure by Design principles and explain why security must be architectural, not a retrofit
- Apply the STRIDE methodology to identify threats in a data flow diagram
- Describe defence in depth 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 layering controls onto a finished system. The UK NCSC Secure by Design guidance (2018, updated 2023) and the OWASP Top 10 (2021) 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 identifies eight principles for secure systems. The most architecturally significant are: establish the context (what are you protecting, from whom, and under what threat model?); make the security model explicit (document trust boundaries, data flows, and authentication points in a design review); and apply secure defaults (systems should be secure out of the box, not requiring users to opt into security features).
OWASP Top 10 2021 introduced "Insecure Design" (A04:2021) as a new category, separate from implementation errors. Insecure design is a category of risks related to design and architectural flaws. 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.
“Secure by design means that technology products are built to be secure from the start, with security being a foundational element of the design and architecture rather than an add-on.”
UK National Cyber Security Centre (NCSC) - Secure by Design principles, ncsc.gov.uk, 2023
The phrase 'foundational element' is precise. Foundations are load-bearing: they determine what can be built on top of them. A system whose foundation assumes untrusted network traffic can be safely interpreted as code cannot be made secure by adding a firewall. The foundation must change. That change is expensive after construction and cheap at design time.
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 least privilege.
“Threat modelling answers four key questions: What are we building? What can go wrong? What should we do about it? Did we do a good enough job?”
OWASP Threat Modelling - OWASP Threat Model Manifesto, 2020, threat-modeling-manifesto.org
The four questions structure the process: the first anchors it in the actual system (not a theoretical one), the second uses STRIDE or similar frameworks to enumerate threats systematically, the third drives mitigation decisions, and the fourth closes the loop with verification. Threat modelling that stops at the third question without verifying is incomplete.
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 software architecture, 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 secure defaults 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.
A Software Bill of Materials (SBOM) 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.
Key takeaways
- Security by design means security is a foundational architectural decision, not a retrofit. OWASP Top 10 2021 added Insecure Design (A04) as a distinct category from implementation errors.
- 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 by Design. ncsc.gov.uk, 2023.
Principles for securing products and services at design time
The authoritative UK government guidance on Secure by Design principles. Quoted in Section 8.1 for the definition and foundational principle.
A04:2021 Insecure Design; A01:2021 Broken Access Control
The most widely referenced web application security framework. Used in Sections 8.1 and quiz question 2 for the Insecure Design category and Broken Access Control.
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 referenced in the opening story and 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. whitehouse.gov, 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, trunk-based development, and the DORA metrics that measure elite software delivery performance.
Module 8 of 22 in Foundations