"Fixing vulnerabilities one at a time is playing whack-a-mole. Security architecture improvements change
the game entirely."
— Security Architecture Principle
Individual vulnerability remediation addresses symptoms. Security architecture
addresses root causes. This week elevates your recommendations from tactical
fixes to strategic improvements that will prevent entire categories of
vulnerabilities from occurring in the future.
Learning Outcomes
By the end of this week, you will be able to:
LO1: Identify patterns across findings that indicate architectural weaknesses
LO2: Apply defense-in-depth principles to recommend layered security controls
LO3: Design network segmentation strategies appropriate for hybrid cloud
environments
LO4: Recommend identity and access management improvements aligned with zero-trust
principles
LO5: Propose security monitoring and detection capabilities to improve incident
response
Introduction: From Tactical to Strategic
Your assessment revealed numerous individual findings. But step back and
look at the patterns:
Credentials in Jenkins indicate absent secrets management
Flat network enabled lateral movement potential
Missing MFA across multiple systems shows inconsistent identity controls
Limited logging hampers detection and response
These patterns point to architectural gaps that, if addressed, would prevent
not just the vulnerabilities you found, but future vulnerabilities of the
same types. This week focuses on strategic recommendations that transform
NovaTech's security posture.
Tactical vs. Strategic Recommendations
Tactical (Week 8)
Strategic (Week 9)
Fix SQL injection in search endpoint
Implement secure coding standards and code review process
Identity is the new perimeter. With cloud and remote work, traditional
network boundaries are insufficient. Zero-trust principles require strong
identity verification for every access request.
Zero Trust Principles
┌─────────────────────────────────────────────────────────────────┐
│ ZERO TRUST PRINCIPLES │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. VERIFY EXPLICITLY │
│ ──────────────────── │
│ Always authenticate and authorize based on all available │
│ data points: identity, location, device, service, data │
│ │
│ 2. USE LEAST PRIVILEGE ACCESS │
│ ────────────────────────── │
│ Limit user access with just-in-time and just-enough │
│ access (JIT/JEA), risk-based adaptive policies │
│ │
│ 3. ASSUME BREACH │
│ ───────────────── │
│ Minimize blast radius, segment access, verify end-to-end │
│ encryption, use analytics for threat detection │
│ │
│ TRADITIONAL: "Trust but verify" inside the network │
│ ZERO TRUST: "Never trust, always verify" everywhere │
│ │
└─────────────────────────────────────────────────────────────────┘
Current NovaTech IAM State
Multiple identity silos (AWS IAM, application database, Google Workspace)
Scan repositories for hardcoded secrets (TruffleHog, git-secrets)
Remove secrets from environment files
Rotate any potentially exposed credentials
Implement pre-commit hooks to prevent future secret commits
5. Security Monitoring and Detection
Prevention controls will eventually fail. Detection capabilities ensure
that when breaches occur, they're identified quickly and responded to
effectively.
Multiple SQL injection vulnerabilities were found across different
endpoints of the WorkflowPro API. Beyond fixing each individual
vulnerability, what architectural recommendations would you make
to prevent this class of vulnerability in the future?
Reveal Answer
Architectural recommendations to prevent SQL injection class:
ORM Enforcement: Mandate use of ORM (Sequelize, TypeORM)
for all database operations; prohibit raw queries in application code
Database Abstraction Layer: Create a data access layer
that enforces parameterized queries by design
SAST in CI/CD: Integrate static analysis that detects
SQL concatenation patterns; fail builds on detection
WAF Layer: Deploy AWS WAF with SQL injection rulesets
as defense-in-depth
Database Permissions: Use least-privilege database
accounts that can't execute DDL or access other databases
Developer Training: Secure coding training covering
injection prevention
Code Review Process: Security-focused review checklist
for database interactions
These architectural changes mean that even if a developer makes a mistake,
multiple layers would catch or mitigate the vulnerability.
Question 2
Explain why network segmentation alone isn't sufficient for security,
and what other controls should accompany it.
Reveal Answer
Network segmentation limitations:
Doesn't prevent allowed traffic abuse: If app server
can reach database (required), attacker on app server can still access database
Insider threat: Segmentation doesn't help against
authorized users abusing their access
Application-layer attacks: SQL injection works over
allowed database port
Data classification → C1.1 Confidential information identification
Access controls → C1.2 Confidential information protection
Processing Integrity:
SAST/DAST → PI1.1 Processing accuracy
Code review → PI1.2 Input validation
Key point: These architectural controls demonstrate systematic,
designed-in security rather than ad-hoc patches—exactly what auditors look for
in Type II certification.
Develop a comprehensive security architecture recommendations document
that addresses systemic issues identified in NovaTech's assessment and
provides a roadmap for strategic security improvements.
Deliverables
Architecture Assessment: Analysis of current state and gaps
Architecture Recommendations: Strategic improvements with diagrams
Implementation Roadmap: Phased approach with dependencies
Time Estimate
4-5 hours
Lab Tasks
Part 1: Pattern Analysis (LO1)
Review all findings from Weeks 3-6
Identify patterns and themes across findings
Map findings to architectural weaknesses
Document current state architecture (diagrams)
Part 2: Defense-in-Depth Analysis (LO2)
Assess NovaTech against defense-in-depth layers
Identify gaps at each layer
Recommend controls for each layer
Create defense-in-depth target state diagram
Part 3: Network Architecture Recommendations (LO3)
Design target network segmentation architecture
Define security group and NACL rules
Document traffic flows
Create network architecture diagrams
Part 4: Identity Architecture Recommendations (LO4)
Design centralized identity architecture
Define SSO integration approach
Specify MFA and conditional access policies
Document secrets management approach
Part 5: Monitoring Architecture Recommendations (LO5)
Design security monitoring architecture
Define log sources and collection
Specify priority detection use cases
Recommend alerting and response procedures
Part 6: Implementation Roadmap
Prioritize recommendations
Identify dependencies between recommendations
Create phased implementation timeline
Estimate resource requirements
Define success metrics
Self-Assessment Checklist
Analysis Quality
☐ Patterns across findings clearly identified
☐ Current state accurately documented
☐ Gaps mapped to security frameworks
Recommendation Quality
☐ Recommendations are strategic (not just tactical)
☐ Architecture diagrams included
☐ Implementation steps provided
☐ Recommendations address root causes
Roadmap Quality
☐ Realistic timelines
☐ Dependencies identified
☐ Resource requirements estimated
☐ Success metrics defined
Professional Standards
☐ Document suitable for executive presentation
☐ Technical accuracy maintained
☐ Diagrams are clear and professional
Portfolio Integration
Save your architecture recommendations deliverables:
09-architecture-recommendations/
current-state-analysis.pdf — Gap analysis
architecture-recommendations.pdf — Full recommendations
Deliverable: Professional capstone component ready for portfolio Time estimate: 4-8 hours
🎤 Architecture Briefing Deck
What you'll do: Create a 10-slide executive briefing that summarizes architecture risks and your top recommendations.
Why it matters: Senior leaders decide funding based on concise, clear narratives.
Time estimate: 2-3 hours
Deliverable: Slide deck and 2-minute presentation script
💡 Capstone Strategy: This work becomes your portfolio—make it job-interview ready.
Resources
Required
NIST Cybersecurity Framework
Framework for improving critical infrastructure cybersecurity,
providing structure for security architecture discussions.
Reflect on the difference between tactical vulnerability remediation
and strategic architecture improvements. How do architectural changes
provide more lasting security benefits than fixing individual vulnerabilities?
What challenges might organizations face when trying to implement
significant architectural changes?
Consider NovaTech's position as a growing startup. How would you
balance the need for security architecture improvements against
business pressures to move fast and ship features? What arguments
would you make to leadership about the value of investing in
security architecture?