Peter Stephenson, technology editor, SC Media
Peter Stephenson, technology editor, SC Media

Over the years we have looked at this group just about annually.  For a long time, it was fairly static. There was a point when GRC (Governance, Risk and Compliance) was all the rage and we spent a couple of years focusing on that.  Today, as with most product categories, risk and policy management and GRC have begun to morph into a group that has the characteristics of all three.

Last year we recognized that there are two distinct types of tools: next generation and traditional.  The traditional tools really are current incarnations of GRC products while the next gen tools take advantage of all the technological advancements prevalent today in other security products. The single easiest way to identify next gen tools in this category is to ask if they do auto-discovery.  Auto-discovery by itself does not make a next gen risk and policy management tool.  But it's been our observation that the two go pretty closely together.  If a vendor claims a next gen tool, it probably does its own auto-discovery.

Another way to differentiate is the level of automation. No-touch automation is rather common in the next gen tools while it is nearly non-existent in the traditional ones. We saw more movement to converge these types of products this year.  In going back to our review of this group in 2015 we saw that we had predicted that next generation tools – as we defined them then – would take over the market.  While that hasn't really happened yet, there is strong movement in that direction.  We have recognized that by selecting three Recommended products: a traditional GRC, a next generation  and a unique tool that focuses on hybrid environments.

Finally, although it certainly is not a requirement, virtually all the next gen tools we saw had at their core firewall management. Last year we questioned whether this was a proper function for risk and policy management.  After all, we had a category for security management that seemed to cover that.  Truth is, if you want to manage policy it very logically can start with managing firewalls.

The problem with firewalls is that there are lots of them in a large organization. Finally, security experts are twigging to the fact that VLANs don't provide security and that VLAN jumping is a common type of east-west attack. That means firewalls or some rather onerous routing. It wasn't long ago that we were hearing security mavens sing the death of the firewall.  Today that's not particularly likely. 

Additionally, firewalls are getting pretty big in the amount of traffic they manage and control. That means ever-growing rule sets. On a big firewall, rule sets can reach the thousands of rules very easily and quickly. Typical firewall managers simply add rules as they are needed and the result is that there are lots and lots of shadow rules (rules that address the same issue but do it differently causing conflicts) and redundant rules. Finding these and managing them over tens of thousands of rules on hundreds of firewalls is an impossible task for humans. Help is needed.

Additionally, we should remember that firewall rules simply are an instantiation of security policy. So now, in addition to managing the rule sets, we need to ensure that we are enforcing our policies correctly and that changes to the firewall rules don't cause a policy violation. If we take the functionality of the traditional risk and policy management tools and add extensive, tightly integrated firewall management with a touch of no-touch automation and auto-discovery, we have a typical next gen product.  In our view that is where this product category is headed.

That is not to deprecate the traditional style of risk and policy management. The problem is that enterprises are reaching a size and wide dispersion that makes the traditional tools awkward to use and keep current. Next, a word about deployment. We heard some claims about time to deployment that amazed us. What this comes down to is what you are willing to accept as deployment. From our experience we would be surprised to see a traditional system deploy fully in under a half year or so.  True, the software could be installed and using some third-party tool most of the devices on the enterprise could be acquired in a few weeks for a large enterprise. But the tuning process likely will take months. And, until that's done the results are not reliable. This is where some of the next generation tools are useful. Their level of automation is crucial to a huge deployment.

Finally, let's talk about automation. On traditional tools we found that just about whatever is claimed, automation usually refers just to the workflow process. In a couple of cases we found that such things as survey analysis and policy assessment analysis were automated.  That is helpful but when you are working with a huge number of assets spread across the globe it may not be enough. Bottom line? Question deeply when issues of time to deployment and level of automation come into the conversation.  And if they don't, bring them in.