Control types, risk and the vulnerability program

Key: B

1. ASecurity cameras are mainly detective (they record and help identify events) and somewhat deterrent, but they do not physically stop entry.
2. BCorrect: A fence physically blocks unauthorized access before it happens, which makes it a preventive physical control.
3. CSecurity training is an administrative control, not a physical one.
4. DFire extinguishers limit damage after a fire starts, so they are corrective or compensating physical controls and do nothing preventive.

Key: D

1. AAdministrative controls are policies, procedures and training, so hardware and software devices fall outside them.
2. BPhysical controls are things like locks, fences and guards that restrict physical access, and they do nothing to network traffic.
3. CThis names a control's function (fixing things after an event), but the question asks for its type, and a firewall mostly prevents.
4. DCorrect: A firewall is a technical control, hardware or software that enforces access rules on traffic; older material calls the same category logical.

Key: C

1. APassword policies stop weak passwords before they are exploited, so they are preventive.
2. BSecurity training reduces future mistakes, so it is a preventive administrative control.
3. CCorrect: Patching fixes a vulnerability that has already been found, which is the role of a corrective control.
4. DA firewall blocks unwanted traffic before it reaches systems, so it is a preventive technical control.

Key: C

1. ADetailed patching steps for each system belong in procedures or runbooks instead of the governing policy.
2. BNaming specific tools makes a policy go out of date whenever tools change; tool choice belongs in standards or procedures.
3. CCorrect: A governance policy defines who is responsible, how fast fixes must happen, how exceptions are approved, and how the program is measured.
4. DA list of CVEs is operational data that changes daily, which is why it has no place in policy content.

Key: C

1. AAutomated patching for non-critical workstations would not cause repeated SLA breaches across critical business units.
2. BHaving QA test critical patches is a normal practice and no sign of a governance failure.
3. CCorrect: Repeated SLA breaches across many units mean no one is tracking remediation SLAs or checking that compensating controls work, which is a governance failure.
4. DPatching outside maintenance windows is a change-management problem, and it would speed fixes rather than cause SLA breaches.

Key: C

1. APrioritizing by raw CVSS without context is poor practice, but it misorders work rather than letting suppressed findings pile up unseen.
2. BUntested rollbacks create change risk, which is different from a gradual buildup of unreviewed risk.
3. CCorrect: Suppressions and exceptions that are never reviewed keep hiding vulnerabilities after their justification has expired, so unmanaged risk quietly grows.
4. DUnauthenticated external scans miss internal details and produce gaps, but they do not suppress known findings over time.

Key: A

1. ACorrect: Severity-based SLAs set clear deadlines, so critical issues are fixed fast and lower-risk ones get reasonable timeframes.
2. BFixing CVEs in alphabetical or numeric order ignores risk completely.
3. CPublic exploit availability is one input to prioritization, but ignoring everything else leaves serious risks unaddressed.
4. DFixing everything at once regardless of impact is not realistic and ignores business disruption and prioritization.

Key: C

1. ALog analysis helps design mitigations, but the failure here is that no one checked whether the mitigations worked or tracked the real fix.
2. BExecutive summaries are meant to leave out technical configuration details, so omitting them is not a failure.
3. CCorrect: Interim controls were never checked for effectiveness and the old vulnerability was never fixed on schedule, which is a failure to track remediation SLAs.
4. DRaw scanner counts in leadership reports would not have protected the server.

Key: A

1. ACorrect: Identifying vulnerabilities, threats, and possible impacts is risk assessment, the step that comes before deciding how to treat the risk.
2. BRisk mitigation comes after assessment, once you choose and apply responses to risks already identified.
3. CRisk monitoring is the ongoing tracking of risks and control effectiveness after controls are in place.
4. DControl implementation is putting chosen controls in place, which follows assessment and treatment decisions.

Key: C

1. AA data retention policy sets how long data is kept and does nothing to stop staff from clicking phishing links.
2. BAn acceptable use policy defines allowed use of company resources, but it does not teach employees to recognize phishing.
3. CCorrect: the root cause is people falling for phishing, so a security awareness training policy, an administrative control that teaches staff to spot and report suspicious messages, addresses it directly.
4. DAn incident response policy governs what happens after an attack succeeds; it does not lower how often employees fall for phishing.

Key: C

1. ADevelopers do not need to learn network scanning; SDLC integration relies on code and dependency testing such as SAST, DAST, and SCA.
2. BLicensing costs are a budgeting issue and only a side concern when integrating security into development.
3. CCorrect: Security checks in the pipeline have to catch real issues without slowing releases so much that teams try to bypass them.
4. DLanguage choice is an engineering decision; security tools must support what the team uses, but that is not the main integration challenge.

Key: A

1. ACorrect: Blocking critical CVEs from production while allowing documented exceptions in lower environments protects what is exposed without stalling development.
2. BBlocking every pipeline on any CVE stops delivery constantly, including for low-risk or unreachable findings.
3. CDisabling all gates removes security checks completely, which trades away safety for speed.
4. DIdentical rules everywhere ignore that dev and staging carry different risk from production and create needless friction.

Key: C

1. AManual reviews of direct dependencies at major releases are still point-in-time and miss transitive dependencies.
2. BAuthenticated filesystem scans go deeper, but they are still periodic scans and give no continuous supply chain intelligence.
3. CCorrect: Feeding SBOMs into the vulnerability workflow lets newly disclosed CVEs be matched automatically against known components at any time, not just during scans.
4. DAnnual vendor questionnaires are slow, self-reported, and say nothing about new vulnerabilities between reviews.

Key: B

1. AThe forward proxy is internet-facing, but its resource-exhaustion weakness is already patched.
2. BCorrect: API Node is internet-facing with an unpatched SQL injection weakness (CWE-89), exactly the kind of flaw layer-7 controls such as WAF rules can filter while the patch is pending.
3. CThe metrics database has a pending patch, but it is not internet-facing, and a buffer overflow is not something layer-7 web filtering reliably stops.
4. DThe HR app's XSS weakness is already patched and the app is not exposed to the internet.

Key: B

1. AAssessment is essentially the analysis work the stem says is already finished, so repeating it is not the next phase.
2. BCorrect: Once vulnerabilities are identified and analyzed, the next phase is remediation, meaning patching, reconfiguring, or applying compensating controls.
3. CIdentification is the phase that was just completed, so it cannot come next.
4. DReporting follows remediation and verification, when there are results to report.