Security by Design | Cybersecurity Policy

Slide 1 of 13  |  CSP-W1  |  Week 1
Security by Design
Build It In  --  Don't Bolt It On
In 2017, Equifax disclosed a breach exposing 147 million records. The root cause was an unpatched Apache Struts vulnerability -- a known flaw with a patch available two months before the breach. The monitoring tools that should have caught the intrusion were offline because an SSL certificate had expired. Neither failure was exotic. Both were preventable by design. Security by Design is the discipline of making those failures structurally impossible rather than hoping someone remembers to prevent them.
13 Slides CIS2208 Week 1 Cybersecurity Policy
Slide 2 of 13
What Is Security by Design?
Security is an architectural property, not a feature you add later.
The Principle
Security by Design means incorporating security requirements, threat analysis, and defensive controls into every phase of system development -- from the initial requirements gathering through architecture, implementation, testing, deployment, and maintenance. Security is not a phase; it is a continuous property of the system.
The Alternative (and Why It Fails)
The opposite approach -- "bolt-on security" -- treats security as an afterthought. Build first, scan later, patch when breached. This model consistently fails because retrofitting security into an insecure architecture is exponentially more expensive and less effective than building it in from the start. You cannot add structural integrity to a building after the foundation is poured.
SECURITY BY DESIGN REQ DESIGN CODE TEST OK BOLT-ON SECURITY BUILD SHIP BREACH PATCH
Cost Multiplier
IBM's Systems Sciences Institute found that fixing a defect in production costs 6x more than fixing it during design and 15x more than fixing it during requirements. For security defects, the multiplier is even higher because a security flaw in production may already be exploited before the patch arrives.
Slide 3 of 13
Saltzer & Schroeder's 8 Design Principles (1975)
Published in "The Protection of Information in Computer Systems." Still the foundation of secure systems design fifty years later.
1. Economy of Mechanism
Keep it simple. Every line of code is attack surface. Complexity is the enemy of security -- simpler systems are easier to verify and harder to subvert.
2. Fail-Safe Defaults
Default to deny. Access decisions should be based on permission, not exclusion. If a check fails or is missing, the result must be "access denied."
3. Complete Mediation
Check every access. Every request to every object must be verified against the access control policy. No bypasses, no cached permissions that outlive their validity.
4. Open Design
Security should not depend on secrecy of the design. The mechanism should be secure even if everything except the keys is public knowledge (Kerckhoffs' principle).
5. Separation of Privilege
Require multiple conditions to grant access. No single key should unlock the vault. Two-person integrity, MFA, and dual-authorization are implementations of this principle.
6. Least Privilege
Every subject operates with the minimum set of privileges needed. No more access than necessary, no longer than necessary. Revoke when the task is complete.
7. Least Common Mechanism
Minimize shared resources between users. Shared mechanisms are covert channels and privilege escalation paths. Isolate where possible.
8. Psychological Acceptability
Security mechanisms must be usable. If the secure path is harder than the insecure path, users will bypass it. Design security that humans will actually follow.
Why This Still Matters
These principles predate the modern internet, cloud computing, and mobile devices. They remain valid because they describe properties of secure systems at a level of abstraction that transcends specific technologies. Every major breach in the last decade violated at least one of these eight principles.
Slide 4 of 13
Secure Software Development Lifecycle (SSDLC)
Security activities mapped to every phase of the development lifecycle -- not just testing.
SSDLC Security at every phase Requirements Design Code Test Deploy Maintain Threat modeling Security architecture Secure coding Pen testing / SAST / DAST Hardening / config review Patch mgmt / monitoring
Requirements
Define security requirements alongside functional requirements. Classify data sensitivity. Identify compliance obligations (HIPAA, PCI DSS, GDPR).
Design
Threat model the architecture. Apply Saltzer & Schroeder. Define trust boundaries, authentication flows, and encryption requirements before writing any code.
Code / Test / Deploy / Maintain
SAST and peer review during coding. DAST and pen testing before release. Hardened deployment configurations. Continuous monitoring and patching in production.
Slide 5 of 13
Threat Modeling: STRIDE
Microsoft's STRIDE framework systematically identifies threats by category. Used during the design phase to find vulnerabilities before they become code.
S Spoofing Identity T Tampering Integrity R Repudiation Accountability I Info Disclosure Confidentiality D Denial of Svc Availability E Elevation Authorization Mitigation: Authentication MFA, certificates Mitigation: Integrity checks HMAC, signing Mitigation: Audit logging Non-repudiation Mitigation: Encryption Access controls Mitigation: Rate limiting Redundancy Mitigation: Least privilege Input validation
How It Works
Draw a data flow diagram of the system. Identify trust boundaries where data crosses between components with different privilege levels. At each boundary, systematically ask: can an attacker Spoof identity? Tamper with data? Repudiate actions? Disclose information? Deny service? Elevate privilege? Document each threat and assign a mitigation.
When to Apply
Threat modeling happens during design -- before code is written. It is revisited when the architecture changes, when new features are added, or when new threat intelligence emerges. A threat model is a living document, not a one-time deliverable.
Slide 6 of 13
Privacy by Design
Ann Cavoukian's 7 foundational principles (1990s). Now embedded in GDPR Article 25 as a legal requirement.
1 Proactive not Reactive Prevent, don't remediate 2 Privacy as the Default No action needed to protect data 3 Embedded into Design Core function, not add-on 4 Full Functionality Positive-sum, not zero-sum 5 End-to-End Lifecycle Cradle to grave data protection 6 Visibility & Transparency Open to audit and verification 7 Respect for User Privacy User-centric design defaults
GDPR Article 25 -- Data Protection by Design and by Default
"The controller shall implement appropriate technical and organisational measures... which are designed to implement data-protection principles, such as data minimisation, in an effective manner." Privacy by Design went from best practice to legal obligation in 2018. Non-compliance penalties: up to 4% of annual global revenue.
Parallel to Security by Design
The overlap is deliberate. Privacy and security share the same architectural foundations: minimize data collection, encrypt at rest and in transit, enforce access controls, audit access, and design for the assumption that breaches will occur. Privacy without security is impossible; security without privacy is incomplete.
Slide 7 of 13
Secure Architecture Patterns
Three foundational patterns for network and system architecture: DMZ, microsegmentation, and zero trust.
DMZ Internet DMZ Web / Proxy Internal Network Microsegmentation Web API DB Auth Cache Log Each segment isolated -- lateral movement blocked Zero Trust Never Trust Always Verify ID MFA CTX Verify identity + device + context for every request
DMZ (Demilitarized Zone)
A buffer network between untrusted (internet) and trusted (internal) zones. Public-facing services sit in the DMZ; internal resources are never directly exposed. Two firewalls enforce ingress and egress rules independently.
Microsegmentation
Divide the network into fine-grained segments with individual access policies. If an attacker compromises one workload, they cannot move laterally to others. Each segment enforces least privilege at the network layer.
Zero Trust Architecture
Eliminate implicit trust based on network location. Every request -- internal or external -- must be authenticated, authorized, and continuously validated. "Never trust, always verify" replaces the castle-and-moat model.
Slide 8 of 13
DevSecOps: Shifting Security Left
Integrate security into the CI/CD pipeline rather than gating it at the end. Every commit is a security event.
Plan Security reqs Code IDE plugins Build SAST / SCA Test DAST / Pen test Deploy IaC scanning Monitor SIEM / Runtime SHIFT LEFT: Find issues earlier, fix them cheaper
Automated Security Gates
SAST (Static Application Security Testing) runs on every pull request. SCA (Software Composition Analysis) flags vulnerable dependencies before merge. DAST (Dynamic Application Security Testing) runs against staging environments. Failures block the pipeline -- security is not optional.
Culture Shift
DevSecOps is not a tool -- it is an organizational commitment. Developers own security in their code. Security teams provide guardrails, training, and automated tooling rather than acting as a final gate. Shared responsibility replaces siloed handoffs.
Key Tools
SAST: SonarQube, Checkmarx, Semgrep. SCA: Snyk, Dependabot, OWASP Dependency-Check. DAST: OWASP ZAP, Burp Suite. IaC: Checkov, tfsec, KICS. Container: Trivy, Grype. Secrets: GitLeaks, TruffleHog. The tooling exists -- the gap is usually organizational adoption, not technology availability.
Slide 9 of 13
Supply Chain Security
Your software is only as secure as its weakest dependency. Modern applications inherit thousands of transitive trust relationships.
Your App Direct code Open Source Libraries Build Tools / CI Container Base Images Package Registries Cloud Infrastructure Third-Party APIs Every connection = potential attack vector
SBOM
Software Bill of Materials -- a complete inventory of every component in your software. US Executive Order 14028 (2021) requires SBOMs for government software. Formats: SPDX, CycloneDX. You cannot secure what you cannot enumerate.
Dependency Scanning
Automated tools check every dependency against known vulnerability databases (NVD, OSV). Run on every build. Alert on new CVEs in existing dependencies. Pin versions and verify checksums. Trust but verify -- then remove the trust.
Notable Attacks
SolarWinds (2020): compromised build system injected backdoor into 18,000 organizations. Log4Shell (2021): single library vulnerability affected millions of applications. Codecov (2021): compromised CI tool exfiltrated secrets from thousands of repos. The supply chain is the new perimeter.
Slide 10 of 13
Case Study: Equifax Breach (2017)
147 million records exposed. $700M+ in settlements. A case study in what Security by Design would have prevented.
PATCH MGMT Apache Struts CVE known 2 months FAILED MONITORING SSL cert expired IDS offline 19mo FAILED SEGMENTATION Flat network Lateral movement FAILED ENCRYPTION Data at rest not encrypted FAILED SbD WOULD Auto-patch Cert rotation Microseg Encrypt all PREVENT
What Went Wrong
Apache Struts vulnerability (CVE-2017-5638) had a patch available March 7. Equifax was breached May 13 -- two months of exposure. Their network monitoring was down because an SSL certificate expired and nobody renewed it. Attackers moved laterally across an unsegmented network. 147 million records were stored unencrypted. Every failure was a design failure, not a technology failure.
What Security by Design Prevents
Automated patch management with SLA enforcement. Certificate lifecycle automation (never let a cert expire silently). Network microsegmentation (lateral movement blocked even if perimeter fails). Encryption at rest as a default (stolen data is useless without keys). Defense in depth means any single failure does not cause a catastrophic breach.
The Outcome
$700 million FTC settlement. CEO, CIO, and CISO resigned. Congressional testimony. Years of litigation. Reputational damage that persists to this day. The total cost of implementing every Security by Design control that would have prevented this breach would have been a fraction of one percent of the settlement alone.
Slide 11 of 13
NIST Secure Software Development Framework (SSDF)
NIST SP 800-218. The US government's authoritative framework for secure software development practices. Required for federal software procurement since EO 14028.
PO -- Prepare the Organization
Define security requirements for the development environment. Implement roles and responsibilities. Establish secure development policies. Train staff. Ensure tooling supports secure practices. Security starts with organizational commitment, not technical controls.
PS -- Protect the Software
Protect all components of the software from tampering and unauthorized access. Secure the code repositories, build systems, and distribution channels. Archive and protect each release. If an attacker can modify your build pipeline, they own your users.
PW -- Produce Well-Secured Software
Design software to meet security requirements and mitigate identified risks. Review and test code for vulnerabilities and compliance. Configure default settings to be secure. Use human review and automated tools together -- neither is sufficient alone.
RV -- Respond to Vulnerabilities
Identify residual vulnerabilities on an ongoing basis. Assess, prioritize, and remediate discovered vulnerabilities. Analyze each vulnerability for root cause to prevent recurrence. Continuous vulnerability management, not one-time scanning.
Executive Order 14028 -- Improving the Nation's Cybersecurity (May 2021)
Requires all software sold to the federal government to comply with the SSDF. Mandates SBOMs, attestation of secure development practices, and vulnerability disclosure programs. This is not guidance -- it is procurement policy. Software vendors who ignore the SSDF lose access to the largest single buyer of software in the world.
Relationship to Other Frameworks
The SSDF maps to and harmonizes with: ISO 27034 (application security), OWASP SAMM (Software Assurance Maturity Model), BSA Framework for Secure Software, and BSIMM (Building Security In Maturity Model). It is deliberately framework-agnostic -- implement the practices using whatever framework fits your organization.
Slide 12 of 13  |  Summary
Key Takeaways
Security by Design is an engineering discipline, an organizational commitment, and increasingly a legal requirement.
8 Principles to Carry Forward
1 Security by Design means building security into every phase of development -- requirements, design, code, test, deploy, maintain. It is not a phase; it is a property of the system.
2 Saltzer and Schroeder's 8 principles (1975) remain the foundation: economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism, psychological acceptability.
3 STRIDE threat modeling (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is applied during design -- before code is written.
4 Privacy by Design (Cavoukian) is now legally mandated by GDPR Article 25. Privacy and security share the same architectural foundations.
5 Secure architecture patterns -- DMZ, microsegmentation, zero trust -- replace implicit trust with verified access at every boundary.
6 DevSecOps shifts security left: automated SAST, SCA, DAST, and IaC scanning in every CI/CD pipeline. Security gates block deployment -- they are not optional advisory scans.
7 Supply chain security requires SBOMs, dependency scanning, and verification of every component. SolarWinds and Log4Shell proved that transitive trust is a systemic risk.
8 The cost of fixing security defects in production is orders of magnitude higher than fixing them in design. The Equifax breach cost over $700M -- the preventive controls would have cost a fraction of that.
The Bottom Line
Security by Design is not optional and it is not theoretical. It is how professionals build systems that protect the people who depend on them. Every system you build, every architecture you design, every dependency you accept is a security decision. Make it deliberately.
Slide 13 of 13  |  Complete
Module Complete
You have completed the Security by Design presentation. Mark this module complete to record your progress.
Covered
Security by Design philosophy. Saltzer & Schroeder's 8 principles. SSDLC phases. STRIDE threat modeling. Privacy by Design (Cavoukian). Secure architecture patterns. DevSecOps pipeline. Supply chain security. Equifax case study. NIST SSDF.
Next Steps
Apply STRIDE to a system you use daily. Identify which Saltzer & Schroeder principles it violates. Consider what a Security by Design redesign would look like. These are not abstract frameworks -- they are tools for your daily practice.
Key Frameworks
Saltzer & Schroeder (1975). STRIDE (Microsoft). Privacy by Design (Cavoukian). NIST SSDF (SP 800-218). EO 14028. OWASP SAMM. Zero Trust Architecture (NIST SP 800-207).