CSY399 Week 08 Capstone

Week Content

Cybersecurity Capstone

Track your progress through this week's content

Mental Model

"A vulnerability report without a remediation roadmap is just a list of problems. Security consultants deliver solutions, not just findings." — Security Consulting Principle

Identifying vulnerabilities is only half the engagement. NovaTech hired SecureFirst Consulting not just to find problems but to help solve them. This week transforms your risk register into an actionable remediation roadmap that considers technical dependencies, resource constraints, and business priorities.

Learning Outcomes

By the end of this week, you will be able to:

  • LO1: Develop specific, actionable remediation recommendations for identified vulnerabilities
  • LO2: Estimate remediation effort and resource requirements
  • LO3: Sequence remediation activities considering dependencies and quick wins
  • LO4: Design compensating controls for risks that cannot be immediately remediated
  • LO5: Create a phased remediation roadmap aligned with business constraints

Introduction: The Remediation Phase

Your risk register from Week 7 established priorities. Now you need to translate those priorities into a practical plan that NovaTech can execute. This requires understanding not just what to fix, but how to fix it, in what order, and with what resources.

Engagement Progress

┌─────────────────────────────────────────────────────────────────┐
│                    ENGAGEMENT PROGRESS                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ASSESSMENT PHASE         ANALYSIS & REMEDIATION    SYNTHESIS   │
│  ────────────────         ──────────────────────    ─────────   │
│  Weeks 1-6                Weeks 7-9                 Weeks 10-12 │
│  ✓ Complete               Week 7: Risk Analysis ✓   Upcoming    │
│                           Week 8: Remediation ◄──               │
│                           Week 9: Architecture                  │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Effective remediation planning balances security urgency against operational reality. A perfect remediation plan that can't be executed is worthless. Your goal is creating a roadmap that NovaTech will actually follow.

1. Remediation Fundamentals

Before diving into specific recommendations, understand the remediation landscape and the types of fixes available.

Remediation Hierarchy

┌─────────────────────────────────────────────────────────────────┐
│                   REMEDIATION HIERARCHY                         │
│              (Most Effective to Least Effective)                │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. ELIMINATE                                                   │
│     ─────────                                                   │
│     Remove the vulnerability entirely                           │
│     • Patch the software                                        │
│     • Fix the code                                              │
│     • Decommission the system                                   │
│     → BEST: Removes the risk completely                         │
│                                                                 │
│  2. MITIGATE                                                    │
│     ────────                                                    │
│     Reduce likelihood or impact                                 │
│     • Implement compensating controls                           │
│     • Add network segmentation                                  │
│     • Enable additional monitoring                              │
│     → GOOD: Reduces risk but doesn't eliminate                  │
│                                                                 │
│  3. TRANSFER                                                    │
│     ────────                                                    │
│     Shift risk to another party                                 │
│     • Cyber insurance                                           │
│     • Contractual liability transfer                            │
│     • Outsource to managed service                              │
│     → PARTIAL: Financial protection, not prevention             │
│                                                                 │
│  4. ACCEPT                                                      │
│     ──────                                                      │
│     Acknowledge and document the risk                           │
│     • Business justification documented                         │
│     • Executive sign-off obtained                               │
│     • Review date established                                   │
│     → LAST RESORT: Risk remains; use sparingly                  │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Types of Remediation

Patching

Applying vendor-provided updates to fix known vulnerabilities. Often the simplest remediation but requires testing and change management.

Code Fixes

Modifying application code to address vulnerabilities. Required for custom application issues like SQL injection or XSS.

Configuration Changes

Adjusting settings to improve security posture. Includes enabling encryption, tightening permissions, disabling unnecessary features.

Architectural Changes

Modifying system design or infrastructure. Includes network segmentation, adding security layers, redesigning authentication.

Compensating Controls

Alternative measures that reduce risk when direct remediation isn't immediately possible. Temporary measure, not a solution.

2. Writing Effective Remediation Recommendations

Good remediation recommendations are specific, actionable, and include enough detail for the technical team to implement without guesswork.

Recommendation Components

