A water utility domain still runs unsupported domain controllers. How should the tester prioritize that observation?
Select an answer to reveal the explanation.
Short Explanation
Domain controllers are the identity backbone — if they go soft, the whole building leans. Unsupported DCs mean missing fixes on the servers everyone trusts. Patch and support them first; workstation hygiene alone will not save the directory.
Full Explanation
Unsupported or unpatched domain controllers threaten the entire identity plane for a water utility: directory availability, authentication integrity, and patch lag concentrate risk where every municipal system depends on AD. Testers should prioritize that observation highly because DC compromise or known-vuln exploitation can cascade across operational technology support accounts, SCADA jump paths, and enterprise apps that trust the same forest.
Workstation patching does not make DC support status irrelevant—the directory is the trust root for those workstations. Framing unsupported DCs as print-only or budget-deferrable understates identity-plane blast radius. Remaining offline from vendor updates is not a security strength; it is accumulated vulnerability and compliance debt for critical civic infrastructure.
Exam caveat: prioritize findings by blast radius to identity and safety-adjacent operations—unsupported DCs outrank many workstation-only issues. CPTS path reporting should still avoid unauthorized exploitation beyond RoE while clearly ranking severity.
Operational check: inventory DC OS builds and support lifecycle, map critical utility dependencies on those DCs, open a remediation plan with timelines, and reassess AD attack-path residual risk after upgrades or compensating controls are in place.