Policy-based Management Tools Unite!

Blogger: Randall Gamby

I’ve recently moved over to the SRMS Analyst team from Burton Group’s Consulting organization. Before moving over to the team I spent almost nine years in the field as a Burton Group Principal Consultant. Over these years I’ve worked one-on-one with many of our clients in both North America and Europe, and one of the topics that has always been an issue, and still is in many enterprises, is the process of implementing the enterprise’s policies in technology.

In the Identity Management (IdM) arena everything is moving to “roles-based” management controls. While roles-based controls are a subset of an enterprise’s policies and deal well with access rights for individuals and groups, in the security world “policies” are much more in-depth than just access. Not only do policies govern the actions of individuals, they also deal with data (whether in motion or at rest) and systems. But it seems that every security control system in the market is developing its own policy-based management interface. So the question is, “How many policy-based management interfaces do we need to configure?”

Historically, most enterprises have taken many years to create a relatively consolidated user identity repository (a vast majority of enterprises I’ve worked with use Microsoft’s Active Directory). However, as we move up the food chain to enforcement and compliance tools, products typically don’t--or can’t--read the LDAP user and group information. This forces the enterprise to go back to a siloed approach of creating and interpreting policies.

Think about it. I have a client that has firewalls being run by its Network Group, secure messaging run by a specialized IT group, host intrusion and prevention system (HIPS) being run by Security, and enterprise Active Directory deployment run by its directory team. Each product has policies about users, groups, and resources but barely recognizes the existence of the others; and each claims to have done policy “right.” Are they consistent? Maybe. Are they genuinely doing their best? Of course. Is there a risk to the organization that something has been overlooked? Very probably.

So what has to be done?

I think the first thing that needs to be done is for enterprises to review their policies. In the field many enterprise security managers (confidentially) have expressed a concern that the brave new world of security enforcement has invalidated, or provided scenarios that were never considered, in their original enterprise security policies. Next, I think vendors have to recognize that while policy-based management is a great ideal, it can’t be done in a vacuum. Managing policy enforcement for your set of tools that addresses only a part of an enterprise’s security front, without considering how you can share this with other sets of vendors’ tools working on other fronts, increases the chance of a hole in the defenses. Finally, I know you hear Burton Group say this all the time, but we need a standard to represent “policies” within a set of tools and a central repository--probably “virtual” if you ask the IdM people--that can store these values for the consumption and update of the tools. If a vendor can create a policy-based management interface that works across its suite of products (and some have), why can’t this framework be standardized for a similar group of tools, or even across all security enforcement technologies?

In the end, it will be the market that will determine whether policy-based management will be something that is a tool requirement or an enterprise requirement. If security managers aren’t educated on the “risk” in their current enforcement technologies; if vendors don’t hear from their clients that they’re tired of interpreting their new, and updated, policies for each of their policy-based enforcement technologies; and if standards can’t be created to make this all “consistent” within an enterprise, then efforts to go out and purchase expensive tools to manage their risk may be in vain.