┌─────────────────────────────────────────────────────────────────┐
│              REMEDIATION RECOMMENDATION TEMPLATE                │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  WHAT TO DO                       HOW TO DO IT                  │
│  ──────────                       ────────────                  │
│  • Clear action statement         • Step-by-step instructions   │
│  • Specific target system         • Commands or code samples    │
│  • Expected outcome               • Configuration examples      │
│                                                                 │
│  WHY IT MATTERS                   VERIFICATION                  │
│  ──────────────                   ────────────                  │
│  • Link to finding/risk           • How to confirm fix works    │
│  • Business impact avoided        • Testing approach            │
│  • Compliance requirement met     • Success criteria            │
│                                                                 │
│  EFFORT & RESOURCES               ALTERNATIVES                  │
│  ─────────────────                ────────────                  │
│  • Time estimate                  • If primary fix not possible │
│  • Skills required                • Compensating controls       │
│  • Dependencies                   • Interim mitigations         │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Good vs. Poor Recommendations

❌ Poor Recommendation

"Fix the SQL injection vulnerability in the search function."

Too vague. Doesn't tell the developer how to fix it, what the specific issue is, or how to verify the fix.

✓ Good Recommendation

Finding: SQL Injection in Customer Search API (R-002)

Affected Endpoint: POST /api/v1/customers/search

Recommendation: Implement parameterized queries for all database interactions in the search endpoint.

Implementation:

// VULNERABLE CODE (current):
const query = `SELECT * FROM customers WHERE name LIKE '%${searchTerm}%'`;

// SECURE CODE (recommended):
const query = 'SELECT * FROM customers WHERE name LIKE ?';
const params = [`%${searchTerm}%`];
db.query(query, params);

Verification: Re-test with SQLMap; endpoint should return no injection vulnerabilities. Manual testing with ' OR '1'='1 should return no data or error, not all records.

Effort: 2-4 hours development + testing

Alternative: If code fix is delayed, implement WAF rule to block SQL injection patterns as interim control.

Sample Remediation Recommendations

R-001 Critical

Log4Shell Remediation - Jenkins Server

Primary Recommendation: Upgrade Log4j

Action: Upgrade Apache Log4j to version 2.17.1 or later on the Jenkins server.

Implementation Steps:

  1. Schedule maintenance window (recommend off-hours)
  2. Backup current Jenkins configuration: 
    sudo cp -r /var/lib/jenkins /var/lib/jenkins.backup
  3. Update Jenkins to latest LTS version (includes patched Log4j): 
    sudo apt update
sudo apt install jenkins
sudo systemctl restart jenkins
  4. Verify Log4j version post-update: 
    find /var/lib/jenkins -name "log4j*.jar" -exec unzip -p {} META-INF/MANIFEST.MF \; | grep Implementation-Version

Verification:

  • Confirm Log4j version is 2.17.1+
  • Re-test with JNDI injection payload; should not trigger callback
  • Verify Jenkins functionality post-update

Effort: 2-3 hours including testing

Skills Required: Linux system administration, Jenkins administration

Dependencies: Maintenance window approval, Jenkins plugin compatibility check

Interim Mitigation (If Immediate Patching Not Possible)

Action: Apply JVM mitigation flag and network controls.

  1. Add JVM flag to disable JNDI lookups: 
    # Edit /etc/default/jenkins
JAVA_ARGS="-Dlog4j2.formatMsgNoLookups=true"
sudo systemctl restart jenkins
  2. Block outbound LDAP/RMI traffic from Jenkins: 
    sudo iptables -A OUTPUT -p tcp --dport 389 -j DROP
sudo iptables -A OUTPUT -p tcp --dport 1099 -j DROP
  3. Enable enhanced logging to detect exploitation attempts

Note: This is a temporary measure. Full patching is required within 48 hours.

R-003 Critical

Public S3 Bucket Remediation

Recommendation: Remove Public Access and Implement Secure Access Pattern

Action: Remove public access policy and implement pre-signed URLs for legitimate access.

Implementation Steps:

  1. Enable S3 Block Public Access at bucket level: 
    aws s3api put-public-access-block \
  --bucket novatech-customer-uploads \
  --public-access-block-configuration \
  "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
  2. Remove the public access policy: 
    aws s3api delete-bucket-policy --bucket novatech-customer-uploads
  3. Implement pre-signed URL generation in application code: 
    // Node.js example for generating pre-signed URLs
const AWS = require('aws-sdk');
const s3 = new AWS.S3();

function getSignedUrl(key) {
  return s3.getSignedUrl('getObject', {
    Bucket: 'novatech-customer-uploads',
    Key: key,
    Expires: 3600 // 1 hour expiry
  });
}
  4. Enable S3 access logging: 
    aws s3api put-bucket-logging \
  --bucket novatech-customer-uploads \
  --bucket-logging-status file://logging-config.json

