Security Hardening for Windows 10 – VDI
Our resources are limited, so we wish to spend as little as possible on security. It is not the end-goal, most organisations are not in the business of security. Security is an enabler to do the business and to do the things we have to do. It allows for you and your business to run uninterrupted, so we don’t wish to apply to much security or to little security. We wish to optimise the use of our resources, so they optimally protect our assets. The aim is to protect what you value most and be able to do what you wish or must do. We don’t want you to switch of the internet and go live in an underground bunker without daylight or contact to anybody. We want that our life and work can run without interruptions from malicious people or errors in software.
That being said, we still notice that VDI hardening is an often-neglected part of the implementation of a new deployment. The most common reason is its complexity to secure your environment without breaking it. But with the current amount of security breaches and ransomware it has become a necessity to spend a decent amount of time on the balance between usability and security.
20 years ago, you could get away with only deploying the windows updates every 6 months or so. Now you want to deploy them as soon as possible after their release on patch-Tuesday. And I remember many discussions where people would say a virus scanner is not needed on a VDI, especially a non-persistent, because a reboot will bring it back to its original state. But those recommendations are long outdated. So, for sure the bare minimum on your VDI deployment is:
- Up-to-date OS and applications
- Up-to-date virus scanner
- Remove unused or legacy applications
- Remove unused services and scheduled tasks
- Prevent access to unauthorized applications
- Prevent Access to Regedit, CMD & Powershell
- Use Network Segmentation
- Move your eventlogs to a persistant drive
- Multi-factor authentication
- Secure connection to the datacentre
Up-to-date OS and applications
Do you have software? Then you need to update. It’s that simple. Don’t have unpatched systems on your network.
Up-to-date virus scanner
Every computer should have an Anti Virus solution installed. But with VDI this is a bit of a tricky topic when not handled well. Every antivirus solution comes with a footprint on the VM resources. And remember that you must multiply that footprint by the number of machines you have. If that number is hundreds or thousands it can easily create a noticeable impact on your budget. That is why it is important to consider at least following topics when choosing and implementing your antivirus solution:
- Select an anti-virus solution with a proper documented way to implement and configure VDI. (especially the non-persistent type)
- Configure your list of exclusions, as detailed as possible.
- Updates of your signatures need to happen as they become available. But how big is your signature file? If you are using a provisioning solution like PVS or MCS this can have a serious impact on your cache solution.
Performance and other optimizations, best you can do is contact your virus scanner vendor and discuss the best practices for your situation. Citrix and VMware both have detailed documentation about the antivirus best practices:
Remove unused or legacy applications
Every peace of software installed on a system is an added security risk and it consumes time to manage it. It is important to keep your software library as small and manageable as possible. We all know that new and shiny software gets security updates at regular intervals. But as the software gets older, the software vendors start to forget about it (mostly they call it “out-of-support” or “end-of-life”).
At many organisations I notice that, without much thinking, admins install all the Visual C++ redistributables, because some legacy software might need it. Sometimes that’s true, but not always. It is a good practice to make sure that software that is no longer needed or supported by the vendor is not installed on your system. Don’t include Adobe Flash, Visual C++ 2005 or other known risks in your VDI image.
That is why I already give you a heads-up with a list of product lifecycles for some of the main software vendors in our market:
For Citrix, here is the list:
For Microsoft products this is the list:
For Visual C++ redistributables, here is a more detailed list:
For VMware the list can be found here:
Remove unused services and scheduled tasks
In the article “Desktop Optimizations for Windows 10 – VDI“, I describe the ways to disable services and scheduled tasks for performance reasons. You should do the same for security reasons because you don’t need 70 unused services running which all can have potential security vulnerablity.
Prevent Access to Unauthorized Applications
In the same philosophy as unused applications and services, it is best to allow users the set of applications that they actually need and use. Mostly in a VDI-environment we work with a limited set of golden images, where applications are installed that are not used by all employees. To block those, you can use Microsoft AppLocker, it is great for Whitelisting: Based on group membership, certain applications will be blocked from launching. I suggest that if a group of users does not need it for work, then block access to it.
And if you don’t have time to configure it in detail, then at least turn on the audit mode. It just takes a few seconds, but you’ll be able to review the logs later. Logging is very important in case you got breached. It’ll help you to find out what happened.
If you wish to go one step further, I recommend that you use Ivanti Application Control (formerly know as AppSense Application Manager). It goes in much more detail and has a lot more options to configure your application security.
Prevent Access to Regedit, CMD & Powershell
In most cases it’s also standard to prevent the user from altering your system and the best places to start are:
- CMD: User Configuration > Administrative Templates > System > Prevent access to the command prompt
- Powershell: User Configuration > Administrative Templates > System > Don’t run specified Windows Applications > Add Powershell & Powershell_ISE (x86 & x64)
- Powershell: User Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn On Script Execution > Allow only signed scripts
- Registry: User Configuration > Administrative Templates > System > Prevent access to Registry Editing Tools
Note: Make sure you don’t lock yourself out as an Administrator
Use Network Segmentation
Your VDIs should be deployed in their own VLAN, with a firewall between them and any other VLAN in datacenter. When attackers manage to enter your network, the next thing they will try to do is reach any of the core components (like for example Active Directory). Firewalls and gateways restrict traffic to their respective zones, reducing lateral movement and attack surface to contain the blast radius of a breach.
I would even go as far as enabling the Windows Firewall on each of the VDIs or servers. It comes at an expense, because you must manage them all, but it really makes a difference in your overall security.
Move your eventlogs to a persistant drive
In case you have non-persistant environment (remove changes after each reboot), then it is key to maintain your eventlogs between reboots. Luckily Microsoft has come with a few Group Policies to redirect the 4 key eventlogs. But I believe this does not go far enough.
I found following wonderfull script on the Microsoft website, which moves ALL eventlogs to the new location:
Local Drives, Network Drives, Client Drives
Local Drives: Your users need files, but those files normally are just their data files. They don’t need access to the system files of your VDI machine. So a rule of thumb: Block access to the Local system:
- User Configuration > Administrative Templates > Windows Components > Windows Explorer > Prevent Access to drives from My Computer > Restrict Al Drives
Network Drives: Keep it clean and structured. I have seen envrionments where, through all kinds of rules, there are potentially tens or even hundreds of drives mapped. Believe me, you lose sight of things (never good from a security point of view) and you’ll spend to much time troubleshooting and slow down the logon proces.
Client Drives: I prevent access to all client drives and other USB drives by default. And just in some extreme exceptional cercomstances open access for specific users. With Citrix Policies:
- Auto connect client drives – Disabled
- Client drive redirection – Prohibited
- Client fixed drives – Prohibited
The MFA will help to protect user logins even in the case of credentials leaked or have been stolen in a fishing attack.
Secure connection to the datacentre
I’m more an expert in Citrix then any other product (Microsoft WVD, VMware, …), so I’ll focus here on explaining how a user connection flow in Citrix is and what the important security measures are.
When users start a session, it is done through the Citrix Workspace app or a website. The user clicks the icon for his virtual desktop or app and it launches. The first imprtant security measure here is the user’s connecting device. This can be anything (Windows, MacOS, Linux, iOS,…) and a user can connect from anywhere. So mostly you as an IT admin don’t have any impact on this device. That is why it is important to run a check on the connecting device before the user opens his session. For that I suggest using Endpoint Analysis Scans from the Citrix Gateway (ADC).
Advanced Endpoint Analysis Scans is used to scan user devices before allowing the user to connect to the database. The device is scanned for security information such as up-to-date OS, antivirus, web browser version and so on. You can use it as part of the smart access policies configured on the Netscaler/ADC. Here is an interesting document by Citrix on how to set it up.
If the user is connecting from outside the LAN (on a public internet connection), make sure the connection ALWAYS goes through the Citrix ADC/Gateway (Netscaler) and over SSL. Making the IIS browser of the Storefront public facing is a bad practice. With the Netscaler, the SSL traffic is handeled and the AD credentials are verified before the user enters the internal LAN.
Also, setup multi factor authentication. There are many options out there that are compatible and easy to setup.
If you don’t know the traffic flow for a Citrix connection, there is a very good video on youtube about it. It’s a bit of an older video, but still relevant:
Security is important, but it is also something that is always changing and improving. That is why I want to maintain this as a living document with new settings and configurations as I get to know about them or implement them at the customer site.
Did I forget something? Or do you believe there is an error in this text? Please let me know in the comments below.