Once an enterprise has decided that a secure Web gateway is the right technology for its security needs and knows...
which SWG features it wants to turn on and deploy, there is still one final decision to make before it seals the purchasing deal: How will we deploy the tool? Knowing the answer to this question will be critical as an organization makes the final call on purchasing a gateway.
Fortunately, there are several different deployment options for SWGs. Each offers advantages for customer-specific requirements in speed, ease of use and flexibility of deployment.
Let's take a look at the main advantages and disadvantages of four available SWG deployment options and then go over how to nail down the final decision.
Secure Web gateway deployment options
Cloud-based SWGs offer elastic, on-demand Web filtering without alteration to existing IT systems being needed.
1. Appliance: Appliances are the most common deployment method for SWGs. They are fast, inexpensive and completely self-contained. Slide one into your rack, turn it on and you are operational. You avoid the software and hardware platform biases. Several even provide specialized hardware to speed up certain computationally expensive functions, allowing them to outperform all rival deployment options. There is a downside, however. As an SWG appliance ages, it typically falls behind customer performance demands and needs to be replaced as opposed to upgraded. Also, scalability means buying more appliances; disaster recovery and failover mean buying more boxes. In a day and age where firms increasingly are moving to internal cloud and virtualized server environments, SWG's hardware model fails to integrate with these data center architectures.
2. Software: A handful of vendors still offer SWGs as software. This model provides flexibility and scalability options that hardware deployments do not. Need more processing power? Simply allocate or install more resources. While software requires more up-front time to install and configure, it offers advantages in flexibility of deployment, integration and resource allocation (i.e., memory, processor, disk). In addition, software licensing is easier to tune to a customer's specific needs, resulting in lower overall costs for most customers.
3. Virtual appliance: The fastest-growing SWG deployment option today is as a virtual appliance. This option is the direct result of companies looking to reduce costs and administrative hassles through virtualization platforms. As the name implies, virtual appliances are a software image of a hardware appliance. In many ways they offer the best of both worlds: They scale like software but have the preconfigured deployment of hardware. And virtual appliances naturally integrate with virtual server deployments. The downside is that virtual appliances don't have the dedicated hardware acceleration that some appliances offer, so performance between virtual and real appliances can vary considerably. Additionally, virtual appliances are no longer prepackaged affairs, which requires customers to monitor resource utilization and periodically tune them in order to ensure they provide good performance.
More info on SWG products and services
Advice on choosing an SWG
SWG products, cloud services supplant URL filtering
Get advice on how to choose hosted Web security services
SaaS startups entering the SWG market
4. Cloud-based or hybrid deployments: Some vendors are launching cloud-based service offerings to complement or supplant on-premises technologies. When internal hardware is overtaxed by antispam or rigorous content analysis, it's easy to offload that processing to a cloud service provider to ease the burden on in-house platforms. Similarly, some customers want third-party cloud services simply because they lack in-house staff to manage a product. Cloud-based SWGs offer elastic, on-demand Web filtering without alteration to existing IT systems being needed. In this model, network services are routed through the cloud service provider before they are sent to you, the customer. Customers can choose to enable a subset of the features -- perhaps because their current system does not offer URL filtering -- and simply pay as they go for that service.
Sealing the deal: Deployment options
It is important to note that each deployment option is sold under different pricing models. For example, hardware is sold based on the level of potential throughput the appliance supports and must be accounted for as Capex. Cloud services are billed monthly as the customer consumes the service, so they fall under Opex. Multiple models give an organization some flexibility in both how it uses the product as well as how it pays for it.
Multiple models give an organization some flexibility in both how it uses the product as well as how it pays for it.
All vendors are in a race to provide a comparable breadth of SWG features to potential buyers. However, given the evolutionary track each vendor has followed, it is critical to remember that not every vendor will do everything well. Vendors will have their specific core competencies, and additional features -- which are often hastily added on or acquired -- many times will lack a degree of efficiency or effectiveness. For example, a vendor might have deep experience with the network layer -- so its load balancing and packet inspection capabilities will provide incredible performance -- but might do a really mediocre job at content filtering and email security.
When an enterprise makes an SWG investment, its buying decision must be based on this balancing act. Be sure to select the vendor that focuses on the areas your organization deems most critical, yet make sure the vendor also offers the flexibility and pricing models that best align with your business' needs.
About the author:
Adrian Lane is CTO of Phoenix-based analyst firm Securosis. Adrian specializes in database security, data security and software development. He is a former executive at security and software companies such as Ingres, Oracle, Unisys and IPLocks, and is a frequent presenter at industry events. Adrian is a graduate of the University of California at Berkeley with post-graduate work in operating systems at Stanford University. Reach Adrian via email at firstname.lastname@example.org.