This group test showed us that the cats still are in the bag with a couple of them almost out. Generally, these six products all performed reasonably well. They all were more difficult to implement than we would have expected. And they all had quirks and foibles on which we were forced to focus in order to differentiate these product from each other.
Web content management products come in two flavors:
filtering and blocking. While the distinction may seem trivial it is important, we found. Content blockers must use a black list of disallowed sites. This requires constant updating and the entire URL is blocked for sites on the black lists. Content filtering, on the other hand, filters based upon objectionable content only. That means that a site may be accessible, but objectionable content on it would be filtered.
For example, one product performed both functions. For sites on the blocked URL list, the entire site was blocked. However, when we went to one of our test web sites, a site advocating the illicit use of several recreational drugs, we saw the home page but all of the graphics were missing. They had been discovered by the product and filtered, not blocked. When we clicked on one of the graphics, a link to a page that discussed a particular drug such as cannabis, we were blocked and saw, instead, the content filter’s banner page.
We also found that, from the implementation perspective, the only consistency was inconsistency. Some products required external SQL Server databases and some could operate with MSDE. We found products that required that the installer implement particular features in a particular order, in at least one case on the server itself, leading us to wonder what would happen if the organization deploying the filter had a long-standing installation of the server that had been set up in the wrong sequence for the content filter. Clearly that organization would need to shut down the server and reinstall it before the filtering product could be deployed. We found at least one product that was not compatible with the latest releases of Microsoft SQL Server and .Net.
We used multilayered tests for these six products. Because we found that implementation was a challenge, we focused upon installation, setup and documentation. Because the network topology for these products differed significantly from product to product, we depended heavily on documentation and tech support. We found the former generally weak and the latter generally strong.
This group review was the first one in our many years of product testing where virtually all of the vendors offered to come on-site and deploy the products for us. Although we, as is our policy, universally declined these offers, by the time we were finished we understood why the offers were extended to us. Web content tools are not trivial to deploy. We recommend that if your vendor makes the same offer, you accept it unless you have explicit experience with the product you are deploying.
Once we had deployed the product in our test environment, we proceeded to the configuration stage. Again, in most cases the products resisted our efforts at first. One word of caution: if you are deploying in a switched environment, you need to plan your installation carefully. Web content filters do not like switched networks. In virtually every product we tested, we found that the best way to deploy was using a user database, such as active directory, if the product supported it.
The next stage of testing involved trying to go to disallowed sites. Once we had updated the black lists on the product, using the vendor’s update process, we manually tried to access a few different sites in categories that we had configured as disallowed. The second test in this group involved using a tool built for us by an interesting little consultancy in Canada called InOrb Technologies. This tool lets us preload blacklists and then it attempts to access each site on the list.
We harvested several blacklists from various web sites and fed those to our InOrb tool. Then we ran the tool and referred to the web filter’s logs for results. Again, there was considerable inconsistency in filtering, blocking and logging. In all, our black lists covered illicit drugs, pornography, and gambling. We had well over 1,000 sites.
Six cats in a bag? Yes. The problem with these cats, though, is that they were similar in that they were difficult to deploy, weakly documented and complicated to manage. They generated similar results; however, there were a few products in the group that stood out.
IMPLEMENTING A WEB CONTENT FILTER: YOU'D BETTER BRING YOUR LUNCH WITH YOU.
In today’s business environment there are many challenges inherent in protecting an enterprise from unauthorized or malicious use. A major precaution that one can take to minimize risk from internal abuse is implementing a web content filter across the network.
There are issues of major importance that need to be examined when finding the right filter for the needs of the organization. We have looked at several of the most common products and found they all share a common thread, and lead us to believe that the three things of most importance are proper documentation, ease of updating, and overall ease of use and deployment. Unfortunately, all three of these can be fraught with challenges and frustration.
First is the issue of proper documentation. We found that there was a significant difference between products that included sufficient documentation and those that had minimal or no documentation at all. Though installation for most of the products we tested is automated, configuring the filters can be difficult without clear manuals. We found that the products that lacked solid documentation took several times more effort to install, with configuration becoming a matter of trial and error.
Next on our list of importance is the ease of updating the product with all the current blacklists and information for the filter to run smoothly and keep the network protected. In all cases, this was a make or break point for a product. If it is difficult to update a product, this becomes a major influence on the flexibility of the product itself. Many products offer free update downloads that can be configured to download automatically into the product at any time of the day. This is a real plus because the product can maintain itself, eliminating the issues of possible human error or neglect by an administrator. We found products that do not automatically update have an in-depth update process that can be confusing.
Finally, overall ease of use is a significant factor present in all the products we observed. With the many functions that these products possess beyond simple URL filtering, administrators can become confused when trying to manage and configure these programs. Some of the products we saw contained most of the possible rules for filtering already embedded in the default installation. With very little tweaking these rules were up and in perfect order to keep the network protected. However, we did see a few that contained a very minimal default setting and rules and policies had to be set up manually by an administrator.
With all of this said, web content filters can be a major asset to any company network. Most filters not only work as web filters but can also be used as anti-virus, peer-to-peer filters, and instant messaging filters. Additionally, they can be used to protect against spam and other dangerous annoyances. However, we found that research on all products before committing to a particular one is the best idea. This will help make sure that it is the right one for the specific implementation, and can save a lot of time, stress, and irritation in the long run.
The bottom line here is if you plan on implementing one of these beasts, give yourself time, expect the unexpected, understand your environment, get help from the vendor when you need it and, above all, don’t expect the documentation to answer all of your questions.