Verification:

  • Confirm public access block is enabled: aws s3api get-public-access-block --bucket novatech-customer-uploads
  • Test that direct URL access returns 403 Forbidden
  • Test that pre-signed URLs work correctly for authorized users
  • Review Access Analyzer for any remaining external access findings

Effort: 4-6 hours (includes application code changes)

Dependencies: Application deployment pipeline, QA testing

Post-Remediation Actions
  • Review S3 access logs for any unauthorized access during exposure period
  • Assess need for breach notification if unauthorized access detected
  • Document incident for SOC 2 audit records
R-004 High

IAM MFA Enforcement

Recommendation: Enforce MFA for All IAM Users with Console Access

Action: Enable MFA for all users and implement IAM policy requiring MFA for sensitive operations.

Implementation Steps:

  1. Communicate MFA requirement to all IAM users
  2. Provide MFA setup instructions (virtual MFA app or hardware token)
  3. Set deadline for MFA enablement (recommend 7 days)
  4. Apply IAM policy requiring MFA for sensitive actions: 
    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllExceptListedIfNoMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}
  5. Attach policy to all IAM users or groups

Verification:

  • Generate new credential report: aws iam generate-credential-report
  • Verify all users with password have mfa_active: true
  • Test that console access without MFA is denied

Effort: 1-2 hours configuration + user communication/support

Alternative: Migrate to AWS SSO with IdP-enforced MFA for centralized authentication management.

3. Estimating Remediation Effort

Accurate effort estimates help NovaTech allocate resources and set realistic timelines. Consider all factors that affect implementation time.

Effort Estimation Factors

┌─────────────────────────────────────────────────────────────────┐
│                  EFFORT ESTIMATION FACTORS                      │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  TECHNICAL COMPLEXITY            ORGANIZATIONAL FACTORS         │
│  ────────────────────            ──────────────────────         │
│  • Number of systems affected    • Change management process    │
│  • Code changes required         • Testing requirements         │
│  • Configuration complexity      • Approval workflows           │
│  • Integration dependencies      • Deployment windows           │
│                                                                 │
│  RESOURCE AVAILABILITY           RISK & TESTING                 │
│  ────────────────────            ───────────────                │
│  • Team availability             • Testing environment needs    │
│  • Skill set requirements        • Rollback planning            │
│  • Competing priorities          • Validation testing           │
│  • External dependencies         • Production verification      │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Effort Categories

Category Time Range Description Examples
Quick Win < 4 hours Simple configuration change, single system Enable MFA, add security header, update password policy
Small 4-16 hours Moderate complexity, limited scope Patch single server, fix simple code issue, update IAM policy
Medium 2-5 days Multiple systems or significant code changes Implement parameterized queries across API, configure WAF rules
Large 1-3 weeks Complex implementation, multiple teams Network segmentation, secrets management implementation
Project > 3 weeks Architectural change, significant planning Zero-trust implementation, major platform upgrade

Sample Effort Breakdown

Example: SQL Injection Fix (R-002)

Activity Effort Notes
Code review and fix identification 2 hours Developer reviews affected endpoints
Code implementation 4 hours Convert to parameterized queries
Unit testing 2 hours Test query functionality
Security testing 2 hours Re-test with SQLMap
Code review 1 hour Peer review of changes
Deployment 1 hour Deploy to staging, then production
Verification 1 hour Confirm fix in production
Total 13 hours ~2 days with buffer

4. Sequencing and Dependencies

Remediation activities often have dependencies. Some fixes must happen before others; some can be parallelized. Understanding these relationships is crucial for realistic planning.

Dependency Types

Technical Dependencies

One fix requires another to be completed first.

  • Can't deploy application fix until CI/CD pipeline is secured
  • Can't enable encryption until key management is configured
  • Network segmentation must precede certain access control changes

Resource Dependencies

Same team or resource needed for multiple fixes.

  • Single DBA needed for multiple database fixes
  • Same developer owns multiple application issues
  • Network team overloaded with concurrent requests

Business Dependencies

Business events or constraints affect timing.

  • Change freeze during month-end processing
  • Customer-facing changes need communication
  • Maintenance windows limited to off-hours

Quick Wins Strategy

Start with quick wins to build momentum and demonstrate progress while larger efforts are planned.

NovaTech Quick Wins (First Week)

