A comprehensive study guide covering remediation and mitigation processes, risk acceptance, change control, configuration baselines (CIS controls, deviations, compensating controls), a 10-point system hardening checklist (attack surface reduction, availability hardening), patch management (classify/test/deploy, SCCM/Endpoint Manager, maintenance windows), and remediation inhibitors (legacy systems, proprietary systems, organisational governance, business process interruption, degraded functionality, MOUs, SLAs).
Objective 2.1 — Vulnerability scanning methods and conceptsObjective 2.5 — Vulnerability response, handling and managementObjective 4.1 — Vulnerability management reporting and communication
1
Remediation & Mitigation — The Process
Remediation is the overall process of reducing exposure to the effects of risk factors. The goal is not zero risk — that's impossible. The goal is to reduce residual risk to within the organisation's risk appetite. Remediation takes many forms: patching, compensating controls, isolation, configuration changes.
Remediation process flow
Prioritise
Order vulnerabilities by criticality. CVSS critical → high → medium → low. Consider asset criticality alongside CVSS score. A medium on the CEO's machine may outrank a critical on an isolated lab server.
Assess
Ask three questions: How critical is the system? How difficult is remediation? How risky is the issue in your specific environment (not just the generic CVSS score)?
Change control
Route all changes through change management. Installing patches, changing configurations, adding firewall rules — all of these are changes. Unmanaged changes add more risk, not less. Follow your organisation's change control process for every remediation action.
Remediate
Apply the fix: patch the vulnerability, adjust the configuration, isolate the system, or apply a compensating control. Choose the approach that best balances risk reduction with business continuity impact.
Verify
Scan again after remediation. Verify the fix worked and identify any residual risk. Installing a patch can fix one vulnerability while introducing two new ones — always verify. Document what remains as accepted risk.
Accept & monitor
For risks that can't or won't be fixed: formally accept the risk, document it on the risk register, and monitor it on an ongoing basis. Risk acceptance is not ignoring risk — it's a deliberate, documented decision.
Risk acceptance
Risk acceptance means no countermeasure is implemented because the risk level is too low to justify the cost, or the cost to fix exceeds the expected cost of the risk materialising. Example: a $10,000 annual risk doesn't justify spending $1M to remediate. When accepting risk, it must still be monitored — document it on the risk register so future analysts understand the decision was deliberate, not an oversight.
Residual risk
The risk that remains after all controls and mitigations are applied. Every system has residual risk. The job is to bring residual risk within the organisation's risk appetite — not to zero. Document residual risk after each remediation cycle.
Change control matters
Every patch, configuration change, or firewall rule must go through change control. Uncontrolled changes are themselves a security risk. Change control ensures testing before deployment, rollback planning, and auditability of all changes to the environment.
Always re-scan after patching
A patch that fixes one vulnerability may introduce others. Just because a patch was applied doesn't mean it succeeded. Re-scan to verify the vulnerability is gone, check for new findings, and confirm the remaining residual risk is within appetite.
A configuration baseline is the set of all service and policy configurations for a server operating in a specific application role (web server, file server, mail server, etc.). Once established, any deviation from the baseline must be either remediated or formally accepted as a risk. The baseline is the "known-good" state everything is measured against.
Creating a baseline
1. Install the OS and all required software. 2. Apply all patches and hardening. 3. Run a vulnerability scan. 4. Remediate findings to acceptable level. 5. Scan again. 6. The result is your baseline. All future scans compare against this state.
Deviations from baseline
Any change from the baseline state — whether configuration drift, new software, a new user account, or an unapproved firewall rule — is a deviation. Deviations must be tracked: either remediated (bring back to baseline) or formally accepted with documentation.
Where to get baselines
Vendor-provided (Microsoft Windows Baseline Security Analyser). Regulatory (PCI DSS provides baseline requirements for cardholder environments). Third-party (Center for Internet Security — CIS Benchmarks). Use the most appropriate source for your environment and regulatory requirements.
CIS Top 5 Critical Security Controls (of the 20)
CIS 1
Inventory of Authorised and Unauthorised Devices — know every device on your network. You can't secure what you don't know exists.
CIS 2
Inventory of Authorised and Unauthorised Software — know every application installed. Unapproved software is an uncontrolled risk.
CIS 3
Secure Configurations for Hardware and Software — baseline hardening for all mobile devices, laptops, workstations, and servers.
CIS 4
Continuous Vulnerability Assessment and Remediation — the scan→patch→scan cycle applied continuously. Identifies and fixes weaknesses before attackers exploit them.
CIS 5
Controlled Use of Administrative Privileges — restrict admin rights to only what's necessary. Limit the blast radius of any single compromise.
Compensating controls
When you can't apply the primary control (e.g. no patch available, or applying the patch would break critical functionality), a compensating control substitutes for it — providing the same or better level of protection through a different method.
Example 1 — unpatched ICS
Can't patch an old ICS/SCADA system — no patch exists and the vendor is gone. Compensating control: isolate it onto a dedicated VLAN with no internet connectivity and strict firewall ACLs. The isolation provides equivalent protection to patching the specific vulnerability.
Example 2 — port 445
Legacy file server requires port 445 but has an unpatched vulnerability. Can't patch it. Compensating control: block port 445 at the perimeter firewall so it's only reachable internally. Eliminates the internet-facing exposure while preserving internal function.
Compensating control requirements
Must provide the same or better level of security as the primary control it replaces. Must be documented formally. Must be reviewed regularly — when the original patch or fix becomes available, the compensating control should be replaced with the proper fix.
3
System Hardening — 10-Point Checklist
System hardening reduces a device's attack surface by removing or disabling anything that isn't needed. The attack surface is every service, interface, port, account, and protocol that allows communication with the system. Every unused item on that list is a potential vulnerability — so remove it.
1
Remove or disable unneeded devices.Attack surface WiFi card, CD/DVD drive, USB ports, Bluetooth — if it's not needed for the system's job, remove or disable it. Hardware you're not using is still an attack vector.
2
Install OS, application, firmware, and driver patches regularly.Patch Tuesday Attackers reverse-engineer patches to create exploits. If you haven't applied the patch, you're vulnerable to a publicly known exploit with working code. Scan → patch → scan.
3
Uninstall unnecessary network protocols.Attack surface Not running a web server? Close port 80. Not running SSH? Close port 22. Not running mail? Close port 25. Workstations should have essentially no open inbound ports. Servers should only expose ports for their specific role.
4
Uninstall or disable unnecessary services and shared folders.Least service Every enabled service is a potential vulnerability. If a service isn't required for the system's business function, uninstall it (preferred) or disable it. Shared folders expose data — only create shares that have a documented business need.
5
Enforce ACLs on all system resources.Access control Files, folders, printers, and shared resources must all have appropriate access control lists restricting access to only authorised users. No resource should be open to everyone by default.
6
Restrict all user accounts to least privilege.Least privilege Standard users don't need admin rights. If a task can be done with a user account, don't use an admin account. Use the lowest privilege level that gets the job done. Admin rights = higher blast radius on compromise.
7
Rename and secure the local admin/root account.Account hardening "administrator" and "root" are known account names — attackers try these first. Disable the default names and create renamed super-user accounts. Always change default passwords (never leave "toor" as the root password on a Kali system).
8
Disable unnecessary default user and group accounts.Account hygiene Guest accounts, default service accounts, and legacy accounts that are no longer in use should be disabled. Each is a potential authentication path for an attacker.
9
Verify permissions on all accounts and groups routinely.Permission creep Users accumulate permissions over time as they change roles — old permissions are rarely revoked automatically. Review all user permissions quarterly against what their current role actually requires. Remove anything that exceeds current need.
10
Install and maintain anti-malware with automatic definition updates.Detection Anti-malware software that never updates is nearly useless against new threats. Configure automatic daily definition downloads and scheduled scans. No exceptions for "critical" systems — they especially need up-to-date protection.
Availability hardening
Power resilience
UPS (battery backup) for all servers — keeps them online during brief outages and provides time for generators to spin up. Secondary generator for extended outages. No UPS = any power fluctuation can cause unplanned downtime.
Network resilience
Multiple ISP connections (primary fibre + backup cellular or satellite). If the primary path fails, traffic automatically fails over. Design for failure — assume any single link will fail eventually.
System redundancy
Load balanced server pairs — one goes offline for patching while the other handles traffic. RAID storage arrays — multiple disks so one failure doesn't cause data loss. Clustered systems for critical services.
4
Patch Management — Classify, Test, Deploy
Patch management identifies, tests, and deploys updates to operating systems and applications. Patches fix security bugs, functionality issues, and performance problems. The security analyst's focus: apply critical and security-critical patches as fast as possible while maintaining system stability through proper testing.
Patch classification and priority
Classification
Priority
Notes
Critical
Immediately — within 24–48 hours
Remote code execution, privilege escalation without interaction. Exploit code almost certainly exists or will soon. Every hour of delay is exposure.
Security-Critical
Urgently — within the current patch cycle
Significant security exposure but requires more conditions to exploit. Still high priority — shouldn't wait longer than one patch cycle.
Recommended
Standard patch cycle
Addresses known bugs or non-critical security issues. Apply on your normal schedule (monthly, weekly) — no need to emergency deploy.
Optional
When convenient
Feature updates, optional functionality changes. Evaluate business need before deploying — some optional patches introduce new issues. Apply in your next scheduled window.
Enterprise patch management tools
Microsoft SCCM
System Center Configuration Manager
Enterprise patch deployment tool for Microsoft environments. Distributes patches to Windows endpoints across large networks. Provides deployment status reporting — critical for verifying patches actually installed successfully on all targets.
Microsoft Endpoint Manager
Intune / Endpoint Manager
Modern cloud-based successor to SCCM. Manages patching for both on-premise and cloud-enrolled devices. Supports mobile device management. Provides patch compliance reporting across hybrid environments.
Patching itself is an availability risk. Many patches require a system reboot. A rebooting server means 5–20 minutes of downtime. Plan maintenance windows: patch during off-peak hours, off-business hours, or use rolling updates (patch one node at a time in a cluster) to maintain availability. Never patch all nodes simultaneously if you need continuous uptime.
When patches don't exist
Legacy systems
OS/software no longer supported — vendor doesn't release patches. Options: isolate from network (air-gap or VLAN), apply compensating controls, or replace the system (expensive but permanent fix). Document as a formal exception with compensating controls.
Proprietary systems
Patches depend on the original vendor's support cycle — could be 6 months, 1 year, or longer. If vendor is gone, no patches ever. Engage contract (SLA) proactively before vulnerability is found, not after. Without an SLA, your only option is compensating controls.
ICS/SCADA & IoT
Embedded systems often can't be patched — or rebooting them stops production. Use network isolation, dedicated VLANs, and firewall rules as compensating controls. Evaluate risk against production impact before any patching attempt.
5
Remediation Inhibitors — What Gets in the Way
Even when a vulnerability is identified and a fix is available, numerous factors can prevent or delay remediation. Understanding these inhibitors helps you plan mitigations and communicate realistic timelines to leadership.
Legacy Systems
Systems no longer supported by their vendor — no patches available, ever. A 20-year-old manufacturing control system may be critical to operations but completely unpatched. Response: compensating controls (isolation, network segmentation) + formal risk acceptance + planned replacement roadmap.
Proprietary Systems
Systems owned by a developer/vendor where patching requires going back to the original creator. Custom-coded internal apps, military systems (F-16, Abrams tank software), specialised manufacturing equipment. Patch timelines depend on vendor contract terms — could be months. SLA/contract critical.
Organisational Governance
Leadership may block remediation for business reasons — "you can't take the X-ray machines offline for two days." Hospitals, factories, and 24/7 operations have valid reasons to delay security patches. Your job: present the risk clearly and propose alternatives (compensating controls, phased rollout) so decision makers can make informed choices.
Business Process Interruption
Applying a patch or rebooting a server interrupts the service. For 24/7 operations (Amazon, online training platforms), any downtime is costly. Solution: build in redundancy (clustered systems, load balancers) so you can patch one node while another handles traffic. Plan maintenance windows for systems that can't be clustered.
Degraded Functionality
Taking one server offline while its partner handles load = reduced capacity. If the remaining server also goes down during this window, you're completely offline. You've traded full redundancy for a patching window. Monitor closely during degraded periods and have a rollback plan ready.
Budget Constraints
If a $10,000 risk would cost $1M to remediate, the organisation will accept the risk rather than fix it. Security professionals must frame vulnerability impact in business and financial terms to compete for budget. ROSI (Return on Security Investment) calculations help justify expenditure.
Exam context: The CySA+ exam will present scenarios with remediation inhibitors and ask what the analyst should do. The correct answer is almost always: assess the risk, implement compensating controls where the fix isn't possible, formally document the accepted risk, and continue monitoring. It's rarely "force the fix immediately regardless of impact."
6
MOUs vs. SLAs — Agreements That Affect Remediation
When third parties are involved in your environment — vendors, service providers, partners — the agreement governing the relationship directly impacts your ability to remediate vulnerabilities on time. Understanding MOUs vs. SLAs is essential for planning realistic remediation timelines.
MOU — Memorandum of Understanding
Not legally binding. No money exchanges. A gentlemen's agreement — an expression of intent to cooperate. Useful for: informal partnerships, preliminary agreements, mutual aid arrangements (e.g. two nearby organisations agreeing to share facilities if one loses power). If the other party can't or won't fulfil the MOU, there's no contractual recourse. Don't rely on an MOU for critical security support or patch timelines.
SLA — Service Level Agreement
Legally binding contract. Consequences for breach. Specifies exact service terms, uptime guarantees, support response times, and patch delivery timelines. If the vendor misses the SLA (e.g. fails to maintain 99.99% uptime), they must compensate — refunds, credits, or other remedies. For proprietary systems: require the SLA to specify patch support timelines, incident response commitments, and forensic support. Everything security-related should be in the SLA, not an MOU.
MOU use case
Preliminary/exploratory cooperation between non-competing organisations. Mutual aid agreements. Pre-contractual relationship-building. Any situation where informal commitment is adequate and the stakes are low enough to accept non-binding terms.
SLA use case
Any commercial service relationship. Hosting and cloud providers. Managed security service providers. Proprietary system vendors providing ongoing support. Any situation where you need enforceable timelines, quality standards, and financial consequences for non-performance.
SLA — what to include for security
Patch support timeline (monthly? quarterly? as-needed?). Incident response support commitments. Forensic/investigation support if breached. Data handling and security requirements. Breach notification obligations. Uptime guarantee and penalties for failure.
Exam
Quick Reference Cheat Sheet
Remediation process
Prioritise (CVSS + asset criticality) → Assess (how critical? how hard to fix? how risky in your env?) → Change control (all changes go through CM) → Remediate (patch/control/isolate) → Verify (re-scan) → Accept & monitor remaining risk. Goal = residual risk within appetite, not zero risk.
Risk acceptance
No countermeasure when risk is too low to justify cost OR fix cost > risk cost. Must still be documented on risk register and monitored. Accepted risk is a deliberate decision, not an oversight. Review at each vulnerability management cycle.
Configuration baseline
Known-good state for a system in its role (web server, file server, etc.). Sources: vendor (Microsoft), regulatory (PCI DSS), third-party (CIS Benchmarks). Any deviation must be remediated or formally accepted. Baseline = install + patch + harden + scan + rescan = starting point for all future comparisons.
CIS Top 5 controls
1 Device inventory (authorised + unauthorised). 2 Software inventory (authorised + unauthorised). 3 Secure configurations for all devices. 4 Continuous vulnerability assessment + remediation. 5 Controlled use of admin privileges. CIS provides benchmarks for each — available at cisecurity.org.
Critical = immediate (24–48h). Security-Critical = urgent (current patch cycle). Recommended = standard cycle. Optional = when convenient. Tools: SCCM / Microsoft Endpoint Manager. Always test before deploying. Patch in maintenance windows — reboots cause downtime. Re-scan after patching to verify.
Remediation inhibitors
Legacy systems (no vendor support, no patches). Proprietary systems (vendor dependent, long SLA cycles). Organisational governance (leadership blocks for business reasons). Business process interruption (can't reboot during production). Degraded functionality (patching one node reduces redundancy). Budget (fix cost > risk cost → accept). Response: compensating controls + formal risk acceptance.
MOU vs. SLA
MOU = Memorandum of Understanding — NOT legally binding, no money, gentleman's agreement, no consequences for non-compliance. Use for informal partnerships. SLA = Service Level Agreement — legally binding contract, specific terms, financial penalties for breach. Use for all vendor relationships, proprietary system support, cloud/hosting. Security patch timelines must be in the SLA, not an MOU.