Tackling the ongoing problem of endpoint defense
A comprehensive collection of articles, videos and more, hand-picked by our editors
Enterprise use of cloud endpoint security services provides the immediate total cost of ownership (TCO) benefit
of eliminating the need to deploy and configure an on-premises management server. Unfortunately, some cloud-based security offerings provide relatively primitive, limited functionality that can tip the TCO scales in the wrong direction! When evaluating cloud-based endpoint security services, never assume the functionality available from an on-premises product is also present in a cloud service.
Unfortunately, some cloud-based security offerings provide relatively primitive, limited functionality that can tip the TCO scales in the wrong direction!
This article provides guidance for evaluating cloud-based endpoint security functionality related to deployment, alerts and reporting. This cloud endpoint security comparison is based on The Tolly Group's recent experience building prototype deployments via services from five well-known cloud security vendors.
Whether an endpoint security rollout covers an entire location or just a few new users, flexibility and easy deployment are always ideal. When the management system is external to the corporate environment, as is the case with cloud-based security, the deployment process necessarily changes somewhat. While an implementation is, by definition, a one-time task, the effort can be significant for a large installation, so it is prudent to examine the installation tasks closely.
The fundamental difference between traditional and cloud-based endpoint deployments is dealing with the fact that, with a cloud-based product, the endpoints are on an internal, private network, and the management server is on a public, external network. Because the corporate endpoints will undoubtedly sit behind firewalls (and almost certainly use a private IP address space), the communication between server and managed client must be initiated by the client.
Our research uncovered three primary deployment methods in use today: an installation software package, an installation URL through which software is downloaded, and a gateway machine. The first two methods are initiated by the client and "pull" the required agent and endpoint security files from the server. The last method "pushes" the agent and related software from the server (via a gateway system situated inside the firewall) to the client.
At a minimum, then, a cloud-based deployment requires at least a single "pull" install of an endpoint client, even if a vendor offers the automated "push" option. This is because a push install requires a local computer to serve as a gateway from the "outside" cloud management server to the "inside" clients that are being pushed to. However, in our evaluation, only one of the five products we worked with offered the "push" option. The simplest way to install the endpoint agent is to use the management console to email the installation URL to the endpoint user. (The URL and the installer used in the "pull" approach are coded with the customer company’s cloud security ID. This automatically associates the client with the customer's cloud security management server.)
The "push" system enables installation without user interaction. Simply identify the target machine from the names and IP addresses displayed on the management console, and then provide credentials that can be used by the automated install to log in to the endpoint.
Cloud endpoint security alerting
Once the installation is complete, next comes alert functionality, which allows an administrator to be immediately apprised of potential security issues. In addition to displaying alerts on the product's administration management console, most cloud-based endpoint security offerings allow for email and/or SMS (text message) alert delivery.
Typical alert conditions include threat detection, blocked URL detection, out-of-date virus definitions, no scan run in X days and so forth. Surprisingly, we have found some services offer limited or no support for alert functionality. Instead of real-time analysis, security managers must rely on reports.
Alerting is an important feature -- administrators can't be at the console 24/7 -- and an enterprise should not only ensure it's offered in the service it selects, but also that it works well.
Cloud endpoint security reports
Report requirements are fairly predictable. Security managers typically want lists of threats detected, infected devices, attempted access to blocked websites, etc. Thus, it was surprising that three of the five services we profiled do not provide any predefined reports. While manually generating these reports is not a big burden, the fact that several major vendors didn’t have developers take the time to attend to basic reports reflects the general lack of depth in functionality that we saw from a number of the offerings.
In advance of an implementation, be sure to carefully define alerting and reporting needs. Are there existing endpoint security reports the new system should provide? Is new or additional reporting necessary? What purpose does it serve? Sketch out answers to these questions, present them to prospective cloud endpoint security providers, and ask them if they can produce those reports for you, ideally without additional costs.
About the author:
Kevin Tolly is founder of The Tolly Group, which has been a leading provider of third-party validation/testing services for more than two decades. Read more of The Tolly Group's reports at http://www.tolly.com.