3.3 Remediation, Mitigation, and Software Controls
Key Takeaways
- The four risk responses are mitigate (reduce), transfer (insure/outsource), accept (document), and avoid (eliminate the activity).
- When a patch is impossible, apply compensating controls: segmentation, WAF/virtual patching, hardening, monitoring, and access restriction.
- Software-specific defenses map to OWASP Top 10: input validation/parameterized queries for SQLi, output encoding for XSS, secure session management for CSRF.
- Shift-left scanning of Infrastructure as Code, containers, and dependencies catches issues before deployment, when fixes are cheapest.
3.3 Remediation, Mitigation, and Software Controls
Once a finding is prioritized, the work shifts from analysis to action. CySA+ Objective 2.4 and 2.5 test whether you can recommend the correct response and the correct technical control for a given context. The grading distinction the exam draws is between remediation (eliminating the vulnerability outright, usually by patching or upgrading) and mitigation (reducing the risk while the vulnerability technically persists, usually through compensating controls). Both are valid; the right one depends on whether a fix exists and whether the business can absorb the change.
The four risk responses
Every prioritized finding ends with one of four decisions. The exam expects you to pick the correct label from a scenario, so internalize the boundary between them - especially the line between mitigation (technically reduce) and acceptance (formally tolerate).
| Response | What it means | Typical trigger |
|---|---|---|
| Mitigate | Reduce likelihood or impact (patch, configure, segment) | Most findings; the default action |
| Transfer | Shift the loss to a third party (cyber insurance, outsourcing) | Residual risk you cannot fully fix |
| Accept | Formally document and tolerate the risk | Cost of fix exceeds the risk, leadership signs off |
| Avoid | Stop the activity or decommission the asset | Risk is intolerable and unfixable |
Key trap: risk acceptance without documentation is not acceptance - it is negligence. A defensible answer always routes acceptance through a sign-off and the risk register.
When you cannot patch: compensating controls
Legacy systems, vendor-unsupported software, and business-critical uptime often block patching. Apply layered compensating controls to reduce exposure:
- Network segmentation / VLAN isolation to shrink the attack surface
- Virtual patching via a WAF or IPS signature that blocks the exploit path
- System hardening - disable unused services, change default credentials, remove default accounts
- Enhanced monitoring - tighter logging and alerting on the exposed host
- Access restriction - allowlists, jump hosts, and least privilege
Worked scenario: an unsupported OS runs a legacy app that cannot be upgraded. Placing it on a dedicated VLAN behind strict firewall rules with 24/7 monitoring is risk mitigation through compensating controls, not risk acceptance - the risk is actively reduced, not merely tolerated.
Software vulnerabilities and their fixes
The exam maps attack classes (OWASP Top 10) to specific defenses. Match the weakness to the control:
| Vulnerability | Primary remediation |
|---|---|
| SQL injection | Parameterized queries / prepared statements, input validation |
| Cross-site scripting (XSS) | Output encoding, content security policy |
| Cross-site request forgery (CSRF) | Anti-CSRF tokens, SameSite cookies |
| Insecure direct object reference | Server-side authorization checks |
| Buffer overflow | Bounds checking, ASLR/DEP, safe languages |
| Hard-coded/default credentials | Secrets management vault, rotate and remove defaults |
Attack surface management and hardening controls
Objective 2.5 covers controls that shrink the attack surface before an attacker arrives. System hardening removes unnecessary services, closes unused ports, and applies secure baselines such as CIS Benchmarks or DISA STIGs. Patch management is the front line, but it pairs with configuration management so that approved baselines are enforced and drift is detected. Default credentials are a perennial finding - every device shipped with admin/admin must have that password changed and unused default accounts disabled before deployment, a textbook secure-configuration control.
Other exam-tested controls: multifactor authentication and least privilege to limit what a compromised account can reach; encryption of data at rest and in transit to blunt the impact of exposure; network access control (NAC) to keep unmanaged devices off sensitive segments; and endpoint detection and response (EDR) for continuous monitoring on hosts that cannot be fully patched. Map the control to the weakness in the stem - hardening for misconfiguration, MFA for credential attacks, segmentation for lateral movement.
Cloud, container, and IaC hardening
Cloud findings cluster around misconfiguration - public S3/Azure Blob/GCS buckets, over-permissive IAM roles, exposed management ports, and disabled logging. The fix is rarely a patch; it is correcting access policy and enabling guardrails such as bucket-level public-access blocks and least-privilege IAM. Container security adds image scanning for vulnerable dependencies, using minimal/distroless base images, avoiding running as root, and signing images to prevent tampering.
Infrastructure as Code (IaC) templates (Terraform, CloudFormation) should be scanned in the pipeline so a misconfiguration is rejected before it ever provisions a resource.
The shift-left principle - scanning in development and continuously after deployment - is repeatedly the correct answer because issues caught early are far cheaper to fix and never expose live data or customers. A misconfiguration blocked in a pull request costs minutes; the same flaw discovered after a breach costs disclosure, fines, and remediation under fire. Software composition analysis (SCA) extends this to third-party libraries, flagging known-vulnerable dependencies that your own code pulls in - the supply-chain risk behind incidents like Log4Shell.
Change management governs every fix
No remediation is exam-correct if it bypasses change management. A patch on a production system requires a tested change ticket, a maintenance window, a rollback plan, and stakeholder approval - because a fix that breaks a critical application trades one risk for a worse one. Emergency change procedures exist for actively exploited critical flaws, but they still produce a record. When a stem offers "patch immediately in production" versus "schedule the patch through change control," the controlled option is almost always correct unless the scenario explicitly describes active exploitation demanding an emergency change.
Validation closes the loop
Remediation is not finished when a ticket is marked resolved. A re-scan must confirm the vulnerability is gone, and the result is recorded for the audit trail. If the rescan still shows the finding, the fix failed or was incomplete, and the ticket reopens. Mature programs also track mean time to remediate (MTTR) by severity and the count of overdue findings against SLA, feeding those metrics into the reporting phase covered later in the guide.
A finance team buys cyber-insurance coverage specifically to offset the residual financial loss from a vulnerability that cannot be fully remediated. Which risk response does this represent?
A web application is vulnerable to SQL injection because user input is concatenated directly into database queries. Which remediation most directly eliminates the root cause?