Choosing the right vulnerability scanning method

Key: D

1. APhysical location rarely changes how likely or how damaging a compromise is, so it is not the main driver of frequency.
2. BThe OS vendor affects which checks run, not how often a system needs to be scanned.
3. CAge can hint at legacy risk, but a new internet-facing critical system still needs more frequent scans than an old isolated one.
4. DCorrect: scanning frequency should follow risk, so critical and exposed systems get scanned most often.

Key: B

1. AHIPAA requires risk analysis and safeguards for health data but sets no scanning frequency or cardholder rules.
2. BCorrect: PCI DSS (Requirement 11.3 in v4.0.1) requires internal and external vulnerability scans at least quarterly and after significant changes, with external scans by an Approved Scanning Vendor (ASV).
3. CSOX governs controls over financial reporting and does not prescribe vulnerability scanning intervals.
4. DGDPR requires appropriate security for personal data in general terms, without a scan frequency or any cardholder-specific scope.

Key: C

1. AWeekly scanning of medium-criticality workstations is more than enough, so it is not a blind spot; cutting it to quarterly would add risk.
2. BWeekly scans of internal payment systems are reasonable, and continuous scanning is not required to avoid a blind spot.
3. CCorrect: internet-facing, high-criticality frontends scanned only quarterly can carry new exposures for months, which is the real gap.
4. DLow-criticality systems should be scanned less often, not removed from scanning; excluding them would create a blind spot.

Key: A

1. ACorrect: throttling bandwidth and batching Core hosts inside their 02:00–04:00 window keeps load low when the business is least affected.
2. BScanning every segment at full speed at once maximizes load and can saturate the 100 Mbps OT link.
3. CAn unthrottled DMZ scan in business hours ignores its 22:00–02:00 window and hits users when traffic is highest.
4. DRandom full scans with no time limits ignore the maintenance windows and can hit critical systems at peak times.

Key: D

1. APublishing findings within 24 hours exposes unpatched weaknesses to attackers and is not a governance requirement.
2. BDaily full scans regardless of asset class ignore the fragility of critical infrastructure and maximize disruption.
3. CRemediating without testing or maintenance windows adds outage risk instead of governing the scan.
4. DCorrect: intrusive scans of critical infrastructure need an approval workflow, exception tracking and a rollback plan defined before anyone runs them.

Key: D

1. AThe change board handles changes to systems and cannot supply the missing scan metadata that makes findings impossible to reproduce.
2. BFinal PDFs keep the results but not the profile, credential set and timing needed to rerun the scan the same way.
3. CManual remediation notes record what was fixed but not how the scan was configured, so findings still cannot be reproduced.
4. DCorrect: a policy that retains the scan profile, the credential set used (not the secrets themselves in the report) and timing lets anyone rerun and validate the same scan.

Key: B

1. APermanently excluding a critical system creates a blind spot; the scan settings should be fixed instead.
2. BCorrect: stop the scan to limit damage, then identify which checks caused the disruption so future scans can be tuned rather than dropped.
3. CLetting the scan continue keeps damaging a critical production system.
4. DPatching everything without testing is unrelated to the disruption and adds outage risk of its own.

Key: A

1. ACorrect: fingerprinting identifies operating systems, services and software versions, often automatically from banners and protocol responses.
2. BDNS enumeration discovers hostnames and records in a domain and reveals nothing about OS or software versions.
3. CPhishing tricks people into revealing information or running code; it is not systematic system profiling.
4. DCredential stuffing replays leaked username and password pairs to break into accounts.

Key: A

1. ACorrect: Profile C runs an aggressive default scan against SCADA/PLC devices, which often cannot handle that traffic volume and crash.
2. BAuthentication is actually disabled for the SCADA profile, and authenticated scanning tends to reduce network probing rather than cause a DoS.
3. CProfile B is throttled and aimed at databases, so it never touched the industrial controller that failed.
4. DProfile A is aggressive but targets web servers, which are built to handle that traffic and were not the device that failed.

Key: D

1. AAgentless scans need network reach, so they miss laptops that are offline or off the corporate network during the scan.
2. BAgents on Windows servers alone leave Linux endpoints, cloud VMs and laptops uncovered.
3. CWeekly non-credentialed scans give only an outside view, miss offline laptops and add network load.
4. DCorrect: agents cover endpoints and roaming laptops without network sweeps, while API integration covers cloud VMs, giving full coverage at low network cost.

Key: D

1. AMaximum intensity during production hours is exactly what crashes the fragile controller.
2. BA full credentialed scan with a production service account is not a gentler setting, and it exposes a privileged credential to the scan.
3. CStandard intensity without lab testing still risks crashing a controller already known to be fragile.
4. DCorrect: the lightest probe set, proven safe on an identical lab unit and then run in a maintenance window, gives coverage without risking the controller.

Key: D

1. APatch management deploys updates; it does not gather vulnerability information.
2. BIntrusive scanning actively probes and may exploit the target, which is the opposite of non-interactive.
3. CPenetration testing actively attacks the target to prove exploitability.
4. DCorrect: passive scanning listens to existing network traffic to infer hosts, services and vulnerabilities without sending probes to the target.

Key: B

1. ASkipping ICS assessment leaves critical systems unassessed, which is a governance failure dressed up as a safety measure.
2. BCorrect: ICS-aware tools understand industrial protocols and fragile devices, and scheduling with approval keeps operations safe.
3. CFull penetration testing on every ICS component risks outages and physical safety issues.
4. DStandard IT scans during production hours can disrupt controllers and halt physical processes.

Key: A

1. ACorrect: image scans catch flaws before deployment, and runtime scans catch drift, configuration issues and containers built from old images.
2. BRegistry-only scanning misses running containers that drifted or were deployed from older images.
3. CRuntime-only scanning finds problems after they are already in production and misses images waiting to be deployed.
4. DScanning only the host OS misses the libraries and packages inside the container images.

Key: D

1. ASeparate scans per framework duplicate effort and can produce inconsistent results for the same systems.
2. BAlternating frameworks leaves each one unmet for most of the year and breaks requirements such as quarterly PCI DSS scans.
3. CScanning for one framework leaves the others out of compliance.
4. DCorrect: one program built to the strictest requirement of each framework satisfies all of them with a single, consistent process.