Finding Fix Effort Impact
Public S3 bucket Enable public access block 30 min Eliminates critical exposure
Missing security headers Add headers via CDN/nginx 1 hour Improves defense-in-depth
SSH open to internet Restrict security group 30 min Reduces attack surface
IAM users without MFA Enable MFA enforcement 2 hours Account takeover protection
CloudTrail not multi-region Enable multi-region logging 30 min Complete audit coverage

Remediation Sequence Example

┌─────────────────────────────────────────────────────────────────┐
│              NOVATECH REMEDIATION SEQUENCE                      │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  PHASE 1: IMMEDIATE (Week 1)                                    │
│  ───────────────────────────                                    │
│  ┌─────────────┐   ┌─────────────┐   ┌─────────────┐           │
│  │ Log4Shell   │   │ Public S3   │   │ SSH SG      │           │
│  │ Patch       │   │ Fix         │   │ Restrict    │           │
│  └─────────────┘   └─────────────┘   └─────────────┘           │
│         │                                                       │
│         ▼                                                       │
│  PHASE 2: URGENT (Weeks 2-3)                                    │
│  ──────────────────────────────                                 │
│  ┌─────────────┐   ┌─────────────┐                             │
│  │ SQL         │   │ XSS         │  ← Requires dev resources   │
│  │ Injection   │   │ Fixes       │                             │
│  └─────────────┘   └─────────────┘                             │
│         │                │                                      │
│         └────────┬───────┘                                      │
│                  ▼                                              │
│  PHASE 3: PLANNED (Weeks 4-6)                                   │
│  ────────────────────────────                                   │
│  ┌─────────────┐   ┌─────────────┐   ┌─────────────┐           │
│  │ IAM Policy  │   │ Network     │   │ Secrets     │           │
│  │ Cleanup     │   │ Segmentation│   │ Management  │           │
│  └─────────────┘   └─────────────┘   └─────────────┘           │
│                           │                                     │
│                           ▼ (depends on segmentation)           │
│  PHASE 4: STRATEGIC (Weeks 7-12)                                │
│  ───────────────────────────────                                │
│  ┌─────────────────────────────────────────────────┐           │
│  │ Security Monitoring Enhancement                  │           │
│  │ SIEM Integration                                 │           │
│  │ Vulnerability Management Program                 │           │
│  └─────────────────────────────────────────────────┘           │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

5. Compensating Controls

When direct remediation isn't immediately possible, compensating controls reduce risk until the fix can be implemented.

When to Use Compensating Controls

Compensating Control Types

Control Type Description Examples
Network Controls Restrict access to vulnerable system Firewall rules, segmentation, VPN requirement, IP allowlisting
Application Controls Block attack patterns at application layer WAF rules, input validation, rate limiting
Detection Controls Identify and respond to exploitation attempts IDS signatures, log monitoring, alerting rules
Administrative Controls Process changes that reduce risk Enhanced review, access restrictions, manual approval

Sample Compensating Controls

Scenario: SQL Injection - Code Fix Delayed 2 Weeks

Compensating Controls:
  1. WAF Rule (Immediate):

    Deploy AWS WAF or CloudFlare rule to block SQL injection patterns:

    # AWS WAF managed rule
AWS-AWSManagedRulesSQLiRuleSet

# Custom rule for specific endpoint
Rule: Block requests to /api/search containing:
- UNION SELECT
- ' OR '
- --
- /**/
  2. Enhanced Logging (Immediate):

    Enable detailed logging on the affected endpoint:

    # Log all requests to search endpoint
# Alert on SQL keywords in parameters
# Send alerts to security team
  3. Rate Limiting (Immediate):

    Limit requests to search endpoint to slow potential exploitation:

    # 10 requests per minute per IP
# Alert on rate limit triggers

Effectiveness: Reduces likelihood from High to Medium. Does not eliminate vulnerability but makes exploitation significantly harder and more detectable.

Duration: Until code fix deployed (target: 2 weeks)

Monitoring: Daily review of WAF blocks and alerts

Compensating Controls Are Temporary

Compensating controls reduce risk but don't eliminate the underlying vulnerability. Always include an expiration date and ensure the permanent fix remains on track. Document the control and its limitations clearly.

6. Building the Remediation Roadmap

The remediation roadmap consolidates all recommendations into a phased plan that NovaTech can execute.

Roadmap Structure

