Hi, this is Greg Shields and I am going to spend a minute with the Whiteboard today helping you understand how Privilege Management and the whole concept surrounding Privilege Management might just solve some of those big IT problems that have been plaguing us so long.
First of all, let me draw up here a regular Windows computer, here is my icon for a Windows Desktop with the computer monitor and the desktop underneath it. In the typical Windows model, when we are thinking about permissions, we have binary options available to us. We have Administrator and then we have not-Administrator or a standard user. This probably worked fine in the early days of Windows, because we were not aware of what permissions we would need and maybe we just did not need those levels of permissions way back in the early days of Windows. But, as our environments have evolved and we have come to understand the isolation of the different roles that different people in our organization may be doing, we recognize that this whole notion of Administrator versus non-Administrator is just not granular enough to provide the level of permissions each individual person might need.
One of the ways that Privilege Management desires to fix this problem is by splitting apart this whole concept of Admin versus non-Admin. I believe in the article I used the word splintered or fractured. By splintering or fracturing Admin into its disparate components we actually can pull those components back together in a much different way to create this whole notion of Least Privilege. Ultimately, granularly assigning these permissions to users for the actual things they need to do.
There are three things that we have to have in order to be able to do this.
The first thing we have to have is a catalog, if you will. This catalog would be a catalog of all the possible actions that any user anywhere might need to do on a computer. This could be things like adding an ActiveX control or elevating an application or installing an application or changing the system time, just a big catalog of all those things that someone might need to be able to do.
The second thing we need to have, in addition to the catalog, is a directory of the users. If I have this directory of users then I can map the users into the catalog of possible actions. The users that are in the Finance group should be able to do the things that the Finance group has been allowed to do. There is this nice mapping here between who are the users and what are the possible things that they might be able to do.
These two pieces alone however, are not enough. We have to have a third piece also that really identifies what that mapping should be.' For this I will call these the policies. You probably have your policies in your organization, maybe they are written down, maybe they are not necessarily defined to the level that can be easily or directly mapped into a catalog but these policies will help define what the mapping is between the users and the catalog.
You can see that we have these three pieces that are, more or less, the three different pieces that make up the Privilege Management Solution. Now how do these track into actual technologies?
The catalog is something that a Privilege Management Solution might provide for you. A good management solution should give you a list of all the possible actions and allow you to create instances of those actions that make sense for whatever your business rules are.
Here in the directory, you already have the directory it is your Active Directory.' The groups and the different global groups you have created, those actually probably define what the roles are for the different users and what they probably should be able to do. This gets back to the whole Finance versus IT versus all the other groups that are in your organization.
Lastly, these policies, while they might not be technical in nature, you probably have written policies that determine which users or which classes of users should be able to do what things. We take the policies and combine them with your Active Directory group so that ultimately you have a least privileged solution catalog and you end up with this nice ability to granularly define what actions whichever user in the organization should be able to do.
Now that you understand what the Privilege Management concept is, really using this concept to apply or to solve problems in your organization really is the next step. Think about this, this catalog of actions can determine things like installing applications or elevating applications, these are two classic things that are associated with Privilege Management, so elevating here. When we look at the different files and folders on our system that we could choose as instances to install or elevate we might be able to, for example, use hashing or certificates that are assigned to different executable to determine whether or not that executable is valid and whether or not it should be installed or elevated or whatever sort of action we need to do.
Because we have those hashes, we now have an ability to absolutely and positively verify each potential item or file on our system. Knowing the certificates that are tagged to a file and we know what the hashes are associated with those files, we can now bring those files under control. If a piece of malware happens to impact that file or change that file the certificate is not going to work anymore and the hash is not going to be the same. If a user tries to update the application with a different version of the application the same holds true there or if they try to install a new application that has not been specifically allowed, it's not in your list of things that are allowed by virtue of your catalog.
All of these really portend to make Privilege Management one of those great solutions that could potentially solve a lot of those big problems in your organization today. If you are interested in solving those problems you might seek out a solution that helps you out.