During an investigation, the incident team can see that a sensitive record was read from a cloud database, but the logs cannot show who read it, from where, or exactly when. Which logging improvement addresses this gap?
Select an answer to reveal the explanation.
Short Explanation
A log entry that says 'something read this record' is like a security camera with no faces and no clock. Every data event you log needs the who, from where, when, what action and on what object. Keeping bad logs longer doesn't make them better logs.
Full Explanation
Auditability, traceability and accountability of data events depend on recording enough attributes to reconstruct who did what, to which data, from where and when. For each access event, logs should capture the authenticated identity of the user or service, the source IP address and derived geolocation, an accurate timestamp, the action performed, such as read, modify or delete, and the object affected, plus outcome and session context where available. With those attributes, investigators can attribute activity, correlate events across systems and support legal and regulatory requirements. Increasing retention keeps logs longer, which is useful, but it does not add the missing attributes; incomplete records retained for years are still incomplete. Database performance metrics such as latency and CPU utilization support capacity and troubleshooting, not attribution of individual data accesses. Encrypting logs at rest protects their confidentiality, and integrity protection is also important, but neither adds the identity, location or time information the investigation lacks. Exam caveat: identity attribution fails when shared accounts are used, so unique identities are a prerequisite for accountability. Operational check: generate a test read of a sensitive record and confirm the resulting log entry contains every required attribute and reaches the SIEM.