October 2015 Issue No: 1.1. Security Procedures Windows Server 2012 Hyper-V

Transcription

1 October 2015 Issue No: 1.1 Security Procedures Windows Server 2012 Hyper-V

2 Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should be implemented to ensure it complies with the requirements of the CPA security characteristics that it was assessed against. The intended audience for this document is HMG implementers, and as such they should have access to the documents referenced within. If you do not have access to these documents but believe that you have an HMG focused business need, please contact CESG Enquiries. Document History Version Date Comment 1.0 June 2014 First issue 1.1 October 2015 First public release

3 About this document These Security Procedures provide guidance in the secure operation of Windows Server 2012 (in relation to Server Virtualisation). This document is intended for System Designers, Risk Managers and Risk Management Advisors. CESG recommends you establish whether any departmental or local standards, which may be more rigorous than national policy, should be followed in preference to those given in these Security Procedures. replace the need for tailored technical or legal advice on specific systems or issues. CESG and its advisors accept no liability whatsoever for any expense, liability, loss, claim or proceedings arising from reliance placed on this guidance. Related documents The documents listed in the References section are also relevant to the secure deployment of this product. For detailed information about device operation, refer to the Windows Server 2012 product documentation. The Security Procedures come from a detailed technical assessment carried out on behalf of CESG. They do not Points of contact For additional hard copies of this document and general queries, please contact CESG using the following details. CESG Enquiries Hubble Road Cheltenham GL51 0EX United Kingdom enquiries@cesg.gsi.gov.uk Tel: CESG welcomes feedback and encourage readers to inform CESG of their experiences, good or bad in this document. Please enquiries@cesg.gov.uk Page 3

4 Contents: Chapter 1 - Outline Description... 5 Product Summary... 5 Certification... 5 Components... 5 Chapter 2 - Security Functionality... 6 Hyper-V... 6 Windows Server Security Domains... 7 Chapter 3 - Secure Operation... 8 Introduction... 8 Pre-installation... 8 Installation... 8 Configuration... 9 Operation Maintenance and Updates System logs Multiple Virtualisation Products Multiple Security Domains System Administration System Accreditation Chapter 4 - Security Incidents Incident Management Chapter 5 - Disposal and Destruction References Glossary Page 4

5 Chapter 1 - Outline Description Product Summary 1. Microsoft Windows Server 2012 is the 6 th release of Windows Server. It is the server version of Windows 8 and succeeds Windows Server 2008 R Windows Server 2012 (Standard and Datacenter Editions) have the Hyper-V role available to them and it is this which provides the Server Virtualisation functionality. Certification 3. Windows Server 2012 (with patches up to 17 January 2014) has undergone CPA assessment and has been certified as meeting the Foundation Grade requirements as described in the Server Virtualisation Security Characteristic (SC), Version 1.21 (reference [a]). Later versions are automatically covered by this certification until the certificate expires or is revoked, as stated on the product s certificate and on the CPA website 2. Components 4. Windows Server 2012 comprises a number of roles. The role that provides the Server Virtualisation functionality is Hyper-V. 5. A server running Windows Server 2012 should be treated at a security classification commensurate with the highest security classification of data which the device has or will handle. The highest security level (security classification) of the Virtual Machines (VMs) determines the minimum security level of the management operating system and server. 6. Security Compliance Manager (SCM) is a free tool provided by Microsoft that enables products to be quickly configured (i.e. locked down or hardened). SCM provides ready to deploy policies that are based on Microsoft Security Guide recommendations. 7. The basic management of VMs is achieved through Hyper-V Manager. System Center Virtual Machine Manager (SCVMM) provides an enterprise class management tool, designed for the management of large numbers of VMs, Virtualisation Hosts, Storage and Networking associated with virtualisation. 1 Microsoft and the trademarks listed at are trademarks of the Microsoft group of companies. 2 CPA website address: Page 5

