Product Group Tests
Endpoint security (2006)
Our Best Buy goes to Safe Access. Even with its relatively high cost, it is an excellent product, offering the full range of endpoint security functions. If your enterprise needs total protection, it is the most serviceable package we looked at. Its ease of use and performance make cost of ownership beyond initial purchase very reasonable. Our Recommended product is LANDesk Security Suite. As part of a larger suite of products, the LANDesk Security Suite offers flexibility and functionality. It suffers a little from initial ease of use and is a bit pricey, but is very competent and has impressive functionality and performance.
Full Group Summary
How can enterprises keep their endpoint computers secure when even the vendors can’t agree on what it means? Peter Stephenson used four key benchmarks to test six leading packages
So what is endpoint security? When research and testing for this group review, we found that this was the core question we needed to ask and, surprisingly, we found limited agreement on the answer. Nor are we alone. Writer Sean Michael Kerner reports that Allan Carey of IDC came to the same conclusion. He contends that vendors define the genre in a variety of ways.
That was bad and good news for our testing; bad because nobody agrees on what endpoint security means, good because we had to define it ourselves in order to have a benchmark for testing.
We reverted to first principles of information security and asked the important question: “If an endpoint computer is truly secure, what would that mean?” Of course, the end objective is to protect the enterprise through securing the endpoints, so the answers needed to be in the context of the whole enterprise. We came up with four general qualities that such a computer would possess, and this was the basis for our testing:
First, endpoint configuration is consistent and complies with a set of policies intended to protect the enterprise through the endpoints (“Configuration Requirement”). Second, users have access to resources, both on the endpoint and in the enterprise or outside it, limited by a set of policies intended to protect the enterprise through the endpoints (“Access Control Requirement”).
Third, users can only access and install approved applications on the endpoints (“Application Control Requirement”).
Finally, the endpoint is protected against external compromise by viruses, worms, Trojans, spyware, and so on (“Endpoint Protection Requirement”).
Even with these criteria, we found that vendors have a variety of ways to reach these goals. Indeed, most did not address all four of them. There are two basic types of endpoint security products – agentless and those with agents.
Agentless products scan endpoint machines and determine whether they should be allowed on the network. Generally, this is done by a server placed in-line between the users and the rest of the network. This server acts as a gateway through which the user must pass in order to access network resources. Compliance with the server’s policies determines whether or not the endpoint machine can access the network.
Products with agents place the agents on the endpoint computer, and if it is not in compliance with policies, the agent adjusts the computer until it is. This can be problematic. For example, we set up a machine as an endpoint on a system that required agents. We set our policy to disallow USB ports because we wanted to stop users spiriting away confidential corporate data on a thumb drive or other USB drive. As a result, the USB mouse on that machine promptly stopped working.
We also found that uninstalling agents could pose a challenge. When we moved from one test to the next we found that if an agent had been installed on our test machine we would probably need to reinstall the operating system to get rid of its effects.
We set up our test bed with one “clean” and one “dirty” machine. The first met the policies of the system being tested, the latter did not. We configured the test system and then attempted to join the two new computers to our isolated test network. Our expectation was that once the clean machine was tested it would be allowed to join, but the dirty computer would not. In cases where the dirty computer was allowed to join, we expected that it would be configured automatically (in an agent system) to comply with policy. In an agentless system, we expected that it would not be allowed and its effort to connect would be reported to the management console.
All the products we tested were checked for support of our four criteria for endpoint security. Some vendors argue that their product is not intended to do all the things we expected. Our response is, simply, that it does not protect the endpoint and, therefore, fully protect the enterprise.
The main argument comes when the topic is anti-virus software. The question of whether this should be included as part of an endpoint security package or is a separate application is an open one. For our tests, we expected that the system under test either had its own AV capability or tested the endpoint to ensure that such a capability was installed as a third-party product.
We agree with Carey that endpoint security is centrally managed client security. But we don’t make a distinction as to how that is done as long as the product under test meets our four criteria and is, in some manner, centrally managed.