Keeping endpoint security secure
Adding an endpoint security system to your network should not open the network to attack. To that end, we evaluated the overall security of each product by trying to poke holes into the system via the client software, the server components and the network traffic they collectively generate.
While none of the products bombed in any of these tests, the highest-scoring products were from Vernier/PatchLink and Senforce. We were unable to sneak past the enforcement mechanism by removing the client software in either of these implementations, and both had relatively secure servers with minimal flaws in their network communications.
To truly enforce policy, client software is required so you can tap into detailed information that is only locally available, such as registry keys or filename/contents/hash values. Attackers understand the opportunity here.
We tested the products to determine if you still could run the client even if a virus or an exploit attempted to remove it. This test was complicated by the fact that some products offer in-line enforcement devices (Cisco, Trend Micro and Vernier/PatchLink), some are client-only (Check Point , Citadel, Senforce), while others integrate with the network infrastructure (InfoExpress, as tested).
With the Check Point, Citadel and InfoExpress products, we were able to use a small amount of exploit code to rename the directory where the client is stored or delete the program files. A system reboot did not show any indication the client software was removed. Senforce solves this problem by keeping its data and program files open continuously, detecting any attempts to remove the client software or components of it.
In our examination of whether the network traffic generated by these products could pose a security risk, we found there were at least two kinds to be concerned about. There is the network traffic from the clients to the server, which could be compromised to claim a noncompliant client when it's not. And there is the network traffic generated and received by the management server interface, which would be a valuable target because of its control over the policy enforcement mechanism.
Some vendors (InfoExpress, Senforce and Vernier/PatchLink) use unencrypted HTTP to communicate from the management server to the operator or to other components. This is simply not secure. InfoExpress also uses Telnet or Version 2 to access the network infrastructure, thus exposing passwords and other information to anyone monitoring that portion of the network.
All the products except Trend Micro's have encrypted communications between the client and the server. If not encrypted, this information is visible to an attacker and possibly leaks information such as what policy you are enforcing, your network configuration information, even possibly usernames and passwords.
We also looked at the servers from a security standpoint because these boxes (be they running on appliances or on customer-supplied platforms) become part of the critical network infrastructure and are a likely target for attack. These servers are prone to having potential vulnerabilities. Some vendors (Check Point, Cisco, InfoExpress, Trend Micro and Vernier/PatchLink) use (TLS)/SSL for the management interface or the client-to-server interface. This is good except when the vendors don't get the minor details right because they all support SSL Version 2, which should never be in production use because of known vulnerabilities. Only SSL Version 3 and TLS are currently considered secure enough for production use. Note that products based on generic customer-supplied Windows platforms can usually turn off SSL Version 2 support, but you can't do that with the appliances.
Most vendors also use self-signed certificates, which are dangerous. If not used very carefully through manual confirmation of the 16-byte MD5 hash, an attacker can spoof these. Products (as Cisco's CCA does) should allow for the replacement of the self-signed certificates in the servers with properly issued certificates from the customer's production certificate hierarchy (such as public-key infrastructure).
One final thing we investigated was the use of off-the-shelf software such as Apache, OpenSSH or PHP for operation of the management server. It is reasonable to expect a company that sells a product that is designed to monitor clients for software updates to have its own update mechanism in place as well. So we were disappointed to find some products using old versions of software. Cisco's CCA uses an old version of OpenSSH and Vernier uses an old version of PHP. All the software running on the infrastructure devices also should be properly maintained, whatever that means, because it too could become a source of vulnerability.
Copyright © 2005 IDG Communications, Inc.