┌─────────────────────────────────────────────────────────────────┐
│                   REMEDIATION ROADMAP TEMPLATE                  │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  EXECUTIVE SUMMARY                                              │
│  • Overall remediation effort                                   │
│  • Key milestones                                               │
│  • Resource requirements                                        │
│  • Success metrics                                              │
│                                                                 │
│  PHASE DETAILS (for each phase)                                 │
│  • Timeline                                                     │
│  • Findings addressed                                           │
│  • Specific actions                                             │
│  • Resources required                                           │
│  • Dependencies                                                 │
│  • Success criteria                                             │
│                                                                 │
│  TRACKING MECHANISMS                                            │
│  • Progress metrics                                             │
│  • Review cadence                                               │
│  • Escalation process                                           │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

NovaTech Remediation Roadmap Summary

Phase Timeline Focus Findings Resources
Phase 1: Critical Week 1 Eliminate critical exposures R-001, R-002, R-003 DevOps, AppDev, Cloud
Phase 2: High Priority Weeks 2-3 Address high-risk findings R-004, R-005, R-006 AppDev, IT Ops
Phase 3: Planned Weeks 4-8 Medium findings, architectural improvements R-007, R-008, Architecture All teams
Phase 4: Continuous Ongoing Low priority, process improvements R-009+, Program build Security team

Detailed Phase Example

Phase 1: Critical Remediation (Week 1)

Objective

Eliminate all critical-severity exposures that pose immediate risk to customer data and business operations.

Findings Addressed
ID Finding Action Owner Target
R-001 Log4Shell on Jenkins Patch to Log4j 2.17.1+ DevOps Day 1-2
R-002 SQL Injection Implement parameterized queries + WAF AppDev Day 3-5
R-003 Public S3 Bucket Enable public access block, implement pre-signed URLs Cloud Day 1
Resources Required
  • DevOps Engineer: 8 hours
  • Application Developer: 16 hours
  • Cloud Engineer: 4 hours
  • QA: 8 hours for testing
Dependencies
  • Maintenance window approval for Jenkins restart
  • Application deployment pipeline availability
  • Pre-signed URL implementation requires application code change
Success Criteria
  • Log4j version 2.17.1+ confirmed on Jenkins
  • SQL injection re-test shows no vulnerabilities
  • S3 bucket returns 403 on direct public access
  • All critical findings marked "Remediated" in risk register
Verification

SecureFirst will perform verification testing on Day 7 to confirm remediation effectiveness.

7. Tracking and Verification

Remediation isn't complete until verified. Establish mechanisms for tracking progress and confirming fixes.

Progress Tracking

Regular Status Meetings

Weekly remediation sync with responsible teams:

  • Review findings by status (Open, In Progress, Remediated)
  • Identify blockers and escalate
  • Adjust timelines if needed
  • Document decisions

Risk Register Updates

Keep the risk register current:

  • Update status as remediation progresses
  • Add notes on implementation details
  • Record compensating controls if applied
  • Track verification dates

Metrics Dashboard

Track remediation progress visually:

  • Findings by status (open vs. closed)
  • Findings by severity over time
  • Mean time to remediate by severity
  • SLA compliance (% fixed within target)

Verification Testing

Each remediated finding should be re-tested to confirm the fix works:

Finding Type Verification Method Tools
Infrastructure vulnerability Re-scan with vulnerability scanner Nessus, OpenVAS, Nmap scripts
Web application vulnerability Re-test with original attack vectors Burp Suite, SQLMap, manual testing
Cloud misconfiguration Re-run cloud security assessment Prowler, AWS CLI validation
Configuration issue Verify configuration change applied CLI commands, configuration audit

Verification Documentation

For each verified remediation, document:

Self-Check Questions

Test your understanding of remediation planning:

Question 1

A critical SQL injection vulnerability has been identified. The development team says a proper code fix will take 3 weeks due to complex database queries. What remediation approach would you recommend?

Reveal Answer

Recommend a multi-layered approach:

  1. Immediate (Day 1): Deploy WAF rule blocking SQL injection patterns on the affected endpoint
  2. Immediate (Day 1): Enable enhanced logging and alerting for the endpoint
  3. Short-term (Week 1): Implement rate limiting to slow potential exploitation
  4. If possible (Week 1): Implement basic input validation as an interim code fix
  5. Long-term (Week 3): Complete proper parameterized query implementation

Key principle: Don't wait 3 weeks with no protection. Compensating controls reduce risk while the proper fix is developed. Document all interim measures and ensure the permanent fix stays on track.

