A municipal Windows host still runs a legacy file-sharing protocol required by one application. How should risk be framed?
Select an answer to reveal the explanation.
Short Explanation
Keeping an old file-sharing protocol for one app is like leaving a rickety bridge up because one truck still uses it. Maybe you need it for now—but say so, add guardrails, and plan the upgrade. Required doesn’t mean risk-free.
Full Explanation
When a municipal Windows host still runs a legacy file-sharing protocol required by one application, risk should be framed as legacy protocol retention expanding exploitability—document compensating controls or an upgrade path even when the app still needs it. Legacy protocols are not risk-free merely because a line-of-business application requires them; business need explains presence, it does not erase weakness. If the protocol is enabled, reporting remains necessary so leadership sees residual risk rather than assuming silent acceptance equals acceptable risk. Internal retention can matter as much as internet-facing exposure when lateral movement is in scope. Exam caveat: good answers acknowledge business constraint while still requiring risk transparency and compensations. Operational check: name the protocol and hosting system, note which app dependency drives it, list compensating controls (segmentation, signing, account restrictions), and record an owner and timeline for migration off the legacy stack. In municipal operations, record the rationale in the engagement notes so future testers and city defenders understand which approach was chosen and which failure modes the rejected options would create for civic services.