Published
Jan 31 2019 02:59 PM
939
Views
First published on TECHNET on Feb 07, 2017
Ahead of the Industry's annual security gathering at the RSA conference next week, today Principal Program Manager Lead for Surface Hub, Paul Barr, walks us through the top Defense-in-Depth strategies behind the design of Microsoft's Surface Hub. As a communal device, the engineering team had the challenge of maintaining the Surface Hub user friendly and ready-to-use multi-media experience without compromising on security.
In today's Microsoft Mechanics demo bench video, Paul explores potential attack vectors to illustrate Surface Hub's security strategies at the level of the physical hardware, operating system, apps as well as the data level.
While we hope that you take the time to watch Paul's full overview, let's summarize some of the highlights of the overall approach.
As Paul demonstrates, an important security measure taken at the physical hardware level is the enforcement of secure-boot. This starts with the removable solid-state drive (SSD) which is keyed to the Trusted Platform Module (TPM) chip on the motherboard.
This approach ensures that if someone tries to inject new code onto the SSD, or if they to switch it out for a different SSD, the Surface Hub will not boot up. Surface Hub importantly also has a custom, locked-down Unified Extensible Firmware Interface (UEFI) with no user interface or API. This provides extra protection from secure boot being disabled. In fact, only genuine Windows Operating Systems will run on the Surface Hub.
At the OS and app levels, notable highlights in Paul's demonstration focus on the safeguarding of app installation to ensure that only approved applications can run on the Surface Hub. Users of Surface Hub by default are standard users. In order to prevent random apps from being installed, device administrator accounts privileges are required to install apps. These apps can only be Universal Windows Apps (UWP) apps, which have been authorized for use with Surface Hub in the Windows Store. UWP apps are sandboxed by design. Device Guard with Windows 10 prevents non-UWP apps from executing on the Hub and blocks scripts or any unapproved executables that may be brought in via USB or the internet.
Also, as Paul shows, peripherals attached to Surface Hub cannot invoke installation of out-of-box device drivers and non-compliant devices are blocked at run-time.
Surface Hub balances the need to keep user sessions active in case participants briefly leave and return to Surface Hub, with the need to remove data and reset the device for new user sessions. The design takes into consideration the risk of data loss from an abandoned session and the risk of subsequent user sessions having access to residual user data on Surface Hub.
The Hub's engineering team has designed the experience so that you have to take deliberate action to end each session with Surface Hub. Pressing the "I'm Done" button or starting a new session resets the Surface Hub device for the next user.
Once the user presses "I'm Done", all information from the session, including browser history, user files and even files copied to the Surface Hub's file system are deleted. Further, all UWP apps are uninstalled and reinstalled, and any credentials are cleared out. As an extra precaution at the end of each day, during the maintenance window specified by IT, the Surface Hub will automatically reset itself and wipe all remaining content (if any) from previous sessions, so that the Hub is ready and in a clean state for the next day.
This covers just a few of the highlights of the top defense in depth strategies behind the design of Microsoft's Surface Hub discussed in today's Microsoft Mechanics episode but it's worth checking out Paul's richer demonstration for a more comprehensive overview.
You can also learn more in our admin guide and for more in the series on Surface Hub design, experience and management, please subscribe to Microsoft Mechanics and follow us on @MSFTMechanics for further commentary.
Ahead of the Industry's annual security gathering at the RSA conference next week, today Principal Program Manager Lead for Surface Hub, Paul Barr, walks us through the top Defense-in-Depth strategies behind the design of Microsoft's Surface Hub. As a communal device, the engineering team had the challenge of maintaining the Surface Hub user friendly and ready-to-use multi-media experience without compromising on security.
In today's Microsoft Mechanics demo bench video, Paul explores potential attack vectors to illustrate Surface Hub's security strategies at the level of the physical hardware, operating system, apps as well as the data level.
While we hope that you take the time to watch Paul's full overview, let's summarize some of the highlights of the overall approach.
Defense at the physical hardware level
As Paul demonstrates, an important security measure taken at the physical hardware level is the enforcement of secure-boot. This starts with the removable solid-state drive (SSD) which is keyed to the Trusted Platform Module (TPM) chip on the motherboard.
This approach ensures that if someone tries to inject new code onto the SSD, or if they to switch it out for a different SSD, the Surface Hub will not boot up. Surface Hub importantly also has a custom, locked-down Unified Extensible Firmware Interface (UEFI) with no user interface or API. This provides extra protection from secure boot being disabled. In fact, only genuine Windows Operating Systems will run on the Surface Hub.
Defense at the OS and app levels
At the OS and app levels, notable highlights in Paul's demonstration focus on the safeguarding of app installation to ensure that only approved applications can run on the Surface Hub. Users of Surface Hub by default are standard users. In order to prevent random apps from being installed, device administrator accounts privileges are required to install apps. These apps can only be Universal Windows Apps (UWP) apps, which have been authorized for use with Surface Hub in the Windows Store. UWP apps are sandboxed by design. Device Guard with Windows 10 prevents non-UWP apps from executing on the Hub and blocks scripts or any unapproved executables that may be brought in via USB or the internet.
Also, as Paul shows, peripherals attached to Surface Hub cannot invoke installation of out-of-box device drivers and non-compliant devices are blocked at run-time.
Defense at the data level
Surface Hub balances the need to keep user sessions active in case participants briefly leave and return to Surface Hub, with the need to remove data and reset the device for new user sessions. The design takes into consideration the risk of data loss from an abandoned session and the risk of subsequent user sessions having access to residual user data on Surface Hub.
The Hub's engineering team has designed the experience so that you have to take deliberate action to end each session with Surface Hub. Pressing the "I'm Done" button or starting a new session resets the Surface Hub device for the next user.
Once the user presses "I'm Done", all information from the session, including browser history, user files and even files copied to the Surface Hub's file system are deleted. Further, all UWP apps are uninstalled and reinstalled, and any credentials are cleared out. As an extra precaution at the end of each day, during the maintenance window specified by IT, the Surface Hub will automatically reset itself and wipe all remaining content (if any) from previous sessions, so that the Hub is ready and in a clean state for the next day.
This covers just a few of the highlights of the top defense in depth strategies behind the design of Microsoft's Surface Hub discussed in today's Microsoft Mechanics episode but it's worth checking out Paul's richer demonstration for a more comprehensive overview.
You can also learn more in our admin guide and for more in the series on Surface Hub design, experience and management, please subscribe to Microsoft Mechanics and follow us on @MSFTMechanics for further commentary.