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.
- Effort: Low to Medium
- Effectiveness: High (eliminates vulnerability)
- Considerations: Testing requirements, downtime, compatibility
Code Fixes
Modifying application code to address vulnerabilities. Required for custom application issues like SQL injection or XSS.
- Effort: Medium to High
- Effectiveness: High (eliminates vulnerability)
- Considerations: Development capacity, testing, deployment pipeline
Configuration Changes
Adjusting settings to improve security posture. Includes enabling encryption, tightening permissions, disabling unnecessary features.
- Effort: Low to Medium
- Effectiveness: Varies (may eliminate or mitigate)
- Considerations: Service impact, testing, documentation
Architectural Changes
Modifying system design or infrastructure. Includes network segmentation, adding security layers, redesigning authentication.
- Effort: High
- Effectiveness: High (often addresses multiple issues)
- Considerations: Project planning, budget, extended timeline
Compensating Controls
Alternative measures that reduce risk when direct remediation isn't immediately possible. Temporary measure, not a solution.
- Effort: Low to Medium
- Effectiveness: Partial (reduces but doesn't eliminate risk)
- Considerations: Temporary nature, monitoring requirements
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/searchRecommendation: 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'='1should 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
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:
- Schedule maintenance window (recommend off-hours)
- Backup current Jenkins configuration:
sudo cp -r /var/lib/jenkins /var/lib/jenkins.backup
- Update Jenkins to latest LTS version (includes patched Log4j):
sudo apt update sudo apt install jenkins sudo systemctl restart jenkins
- 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.
- Add JVM flag to disable JNDI lookups:
# Edit /etc/default/jenkins JAVA_ARGS="-Dlog4j2.formatMsgNoLookups=true" sudo systemctl restart jenkins
- 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
- Enable enhanced logging to detect exploitation attempts
Note: This is a temporary measure. Full patching is required within 48 hours.
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:
- 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"
- Remove the public access policy:
aws s3api delete-bucket-policy --bucket novatech-customer-uploads
- 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 }); } - 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
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:
- Communicate MFA requirement to all IAM users
- Provide MFA setup instructions (virtual MFA app or hardware token)
- Set deadline for MFA enablement (recommend 7 days)
- 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" } } } ] } - 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
- Patch not available: Vendor hasn't released fix yet
- Resource constraints: Development team overloaded
- Change freeze: Business constraints prevent changes
- Complex dependencies: Fix requires significant planning
- Legacy systems: System can't be updated without major effort
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:
-
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 ' - -- - /**/
-
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
-
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:
- Date of verification testing
- Tester name
- Test method used
- Results (Pass/Fail)
- Evidence (screenshot, scan output)
- If failed: reason and re-test date
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:
- Immediate (Day 1): Deploy WAF rule blocking SQL injection patterns on the affected endpoint
- Immediate (Day 1): Enable enhanced logging and alerting for the endpoint
- Short-term (Week 1): Implement rate limiting to slow potential exploitation
- If possible (Week 1): Implement basic input validation as an interim code fix
- 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:
- Schedule maintenance window
- Backup current configuration
- Update Jenkins to latest LTS:
sudo apt update && sudo apt install jenkins- Restart service:
sudo systemctl restart jenkins- 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:
- Option A: Delay Product Launch
- Dedicate 1-2 weeks to security fixes before launch
- Risk: Business impact from delayed launch
- Benefit: Ship secure product
- 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
- 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
- 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?
- A: Jenkins Log4Shell vulnerability (external-facing, Critical)
- B: AWS credentials stored in Jenkins (found during A exploitation)
- C: Overly permissive IAM policy for those AWS credentials
Reveal Answer
Sequence: A → B → C (with some parallelization)
Rationale:
- 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
- B (AWS credentials in Jenkins) - Second
- Even after A is fixed, credentials may be compromised
- Rotate credentials immediately
- Implement secrets management solution
- 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:
- Independent testing: Security team (not developers) should re-test
- Same attack vectors: Use the original attack methods that found the vulnerability
- Tool validation: Re-run SQLMap or other automated tools
- Manual testing: Test edge cases and variations
- Code review: Verify parameterized queries are correctly implemented
- 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
- Remediation Recommendations Document: Detailed recommendations for all findings
- Remediation Roadmap: Phased plan with timeline and dependencies
- Compensating Controls Plan: Interim measures for delayed remediations
Time Estimate
4-5 hours
Lab Tasks
Part 1: Develop Detailed Recommendations (LO1)
- Review your risk register from Week 7
- For each Critical and High finding, write detailed recommendations including:
- Specific actions to take
- Implementation steps with commands/code
- Verification method
- References to documentation
- For Medium findings, write summary recommendations
- For Low findings, provide brief guidance
Part 2: Estimate Effort (LO2)
- For each recommendation, estimate:
- Implementation time (hours/days)
- Skills required
- Testing time
- Deployment complexity
- Categorize by effort (Quick Win, Small, Medium, Large, Project)
- Identify total resource requirements
Part 3: Identify Dependencies (LO3)
- Map dependencies between findings/remediations
- Identify resource conflicts (same team needed for multiple fixes)
- Note business constraints (change freezes, deployment windows)
- Document external dependencies (vendor patches, third parties)
Part 4: Design Compensating Controls (LO4)
- For any Critical/High finding that can't be fixed immediately, design compensating controls
- Document:
- Control description
- Implementation steps
- Effectiveness assessment
- Monitoring requirements
- Expiration date
Part 5: Build Remediation Roadmap (LO5)
- Organize findings into phases based on:
- Risk level
- Dependencies
- Quick wins
- Resource availability
- Create timeline with milestones
- Assign ownership by team/role
- Define success criteria for each phase
- Document tracking and verification approach
Part 6: Create Executive Presentation
- Prepare 2-3 slide summary of remediation roadmap
- 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:
08-remediation-planning/remediation-recommendations.pdf— Detailed recommendationsremediation-roadmap.pdf— Phased plan with timelinecompensating-controls.pdf— Interim mitigation planexecutive-presentation.pdf— 2-3 slide summary
🎯 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
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)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)AWS Security Best Practices
AWS documentation on security best practices for remediating common cloud misconfigurations.
AWS Security Reference Architecture 30 minutesWeekly 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