📖 Report📚 Glossary🗺️ Concepts💡 Examples🃏 Flashcards✅ Quiz🎯 Tricks
Chapter 86 · Tricks

Vulnerability Remediation — Exam Tricks

Four high-yield patterns and three practice scenarios: insurance exclusions, VLAN routing requirements, compensating controls vs. exceptions, and why rescanning is mandatory after patching.

Trick 1 Cybersecurity Insurance Is Risk Transfer, Not Risk Elimination — Know the Exclusions

The exam tests whether candidates understand both what cybersecurity insurance covers and what it does not. Insurance is a risk transfer strategy: it moves financial consequences to the insurer. It does not reduce the probability of an attack or remove any vulnerability.

Coverage that is frequently tested:

  • Lost revenue from attack-caused service outages
  • Data recovery costs after a breach or ransomware
  • Losses from phishing attacks where employees were deceived
  • Privacy lawsuit costs from affected customers

Exclusions that are frequently tested:

  • Intentional acts by insured parties — if someone inside the organization deliberately caused or worsened the damage, the claim is denied
  • Unauthorized fund transfers — business email compromise scenarios where the organization was tricked into initiating a transfer may have limits or exclusions
  • Negligence that constitutes a policy condition violation (e.g., failing to maintain required MFA)

The exam trap: A question may present insurance as the answer to "how can the organization avoid all consequences of a breach." Insurance reduces financial consequences but does not prevent breaches, does not patch vulnerabilities, and does not cover every scenario. The correct framing: insurance is a backstop for residual financial risk that cannot be eliminated through technical controls.

Rule: Insurance covers financial aftermath, not technical prevention. Know the exclusions: intentional acts and fund transfers are commonly excluded.
Trick 2 VLANs Cannot Communicate Without a Layer 3 Device — This Is Always Tested

VLAN segmentation is one of the most commonly tested network topics in the Security+ exam. The single most tested fact about VLANs: devices on different VLANs cannot communicate without a Layer 3 device (router or Layer 3 switch).

Why this matters for security: VLANs are the standard way to provide logical segmentation on shared physical hardware. A switch can have 48 ports all assigned to different VLANs, and none of them can communicate with ports in another VLAN unless a router routes the traffic between them. This is the enforcement mechanism that makes VLAN segmentation work as a security control — without routing, VLAN boundaries are absolute.

Physical vs. logical segmentation comparison:

  • Physical segmentation — separate hardware, infrastructure, and cabling; maximum isolation but expensive and inflexible
  • VLAN (logical segmentation) — same hardware, logically separated; requires Layer 3 to cross boundaries; cost-effective and standard in enterprise environments
  • Air gap — most extreme; no network connectivity at all; eliminates remote exploit paths entirely

NGFW in segmentation: Next-generation firewalls placed between segments provide application-layer visibility on inter-segment traffic. A basic firewall allows or blocks by IP and port; an NGFW can identify the application and detect anomalous traffic patterns from systems that should not be generating them.

Rule: Different VLANs cannot talk without a router. Physical = separate hardware. Logical = same hardware, different VLANs. Air gap = no network at all.
Trick 3 Compensating Controls Are Temporary — Exceptions Are Formal and Documented

The exam tests the distinction between a compensating control and an exception/exemption. Both apply when a vulnerability cannot be immediately patched, but they are different responses with different implications.

Compensating controls:

  • Technical measures deployed to reduce exploitation risk without patching
  • Examples: disable the service, restrict access, add firewall rules, deploy host-based controls
  • Intended as temporary bridges — they remain in place until the patch can be deployed
  • Do not eliminate the vulnerability; reduce likelihood or impact of exploitation

Exception / Exemption:

  • A formal, documented decision to accept the risk of an unremediated vulnerability
  • Approved by a security committee or change control committee — not a single individual
  • Granted when: patch causes conflicts; vendor no longer supports the system; exploitation requires physical access that is controlled; operational constraints prevent deployment
  • Time-limited where possible; subject to periodic review; accompanied by documentation of compensating controls in place

The exam trap: A question may describe someone deciding unilaterally not to patch a system. This is not a valid exception — exceptions require a formal committee process. A single person cannot grant a valid exception, regardless of seniority.

Rule: Compensating controls = technical temporary fix. Exception = formal committee-approved risk acceptance. Neither is the same as ignoring the vulnerability.
Trick 4 Deployment Report "Success" Is Not Validation — Always Rescan After Patching

