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?
8 responses to “How to Audit User Access”
So does no comments mean that no one audits user access?
Or that no one looks at anything beyond AD groups, ignoring application IDs, folder access, etc?
Wow, the years go by, and nothing changes….
Pingback: New IT Auditors Should Start Here | ITauditSecurity
you seemed lonely, so i left a comment.
Ha ha, thanks Jan.
I’m not lonely. Just frustrated that too many auditors 1) don’t know how to audit user access, and 2) don’t engage or communicate others at work (I have worked many places) or on this blog. In general, auditors are more boring than accountants.
Personally, I like accountants; never met an accountant that wasn’t passionate about his work.
Not sure why accountants become boring and lifeless when they become auditors.
Thanks for the write up. I’m auditing user access for the first time and i needed pointers on what to look for. The thing is I’m looking at user access for a website and wondering if the criteria you mentioned above are still applicable?
Yes, Jay, most of the items above are applicable. Just make sure you ask about how access is assigned, changed, removed, and otherwise managed. Also ask how often access is reviewed for admins, power users, system/generic IDs, and regular users.
Keep in mind that many websites have applications that manage all the access, such as Sharepoint websites.
Also for websites, understand the function of the website. It is gathering data and have a database behind it? If so, you should consider access to the database also, as some users will have access only to the website and others (admins) will have access to the database also.
So ask lots of questions about how each portion/subset of the website is used and what it is attached to (database, application, Excel list, etc.). Then understand the function it provides, which helps you understand the risks involved.
Pingback: Most Popular Blog Posts of 2021 | ITauditSecurity