Question 2

You've written a remediation recommendation that says "Patch the server." Why is this insufficient, and how would you improve it?

Reveal Answer

"Patch the server" is insufficient because it:

  • Doesn't specify which server
  • Doesn't specify which patch/version
  • Doesn't provide implementation steps
  • Doesn't address testing requirements
  • Doesn't explain verification method

Improved recommendation:

Server: jenkins-prod-01 (10.10.10.50)

Action: Update Apache Log4j from 2.14.1 to 2.17.1

Steps:

  1. Schedule maintenance window
  2. Backup current configuration
  3. Update Jenkins to latest LTS: sudo apt update && sudo apt install jenkins
  4. Restart service: sudo systemctl restart jenkins
  5. Verify version: find /var/lib/jenkins -name "log4j*.jar"

Verification: Log4j JAR version shows 2.17.1+

Effort: 2 hours including testing

Rollback: Restore from backup if issues occur

Question 3

NovaTech's development team is fully committed to a product launch for the next 4 weeks. You have 5 high-severity application vulnerabilities that need code fixes. What options would you present to leadership?

Reveal Answer

Present options with risk implications:

  1. Option A: Delay Product Launch
    • Dedicate 1-2 weeks to security fixes before launch
    • Risk: Business impact from delayed launch
    • Benefit: Ship secure product
  2. Option B: Parallel Track
    • Assign 1-2 developers to security while others continue launch
    • Risk: Slower progress on both tracks
    • Benefit: Some security improvement + launch continues
  3. Option C: Launch with Compensating Controls
    • Implement WAF rules, monitoring, rate limiting
    • Schedule code fixes for post-launch sprint
    • Risk: Vulnerabilities still exist; controls may be bypassed
    • Benefit: Launch on schedule
  4. Option D: Risk Acceptance (Not Recommended)
    • Document risks, obtain executive sign-off
    • Risk: High likelihood of security incident
    • Requires formal acceptance from CISO/executive

Recommendation: Option B or C with clearly documented compensating controls and firm commitment to post-launch remediation sprint.

Question 4

How would you sequence remediation for the following three findings, and why?

Reveal Answer

Sequence: A → B → C (with some parallelization)

Rationale:

  1. A (Jenkins Log4Shell) - First
    • This is the entry point; if not fixed, attacker can still access B and C
    • External-facing means highest exposure
    • Fix eliminates the attack vector
  2. B (AWS credentials in Jenkins) - Second
    • Even after A is fixed, credentials may be compromised
    • Rotate credentials immediately
    • Implement secrets management solution
  3. C (Permissive IAM policy) - Third
    • Reduces blast radius if any credential compromise occurs
    • Can be done in parallel with B
    • Defense-in-depth improvement

Note: While A is being fixed (Day 1), immediately rotate the AWS credentials (B) as they may already be compromised. C can be addressed once the immediate crisis is resolved.

Question 5

A remediation was implemented for a SQL injection vulnerability. The development team says it's fixed. What should happen before marking this as "Remediated" in the risk register?

Reveal Answer

Verification steps required:

  1. Independent testing: Security team (not developers) should re-test
  2. Same attack vectors: Use the original attack methods that found the vulnerability
  3. Tool validation: Re-run SQLMap or other automated tools
  4. Manual testing: Test edge cases and variations
  5. Code review: Verify parameterized queries are correctly implemented
  6. Production verification: Test in production (carefully) not just staging

Documentation required:

  • Verification date and tester
  • Test methods used
  • Results (scan output, screenshot)
  • Confirmation that original attack no longer works

Only after verification passes should the finding be marked "Remediated" with evidence attached.

Question 6

What information should be included in a compensating control documentation for a vulnerability that can't be immediately patched?

Reveal Answer

Compensating control documentation should include:

  • Finding reference: Which vulnerability this compensates for
  • Control description: Exactly what was implemented
  • Implementation details: Configuration, rules, settings
  • Effectiveness assessment: How much does this reduce risk?
  • Limitations: What scenarios are NOT covered
  • Monitoring requirements: How to detect if control fails or is bypassed
  • Expiration date: When must permanent fix be implemented
  • Review schedule: How often to verify control is working
  • Responsible party: Who maintains the control
  • Removal plan: How to remove control when permanent fix is done

Key principle: Compensating controls are temporary. The documentation ensures they don't become permanent band-aids that are forgotten.

