I’ve written before how some periodic reviews provide management with little assurance, but management doesn’t realize how little.
My previous post focused mostly on server access. In this post, I want to look at normal user access.
For example, let’s assume your company has a policy that states that all IDs must be assigned within an Active Directory group. In other words, IDs are assigned to groups, and groups are assigned to assets; IDs should not be assigned directly to an asset.
Assume the control you are testing states that user access is reviewed annually.
Believe it or not, many companies simply review the groups and ensure that the IDs in each group are appropriate.
It’s simple and relatively easy, but it gives reviewers and management a false sense of security.
First, unless you test each asset (LAN folder, server, application role, database), you have no idea which groups are assigned to the asset. You can assign a group that contains only interns to a role that grants them admin access within an application. The right people in the right group are assigned the wrong permissions to an asset. Oh well, Maybe they won’t notice.
Second, a group can be assigned READ access in one LAN folder, but MODIFY access to another folder. Like the above example, and in this example, reviewing the groups tells you nothing as to how that group is used across the enterprise or the access levels assigned to it wherever it is used. In other words, it doesn’t tell you much.
Third, regardless of the policy that exists (and only on paper), it is still possible to assign IDs directly to an asset (folder, file, database, etc.), and the periodic review of groups ignores this risk. IDs assigned like this can go completely undetected.
In fact, it is easy and likely that someone would assign an ID directly to a resource for the following reasons:
- For troubleshooting or fixing a major outage. Then once the problem is solved, no one remembers to go back and remove those IDs.
- In the case of databases, sometimes tables or other items are restored from the test environment or a production backup into production. Usually, whatever permissions are assigned to that restored data get restored also. And since test environments usually have looser controls than production, and allow direct assignment of IDs to the database, now you have these IDs in the production environment.  Again, once the restore is done, no one remembers to go back and ensure the production standards are enforced. In the periodic review won’t catch them either. 
- The person who has not been trained as to what the policy is and how important following the policy is to the company (after all, the same policies existed at the person’s previous company, and nobody ever followed them).
So what’s my point?
Periodic reviews of access can only go so far, especially if they depend on reviewing groups. Access CAN be assigned outside of groups, so it’s always better to review the access assigned to the asset rather than review the members that are assigned to the group, which tells you WHO but not WHERE or at WHAT LEVEL.
At least occasionally, review the access directly, especially for your most critical assets. Always make sure management knows that controls can be bypassed, and in cases where you are not reviewing the direct access, you’re only getting some assurance, but not all of it. Make sure management knows what they’re actually getting…or not.
ITauditSecurity 