WebSense is probably the best-known provider of website filtering and logging – they have, after all, been doing it since the mid 1990s.
Traditionally the way to implement the product is to run up one or more servers within your network and point your client devices at it as their proxy; now, however, you can forget the internal aspect completely and use their externally hosted cloud service.
At the time of writing the service has 15 clusters, spread in locations around the world including the UK. The service uses global load balancing, so that when accessed via a generic hostname it'll automatically send your requests to the most appropriate location.
The service has three key functions:
- Logging all access attempts made to websites.
- Permitting/blocking each request based on an access policy that you define.
- Checking your downloads for viruses and other malware.
Websites are defined in terms of “categories”, some of which are stand-alone entities and some of which (particularly those with a vast number of candidate sites, such as adult material) are split into sub-categories. Each category and sub-category can be permitted or blocked in its own right, and additionally you're able to part-permit items – for instance you might use the 'quota' feature permit a user to access social media sites for up to an hour a day and block access once the quota has been reached.
Because blocking is based on categories, not individual sites, it's common to want to add exceptions into the list. This is a really simple exercise, which is really just a case of adding the site(s) in question to an exception list and (b) assigning that exception list against the appropriate user(s) and group(s). A word of caution, though: before you start to implement exceptions you should consider carefully how you're going to do it and structure your approach – otherwise you'll quickly end up with uncontrolled chaos that becomes impossible to unpick.
Speaking of users and groups, since the service is reliant on your user and group structure you'll need to sync your directory service with the WebSense cloud. This is a nice straightforward process, as they provide you with a simple sync tool that pulls the data from your directory via LDAP and uploads it via an encrypted link to the hosted service. Transfers are summarised at the sender and receiver, and there's a useful screen on the hosted service that lets you interrogate the database for diagnostic purposes.
The server end is, of course, only part of the story – you won't get anywhere without configuring the client end as well. Clients connect to the service via the Proxy Auto Configuration option of their browsers; in the “preferences” section you enter the URL of the WebSense-hosted service and the browser will do the rest.
For each policy you define, the WebSense service will give you a unique URL to be entered in your browser – and of course you can choose to distribute your browser settings automatically via logon scripts or AD policies. Don't forget, incidentally, that it might not just be your browsers that need proxies set by hand: if you have proprietary apps that use HTTP connections and don't have a “use my operating system's proxy settings” option you'll have to deal with those separately.
Now, although you'll be using a unique URL as the proxy configuration, how does the server know it's actually one of your client devices using it? Well, if you're in the office that's easy – you configure the public-facing IP addresses that outbound connections from your offices will advertise as their source.
If you're outside the office, however, users will have to identify themselves as your organisation's people. They do this with a one-off registration exercise: if they hit the hosted proxy from outside your office they'll see a “We don't know who you are” alert, and will be invited to register with their email address and a password of their choice. The service will then check that their email address is one of yours, and will send them a verification email with a link that they click in order to finalise the registration. For subsequent sessions they'll simply have to authenticate with their email and this new password.
If this sounds like a faff … well, actually it is indeed a complete balls-ache. What you need, therefore, is the Web Endpoint. This is a Windows add-on that stores the necessary authentication information and identifies itself as one of your computers whenever the user is outside your office's IP ranges. You can distribute the Web Endpoint like you would any other corporate app (it's a Windows MSI) or you can enable the users to download and install it themselves from the hosted site.
All very well so far, then … so what's wrong with the service?
First, the documentation needs some serious updating: because they've basically taken their software product and implemented it in the cloud, the docs still refer in places to screens you'd see if you were running it on a Windows server or an appliance in-house. This is annoying and unnecessary. Second, the Web Endpoint is a bit Windows-centric, and other platforms such as Mac and Linux are something of an afterthought.
Next, if you're moving from an in-house proxy installation you need to remember that although you're introducing filtering and blocking to your Internet connection, traffic levels may in fact go up if your policy is lenient – every connection attempt now goes out over your Internet connection before hitting the proxy and standing a chance of being refused.
Moving swiftly on, there are some popular sites that the service breaks in its default form. Using the WebEx Web conferencing service requires a tweak before it will work properly, for example – though it only took the WebSense tech support guy half an hour to diagnose my problem, and the facility to tweak such things isn't rocket science but a standard part of the GUI.
Oh, and if you want detailed logging you'll need to implement an internal tool to download the log files to an in-house system for reporting, as the full detail is kept for only a short time on the hosted service for space reasons.
Finally, whatever installation you're moving from you may experience a slow-down in service. If you used to have an internal proxy and you're moving to the cloud your packets will be going further as they're all bouncing off an external device. And if you've never had a proxy before, you'll also have the slowdown of the service checking downloads for viruses and other malware. Neither of these should be a big deal once you're used to them, though, and in the case of the malware inspection the loss in performance is offset by the gain in security.
All in all, WebSense's cloud service is straightforward to use and works well. Any performance loss you get will largely be offset by the benefits of the filtering, logging and malware inspection, and although the off-site authentication is a pain you can simply use the Web Endpoint instead.
I hope that in the next update they'll sort out the documentation so it's more complete for the cloud-specific service, and that they'll store the log files for longer for those who do want detailed logging without mucking about downloading them to a local box.
Pros
- No need to install hardware or software solutions on-premise
- Wide geographic coverage with global load balancing
- Web Endpoint for seamless off-site operation
Cons
- Limited storage for detailed log files
- Should cater out-of-the-box for common apps that are a bit non-standard such as WebEx
- Very Windows-centric, client-wise
Price
Depends on the options chosen and the size of licence
