Technical Approaches For Client Management
Written By Dr Al Hartmann And Presented By Charles Leaver Ziften CEO
Within the systems management space, there has traditionally been a lack of visibility as to the applications running and resources being consumed on Windows clients. While great tools exist to monitor the network and server infrastructure, the client has been the weak link in the chain. This has caused vendors like Ziften to pioneer a new class of solutions aimed at managing the security and performance of enterprise clients, otherwise known as enterprise client management. Technically speaking, in order to collect the wealth of information within Windows needed to provide client visibility, we had two alternative approaches to consider. We could have written custom driver code, or utilized standard Windows APIs.
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.”
Ziften therefore took the approach of building our solution around standard Windows interfaces, which results in the following benefits:
Higher resilience to Windows changes and updates that tend to require driver modifications
Less susceptibility to driver conflicts that can result in system crashes (Blue Screen of Death)
Less likelihood of coding errors that may impact system performance through kernel interference
Within the systems management space, there has traditionally been a lack of visibility as to the applications running and resources being consumed on Windows clients. While great tools exist to monitor the network and server infrastructure, the client has been the weak link in the chain. This has caused vendors like Ziften to pioneer a new class of solutions aimed at managing the security and performance of enterprise clients, otherwise known as enterprise client management. Technically speaking, in order to collect the wealth of information within Windows needed to provide client visibility, we had two alternative approaches to consider. We could have written custom driver code, or utilized standard Windows APIs.
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.”
Ziften therefore took the approach of building our solution around standard Windows interfaces, which results in the following benefits:
Higher resilience to Windows changes and updates that tend to require driver modifications
Less susceptibility to driver conflicts that can result in system crashes (Blue Screen of Death)
Less likelihood of coding errors that may impact system performance through kernel interference