A database team encrypted customer records at rest, but the encryption keys are stored in a file on the same server as the database. What is the PRIMARY concern for the information security manager?
Select an answer to reveal the explanation.
Short Explanation
Locking your front door and taping the key to it isn't much of a lock. Encryption only protects you as well as the keys are protected. The trap is fretting about performance when the real problem is that one break-in gives away both the safe and the combination.
Full Explanation
Encryption converts data into a form that is useless without the key, so its protective value depends entirely on keeping keys separate from the data and tightly controlled. Storing the keys on the same server as the database means that anyone who compromises that server, or obtains a copy of its storage, can retrieve the keys and decrypt the records, which largely defeats the purpose of encrypting at rest. Effective key management separates keys from protected data, restricts and logs key access, and covers generation, rotation, backup and destruction. Performance overhead from encryption at rest is a common worry, but it is a design and capacity consideration rather than a security weakness and is not what the scenario describes. Administrators losing reporting capability is not a consequence of where keys are stored; authorized processes continue to work through the database's normal access path. Restoring backups to another server is an availability concern that proper key backup addresses; it is not created by co-locating keys with data and is secondary to the confidentiality exposure. Exam caveat: CISM treats key management as part of the control design, not a technical afterthought, and expects key custodians and responsibilities to be defined. Operational check: confirm keys are held in a dedicated key management service or module, separate from the data, with access limited and logged.