A municipal payment portal uses a well-regarded cipher suite, yet testers recover plaintext via a padding-oracle style flaw and weak random number generation for nonces. Where should remediation focus?
Select an answer to reveal the explanation.
Short Explanation
A great lock on a crooked door still fails. Padding oracles and bad RNG are implementation wounds, not proof the algorithm name was wrong. Fix how crypto is built and seeded, not the brochure.
Full Explanation
When testers recover plaintext despite a well-regarded cipher suite, remediation must target cryptographic implementation quality. Padding-oracle style flaws, incorrect error handling, nonce or IV misuse, and weak random number generators for nonces defeat algorithms that are sound on paper. Municipal payment portals need vetted libraries, current protocol profiles, authenticated encryption modes, cryptographically secure RNGs, and careful patching—not brochure-level confidence in a cipher brand.
Updating marketing materials that celebrate the cipher name does not close oracles or fix RNG. Thickening data-center walls addresses physical durability, not protocol bugs reachable over the network. Disabling TLS removes confidentiality to avoid implementation work and exposes payment sessions—an unacceptable trade for a city portal.
Exam caveat: CISSP separates algorithm strength from implementation security. Famous algorithms used incorrectly remain vulnerable; prefer proven libraries and correct protocol engineering.
Operational check: upgrade to maintained TLS stacks; eliminate legacy CBC padding oracles via modern AEAD suites; verify CSPRNG sources for nonces and keys; ban custom crypto; retest with padding-oracle and randomness checks after each platform change; monitor for weak suite negotiation.