Periodic Access Review Problems

One of my current clients is trying really hard to do periodic access reviews.

They know that mistakes are made in granting access, that users get access and eventually don’t need it anymore, but don’t tell anyone, and that some users leave the company without their manager’s knowledge (I never have understood how that happens, but it does; it has happened in every Fortune 500 company in which I’ve worked).

Part of the problem is that they don’t review server access. Not on SOX servers or GLOVE servers (joke) or PCI servers or any servers.

Local Admins on Servers

In some recent audits, this issue has come up repeatedly because pesky auditors keep finding that the local Administrators group on some servers contain an inappropriate Active Directory (AD) global group or two. Oops. That grants everyone in that global group admin access to the server.

Local groups reside on individual Windows servers; they are local to the server. All IDs or groups that are granted access to a server must be placed in a local group. On the other hand, global groups reside in Active Directory and can contain domain IDs or domain groups (other global groups). A local server group can contain IDs local to the server, IDs from AD, other local groups on the server, and global groups from the domain.

But What About the Annual User Review?

The company does do an annual user review (AUR) on specific AD groups; the review is performed by the user’s manager. That raises 2 questions: Does this AUR mitigate the problem? And, is a user review the same as an access review? No to both questions, because….

1) The review is performed by the user’s manager, not the owner of the asset (each server has a specific function and has 1 data owner). The company does this type of review for 3 reasons:

a) if the user has left the company or transferred to another manager, the user’s manager would know that, not the data owner.

b) the number of employees each manager has is a lot less than the number of users that typically have access to a function.

c) the user’s manager is more likely to review his people with more diligence than someone who has 1500 users that have access to their system.

2) The review only ensures, at the time of the review, that the membership of those groups is correct. No part of the review connects the groups or users to a specific server, much less functions or applications on that server.

3) The local group can be assigned to any area (drive, folder file, or application) with any permission. The local Administrator group could be assigned READ access to a particular shared directory; the local Guests group could be assigned FULL access (update access with the ability to add/remove users or change permissions) to an application. In fact, a local group on a Windows server can be assigned to different areas of the server with totally different access to each area.

In other words, the only way to do a full access review is to list each server’s items (drives, shares, services, etc.), the local groups assigned to that item, and the permissions assigned to the local group for each item. And don’t forget to review the membership of each of the local groups and global groups, and any groups inside those groups. Yeah, it’s messy and time-consuming, which is why few companies do it. (If yours does, I’d love to hear about it.)

Mitigation Theatre

My biggest problem is that the company THINKS by doing the AUR, much of the risk of not doing a full local server access review is mitigated. Yes, it is better than doing nothing, but not much, since not all AD groups are reviewed, and NO local server groups are reviewed.

But much ado is made over this review, and my concern is that management thinks this review mitigates more than it does. Some would call this “security theatre”, but I like to call it “mitigation theatre”. The risk simply is not mitigated enough, and here’s another reason why:

Any local or domain administrator on a server can add/remove or change any ID or local group at any time. If you don’t review the local group assigned to a server asset as well as the permissions assigned to that group, you won’t know if any changes were made or if they are inappropriate. In addition, during installation, some applications automatically make the local Administrators group the application administrators, which is not always appropriate.

Full Access Review or Rubber Stamp?

If you have hundreds of servers (or more) and do a full access review, you are going to get some managers or data owners who only do a rubber-stamp review–in other words, a quick “review” that consists of approving all the access across the board, or a review that only ensures all the users are still with the company.

After all, what manager wants to take the chance that he might request access to be removed only to discover the access was not only required, but critical for running or fixing a high profile application?

Also, some access is needed only once a year for a couple year-end programs. Do managers want to try to determine why a critical job failed a year after the access was removed? It’s much safer for managers to just approve the access.

So what do you do?

Like always, you have to weigh the cost of remediation against the risk. Depending on the other controls in place, you need to determine, as best as you can, what is the likelihood of a serious security event happening due to a full access review not being performed.

This particular company KNOWS the wrong people are occasionally given admin access to critical assets. It KNOWS that IT does not typically find it, but auditors do. It also KNOWS which servers are logged and monitored and the track record of their security monitoring team.

And, as often happens, IT thinks they do a better job of security than the auditors think they do…

I believe this company will continue their AUR and do one of the following, due to the extremely high cost of doing full access reviews of all servers: 1) do full access reviews on a select number of critical servers, OR 2) accept the risk by documenting it, the reasons why they chose to accept it rather than remediate it, get the appropriate signatures, and review the risk annually thereafter While this isn’t a great solution, it does mitigate a portion of the risk, at least on the selected servers.

As for accepting risks, the higher the authority or title that is required to accept such risks  is usually inversely proportionate to that person’s level of understanding of the risk itself. In other words, the higher up the chain you go, the less oil is on the chain.

On the other hand, if more than a year goes by without remediating a risk or accepting it, hasn’t the company already accepted the risk without formalizing it? Better to formalize it with some documentation and a signature or two than to hope you can get to it next year.

While only the first option mitigates additional risk, the second attacks the mitigation theatre problem by clarifying what IS and IS NOT being done and identifies the risk that remains on the table. It also means that someone’s name is attached to that risk.

We live in a fallen world with few perfect solutions that have a reasonable cost. Either solution is a small step forward.

As Yoda said, “Do or do not. There is no try”.

Questions for You

– Do you do a full access review on your servers? If so, how many servers do you have?
– If not, what type of reviews do you do?
– Or did you accept the risk?
– Do you have risks that have been open for years without any mitigation or documented risk acceptance?
– Do you have controls on only select assets?
– Do you agree with my assertion that either of the solutions above is better than continuing with no solution?

See also How to Audit User Access.

Advertisement