The exam specifically tests validation of remediation. The most important concept: a patch management platform reporting deployment success is not the same as the vulnerability being remediated. These are two different things.

Why deployment reports fail silently:

  • The deployment agent confirms the job completed; it does not confirm the patch persisted and is active
  • Configuration conflicts or conflicting software can silently roll back a patch after the agent reports success
  • Systems offline during deployment receive no patch but may not be flagged as failures if the agent did not attempt them
  • The patch may install but fail to apply to the correct component (a partial installation)

The three validation methods in priority order for the exam:

  1. Rescan — run a vulnerability scan after patching; this is the standard post-patch validation step and should be performed for every significant patch deployment
  2. Audit — review logs and deployment records for anomalies; supports compliance documentation
  3. Verify — manually log into the system and confirm the patch is installed and active; used for critical systems or when automated scanning is insufficient

The exam scenario: An organization deploys a patch, the platform reports 100% success, and the team closes the ticket. The next scheduled scan (weeks later) still shows the vulnerability on several systems. Lesson: rescan immediately after patching, not weeks later in a scheduled scan cycle.

Rule: Platform says success ≠ vulnerability is gone. Rescan after every significant patch deployment. Deployment report and vulnerability scan are not the same thing.
Practice Scenarios
Scenario A: A network engineer proposes solving a vulnerability on an unpatched server by placing it on a separate VLAN and arguing that "it can't reach anything now." The CISO asks two clarifying questions: (1) Is the server truly isolated from all other VLANs, and (2) what controls are on the inter-VLAN boundary? What should the security team verify, and what makes VLAN isolation effective or ineffective as a compensating control?
Answer: VLAN isolation is only effective if inter-VLAN communication is properly restricted. The team must verify: (1) No router or Layer 3 switch is routing traffic between the new VLAN and any other VLAN that contains sensitive systems. If a router is routing between the isolated VLAN and the rest of the network, the server is not isolated — it can still communicate with other VLANs via the router. (2) If a router or Layer 3 device does exist on the boundary (which it may need to for management traffic), an NGFW or ACL should restrict what traffic is permitted. The engineer's assertion that "it can't reach anything" is only true if there is genuinely no Layer 3 routing between that VLAN and any other VLAN. A VLAN boundary without verified routing controls may provide a false sense of isolation while still permitting communication through an uncontrolled Layer 3 device.
Scenario B: After a ransomware incident, an organization submits a cybersecurity insurance claim for: (a) $2.1M in lost revenue during the two-week recovery; (b) $800K in data recovery and forensics costs; (c) $500K in customer notification and credit monitoring; (d) $1.2M that a finance employee transferred to an attacker's account after receiving a convincing spoofed invoice email. Which portions of the claim are most likely to be paid, and which are at risk of partial denial?
Answer: Items (a), (b), and (c) are the most likely to be covered: lost revenue, data recovery, and customer notification costs are standard cybersecurity insurance coverage categories. Item (d) — the $1.2M fund transfer — is the most at risk. Unauthorized fund transfers, particularly those involving business email compromise scenarios, are frequently subject to exclusions, sublimits, or additional scrutiny in cybersecurity insurance policies. The insurer will examine whether the organization had appropriate controls (invoice verification procedures, multi-person authorization for large transfers, email authentication) and may deny or reduce the claim if those controls were absent. The exact outcome depends on the policy language, but fund transfers are a well-known coverage gap that organizations should specifically verify when purchasing policies.
Scenario C: A security operations team patches a Critical vulnerability across 850 servers on a Friday evening. The patch management platform reports 847 successful and 3 failures (all documented as systems that were offline for maintenance). On Monday morning, a junior analyst proposes closing the remediation ticket because "99.6% success is good enough for a Critical patch." The security manager disagrees. What is the correct next step, and what risk does the junior analyst's approach create?
Answer: The correct next step is to rescan all 850 servers with a vulnerability scanner before closing the ticket. The junior analyst's approach has two problems: (1) The 3 offline systems are unpatched and must be patched when they come back online — they cannot be ignored. (2) More importantly, the 847 "successful" deployments have not been validated. Patch management platforms report that a deployment job completed, not that the vulnerability is absent. Silent failures — where the platform reports success but the patch did not take effect — are a known phenomenon. For a Critical vulnerability, closing the ticket without rescanning creates the risk that some of the 847 "patched" systems are still vulnerable while the organization believes they are secure. Rescanning after patching is mandatory for Critical and High severity findings, not optional. The ticket should remain open until the rescan confirms the vulnerability is absent from all in-scope systems.