6 Chapter 2 - Security Functionality Hyper-V 8. Hyper-V is used in conjunction with Windows Server 2012 (as the operating system in the root partition). It provides a computing environment that allows the creation of VMs within a single computer system where each VM can load and operate an operating system and its applications, very much like the operating system and its application would execute directly on real hardware. 9. Hyper-V provides the following primary security functionality: Access control between partitions and virtualised resources Auditing of security critical events detected by Hyper-V (where the audit records are then submitted to the Windows Server 2012 audit subsystem in the root partition and stored together with audit record created by this instance of Windows Server 2012) Object reuse for all resources managed by Hyper-V Management of the Hyper-V configuration including the configuration of the partitions Maximum quota for defined resources assigned to partitions (CPU time, memory, disk storage) Live migration of partitions from one instance of the product to another instance ensuring the integrity and consistency of the partition being migrated 10. In addition, Hyper-V provides the following architectural properties: Protection against tampering from guest partitions and network devices Separation between the guest partitions Reference mediation for access of guest partitions to protected resources (including virtualised devices) Reference mediation cannot be bypassed Separation mechanism provided by the underlying hardware is maintained when virtualising resources and devices or responding to hypervisor calls for a guest partition Windows Server The Windows Server 2012 instance in the root partition provides the following security functionality which is used by Hyper-V: Identification and authentication of administrative users and users that request to be passed through to a guest partition Management and protection of the audit trail Page 6

7 Access control of administrative users to management objects Access control to files and devices used Management of users and access rights (to Windows Server 2012 objects) Security Domains 12. A virtualisation product only needs to be assured when it is being used to run VMs from different security domains on the same platform (i.e. the virtualisation product forms part of the security boundary). 13. In this context, a security domain refers to one or more VMs sharing a common threat model. 14. Security domains are described as Red or Black (or, similarly, Red side or Black side ), based on terms commonly used in the design of cryptographic systems. The Red side contains the more sensitive data, while the Black side contains the less sensitive data. 15. This document assumes that an attacker will compromise the Black side and that attacks will be against the Red side from the Black side; however, this doesn t rule out data exfiltration from misuse of the Red side. 16. By extension, this document will refer to Red and Black VMs, network cards, networks, data, etc, according to which security domain they are in. 17. Hyper-V does not distinguish between Red and Black VMs and therefore provides symmetric protection. Page 7

8 Chapter 3 - Secure Operation Introduction 18. The following recommendations outline a configuration for Windows Server 2012 that is in line with CPA Security Characteristic, Server Virtualisation (reference [a]). These requirements should be followed unless there is a strong business requirement not to do so. Such instances should be discussed with your Accreditor. 19. The only user accounts to be set up for Windows Server 2012 should be for Virtualisation Administrators (VAs) and these will have full access rights. Guest OSs may have administrators and users but these are different and should not be confused with VAs. More details are provided in the System Administration section within this Chapter. Pre-installation 20. The procurement process for the server hardware for the product must ensure that it meets the Microsoft minimum specification (see reference [b]) and specifies and delivers equipment with: Hardware support for virtualisation, e.g Intel VT-x or AMD-V Support for Second Level Address Translation (SLAT) - only hardware that supports RVI/EPT must be used Support for hardware Data Execution Protection (DEP) - only hardware that supports DEP must be used 21. Before installing the product, a check should be made to verify the authenticity of the installation media or the download contents. Microsoft openly publishes the SHA-1 hash values within the additional details for each product listed on MSDN Subscriber Downloads and the relevant one must be validated against the (ISO image) installation software. A variety of publicly available utilities can be used, including the Microsoft File Checksum Integrity Verifier which can be obtained at reference [c]. The command to be executed for a single file using the File Checksum Integrity Verifier is: fciv -sha1 <filename>. Installation 22. Installation must only be performed by trained, knowledgeable and authorised personnel. Details regarding installing the product are given in reference [b]. 23. Physical access to the server hardware should be restricted to authorised personnel only. 24. Physical access to the management network should also be restricted to authorised personnel only (thus preventing an unauthorised person connecting an unauthorised device to it). Page 8

