By David Shefter

Decision making around enterprise endpoints

I’ve been giving this a lot of thought lately, as CTO of my company, Ziften, which plays a significant role in the enterprise endpoint technology space, delivering endpoint detection and response capabilities which continuously monitor endpoints for improved security posture.  A key point is what drives an enterprise to consider improvements, when they “feel” that the area in question (the Endpoint) is already locked down and safe.

First, you have to look at the numbers and according to the most recent Verizon Data Breach Report, over 72% of all advanced malware and “bad guy” entry occurs through the overall endpoint environment.

There are several challenges here, one of which is that most corporations “feel” they have a sufficiently locked down their endpoints through the use of AV protection, USB disablement and standard operating environments – Well, here’s a hint for their feeling, “they haven’t”.   A second challenge is that there is some exhaustion at the endpoint as they typically have at least 12+ drivers running at minimum from possibly as many as 10–20 vendors.

The belief, and one that I agree with, is that adding net new drivers or kernel-based solutions at the endpoint (from as few as several dozen to as many as tens of thousands of machines) will break other processes, applications, etc.  For instance, the average financial institution has at least a few hundred custom built applications (in the thousand’s for the larger firms) – hard enough to support without the introduction of new kernel and driver based solutions.

We considered driver code as a last resort only, due to well-known shortcomings:

  • Windows driver development requires in-depth understanding of Windows kernel data structures and coding conventions
  • Windows drivers are prone to incompatibilities with even minor system changes, such as Microsoft’s monthly patch updates
  • An error in driver code can cause a disastrous system crash
  • The vast majority of Windows instabilities are caused by third-party driver code

Solutions that use low-level drivers in their agents do not use standard Windows interfaces and essentially “take over” control from Windows. This has the potential to wreak major havoc on the operating systems of the desktops under management. A malfunctioning driver can crash the system and since it runs at kernel level it is also an additional security exposure. Microsoft says regarding driver security, “anything a user can do that causes a driver to malfunction in such a way that it causes the system to crash or become unusable is a security flaw. When most developers are working on their driver, their focus is on getting the driver to work properly and not whether a malicious intruder will attempt to exploit holes within the system.”

These types of solutions also require immense and intense certification efforts, sometimes greater than 6-9 months – by the time the new image is built and baked, the next version of the OS could be released.  This is a non-supportable, cumbersome and time consuming process.

This is why I strongly believe that the Ziften approach is a differentiator in the marketplace.  By implementing an incredibly light weight, non-invasive agent and implementing as a system service, it bypasses the “pain and suffering” that most new software products introduce at the endpoint.  To me, it’s all about ease of implementation that results in fast time to market, scalability, easy support and straightforward solutions that do not impede the user environment.

Get the Blog Here