How to Audit User Access

When checking system access, make sure you look at all the different items that affect the user’s access. For example, the user might need one or more of the following:

• Application ID
• Application role or group
• Membership in an local server group, Active Directory (AD) group, or UNIX Group
• Access to the application’s share and/or folder on the server
• Database ID
• Database role, including access permissions (read/write)
• Other permission (from a home-grown application code or enterprise identify management system)

The best way to determine all the pieces a user needs is to have your subject matter expert/auditee walk you through the new user setup for regular users and administrators. That way, you’ll see all the pieces.

Keep in mind:

• Removal of 1 item (e.g., Active Directory group) may prevent user from accessing the system, but that doesn’t necessary mitigate all the risks. For example, if AD group is removed, preventing the user from logging into the system, the user might still have database access. Update database access could result in changes to financial data (SOX problem) or exposure of confidential data (HIPAA, PCI problem).When a system requires multiple pieces for access (Application ID, AD group, Database ID), compare all the lists against each other to see which users have only some of the pieces. If a user is missing one or more of the pieces, ask 2 questions: 1) Why this configuration? This can lead to some interesting findings* 2) What’s can a user do with this configuration (what’s the risk)?
• Check the permissions on the share/folder in which the systems resides. A user may not be able to log in, but they could have access to the system executables, systems settings, logs, or temporary data written to folders before or in conjunction with data being written to the database.
• Check the permissions of the users defined at the operating system level. In some systems, being defined at the OS level gives you access to the entire system or enough access at the folder/file level to alter the system so that you can log in.
• Beware of systems and databases that do not use an LDAP directory ID such as AD to log in, where the only ID required is an internal system ID. Removing the AD account does not remove access from these systems.
• Scripts and batch processes can also affect the application. If a user has the ability to run or alter scripts or batch jobs, he might be able to change or extract financial or confidential data. And often, the scripts don’t reside on the system, but in a central, enterprise location available to all systems.
• Determine who has access to generic IDs, such as default system IDs or any ID not named after a person (non-personal), such as guest, system, reports, and ftp. Determine if the password is controlled by an individual, a team, or the security department, and the last time it was changed.
• When determining whether IDs are personal or generic, do not depend on format alone (i.e., all personal IDs begin with 2 numbers and generic IDs have no numbers). Match all IDs against your human resource file of employees and contractors—any ID without a human to match it to should be considered suspect.
  I have found generic IDs that were created to look like personal IDs; I’ve also found IDs that started out as personal IDs, but were used as a generic after the user left the company.

* One user didn’t have an application ID or database ID, but was a member of the required AD group. I was told that this user needs access to the folders on the test system as she’s testing new functionality on the latest application version. So why, I asked, is she in the group that gives access to the folders on the production system? Because, I was told, the same AD group grants access to the folders on the test system and the production system. Oh, I said (gulp), we need to look at this a little closer…

What other things do you look for? What strange or sly things have you found?

Advertisement