Lab: NovaTech Remediation Roadmap

Objective

Develop a comprehensive remediation roadmap for NovaTech that includes specific recommendations, effort estimates, sequencing, and compensating controls.

Deliverables

Time Estimate

4-5 hours

Lab Tasks

Part 1: Develop Detailed Recommendations (LO1)

  1. Review your risk register from Week 7
  2. For each Critical and High finding, write detailed recommendations including:
    • Specific actions to take
    • Implementation steps with commands/code
    • Verification method
    • References to documentation
  3. For Medium findings, write summary recommendations
  4. For Low findings, provide brief guidance

Part 2: Estimate Effort (LO2)

  1. For each recommendation, estimate:
    • Implementation time (hours/days)
    • Skills required
    • Testing time
    • Deployment complexity
  2. Categorize by effort (Quick Win, Small, Medium, Large, Project)
  3. Identify total resource requirements

Part 3: Identify Dependencies (LO3)

  1. Map dependencies between findings/remediations
  2. Identify resource conflicts (same team needed for multiple fixes)
  3. Note business constraints (change freezes, deployment windows)
  4. Document external dependencies (vendor patches, third parties)

Part 4: Design Compensating Controls (LO4)

  1. For any Critical/High finding that can't be fixed immediately, design compensating controls
  2. Document:
    • Control description
    • Implementation steps
    • Effectiveness assessment
    • Monitoring requirements
    • Expiration date

Part 5: Build Remediation Roadmap (LO5)

  1. Organize findings into phases based on:
    • Risk level
    • Dependencies
    • Quick wins
    • Resource availability
  2. Create timeline with milestones
  3. Assign ownership by team/role
  4. Define success criteria for each phase
  5. Document tracking and verification approach

Part 6: Create Executive Presentation

  1. Prepare 2-3 slide summary of remediation roadmap
  2. Include:
    • High-level timeline
    • Resource requirements
    • Key milestones
    • Decision points requiring executive input

Self-Assessment Checklist

Recommendation Quality

  • ☐ All Critical/High findings have detailed recommendations
  • ☐ Recommendations include specific implementation steps
  • ☐ Verification methods defined for each recommendation
  • ☐ Code/command examples provided where applicable

Effort Estimation

  • ☐ All findings have effort estimates
  • ☐ Estimates include testing and deployment time
  • ☐ Resource requirements clearly identified
  • ☐ Estimates are realistic and justified

Roadmap Quality

  • ☐ Phases are logically organized
  • ☐ Dependencies are identified and addressed
  • ☐ Quick wins appropriately prioritized
  • ☐ Timeline is realistic
  • ☐ Success criteria defined for each phase

Compensating Controls

  • ☐ Controls designed for any delayed Critical/High fixes
  • ☐ Controls include expiration dates
  • ☐ Monitoring requirements documented
  • ☐ Limitations clearly stated

Portfolio Integration

Save your remediation planning deliverables:

🎯 Hands-On Capstone Activities

Week 8 capstone activities - Remediation Planning

🎯 Remediation Planning Lab

Deliverable: Professional capstone component ready for portfolio
Time estimate: 4-8 hours

💡 Capstone Strategy: This work becomes your portfolio—make it job-interview ready.

Resources

Required

NIST SP 800-40: Guide to Enterprise Patch Management

Federal guidance on establishing and maintaining patch management programs, including prioritization and testing considerations.

NIST SP 800-40 Rev 4 45 minutes (Sections 2-3)
Required

OWASP Vulnerability Remediation Guide

Practical guidance for remediating common web application vulnerabilities with code examples and verification approaches.

OWASP Cheat Sheet Series 60 minutes (SQL Injection, XSS prevention sheets)
Optional

AWS Security Best Practices

AWS documentation on security best practices for remediating common cloud misconfigurations.

AWS Security Reference Architecture 30 minutes

Weekly Reflection

Prompt

Reflect on the difference between identifying vulnerabilities and planning their remediation. What additional considerations come into play when moving from "what's wrong" to "how to fix it"? How do organizational constraints (resources, timelines, priorities) affect security decisions?

Consider a scenario where business pressures push for minimal remediation time. How would you balance the need to fix vulnerabilities against realistic constraints? What role do compensating controls play in this balance, and what are their limitations?

Target length: 250-350 words

Week 08 Quiz

Test your understanding of the weekly concepts.

Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.

Take Quiz