At an MSSP, a customer wants a control for AI-written mail that has no attachment and no malicious URL and only asks to change a payment account. Which control fits that request?
Select an answer to reveal the explanation.
Short Explanation
You can verify a payment-account change with a trusted callback to a number already on file, rather than one supplied in the email. A hash blocklist can miss rewritten wording, deeper packet inspection has no file or malicious URL to examine, and changing the firewall password does not verify the request. You can hold the change until the callback confirms it.
Full Explanation
The message has no attachment and no malicious URL; its only payload is a business request to change a payment account, and generative AI can rewrite that request in clean prose. A callback to a number the organization already trusts, made before applying the change, verifies the request independently of the email. A hash blocklist entry for the exact message body fails when the wording changes, and there is no malicious file to identify as known-bad. Deeper packet inspection examines a message with neither a file nor a malicious URL; the harm comes from a person approving a payment change, not from an exploit in an attachment or link. A longer password on the customer firewall, even if changed after every payment-account request, changes an administrator credential but does not verify who requested the bank-detail change. Exam caveat: out-of-band verification is the control for a polished lure; good grammar or a missing attachment does not establish that the request is genuine. Practical check: place the callback to a number from the customer master record, refuse numbers printed in the email, and hold the payment change until the call confirms it.