I hope you managed to join our recent webinar on Windows 10 Security, where we introduced three features of Windows 10 security (Secure Boot, Device Guard and Credential Guard) and demonstrated why your choice of migration methods may restrict your use of them. If you missed it, you can get the full recording and edited highlights at https://www.1e.com. We had lots of questions during the Q&A session but we didn’t have time to answer them all, so I thought I’d share the highlights through this blog.
Q: Are these security features only available with Windows Enterprise? We’re using Professional at the moment.
A: Device Guard and Credential Guard are exclusive to Windows 10 Enterprise (or Education) Edition. It’s also worth mentioning that the Virtual Secure Mode is only available on 64-bit Windows Enterprise. So in fact, even if you’re currently running Windows 8.1 with Secure Boot but 32-bit OS on a 64bit hardware, you’ll need to upgrade using a wipe-and-load if you want to use the Virtual Secure Mode features for Device Guard. Credential Guard is based on the Virtual Secure Mode so is dependent on 64 bit OS.
However, Secure Boot is available for all editions and should be used. UEFI actually makes it easier to write and implement malware – there is a link to an example of this in our blog “Is Windows 10 the Most Secure Enterprise Desktop Ever?” – so you should never consider running UEFI firmware in UEFI mode without Secure Boot.
Q: So do I no longer need anti-malware software if I have Device Guard and Credential Guard?
A: These features do not replace anti-malware software entirely. Device Guard prevents execution of unauthorised or modified executables and Credential Guard prevents stored credential hashes from being used with pass-the-hash style attacks. Anti-malware software is still required for other attack techniques, such as in-memory attacks or scripts executed through email or web sites etc. The idea is that your anti-malware software has less work to do.
Q: We’ve already started migrating PCs to Windows 10 using an in-place upgrade from Windows 7. Is there a way to enable UEFI after the upgrade?
A: If a PC was running in BIOS emulation mode before the in-place upgrade, it will still be using BIOS emulation. Switching to native UEFI will require the disk to be reconfigured, so you’ll need to rebuild the PC using a wipe-and-load process if you want to use these features.
Q: How is Device Guard different from AppLocker?
A: Conceptually, Device Guard is similar to AppLocker as it’s about only allowing execution of trusted applications. However, Device Guard goes further as it protects kernel mode as well as user mode and can be made much more secure using Secure Virtual Mode. AppLocker can give a further level of granularity to Device Guard too, for example Device Guard might trust all applications from a specific vendor based on the vendor’s signing certificate, but you may want to prevent specific applications from that vendor from being executed in your environment.
Q: How well can you bring Device Guard online in an existing organization with 1000’s of applications? Is there a way to scan and bring in the information from the environment?
A: Implementing Device Guard requires you to build policies that identify the signing certificates that you want to trust. There is a process that involves building one or more reference PCs with all the applications you need to run, then use a PowerShell tool to scan the PC and create a new policy based on the applications installed. Implementation will be covered in part three of Troy Martin’s Device Guard blog series, which will be available in a couple of weeks. You can also check out the Microsoft Device Guard deployment guide in the TechNet library.
Q: During the automated update process, what if the elected peer happens to be a laptop and that user goes home with their laptop during the process of another machine upgrading?
A: This is a reference to the 1E solution where we backup the user data to a local peer before we start migrating the PC. In the simulation I showed in the session, the data was only backed up to one peer. We have high-availability option for this feature that lets you make multiple copies on other peer workstations. You can define a minimum number of copies that must be available and the Task Sequence will not progress until that minimum number has been reached. At that point the Task Sequence will continue with the migration, but you have the option to create further copies up to a defined maximum while the source machine completes its migration. This removes any dependency on a single peer.
Q: Concerning the Windows 7 migration to 10 during the data backup process, what constitutes a “peer”? Another SCCM distribution point?
A: Throughout the whole process, a “peer” can be any existing workstation residing in the same location as the device being migrated. At any point in the process where a peer is required to perform a task, whether that’s storing user data, serving a Windows PE boot image through PXE or serving content, the peer is dynamically selected based on the most suitable at the time of the request. Our solution eliminates the need for remote Distribution Points, PXE Service Points and State Migration points.
Q: Instead of a peer machine, can we use the original drive as a source? And install apps/data on a brand new HD?
A: This is an interesting one! You could run USMT to back up the user data and settings on the original HD and restore this onto to the new HD. Unfortunately, you can’t do the same with applications as these will need to be installed on the new HD using installation source files – you can’t simply backup and restore applications from one disk to another. We use Configuration Manager to do the installation, but the content for these Packages and Applications is cached on local peers ahead of the migration, so they can be installed from the local peer instead of downloading from a Distribution Point. Using local peers also means that you don’t have to visit every workstation to install another disk – you can automate the entire process in every location 🙂
Q: Are you familiar with McAfee Drive Encryption 7.1.3? And if so how does it interact with Secure Boot implementation since it also implements controls on the Windows Boot Manager and actually replaces it with McAfee boot code.
A: I’m not very familiar with McAfee Drive Encryption 7.1.3, but any vendor that implements UEFI boot manager or boot loader code must sign it using a trusted certificate (i.e. included in the trusted certificate database hardcoded in the UEFI firmware). Either McAfee have requested PC manufacturers to add their signing certificate to this database, or more likely they have applied to Microsoft to have their code signed by Microsoft (all manufacturers are required to include Microsoft signing certificates in the database). There’s a bit more information on McAfee DE and Secure Boot in the McAfee knowledge base.
Q: Does USMT hard links support difference partition table, so if I’m on Win7 legacy boot, and I reinstall with Windows 10 UEFI and GPT… will USMT hardlink still work?
A: Switching to UEFI and GPT disk requires the disk to be completely repartitioned and formatted. You are therefore unable to use USMT with hardlinks during the migration process. You have to store the data off the PC being migrated. Normally this would require a State Migration Point in Configuration Manager – we enable you to use a peer workstation instead.
Q: Will changing from BIOS to UEFI interfere with 1E NightWatchman Wake-on-LAN BIOS Settings?
A: That may depend on the firmware and device vendor – the question really is are the legacy WoL BIOS settings preserved through the change to native UEFI. We use vendor-specific tools to manage the switch from BIOS to UEFI. These same tools can be used to manage settings within the firmware, so to be certain you can enable WoL in the UEFI settings at the same time.
Want to learn more about Windows 10 Security? You can review the entire webinar recording, and also selected highlights from the session here.
Don’t forget to check out the other blogs referenced in the session:
- Is Windows 10 the Most Secure Enterprise Desktop Ever?
- What is UEFI and Why Do I Need it?
- Device Guard: The Holy Grail of Endpoint Security?
- Device Guard: The Theory
Don’t forget to register for our next webinar on Wednesday 23rd March – “Creaking infrastructure, stressed IT staff and cranky users. Does your Windows 10 migration have to be this way?” where we’ll be looking at how to make your migration easier on your infrastructure, your IT staff and your users.
