Web Filtering for the SaaS School - Part 2

In a previous blog we saw how functionality required from a modern web filtering service has now expanded beyond the simple on-premise server installation that fulfilled this role a decade ago and proposed that SaaS is now in a position now deliver a better solution than an on-premise server.

Instead of just looking at the current options and then tabulating up the pro’s and cons (other sites do this so much better) let’s play a mind game and list all the things we’d like from a filtering solution in a perfect world and see where that leaves us.

• The system must be able to interpret encrypted traffic. Ideally this would be without the overhead of deploying local certificates or any local configuration but if this isn’t possible the device management should be simple and non-invasive.


• The service should not have any hard limits and should be capable of scaling up and down on-demand.  The solution should operate the same way for a 10 user installation as a 10,000 seat install and the migration between the two should be seamless without any hardware or licensing breakpoints.


• The solution must be fault tolerant across the whole product range and be backed up with SLA which guarantees at least 99.9% uptime.


• The solution must be simple to install and provide a trial option.


• The service must have the option for ‘remote’ operation to protect 1:1 devices outside of the schools network.


• The filtering policies and reporting tools must be accessible from any location or device without VPN assistance and have a multi-site capability that comes as standard.


• Policies must be driven from an existing student/group database without any data re-entry.


• All software, firmware and product updates must be applied automatically without any local user intervention. A configuration backup will also be made automatically and held off site as part of the service.


• Licensing is simple, based on user or device with no up-front installation costs and with the option of short term contracts.


• There should be no requirement to provide third party hardware, software or licensing to support the service.


• The service should not increase the quarterly power bill but if does it must display an exciting set of flashing lights and be finished in a bright primary color to give the impression of modernity and general funkiness.
• 
  

Now the question is - how many of these requirements are likely to be fulfilled by an on-premise filter?

Of course the requirements are skewed in favour of SaaS and they could have been summarised in a much simpler list;

• easy administration through a web console.
• automatic updates and patch management
• elasticity on-demand
• subscription licensing model with no barrier to entry.
• remotely hosted with built-in fault tolerance.
• SLA implicit with service.

but that doesn’t make them any less more desirable with respect to content filtering.

The final takeaway is that the move toward secure communication has fundamentally changed the playing field.

What used to be a simple function of running a lookup on a web address has now become a processor intensive operation that will only ever increase with time and the most efficient way of doing this is in the cloud were the unit cost of those processor cycles is far cheaper than the on-premise fixed capacity server. 


SaaS Options.

There are a number of companies that can offer web protection as a true SaaS service with no on-site component.

GoGuardian has developed a service that focuses specifically on the education Chromebook space.

Securly offers a comprehensive package specifically for education that covers a range of clients types. Interestingly they recently announced the possibility of SSL decryption without configuration files which would provide a clean sweep of the “wish list”.

At same time the standard players such as McAfee and Symantec have caught the trend and are now offering a SaaS option as part if the product line.

And of course there's always the option of the brightly coloured box if you like that 'retro' feel.

Web Filtering for the SaaS School - Part 1.

It used to be so simple, where did it all go wrong ?

In the past managing student web activity usually involved installing an in-house proxy server, commonly Microsoft Threat Management Gateway (TMG) or even further back Microsoft ISA server. Client web traffic was forwarded directly to the proxy server which queried the web in the users behalf but only after passing the request through a series of filters that denied access to sites displaying inappropriate material. All of this was neatly integrated into Microsoft AD security for ease of management.

Alternatively the school could rely on a ‘clean’ feed provided by an educational authority, district  or ISP, so long as you were happy with a ‘one-size-fits-all’ approach.

All was well with the world….. and then it went horribly wrong.

It difficult to say exactly when this happened but Microsoft’s formal announcement of the end-of-life for TMG in 2012 without providing a direct replacement for outbound URL filtering was probably the start although things were not well in the ‘walled garden’ before then. The idea that you could effective ‘whitelist’ the internet had long gone and the expansion of platforms such as YouTube to include educational content meant that IT services were under pressure to unblock access to sites previously viewed as undesirable.

However there are other suspects in this crime.

The growth of interest in BYOD and 1:1 tablet programs meant that configuring proxy settings on each device added a new layer of administration outside of Active Directory group policy.

In addition student using iPads and Android tablets were no longer authenticating against Active Directory before browsing the web. A work round required the student to provide a username and password using a captive web portal before proceeding. This worked pretty well for simple web access but proved a challenge for tablet apps that were not expecting a “call home” to return the captive portal page.

Things were getting difficult.

For a while the solution seemed to be to install the filtering service in-line with the firewall (transparent mode), silently ‘snooping’ on the packets as they pass between the user device and the internet. This certainly made device configuration easier (there wasn’t any) which fixed the BYOD and app issue although user identification remained a challenge.

All was well for a while until Google made an announcement that as of 23rd June 2015 the Google search services will move all search results behind SSL encryption.

This means that in the future the session from the device to internet will be encrypted end-to-end and although a transparent proxy could still access the data packets it could not decipher the information to make any sensible decisions with regards filtering. So as Google and other content providers made the switch to secure communication the transparent proxy, which had solved so many problems, effectively became ‘blind’.

As a quick fix schools simply blocked sites that used a secure connection or bypassed the proxy entirely but this quickly became impractical as more external sites adopted the secure standard.

The transparent proxy approach has survived, employing the latest encryption standard  (TLS) which was slightly more cooperative with regards to filtering. Using TLS the gateway knows that a device had accessed YouTube but would have no further details as to what resource the student was requesting from that site.

A number of workarounds quickly emerged but most fell back on a variation of the “relay’ model whereby the client held a secure connection with the gateway and the gateway maintained the secure connection to the external service. Unfortunately this simply reintroduced all the historical issues with client configuration (with the addition of certificate deployment) as well as loading the proxy with a significant amounts of additional processing as it encrypts and decrypts the packets.

Which is pretty much where we are today. Frankly it's a bit of a mess.

So in the future what's likely to happen and how can SaaS help.

There’s little doubt that sites will continue to adopt secure protocols until it’s the de-facto standard for web traffic. Traditional on-premise systems will just have to come to terms with the fact that the data stream from client to host will be encrypted.

Protocols like TLS provide some visibility of the stream but not enough to support a comprehensive filtering service. Filtering support is a by-product of using TLS and is not its prime purpose so we can’t expect improvements in this area to deliver the solution.

Currently on-premise proxy servers can intercept the secure channel by acting as an intermediary and decrypting and encrypting the packets as they pass through but this activity is processor intensive and to achieve this on any scale without affecting latency is not going to be easy especially as the proportion of encrypted traffic rapidly increases.

So when the renewal of the proxy support contract comes around do you invest a tin-box that can can handle your schools current data load or the projection for the next three years?  Are you going to be forced to purchase an expensive device that can handle the peak loads prior to the exam season only to remain idle for four months of the year?

Remember you still have the problem of client proxy management, certificate deployment and user authentication on top of this.

Or maybe we should just throw away all the historical baggage and a design a system for the world of mobility and SaaS.

And if we did this, what would it look like and what advantages do you gain?

Web Filtering for the SaaS School  - Part 2.

Further Reading.
Adams blog gives an excellent technical summary of this issue.
http://adamwelch.com/2014/11/google-ssl-search/