What records to keep for privileged account audits

For privileged accounts, the admin accounts that can change settings and other people’s access, two kinds of records matter in an audit. Use records tie each action to who did it, when, and under which account. Access records show when admin rights were granted, removed and reviewed. NIST SP 800-53 Rev. 5, the federal government’s security control catalog, and the CIS Controls from the Center for Internet Security both cover this ground. Both also ask you to protect the logs and look at them on a schedule. What a privileged account is, in general, is in What is a privileged account?

What each source asks for

Recording who used a shared admin account

NIST IA-2 asks you to identify each user uniquely. For shared accounts, IA-2(5) asks you to “require users to be individually authenticated before granting access to the shared accounts.” AC-2(9) asks you to allow shared accounts only under conditions you set, given their “lack of accountability.”

So a shared admin login meets these controls only if something confirms who each person is before they get in, and records it. A sign-out log records who says they used the account, but nothing confirms the entry. Ways to set this up are compared in Ways to manage shared SaaS admin accounts, compared.

What to log

NIST AU-2 asks you to decide which event types to log and explain why they’re enough to investigate an incident afterward. Its examples include password changes, failed logons and “administrative privilege usage.” AU-3 sets what each record must establish: the type of event, when and where it happened, its source, its outcome, and who was involved. AC-6(9) adds that the use of privileged functions must be logged.

CIS safeguard 8.5 lists similar details for systems that hold sensitive data, such as event source, date, username, timestamp, and source and destination addresses. For SaaS consoles, safeguard 8.12 asks you to collect service provider logs where supported. Its examples include sign-in and permission events and user management events.

Time stamps need care. AU-8 asks for them in UTC or with a fixed offset from UTC, and CIS 8.4 asks for at least two synchronized time sources. If the console’s log and your own record of who signed in use different clocks, you can’t line up one person’s sign-in with what the account did.

How long to keep logs and how to protect them

NIST AU-11 asks you to keep audit records for a period you define. It should fit your records retention policy and be long enough to investigate incidents after the fact. CIS safeguard 8.10 sets a floor of 90 days.

AU-9 asks you to protect logs from unauthorized access, change and deletion, and to alert someone if that happens. AU-9(4) goes further. Only a subset of privileged users should be able to manage logging. The reason given: people with privileged access who are also the subject of the logs can affect them, by holding back logging or changing records.

Who reviews the records

NIST AU-6 asks you to review and analyze audit records at a frequency you set, looking for inappropriate or unusual activity. You report what you find to people you name. CIS safeguard 8.11 sets the pace at weekly or more often.

Access reviews run on their own schedule. AC-6(7) asks you to review privileges at a frequency you set and remove the ones nobody needs. CIS 6.8 asks for access reviews at least once a year, and CIS 5.1 asks you to confirm active accounts are authorized at least every quarter.

The reviewer should be someone other than the admins being reviewed. NIST’s separation-of-duties control, AC-5, points the same way: people who administer access shouldn’t also administer audit functions. Keep a record of each review: the date, who reviewed, and what changed. That record is what you hand an auditor. What a SOX audit asks for is covered in What a SOX audit asks about admin accounts, and which records to keep.