You want to know who has access to what? Good luck

There’s a dirty little secret in the computer security world that makes the dream of least-privilege access control very hard to attain: It’s often literally impossible to determine who has what level of access to which objects.

How so? The access privileges granted to a person or any other security subject — such as another computer, service, daemon, and so on — are determined by the permissions configured on each individual computer and each individual object, such as file, folder, registry key, memory area, and more. Both can be difficult to check, but the latter is much more difficult, thanks to scale.

[ It’s time to reconsider security. Two former CIOs show you how to rethink your security strategy for today’s world. Bonus: Available in PDF and e-book versions. | Stay up to date on the latest security developments with InfoWorld’s Security Central newsletter. ]

Your basic access-control model Overall access policies are defined for every computer. These include the types of access that are allowed, either for all users or specific sets of users. In Windows, more than a dozen different types of general access can be defined: logging on locally, using RDP, over the network, anonymously.

After access has been granted, the objects a user can view, read, delete, or modify are controlled by the individual permissions stored along with each object. In Windows, these permissions are called access-control entries, and the collection of all access-control entries is called an access-control list.

When the user attempts to access a particular object, Windows first checks to see if the user is allowed to access the computer via the method employed, whether local, network, or otherwise. Then it compares the access-control list’s set of permissions to the access requested. If they match, the user is allowed to access the object.

That’s the local machine. When the user requests write access to a particular file on a remote computer over the network, the user’s “security token” — holding his or her authenticated identity and group memberships — is passed to the remote operating system along with the user’s desired access request. A security mechanism in the remote operating system then queries the file’s access-control list. The access-control list defines what users and groups are allowed to work with the object and with what permissions (read, write, and so on).

Let’s say the user account is allowed read access only, but the user belongs to a group that is allowed write access. In most modern operating systems, that group membership would enable the user to write to the file. This is a pretty straightforward process — or so it seems.

Who can do what Now suppose a company wants to know all about a particular user’s access privileges. Unless that has been meticulously documented, every computer system and every object on every computer system in the environment must be queried to generate an accurate list.

Now repeat this process for every user and computer within your environment. Even if you limit queries to important computers and important files, you can easily end up with hundreds of billions of individual queries and answers, even in a small-to-midsize business.

To obtain accurate results, the query must match the user and the groups they belong to against the object’s allowed users and group memberships — and understand how nested groups impact the answer. It’s not unusual for a single user to belong to dozens or even hundreds of groups, and no small percentage of those groups are typically members of other groups. I’ve seen a user account that apparently belonged to 10 groups, but after taking nesting into account, the user actually belonged to more than 100 groups.

When an access-control query comparison is made, the querying tool must first build a master list of all the groups the person belongs to, including nested groups. This is no small task, since most companies I deal with have more groups than users. The real world is far messier.

Application permissions You also need to appreciate application-level permissions. Most network applications have varying levels of access control for an application. While a user may not be a network or domain administrator, he or she may have privileged access inside a particular application. This access is just as important as operating system permissions.

In a large organization, it is not unusual for a common network application to have dozens or even a hundred or more admins. If a computer is completely compromised, the hacker can access anything available to the affected user, including application data.

That hypothetical hacker may not be able to take over the domain or dump any other user’s passwords, but can download and change any data in the application database. Ultimately, most of today’s hackers are after exactly that: application data. They compromise OS accounts and permissions as a way to get to the data.

Note that I haven’t included the problems of multiple operating systems, mobile platforms, data copied to nonmanaged systems, access to offline data (such as tape backups), and many more complications. To get a completely accurate account of what access a particular person has to all the resources in a company takes a really granular and comprehensive survey by a really smart tool. And that tool does not exist.

I have no doubt vendors will claim their tool can determine who has what access to every object in the environment. I’ll be glad to be schooled about a new, great tool. But I’ve been teaching computer security for more than two decades, including a decade-plus spent working with computer security auditors, and I can tell you that no tool comes close to doing a decent job.

Partial solutions Some tools can search many of the computers in your environment and tell you which users and groups can access particular objects. Getting just that information is more than most people have. Most of these tools work by running a query on each computer and compiling all the findings in a large database. You can then query that database to find out who has what access to which files and folders. The query is run on a regular basis to update the database.

On the downside, these tools never cover all object types (registry keys, memory areas, metadata), rarely understand the impact of group nesting, don’t take into account the user’s overall access to a computer (local vs. remote), and never cover all operating systems and platforms. But if you don’t have a tool that can at least do the basics, you probably need to get one. Otherwise, you won’t have a clue as to what is going on.

Allow me to make two other recommendations. First, use groups as much as possible to set permissions. This has long been a best practice for security pros. We want to reduce individual access-control designations as much as possible. If you can confirm that all access is accorded only by group membership, then getting the whole access-control picture is easier.

Second, take advantage of tools that let you set and document access control from a centralized console. Within those tools you can often easily determine who has access to what — when the access control has been set by the tool, that is. Many directory services, applications, and role-based access-control systems have this capability. My only caveat is that they often don’t understand group nesting well or apply to all objects in the enterprise. But some centralized control is better than no centralized control.

I welcome reader or vendor recommenations on access-control query tools. But the sad fact is, we cannot reliably answer the supposedly easy question: Who has access to what?

This story, “You want to know who has access to what? Good luck,” was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes’s Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.