As I mentioned in my opening column this month, the notion of web content management is a bit convoluted. When you look for a solid definition of web content management, you find that it is focused at the server end. So what we really have at the client end is content filtering. In that regard, the purpose has not changed much since we first started discussing content filtering years ago. And, ironically, when SC Lab Manager Mike Stephenson ran the web products through the lab, his major comment was that we saw all of this last year - with the exception that there are some new protocols being covered. For example, there is increasing emphasis on peer-to-peer traffic, especially such protocols as Skype.
Most of the products we saw were appliances. Generally, we like that because setup and administration are easier than with software-based products.
What we looked for
As always, the key to any kind of content management is policy and we looked hard at that. Policy in a product, however, is of little use unless it translates organizational policy into configuration easily and quickly. We are picky about how products make that translation. The old days of needing to program filters in what feels like a scripting language are - or should be - over. Time is money and precision counts a lot. We look carefully for precise, easy to configure, hard to fool policy engines.
In addition to some new protocols, most of the remaining improvements over last year were cosmetic. User interfaces are becoming a bit easier and more intuitive to use, a trend we applaud. We also like products that integrate nicely with existing infrastructure. The ability to hook into Active Directory and take advantage of user management that already is in place in the enterprise is a key benefit, especially during deployment.
We looked for ease of use and ease of implementation and management. Straightforward management is a key feature that helps security administrators be more efficient and effective.
What you should look for
As with any product, especially products that can have a potential impact on network performance and user satisfaction, web content filters need to do their jobs as unobtrusively as possible. A web filtering product should not be noticed unless it has to do something, such as block a website. Too, it should not materially slow network performance. It should be easy to update and it should fit well into your enterprise.
Fitting into the enterprise is important, and what that means is not intuitively obvious. I have seen products that do what they do very well, but drive their users nuts with interruptions and pop-up messages that many of the users don't fully understand. Not all enterprises are the same. For example, enterprises in organizations that have a culture of high security often are more tolerant of severe restrictions while more open enterprises, such as universities, have a culture of low tolerance for restrictions. The product you select should allow you to match it to the culture of your organization while offering adequate protection.
How we tested
We set up each system - initially attempting to rely as little as possible on the manuals - to get a feel for the product's intuitiveness. We then completed the implementation according to quick-start guides and manuals to ensure that we had the configuration correct for our test bed. That included integrating with our Active Directory in the test bed. We then browsed through the user interface, especially administration sections, looking for ease of use and administrations.
Our next stop was the policy engine where we started with the default policy set if there was one. We used a series of tests that attempted to defeat the policies in place as a default. Then we created a policy and attempted to defeat it. We were interested, especially, in the number of ways that the product accomplished its filtering. We looked for URL, key word and protocol filtering.
Finally, we looked at how well the product was documented in conjunction with its complexity. More complicated products - and a product may legitimately be complicated depending on its functions - require more complete documentation. Some products require little because they are intuitive. In addition to documentation, we are concerned about support options and the support website.