Windows 10 Rollout Programme Key decision points for consideration 1. Folder Redirection 2. Admin Rights 3. Roaming Profiles 4. Data Ownership W10 - Key Decision 1 - Folder Redirection We are consulting with College and Service Group Representatives on Folder Redirection for Windows 10 as follows: 1) Please respond by accepting the only offered solution option 1 below 2) Or by rejecting with reasons for that response. Options: Option 1 – Folder redirection ON for desktop clients but OFF for mobile clients. This is the same as the existing SD7 “Windows 7” and “MDSD Windows 8” folder redirection configuration. This “option” is recommended by the service team. W10 - Key Decision 2 - Admin Rights 1) Please respond by choosing one or more from the options presented below. 2) Or by rejecting all options with reasons for that response. Option 1 – Admin rights for end users are enabled on request, are not reviewed, and are rarely revoked. This is the current solution. Enables users to install any application they want, which means that: The estate is vulnerable to threats posed by Potentially Unwanted Applications (PUAs). Applications which install to provide some stated function but modify the OS in unknown ways, e.g. install as search toolbar but harvest web activity. The estate is vulnerable to threats from unmanaged applications. E.g. Applications dependant on insecure versions of Java, Flash or .Net. End user’s files, data and information is unprotected. E.g. PUA’s which inspect html traffic on client and inject paid advertisements. Enables users to change a range of setting on a device, which means that: The state of estate is uncontrolled and unknown. The estate cannot be efficiently managed or supported. Ensures that UoE cannot be compliant with certain InfoSec standards, which means that: UoE will be ineligible for some business opportunities. UoE operates W10 with higher than desirable level of risk. This option is not recommended by the service team. Option 2 – Admin rights for end users are off. Fits strictly with principle of least privilege. [See Background, Proposal and Notes below]. All applications would need to be packaged and delivered via the Software Catalogue. Packaging all applications in use within the University would be a monumental task that would have a negative bearing on the project delivery timelines. In the short to medium term, end users with a requirement to run a non-packaged applications must either: 1. Arrange for that application to be packaged 2. Package the application with local resources to a quality determined by ISG 3. Wait for option 3, 4 or 5 to become available. In the medium term this option will become unworkable for a range of devices/users forcing them to become Self Supported. This option is recommended by the service team for early adopters. This option is not recommended for service. Option 3 – Develop a self-service, authorised, temporary enabling of admin rights for end users in accordance with Info Sec policy Reduces the threat opportunity to a limited time window: 1 day of admin rights per year reduces the threat opportunity to 0.3% of the time for a single device. We would need to investigate options to allow the end user to request Administrative rights for a limited period so that any additional exposure to risk is for a very minimal period. We can envisage a service and technical solution with these features: A request and authorisation application; in the SCCM Software Center (similar to application approval process). A request process where requesters confirm compliance with regulations and InfoSec policy, e.g. o confirm completion of required training: Security Essential training is mandatory for new and existing staff o an undertaking to use additional privileges in accordance with regulations and policy o acknowledging a reminder of their increased vulnerability to common threats An approval process where requests are authorised by line managers or other responsible persons Automated revoke of admin rights, e.g. daily at 00:01 hours This option is recommended by the service team. Option 3a – Admin rights for relatively few end users are permanently enabled, are managed, and maybe revoked This a significantly more controlled and limited use version of Option 1 that is additional to Option 3. We will need to assess the individual requirement for admin rights as part of the preparation to migrate to W10 for each area. We can envisage a service and technical solution with those with admin rights will need to periodically confirm compliance with regulations and InfoSec policy, e.g. confirm completion of required training confirm awareness of their increased vulnerability to common threats undertake to use additional privileges in accordance with regulations and policy This option is recommended by the service team. Option 4 – Investigate alternative technology. This is the preferred long-term solution. Identify, purchase and implement a commercially available product which would be fully-featured / updated and maintained by a third party. This option is recommended by the service team. Background The Administrator account gives the user full control of all files, directories, services, and other resources that are under the control of the local computer. The Supported Desktop has previously held the position that there should be, at most, limited granting of administrative rights. However, the final decision on granting administrative rights was left to the discretion of the local computing officer or manager of unit computers. The Windows 10 operating system is designed to be usable by a user possessing a standard user access token [See note 1]. It is not a requirement that users be granted administrative rights. A library of user requested software is made available via the “Application Catalog”. Installation of this software via the “Application Catalog” does not require administrative rights. Proposal Therefore, in conjunction with InfoSec, SDX proposes that the “Principle of least privilege” [See Note 2] is implemented, whereby users are granted a standard user token by default. Also, SDX proposes that methods and processes are brought into being which facilitate the managed granting of admin rights to end users where deemed necessary. This proposal is based on the following: 1) Protection of end users, devices and data both directly, from own actions, and indirectly from other’s actions, e.g. an infected machine on local network. [See note 3]. Estimates vary, but conservatively, running with a non-admin account mitigates against over 90% of Microsoft critical vulnerabilities. The most basic tenent of endpoint protection being 1) Patching 2) Anti-Malware 3) “Non admin” account. 2) The Principle of least privilege provides support benefits through increased consistency and automation opportunities. Administrative rights may lead to divergence of endpoint devices. For example, Microsoft Analytics has revealed the installation of competing anti-malware products with the existing Supported Desktop. Consistent data storage paths (e.g. only offline storage permitted) also offers a huge benefit particularly in the areas of data resilience (e.g. hardware failure) & OS migration. 3) SDX recognises that there are situations where Administrative rights may lessen the support burden of specific devices. For example, Administrative rights for laptop devices used in the field where access to support is not available. 4) Similarly, there may be issues with specific software requiring Administrative rights to be fully functional. For example, Veracrypt and MirrorOp. Notes [1] Standard User vs Admin User Windows Implementation. As part of the logon process to a Windows computer the logging on user is granted an access token. This token is used by the operating system to determine the Windows objects the user is permitted to access and what subsequent actions the user is permitted to carry out. For example, a Windows object can be an NTFS file and based on the user’s access token the user can read and add data to that file. Whereas a user with a differing token may read the file but is not able to make changes to its contents. Within Windows there are two classes of tokens, “standard user tokens” and “administrative user tokens”. Administrative user tokens have full rights over the all the operating system and whereas standard user tokens are limited in their scope. Users logging in with an account which is a member of the “Local Administrators” group on that machine are granted an administrative token. If the account is not a member of the “Local Administrators” group they are granted a standard token. [2] Principle of least privilege “When applied to users, the terms least user access or least-privileged user account (LUA) are also used, referring to the concept that all user accounts at all times should run with as few privileges as possible, and also launch applications with as few privileges as possible.” https://en.wikipedia.org/wiki/Principle_of_least_privilege [3] Mitigation https://www.avecto.com/news-and-events/news/removing-admin-rights-mitigates-97-of-critical- microsoft-vulnerabilities [4] Many valid requirements for end user having admin rights 1) Install software 2) Run installed software (which, say, requires direct access to OS (e.g. Visual Studio) or direct access to drivers/hardware) e.g. If we say to laptop users that they should install their own drivers, we have to give them means to do so. Also, NVidia, for example, releases driver update often