9 25. A Server Core installation of Windows Server 2012 should be used for the management operating system. A Server Core installation provides the smallest attack surface and reduces the number of patches, updates, and restarts required for maintenance. 26. The host management network should be treated as a segregated Red network or as a separate network altogether. Preferably it should be on a separate network and a dedicated network adapter should be used which should not be exposed to untrusted network traffic. VMs should not be allowed to use this network adapter. 27. Note that a special VM (the root partition) for managing the product is considered part of the host software and as such must only be connected to the management network, not the regular Red client network. Similarly, ordinary VMs must not be connected to the management network. 28. The management operating system should be hardened using the baseline security setting recommendations in the Windows Server 2012 Security Compliance Management Toolkit (see reference [d]). 29. The Hyper-V component should be hardened using the baseline security setting recommendations in the Security Compliance Management Toolkit (see reference [d]). 30. Only drivers that have been through the Microsoft driver verification program should be used on the product. These will have the correct signature and logo to demonstrate that they have successfully been evaluated. Drivers that do not have the signature and logo should not be used. 31. Software applications, that are not required for virtualisation support or the management of Hyper-V, must not be run in the management operating system, i.e. unnecessary software must not be installed in the root partition. 32. During installation, the host software and all essential VMs must have guaranteed resources allocated to them (which are sufficient to prevent the host software and any essential VMs from being denied access to necessary resources to operate). 33. Any out-of-band management technology should be passphrase-protected. Outof-band access must be secured using access controls provided by the supplying vendor of the out-of-band management technology. Further guidance on this subject is given in CESG Implementation Guide No. 3 (IG 3), User Authentication Systems (reference [e]). Configuration 34. Shared VHDs should be configured so that only VMs in the same security domain can access each data item. VMs in different security domains must not share VHDs (unless they have been specifically approved to do so by the relevant authority). VHDs are only permitted to store data from multiple security domains if they have been approved to do so. Page 9

10 35. The system must be configured such that only VAs, or other authorised personnel, can make network configuration changes. Further information on this subject is given in the Microsoft Hyper-V Security Guide (reference [f]). 36. ASLR is enabled by default on installation of the product. It must not be disabled afterwards. 37. Integration services should be installed on all VMs. The accuracy of timestamps and audit log entries is important for computer forensics and compliance. Integration services ensure that time is synchronised between VMs and the management operating system. 38. Quotas should be applied to files created by a Guest OS. Quotas should be employed on all file-systems holding virtual disk files. 39. The following recommendations relate to creating and configuring VMs: VMs should be configured to use fixed-sized VHDs, or if dynamically expanding VHDs are used, an appropriate maximum limit must be set VHDs and snapshot files should be stored in a secure location where only VAs can access them. A snapshot is a point in time image of a VM s state that can be returned to later Implementers should decide how much memory to assign to a VM (memory on the physical computer is apportioned to all of the VMs on the server, including the virtual machine running the management operating system, so assigning an appropriate amount of memory to each VM is important to ensure the continuing availability of all VM resources. The amount of memory to assign will depend on the workload of the VM, how much physical memory is available on the computer, and how much memory other VMs running on the same computer are using) Implementers should impose limits on processor usage (by default, Hyper- V does not limit the amount of processing power used by VMs. A compromised VM that can use all of the processing power on the physical computer could cause the computer and other VMs running on it to become unresponsive. The precise number of logical processors to use and the limits that should be imposed on them depend on the workload they perform, the number of physical processors and cores installed on the physical computer, and the amount of processor power required by other VMs running on the same computer. To ensure continuing availability of all VM resources, processor usage should be monitored and the limits adjusted accordingly) Implementers should configure the virtual network adapters of each VM to connect to a network in the correct security domain to isolate network traffic as required Page 10

