Application servers connect to a database server across a shared network segment, and a packet capture shows query text and result sets in clear text. Which control addresses this exposure?
Select an answer to reveal the explanation.
Short Explanation
What you captured is data in transit, like a postcard anyone in the mail room can read. Wrap the conversation in TLS and the postcard becomes a sealed envelope. Don't grab TDE here; it locks the files on disk but does nothing for bytes flying across the wire.
Full Explanation
Data in transit is protected by encrypting the network session between client and server. Enabling TLS on the database listener, installing a trusted certificate and configuring the server and client drivers to require encryption ensures that query text, credentials exchanged during login and returned result sets are encrypted on the wire, and that clients can verify they are talking to the genuine server. Transparent data encryption protects data at rest in data files, log files and often backups; once the engine reads and decrypts a page to answer a query, results travel to the client unprotected unless the session itself is encrypted. Moving the listener to a nonstandard port is obscurity: the traffic remains readable to anyone who captures it, and port scanning finds the new port quickly. Hashing columns before storage is irreversible, so the application could no longer retrieve the original values, and it does nothing for the rest of the query and result traffic. Exam caveat: requiring encryption only on the server side is insufficient if clients are allowed to skip certificate validation, which leaves room for interception. Operational check: repeat the packet capture after the change and confirm payloads are unreadable, then verify through the server's session information that each connection reports encryption.