Mental Model
"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:
- Multiple injection vulnerabilities suggest missing input validation standards
- 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 |
| Rotate AWS credentials on Jenkins | Deploy secrets management solution (Vault, AWS Secrets Manager) |
| Enable MFA for IAM users | Implement centralized identity with SSO and conditional access |
| Restrict security group for bastion | Design network segmentation architecture |
| Enable CloudTrail multi-region | Build security monitoring and SIEM capability |
1. Defense-in-Depth Architecture
Defense-in-depth is the principle of using multiple layers of security controls so that if one fails, others continue to provide protection.
Defense-in-Depth Layers
┌─────────────────────────────────────────────────────────────────┐
│ DEFENSE-IN-DEPTH LAYERS │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ POLICIES & PROCEDURES │ │
│ │ Security policies, awareness training, │ │
│ │ incident response plans, governance │ │
│ └─────────────────────────────────────────────────────────┘ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ PHYSICAL SECURITY │ │
│ │ Data center access, device security │ │
│ └─────────────────────────────────────────────────────┘ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ PERIMETER SECURITY │ │
│ │ Firewalls, WAF, DDoS protection, VPN │ │
│ └─────────────────────────────────────────────────┘ │
│ ┌─────────────────────────────────────────────┐ │
│ │ NETWORK SECURITY │ │
│ │ Segmentation, IDS/IPS, flow monitoring │ │
│ └─────────────────────────────────────────────┘ │
│ ┌─────────────────────────────────────────┐ │
│ │ ENDPOINT SECURITY │ │
│ │ EDR, patching, hardening, AV │ │
│ └─────────────────────────────────────────┘ │
│ ┌─────────────────────────────────────┐ │
│ │ APPLICATION SECURITY │ │
│ │ Secure coding, input validation, │ │
│ │ authentication, authorization │ │
│ └─────────────────────────────────────┘ │
│ ┌─────────────────────────────────┐ │
│ │ DATA SECURITY │ │
│ │ Encryption, classification, │ │
│ │ DLP, backup, access control │ │
│ └─────────────────────────────────┘ │
│ │
│ Each layer provides protection if outer layers fail │
│ │
└─────────────────────────────────────────────────────────────────┘
NovaTech Defense-in-Depth Gaps
Based on assessment findings, NovaTech has gaps at multiple layers:
| Layer | Current State | Gap | Recommendation |
|---|---|---|---|
| Perimeter | CloudFlare CDN, basic WAF | WAF not blocking injection attacks | Tune WAF rules, add managed rulesets |
| Network | Single VPC, minimal segmentation | Flat network enables lateral movement | Implement network segmentation |
| Endpoint | Basic patching, no EDR | Limited visibility into compromises | Deploy EDR solution |
| Application | No secure coding standards | Injection vulnerabilities recurring | SAST/DAST in CI/CD, training |
| Data | S3 encryption enabled | No classification, DLP absent | Data classification program |
Defense-in-Depth Recommendation
Recommendation: Implement Layered Application Security
Current State: Application vulnerabilities (SQLi, XSS) exist because security relies solely on developer awareness.
Target State: Multiple layers of protection for web applications:
┌─────────────────────────────────────────────────────────────────┐
│ LAYERED APPLICATION SECURITY ARCHITECTURE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ LAYER 1: WAF (Edge) │
│ ─────────────────── │
│ • AWS WAF with OWASP managed rules │
│ • Rate limiting │
│ • Geographic restrictions │
│ • Bot protection │
│ ▼ │
│ LAYER 2: API Gateway │
│ ──────────────────── │
│ • Input validation schemas │
│ • Request/response transformation │
│ • Authentication enforcement │
│ • Rate limiting per API key │
│ ▼ │
│ LAYER 3: Application Code │
│ ───────────────────────── │
│ • Parameterized queries (mandatory) │
│ • Output encoding │
│ • Input validation │
│ • SAST scanning in CI/CD │
│ ▼ │
│ LAYER 4: Database │
│ ───────────────── │
│ • Least-privilege database users │
│ • Row-level security where applicable │
│ • Audit logging │
│ • Encryption at rest │
│ │
│ If any layer fails, others continue to provide protection │
│ │
└─────────────────────────────────────────────────────────────────┘
Implementation Approach:
- Phase 1: Deploy AWS WAF with OWASP Core Rule Set (2 weeks)
- Phase 2: Implement API Gateway validation (4 weeks)
- Phase 3: Integrate SAST into CI/CD pipeline (2 weeks)
- Phase 4: Database access review and hardening (2 weeks)
2. Network Segmentation Architecture
Network segmentation limits the blast radius of a compromise by restricting communication between systems that don't need to interact.
Current NovaTech Network
┌─────────────────────────────────────────────────────────────────┐
│ CURRENT NOVATECH NETWORK (FLAT) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ SINGLE VPC (10.0.0.0/16) │ │
│ │ │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Web │ │ App │ │ Database│ │ Jenkins │ │ │
│ │ │ Servers │◄─►│ Servers │◄─►│ Servers │◄─►│ │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ ▲ ▲ ▲ ▲ │ │
│ │ │ │ │ │ │ │
│ │ └────────────┴────────────┴────────────┘ │ │
│ │ ALL CAN TALK │ │
│ │ │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
│ PROBLEM: Compromise of any system enables access to all │
│ │
└─────────────────────────────────────────────────────────────────┘
Recommended Segmented Architecture
┌─────────────────────────────────────────────────────────────────┐
│ RECOMMENDED SEGMENTED ARCHITECTURE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ DMZ SUBNET (Public) 10.0.1.0/24 │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │ ALB │ │ Bastion │ Only internet-facing │ │
│ │ └────┬────┘ └────┬────┘ components here │ │
│ └───────┼────────────┼────────────────────────────────────┘ │
│ │ │ │
│ │ ┌──────┴──────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ APPLICATION SUBNET 10.0.2.0/24 │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Web/App │ │ API │ Application servers │ │
│ │ │ Servers │ │ Servers │ No direct internet access │ │
│ │ └────┬────┘ └────┬────┘ │ │
│ └───────┼────────────┼────────────────────────────────────┘ │
│ │ │ │
│ └─────┬──────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ DATA SUBNET (Private) 10.0.3.0/24 │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │ RDS │ │ Redis │ Databases and caches │ │
│ │ │ │ │ │ No internet access │ │
│ │ └─────────┘ └─────────┘ Only app subnet can reach │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ MANAGEMENT SUBNET 10.0.4.0/24 │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Jenkins │ │Monitoring│ CI/CD and ops tools │ │
│ │ │ │ │ │ Restricted access │ │
│ │ └─────────┘ └─────────┘ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Security Groups + NACLs enforce boundaries │
│ │
└─────────────────────────────────────────────────────────────────┘
Segmentation Rules
| Source | Destination | Allowed Traffic | Rationale |
|---|---|---|---|
| Internet | DMZ | HTTPS (443), SSH (22 from VPN only) | Only public-facing services exposed |
| DMZ (ALB) | Application | HTTP (8080) | Load balancer to app servers |
| Application | Data | PostgreSQL (5432), Redis (6379) | App servers to databases only |
| Management | All | SSH, HTTPS (management ports) | Ops access for administration |
| Data | Any | None outbound | Databases should not initiate connections |
Implementation Approach
-
Phase 1: Planning (Week 1-2)
- Document current network flows
- Design target architecture
- Create security group specifications
- Plan migration sequence
-
Phase 2: Build New Subnets (Week 3)
- Create new subnet structure in VPC
- Configure route tables
- Create security groups with rules
- Set up NACLs for subnet-level controls
-
Phase 3: Migrate Non-Critical (Week 4-5)
- Move development/staging environments first
- Validate connectivity and functionality
- Tune security group rules as needed
-
Phase 4: Migrate Production (Week 6-8)
- Schedule maintenance windows
- Migrate production workloads
- Validate all application functionality
- Monitor for issues
3. Identity and Access Management Architecture
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)
- Inconsistent MFA enforcement
- Long-lived credentials (API keys, SSH keys)
- Over-privileged service accounts
- No centralized access governance
Recommended IAM Architecture
┌─────────────────────────────────────────────────────────────────┐
│ RECOMMENDED IAM ARCHITECTURE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────┐ │
│ │ IDENTITY PROVIDER │ │
│ │ (Okta / Azure AD) │ │
│ │ │ │
│ │ • Single source of │ │
│ │ identity truth │ │
│ │ • MFA enforcement │ │
│ │ • Conditional access│ │
│ └──────────┬──────────┘ │
│ │ │
│ ┌───────────────────┼───────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ AWS SSO │ │ WorkflowPro │ │ Google │ │
│ │ │ │ (SAML/OIDC) │ │ Workspace │ │
│ │ • Federated │ │ │ │ │ │
│ │ access │ │ • SSO login │ │ • Directory │ │
│ │ • Temp creds │ │ • RBAC │ │ sync │ │
│ │ • Permission │ │ • Audit log │ │ │ │
│ │ sets │ │ │ │ │ │
│ └───────────────┘ └───────────────┘ └───────────────┘ │
│ │
│ BENEFITS: │
│ • Single MFA policy across all systems │
│ • Centralized access reviews │
│ • Consistent offboarding (disable once, access revoked) │
│ • Reduced credential sprawl │
│ │
└─────────────────────────────────────────────────────────────────┘
Key IAM Recommendations
1. Implement Centralized Identity with SSO
Action: Deploy identity provider (Okta or Azure AD) as single source of identity.
- Federate AWS access via AWS SSO
- Integrate WorkflowPro with SAML/OIDC
- Sync with Google Workspace directory
- Enforce MFA at IdP level (applies to all connected systems)
Effort: 4-6 weeks
2. Eliminate Long-Lived Credentials
Action: Replace static credentials with temporary, automatically rotated credentials.
- AWS: Use IAM roles instead of access keys
- Applications: Use AWS Secrets Manager with automatic rotation
- SSH: Implement AWS Session Manager or certificate-based auth
- Database: Use IAM database authentication where supported
Effort: 3-4 weeks
3. Implement Least Privilege
Action: Review and reduce permissions across all systems.
- Audit existing IAM policies for over-privilege
- Implement permission boundaries
- Use AWS IAM Access Analyzer to identify unused permissions
- Establish regular access review process (quarterly)
Effort: 2-3 weeks initial + ongoing
4. Conditional Access Policies
Action: Implement risk-based access decisions.
- Require MFA for sensitive operations
- Block access from untrusted locations/devices
- Step-up authentication for high-risk activities
- Time-based access restrictions for privileged accounts
Effort: 2 weeks
4. Secrets Management Architecture
The discovery of AWS credentials in Jenkins highlights a common problem: secrets scattered across systems with no centralized management.
Current State: Secrets Sprawl
┌─────────────────────────────────────────────────────────────────┐
│ CURRENT SECRETS SPRAWL │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Jenkins │ │ .env files │ │ Config │ │
│ │ │ │ │ │ files │ │
│ │ AWS keys │ │ DB password │ │ API keys │ │
│ │ SSH keys │ │ API secrets │ │ Tokens │ │
│ │ API tokens │ │ │ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Git │ │ Developer │ │ Terraform │ │
│ │ Repos │ │ Machines │ │ State │ │
│ │ │ │ │ │ │ │
│ │ Hardcoded │ │ SSH keys │ │ Provider │ │
│ │ credentials │ │ AWS creds │ │ credentials │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ PROBLEMS: │
│ • No visibility into what secrets exist │
│ • No rotation policy or capability │
│ • Secrets in version control history │
│ • No audit trail of secret access │
│ • Difficult to revoke compromised credentials │
│ │
└─────────────────────────────────────────────────────────────────┘
Recommended: Centralized Secrets Management
┌─────────────────────────────────────────────────────────────────┐
│ CENTRALIZED SECRETS MANAGEMENT │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────┐ │
│ │ AWS SECRETS MANAGER │ │
│ │ (or HashiCorp Vault) │ │
│ │ │ │
│ │ • Centralized storage │ │
│ │ • Automatic rotation │ │
│ │ • Audit logging │ │
│ │ • Access control │ │
│ │ • Encryption at rest │ │
│ └───────────┬─────────────┘ │
│ │ │
│ ┌─────────────────────┼─────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Jenkins │ │ Application │ │ Terraform │ │
│ │ │ │ Runtime │ │ │ │
│ │ Fetches │ │ │ │ Retrieves │ │
│ │ secrets at │ │ Secrets │ │ provider │ │
│ │ build time │ │ injected │ │ creds at │ │
│ │ │ │ via SDK │ │ plan/apply │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ BENEFITS: │
│ • Single source of truth for all secrets │
│ • Automatic rotation (30-day policy) │
│ • Complete audit trail │
│ • Easy revocation (change in one place) │
│ • No secrets in code or config files │
│ │
└─────────────────────────────────────────────────────────────────┘
Implementation Roadmap
-
Phase 1: Deploy Secrets Manager (Week 1)
- Enable AWS Secrets Manager
- Define secret naming conventions
- Set up IAM policies for access
-
Phase 2: Migrate Critical Secrets (Week 2-3)
- Inventory all existing secrets
- Migrate database credentials first
- Update applications to fetch from Secrets Manager
- Enable automatic rotation
-
Phase 3: CI/CD Integration (Week 4)
- Configure Jenkins to use Secrets Manager
- Remove credentials from Jenkins credential store
- Update deployment scripts
-
Phase 4: Cleanup (Week 5-6)
- 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.
Detection Maturity Model
┌─────────────────────────────────────────────────────────────────┐
│ DETECTION MATURITY LEVELS │
├─────────────────────────────────────────────────────────────────┤
│ │
│ LEVEL 0: MINIMAL │
│ ───────────────── │
│ • Basic logging enabled │
│ • Manual log review (rare) │
│ • Reactive incident discovery │
│ ← NovaTech is approximately here │
│ │
│ LEVEL 1: REACTIVE │
│ ───────────────── │
│ • Centralized logging │
│ • Basic alerting on known-bad patterns │
│ • Incident response plan exists │
│ │
│ LEVEL 2: PROACTIVE │
│ ────────────────── │
│ • SIEM with correlation rules │
│ • Threat intelligence integration │
│ • Regular threat hunting │
│ • Defined detection use cases │
│ │
│ LEVEL 3: OPTIMIZED │
│ ─────────────────── │
│ • Advanced analytics/ML │
│ • Automated response (SOAR) │
│ • Continuous improvement program │
│ • Red team validation │
│ │
│ TARGET: Move NovaTech to Level 2 within 6 months │
│ │
└─────────────────────────────────────────────────────────────────┘
Recommended Monitoring Architecture
┌─────────────────────────────────────────────────────────────────┐
│ SECURITY MONITORING ARCHITECTURE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ LOG SOURCES COLLECTION │
│ ─────────── ────────── │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ CloudTrail │──────────────────►│ │ │
│ │ (API logs) │ │ │ │
│ └─────────────┘ │ │ │
│ ┌─────────────┐ │ CloudWatch │ │
│ │ VPC Flow │──────────────────►│ Logs │ │
│ │ Logs │ │ │ │
│ └─────────────┘ │ │ │ │
│ ┌─────────────┐ │ │ │ │
│ │ Application │──────────────────►│ │ │ │
│ │ Logs │ │ │ │ │
│ └─────────────┘ └──────┼──────┘ │
│ ┌─────────────┐ │ │
│ │ WAF Logs │──────────────────────────┤ │
│ └─────────────┘ │ │
│ ┌─────────────┐ │ │
│ │ GuardDuty │──────────────────────────┤ │
│ │ Findings │ │ │
│ └─────────────┘ ▼ │
│ ┌─────────────┐ │
│ │ SIEM │ │
│ │ (Splunk/ │ │
│ │ Elastic/ │ │
│ │ Sentinel) │ │
│ └──────┬──────┘ │
│ │ │
│ ┌────────────────┼────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐│
│ │ Dashboards│ │ Alerts │ │ Reports ││
│ └──────────┘ └──────────┘ └──────────┘│
│ │
└─────────────────────────────────────────────────────────────────┘
Priority Detection Use Cases
| Use Case | Data Source | Detection Logic | Priority |
|---|---|---|---|
| Credential compromise | CloudTrail | API calls from unusual locations, multiple failed auth | Critical |
| Data exfiltration | VPC Flow, S3 logs | Large outbound transfers, unusual S3 GetObject patterns | Critical |
| Privilege escalation | CloudTrail | IAM policy changes, new admin users, role assumption | High |
| SQL injection attempts | WAF, Application logs | SQL keywords in parameters, blocked WAF requests | High |
| Brute force | Application logs, WAF | Multiple failed logins from same IP, rate limit triggers | Medium |
| Resource hijacking | CloudTrail, CloudWatch | Unusual EC2 launches, crypto mining indicators | Medium |
Implementation Recommendation
Short-Term: AWS-Native Solution (4-6 weeks)
- Enable AWS GuardDuty (threat detection)
- Configure CloudWatch Logs Insights queries
- Set up CloudWatch Alarms for critical events
- Enable AWS Security Hub for centralized findings
- Create SNS topics for alert notification
Cost: ~$500-1000/month based on data volume
Medium-Term: SIEM Implementation (3-6 months)
- Evaluate SIEM options (Splunk, Elastic, Azure Sentinel)
- Deploy in AWS or use SaaS option
- Integrate all log sources
- Build detection rules for priority use cases
- Create dashboards and reporting
- Establish monitoring procedures
Cost: $2,000-10,000/month depending on solution and data volume
6. Secure Development Lifecycle
Multiple application vulnerabilities indicate the need for security integration into the development process—shifting security left.
Recommended SDLC Security Integration
┌─────────────────────────────────────────────────────────────────┐
│ SECURE DEVELOPMENT LIFECYCLE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ PLAN CODE BUILD TEST DEPLOY
│ ──── ──── ───── ──── ──────
│ │
│ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ │Security│ │IDE │ │SAST │ │DAST │ │Config │
│ │Require-│ │Security │ │Scanning│ │Scanning│ │Scanning│
│ │ments │ │Plugins │ │ │ │ │ │ │
│ └────────┘ └────────┘ └────────┘ └────────┘ └────────┘
│ │
│ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ │Threat │ │Pre- │ │Depend- │ │Penetra-│ │Runtime │
│ │Modeling│ │Commit │ │ency │ │tion │ │Protect-│
│ │ │ │Hooks │ │Check │ │Testing │ │ion │
│ └────────┘ └────────┘ └────────┘ └────────┘ └────────┘
│ │
│ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ │Secure │ │Code │ │Secret │ │Security│ │Monitor-│
│ │Design │ │Review │ │Scanning│ │Sign-off│ │ing │
│ │Review │ │ │ │ │ │ │ │ │
│ └────────┘ └────────┘ └────────┘ └────────┘ └────────┘
│ │
│ Security gates at each stage prevent vulnerabilities from │
│ progressing to production │
│ │
└─────────────────────────────────────────────────────────────────┘
Priority Implementation
1. SAST in CI/CD Pipeline (High Priority)
Tool: SonarQube, Semgrep, or Snyk Code
Integration: GitHub Actions / Jenkins pipeline step
# Example: GitHub Actions with Semgrep
- name: Semgrep Scan
uses: returntocorp/semgrep-action@v1
with:
config: p/owasp-top-ten
Gate: Fail build on High/Critical findings
2. Dependency Scanning (High Priority)
Tool: Snyk, Dependabot, or OWASP Dependency-Check
Integration: Automated PR checks, weekly scans
# Example: Snyk in CI
- name: Snyk Security Scan
uses: snyk/actions/node@master
with:
command: test
args: --severity-threshold=high
Gate: Block PRs with vulnerable dependencies
3. Secret Scanning (High Priority)
Tool: GitLeaks, TruffleHog, or GitHub Secret Scanning
Integration: Pre-commit hook + CI check
# Pre-commit hook example
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.16.0
hooks:
- id: gitleaks
Gate: Block commits containing secrets
4. Developer Security Training (Medium Priority)
Approach: Secure coding training for all developers
- OWASP Top 10 awareness
- Secure coding practices for Node.js/React
- Hands-on exercises with real vulnerabilities
- Annual refresher training
7. Architecture Recommendations Summary
| Area | Key Recommendation | Effort | Timeline | Impact |
|---|---|---|---|---|
| Network | Implement VPC segmentation | Large | 6-8 weeks | Limits lateral movement |
| Identity | Deploy SSO with centralized MFA | Large | 4-6 weeks | Consistent access controls |
| Secrets | Implement secrets management | Medium | 4-6 weeks | Eliminates credential sprawl |
| Monitoring | Deploy GuardDuty + Security Hub | Small | 2 weeks | Threat detection capability |
| SDLC | Integrate SAST/SCA in CI/CD | Medium | 2-4 weeks | Prevents future app vulns |
| Application | WAF with tuned rulesets | Small | 1-2 weeks | Defense-in-depth for apps |
Implementation Priority
┌─────────────────────────────────────────────────────────────────┐
│ ARCHITECTURE IMPROVEMENT PRIORITY ORDER │
├─────────────────────────────────────────────────────────────────┤
│ │
│ IMMEDIATE (Month 1) │
│ ─────────────────── │
│ 1. WAF tuning (quick win, high impact) │
│ 2. GuardDuty + Security Hub (quick win, detection) │
│ 3. Secrets Management (addresses critical finding) │
│ │
│ SHORT-TERM (Months 2-3) │
│ ──────────────────────── │
│ 4. SSO implementation (foundational) │
│ 5. SAST/SCA in CI/CD (prevents future vulns) │
│ │
│ MEDIUM-TERM (Months 4-6) │
│ ───────────────────────── │
│ 6. Network segmentation (significant project) │
│ 7. SIEM implementation (enhanced detection) │
│ │
│ ONGOING │
│ ─────── │
│ 8. Security training program │
│ 9. Regular architecture reviews │
│ 10. Continuous improvement │
│ │
└─────────────────────────────────────────────────────────────────┘
Self-Check Questions
Test your understanding of security architecture:
Question 1
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
- Credential theft: Stolen credentials bypass network controls
Complementary controls needed:
- Identity controls: Strong authentication, MFA, least privilege
- Application security: Input validation, secure coding
- Data protection: Encryption, access logging, DLP
- Monitoring: Detect anomalous behavior even on allowed paths
- Endpoint security: Protect the systems within segments
Segmentation reduces attack surface and limits blast radius, but must be part of defense-in-depth, not a standalone solution.
Question 3
NovaTech uses AWS for production. Describe a zero-trust approach to AWS access that eliminates long-lived IAM access keys.
Reveal Answer
Zero-trust AWS access without access keys:
- Human Access:
- Implement AWS SSO federated with corporate IdP (Okta/Azure AD)
- Users authenticate via IdP with MFA
- AWS SSO issues temporary credentials (1-hour sessions)
- No IAM users with passwords or access keys
- Application Access:
- EC2/ECS: Use IAM roles attached to instances/tasks
- Lambda: Use execution roles
- Credentials automatically rotated by AWS
- CI/CD Access:
- Use OIDC federation (GitHub Actions, GitLab)
- CI assumes IAM role via web identity
- No stored credentials in CI system
- External Service Access:
- Use IAM Roles Anywhere for on-prem systems
- Or service-specific solutions (RDS IAM auth)
Result: No long-lived credentials to steal; all access is temporary, audited, and tied to verified identity.
Question 4
What detection use cases would you prioritize for NovaTech's security monitoring, and why?
Reveal Answer
Priority detection use cases for NovaTech:
- AWS Credential Compromise (Critical)
- Why: Direct path to infrastructure and data
- Detection: Console logins from new locations, API calls from unusual IPs, impossible travel, access key usage after rotation
- Customer Data Access Anomalies (Critical)
- Why: Core business asset, regulatory implications
- Detection: Unusual S3 access patterns, bulk downloads, access outside business hours
- CI/CD Pipeline Tampering (High)
- Why: Supply chain risk to all customers
- Detection: Unauthorized Jenkins access, pipeline modifications, unexpected deployments
- Web Application Attacks (High)
- Why: Internet-facing, known vulnerabilities
- Detection: WAF blocks, injection patterns, authentication failures
- Privilege Escalation (High)
- Why: Enables broader compromise
- Detection: IAM policy changes, new admin users, role assumption patterns
Prioritization based on: business impact, likelihood (based on assessment findings), and detection feasibility.
Question 5
How would you measure the success of security architecture improvements over time?
Reveal Answer
Metrics for measuring security architecture success:
Vulnerability Metrics:
- Number of critical/high vulnerabilities found in assessments (should decrease)
- Time to detect new vulnerabilities (should decrease with SAST/DAST)
- Vulnerability recurrence rate (same vuln types shouldn't reappear)
Detection Metrics:
- Mean time to detect (MTTD) security events
- Mean time to respond (MTTR)
- Percentage of incidents detected internally vs. externally reported
Access Control Metrics:
- Percentage of users with MFA enabled (target: 100%)
- Number of long-lived credentials (should approach zero)
- Over-privileged accounts identified in reviews
Process Metrics:
- Percentage of deployments passing security scans
- Security findings blocked in CI/CD pipeline
- Developer security training completion rate
Business Metrics:
- Security incidents impacting customers
- Compliance audit findings
- Customer security questionnaire scores
Question 6
NovaTech is planning to achieve SOC 2 Type II certification. How do your architecture recommendations support this goal?
Reveal Answer
Architecture recommendations mapped to SOC 2 Trust Service Criteria:
Security (Common Criteria):
- Network segmentation → CC6.1 Logical access security
- SSO with MFA → CC6.1 Authentication controls
- Secrets management → CC6.1 Credential management
- WAF → CC6.6 Boundary protection
Availability:
- Segmentation → A1.2 Environmental protections
- Monitoring → A1.1 Capacity management visibility
Confidentiality:
- 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.
Lab: Security Architecture Recommendations Document
Objective
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 analysisarchitecture-recommendations.pdf— Full recommendationsarchitecture-diagrams/— Network, identity, monitoring diagramsimplementation-roadmap.pdf— Phased approach
🎯 Hands-On Capstone Activities
Week 9 capstone activities - Security Architecture Design
🎯 Security Architecture Design Lab
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
NIST Cybersecurity Framework
Framework for improving critical infrastructure cybersecurity, providing structure for security architecture discussions.
nist.gov/cyberframework 60 minutesAWS Well-Architected Security Pillar
AWS guidance on designing secure cloud architectures, covering identity, detection, infrastructure protection, and incident response.
AWS Security Pillar 90 minutesZero Trust Architecture (NIST SP 800-207)
NIST guidance on zero trust architecture principles and implementation approaches.
NIST SP 800-207 60 minutes (executive summary + key sections)Weekly Reflection
Prompt
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?
Target length: 250-350 words