11 Implementers should configure only required storage devices for a VM (each VM should be given access to the physical hard disks, VHDs, and removable storage devices that it needs, and no others. If a VM does not require access to a resource like a CD/DVD drive except when installing software say, the virtual drive should be removed or None selected as the media when it is not in use) Operation 40. VMs should be configured and managed, as far as practicable, as if they were real machines. The host, as a real machine, should also be managed appropriately. For example, system patching, administration of accounts and maintenance of anti-virus software, should all be performed as if the machine were a physical machine. 41. The same security measures and hardening that would normally apply to a physical computer should be applied to all VMs. 42. Removable storage devices should be prevented from being automatically mounted. This also includes devices other than drives that have a storage capability: they must not be auto-mounted, to prevent any attack based on writing to the device from one VM and auto-mounting it from another (see reference [g] for details on how to perform this in Hyper-V). In each Guest OS, the automatic mounting, reading or playing of removable media must be disabled. USB devices are not supported in Hyper-V (see reference [h]) for further information. 43. Security classifications of removable media should be recorded, and users instructed on the correct handling. Users must not write to removable media from one VM and then read from another VM in a different security domain. 44. VM snapshots must not be used or relied on as a form of data backup. Maintenance and Updates 45. The latest version of the product should be used ( latest version here means that it is updated with the most recent security patches). Therefore product updates should be applied as soon as is possible. Further guidance on this is provided in CESG Good Practice Guide No. 7 (GPG 7), Protection from Malicious Code (reference [i]). Details on the Windows Update process are provided in reference [f]. 46. The product should be configured to use either the Windows Update process or the Windows Software Update Services (WSUS) process. 47. VMs should be fully updated (i.e. patched) before they are deployed in a production environment. 48. All VMs must be kept up to date with operating system, application, and antivirus updates as appropriate. Page 11

12 System logs 49. Adequate space should be allocated and maintained for host log files to grow. VAs should configure, monitor and manage system log files and disk space. Action must be taken if the log files threaten to outgrow the space available, e.g. archive old logs or increase the disk space. 50. Audit logs must be regularly reviewed for unexpected entries. Further guidance on this matter is provided in CESG Good Practice Guide No. 13 (GPG 13), Protective Monitoring for HMG ICT Systems (reference [k]). Multiple Virtualisation Products 51. To mitigate the risk of running one virtualisation product on another (if both are operating at multiple security domains), different Foundation Grade virtualisation products should be used to reduce the risk of a cascade exploit. However, running one virtualisation product on another should be avoided if at all possible. Hyper-V will not run on top of another instance of Hyper-V. 52. To mitigate the risk of a network cascade when using several virtualisation products on connected networks, the deployment is required to use different Foundation Grade virtualisation products. Multiple Security Domains 53. The product should use separate physical network cards for networks belonging to different security domains. Where this is not possible, assurance that the network traffic will be kept separate needs to be obtained in another way, e.g. an assured VPN product. 54. A VM must not be directly connected to a VM in another security domain; it may be indirectly connected, provided such a connection would be acceptable in a non-virtualised architecture. 55. The transfer of data between VMs in different security domains should be avoided except when operationally required/necessary. In this case, staff must follow the instructions on how data is to be moved (including virus scanning, potentially downgrading data, etc). 56. Separate instances of services, provided to multiple VMs running in different security domains, should be created. No service should cross-connect different security domains except via a connection (such as content inspection) that would be acceptable in a non-virtualised architecture. 57. The host must be configured such that it cannot pass data between networks in different security domains. It is acceptable for information about network traffic to be logged on the management network, provided the traffic itself is not routed directly to the management network. 58. A VM must not connect to a network in a different security domain except via a connection (such as content inspection) that would be acceptable in a nonvirtualised architecture. Page 12

