Azure Windows Virtual Desktop (WVD) environment provides desktop and application virtualization, allowing connections from almost any kind of device to either a fully functional Windows 10 desktop or to an application virtualized on a Windows 10 VM. While providing great flexibility, it introduces additional components that require monitoring from a security perspective.
Fortunately, the Azure security services can raise up to the task and mitigate most of the security risks WVD opens.
In the diagram below we can see the high-level design of a typical WVD deployment: a mix of clients, the VMs providing virtualization services, the virtual network, the Azure AD, the VPN gateway providing connectivity to on-premises resources and the Windows Active Directory services.
We have not included the components of the RDS backend that transparently provides the management of the virtual desktop environment. As a SaaS, these components are managed by Microsoft and the customer has little visibility into their operations and security monitoring. All the other components however, are the customer responsibility.
The monitoring infrastructure would be naturally provided Azure Sentinel SIEM, integrated with complementary services such as Azure Security Center and Azure Defender ATP.
To build our monitoring infrastructure and the potential use cases, we need to understand what data is available to us. Based on the diagram we can identify the following:
- Windows event logs from the VM that are part of the WVD host pool, the Windows 10 Multi-Session installation that provide the virtualization services. These include all the typical Windows event logs (Security, Application, System, etc.) so from the start all the use-cases relevant to these logs can be applied.
- Windows event logs from Windows AD domain controllers (in Azure on on-prem). Since all the accounts used to login into WVD are Windows AD, the logon/logoff activities will be recorded in the domain controller security event logs, along with all the processes created and their command line arguments (if the audit is enabled). All the Azure Sentinel SIEM cases around AD user and group management will be based on these logs. Same examples from our use case catalog:
- The other Window event logs such as System and Application can provide information on the health of the operating system and monitoring for errors and warnings are still part of security as they can affect the “Availability” part of the Confidentiality – Integrity – Availability security triad. We typically deploy a weekly report with a summary of such events.
- Azure AD SignIn logs – These logs provide information on the initial connectivity to WVD and contain very important information on the type of client used, if it is a managed device, the IP address and the location of the client:
- This information can be used a wide range of SIEM use case such anomalies in the number of connections, connections from multiple location from the same account and can be correlated with threat intelligence feeds. In the example below, we can see how a malicious actor, matching an IP from our Firegen Threat Intel feed tried to connect to our WVD environment using an easy to guess account/password that we configured on purpose:
