I still see enterprises trying to go simple with their Windows clients: somehow deploying Windows 10, applying GPOs and just using WSUS to apply updates. But this leaves many points open in the management of the client ecosystem.
The new Windows 10 guards heavily depend on virtualization technologies, so beyond TPM 2.0, UEFI and secure boot, the CPU needs to be x64 and to support Input–Output Memory Management Unit (IOMMU) e.g.” Intel® Virtualization Technology for Directed I/O” (VT-D) or “AMD-Vi”. But these options need to be set. Especially IOMMU is not enabled in the default configuration of the OEMs.
So, you need to be able to configure the firmware settings and to change the settings if needed on existing machines. You also should have a process in place to regularly change the firmware password on all machines. For the most OEMs, these capabilities exist only in the professional series of models.
The firmware is a software and so it comes with bugs. Running an outdated firmware may be the root cause for blue screens or in worst case it opens a security vulnerability that can’t be defended in the Operating System. The Intel AMT vulnerability (INTEL-SA-00075) published in May 2017 is a good example.
First Intel published a toolkit to detect vulnerable systems, so an application needed to be executed on all machines and an inventory solution to collect the registry keys or xml-file holding the detection results. In the second phase, the OEMs published firmware updates to close the vulnerability, so you needed to able to deploy the right firmware update to the right hardware model.
Another vulnerability (MZ-17-01) published in May 2017 was related to the widely used “Conexant HD Audio Driver”. To mitigate it, the driver needed to be updated on all vulnerable devices, so driver-detection and deployment-capabilities for all running model were required.
As you can see in the examples, it is critical to know about your ecosystem. Not only the models in use, but firmware versions, hardware components, driver versions and on top a way to customize the inventory to collect non-standard information.
Depended on the configuration of the clients, updating to a new Windows 10 version requires more than just applying the feature update. Language Packs and Features on Demand (e.g. .Net 3.5) are version specific, so after applying the feature update these components are removed and need to be reinstalled. Applications can create issues too, e.g. a 3rd party anti-malware creating blue screens, so it needs to be removed upfront and reinstalled later. Already installed applications may require a repair, as seen with Skype for Business in an Office 2016 msi-based setup. These tasks are hard to be executed with just WSUS.
Configuring machines with GPOs is common and easy, but in a complex environment with multiple GPOs applied on different OU levels, are you sure that the correct setting wins on every machine? So, the client needs to compare the required configuration (baseline) with the current configuration and create alerts in case of mismatch.
3rd party applications
With Windows itself having lesser vulnerabilities, the attackers are using more often vulnerabilities in 3rd party applications. This is easy to be followed by commonly used applications like Oracle Java. But in enterprises the application landscape is complex. Do you know for all installed applications if they are still in the supported lifecycle or if vulnerabilities are announced and patched? So, you need a solution that compares the software inventory data with a vulnerability database to show existing vulnerabilities in the application landscape.
As you can see keeping the client ecosystem stable and secure requires many different capabilities in client management tools. The tools may come with additional costs, but compare the costs to the potential costs of a malware outbreak, e.g. the A.P. Møller-Mærsk‘s container related businesses expect the results impacted negatively by USD 200-300m in the NotPetya ransomware attack alone.