A small parks-and-recreation registration app is being given a highly custom, complex single sign-on stack that few staff understand. What secure-engineering response is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Fancy homemade SSO on a tiny parks app is a gift to attackers and a headache for support. Threat-model it, keep it simple, and lean on boring proven identity patterns. Complexity is not a feature here.
Full Explanation
Secure engineering for a small parks-and-recreation registration app favors simplicity and threat modeling over a highly custom SSO stack few staff understand. Unnecessary complexity enlarges attack surface, configuration error rates, and bus-factor risk. Prefer proven identity patterns—standard OIDC/SAML via a managed IdP, or platform SSO the city already operates—unless a documented threat model shows unique needs that justify custom work.
Adding more undocumented custom modules increases uniqueness and fragility. Disabling authentication eliminates complexity by eliminating protection. Ignoring attack surface because parks data is “never targeted” underestimates credential stuffing, payment add-ons, and pivot value of municipal accounts.
Exam caveat: CISSP secure design principles include keep it simple and small, reuse proven components, and use threat modeling to justify complexity—custom SSO on a low-complexity app is a classic anti-pattern.
Operational check: threat-model the registration flows; compare custom SSO residual risk to managed IdP integration; measure operational ownership (who patches, who rotates secrets); choose the simpler design that meets authentication and session requirements; document exceptions if custom code remains.