A city asks the tester to spend remaining time only on a CTF-style kernel exploit that depends on rare race conditions, while common local misconfigs remain unreviewed. What should the tester prefer for CPTS-style value?
Select an answer to reveal the explanation.
Short Explanation
Chasing a once-in-a-blue-moon race is like hunting for a unicorn while the back door is unlocked. CPTS-style work pays off when you cover the everyday misconfigs that actually show up in cities—sudo, services, scripts, and permissions.
Full Explanation
When a city asks to spend remaining time only on a CTF-style kernel exploit depending on rare race conditions while common local misconfigs remain unreviewed, CPTS-style value favors prioritizing realistic misconfiguration classes (sudo, SUID, cron, services, credentials) over obscure race-only kernel tricks on civic systems.
Abandoning the engagement is unnecessary. Guaranteeing a kernel exploit PoC on fragile SCADA-adjacent systems is unsafe. Treating race-condition kernel work as mandatory before any sudo or service review inverts sound methodology.
Exam caveat: rare races may be academic interest; municipal risk reduction usually comes from fixing common, durable misconfigs first.
Operational check: present a timeboxed plan that finishes high-prevalence local enum classes, defer fragile races unless RoE and stability allow, and align remaining hours to city risk priorities. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same finding class still applies under the estate's current patch and configuration baseline.