13 System Administration 59. The only users to be defined for Windows Server 2012 (in the root partition) should be VAs and these will be set up with full access rights (e.g. restore, migrate and configure partitions). Guest OSs may have administrators and users but these are different and should not be confused with VAs. 60. Authorised administrators of the product (VAs) are assumed to be knowledgeable (i.e. experienced and having the skills to administer the product), cleared to access all material on the host, trustworthy to follow the guidance and not misuse their privileges. It is also assumed that properly trained and trusted administrators will create and manage the configuration data of partitions. 61. The administrative interface for the virtualisation product, whether local or remote, acts as a bridge across all VMs (and hence security domains), and therefore should be treated as the most security sensitive interface on the system (this should be considered a Red interface). It should only be used for administration of the virtualisation product, and should not be used for the normal administration of services provided by the VMs. For the same reason, it should only be remotely accessible through its own dedicated network. 62. Administering software within a VM and the virtualisation management operating system are separate roles that need separate accounts. VM administrators should not be given permissions on the management operating system unless there is a business need (and all of the other VA requirements are met). 63. VAs must not enable program exceptions to DEP and must not reduce DEP coverage to only essential Windows Programs and Services. 64. The ability to change a VM s power state should be restricted to specifically authorised users (i.e. those with a business need). In some circumstances, this could be all of the VM s users. System Accreditation 65. Accreditors should be familiar with the recommendations and guidance. Page 13

14 Chapter 4 - Security Incidents Incident Management 66. In the event of a security incident that results in the compromise of information protected by Windows Server 2012, the local IT security incident management policy should ensure that the Department Security Officer (DSO) is informed. 67. Any security incidents should be managed in accordance with the local accredited security incident management procedures and policies. 68. Contact CESG if a compromise occurred that is suspected to have resulted from a failure of Windows Server Page 14

15 Chapter 5 - Disposal and Destruction Routine Destruction of Equipment 69. Disposal and destruction of equipment (e.g. server hardware, network devices, etc) must be in accordance with HMG policy and guidance, including preliminary sanitisation before it is sent for disposal or destruction. See HMG IA Standard No. 5, Secure Sanitisation (reference [l]). Page 15

16 References Unless stated otherwise, these documents are available from the CESG website. Users who do not have access should contact CESG Enquiries to enquire about obtaining documents. [a] [b] [c] [d] [e] [f] [g] [h] [i] [j] [k] [l] CPA Security Characteristic, Server Virtualisation, CESG, ID , Version 1.21, May 2012 (available from Installing Windows Server 2012, Microsoft File Checksum Integrity Verifier, Microsoft Security Compliance Manager, Windows Server 2012 Security Baseline, CESG IA Implementation Guide No. 3, User Authentication Systems latest issue available from the CESG website. Hyper-V Security Guide, Automount Guidance, Hyper-V FAQ, CESG Good Practice Guide No. 7, Protection from Malicious Code latest issue available from the CESG website. How to Keep Windows up-to-date, CESG Good Practice Guide No. 13, Protective Monitoring for HMG ICT Systems latest issue available from the CESG website. HMG IA Standard No. 5, Secure Sanitisation latest issue available from the CESG website. Page 16

17 Glossary ASLR CPA CPU DEP DSO DVD EPT GPG HMG IA ICT ISO LAN MSDN OS RVI SC SCM SCVMM SHA SLAT SSH TLS VA VHD VM VMM VPN UK US Address Space Layout Randomisation Commercial Product Assurance Central Processing Unit Data Execution Protection Departmental Security Officer Digital Video Disk Extended Page Table Good Practice Guide Her Majesty s Government Information Assurance Information and Communications Technology Term used to represent an archive file of an optical disc Local Area Network Microsoft Developer Network Operating System Rapid Virtualisation Indexing Security Characteristics Security Compliance Manager System Center Virtual Machine Manager Secure Hash Algorithm Second Level Address Translation Secure Shell Transport Layer Security Virtualisation Administrator Virtual Hard Disk Virtual Machine Virtual Machine Manager Virtual Private Network United Kingdom United States Page 17

18 CESG provides advice and assistance on information security in support of UK Government. Unless otherwise stated, all material published on this website has been produced by CESG and is considered general guidance only. It is not intended to cover all scenarios or to be tailored to particular organisations or individuals. It is not a substitute for seeking appropriate tailored advice. CESG Enquiries Hubble Road Cheltenham Gloucestershire GL51 0EX Tel: +44 (0) enquiries@cesg.gsi.gov.uk Crown Copyright 2015.