windows server 2012 hyper-v - ncsc site · security procedures windows server 2012 hyper-v issue...

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

Upload: hakhue

Post on 23-Jun-2018

220 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

October 2015 Issue No: 1.1

Security Procedures

Windows Server 2012

Hyper-V

Page 2: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

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

Page 3: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

Page 3

Windows Server 2012 Hyper -V

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. The Security Procedures come from a detailed technical assessment carried out on behalf of CESG. They do not

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.

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

[email protected] Tel: 01242-709141

CESG welcomes feedback and encourage readers to inform CESG of their experiences, good or bad in this document. Please email [email protected]

Page 4: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

Page 4

Windows Server 2012 Hyper -V

Contents:

Chapter 1 - Outline Description ................................................................................ 5

Product Summary ..................................................................................................... 5 Certification ............................................................................................................... 5 Components ............................................................................................................. 5

Chapter 2 - Security Functionality ........................................................................... 6

Hyper-V .................................................................................................................... 6 Windows Server 2012............................................................................................... 6 Security Domains ..................................................................................................... 7

Chapter 3 - Secure Operation ................................................................................... 8

Introduction ............................................................................................................... 8 Pre-installation .......................................................................................................... 8

Installation ................................................................................................................ 8 Configuration ............................................................................................................ 9

Operation ................................................................................................................ 11 Maintenance and Updates ...................................................................................... 11 System logs ............................................................................................................ 12

Multiple Virtualisation Products ............................................................................... 12 Multiple Security Domains ...................................................................................... 12

System Administration ............................................................................................ 13 System Accreditation .............................................................................................. 13

Chapter 4 - Security Incidents ................................................................................ 14

Incident Management ............................................................................................. 14

Chapter 5 - Disposal and Destruction .................................................................... 15

References ............................................................................................................... 16

Glossary ................................................................................................................... 17

Page 5: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

Page 5

Windows Server 2012 Hyper -V

Chapter 1 - Outline Description

Product Summary

1. Microsoft Windows Server 2012 is the 6th release of Windows Server. It is the server version of Windows 8 and succeeds Windows Server 2008 R21.

2. 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 website2.

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

http://www.microsoft.com/about/legal/en/us/IntellectualProperty/Trademarks/EN-US.aspx are trademarks of the Microsoft group of companies. 2 CPA website address: http://www.cesg.gov.uk/servicecatalogue/CPA/Pages/CPA.aspx

Page 6: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

Page 6

Windows Server 2012 Hyper -V

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 2012

11. 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 7: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

Page 7

Windows Server 2012 Hyper -V

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 8: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

Page 8

Windows Server 2012 Hyper -V

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 9: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

Page 9

Windows Server 2012 Hyper -V

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. Out-of-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 10: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

Page 10

Windows Server 2012 Hyper -V

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 11: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

Page 11

Windows Server 2012 Hyper -V

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 12: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

Page 12

Windows Server 2012 Hyper -V

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 non-virtualised architecture.

Page 13: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

Page 13

Windows Server 2012 Hyper -V

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 14: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

Page 14

Windows Server 2012 Hyper -V

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 2012.

Page 15: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

Page 15

Windows Server 2012 Hyper -V

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 16: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

Page 16

Windows Server 2012 Hyper -V

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] CPA Security Characteristic, Server Virtualisation, CESG, ID18939561, Version

1.21, May 2012 (available from www.cesg.gov.uk/servicecatalogue/CPA)

[b] Installing Windows Server 2012, http://technet.microsoft.com/en-us/library/jj134246.aspx

[c] Microsoft File Checksum Integrity Verifier, http://support.microsoft.com/default.aspx?scid=kb;en-us;841290.

[d] Microsoft Security Compliance Manager, Windows Server 2012 Security Baseline, http://technet.microsoft.com/en-us/library/jj898542.aspx.

[e] CESG IA Implementation Guide No. 3, User Authentication Systems – latest issue available from the CESG website.

[f] Hyper-V Security Guide, http://www.microsoft.com/en-gb/download/details.aspx?id=16650

[g] Automount Guidance, http://technet.microsoft.com/en-us/library/cc753703.aspx

[h] Hyper-V FAQ, http://technet.microsoft.com/en-us/library/dd744892(v=WS.10).aspx#BKMK_10.

[i] CESG Good Practice Guide No. 7, Protection from Malicious Code – latest issue available from the CESG website.

[j] How to Keep Windows up-to-date, http://support.microsoft.com/kb/311047

[k] CESG Good Practice Guide No. 13, Protective Monitoring for HMG ICT Systems – latest issue available from the CESG website.

[l] HMG IA Standard No. 5, Secure Sanitisation – latest issue available from the CESG website.

Page 17: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

Page 17

Windows Server 2012 Hyper -V

Glossary

ASLR Address Space Layout Randomisation

CPA Commercial Product Assurance

CPU Central Processing Unit

DEP Data Execution Protection

DSO Departmental Security Officer

DVD Digital Video Disk

EPT Extended Page Table

GPG Good Practice Guide

HMG Her Majesty’s Government

IA Information Assurance

ICT Information and Communications Technology

ISO Term used to represent an archive file of an optical disc

LAN Local Area Network

MSDN Microsoft Developer Network

OS Operating System

RVI Rapid Virtualisation Indexing

SC Security Characteristics

SCM Security Compliance Manager

SCVMM System Center Virtual Machine Manager

SHA Secure Hash Algorithm

SLAT Second Level Address Translation

SSH Secure Shell

TLS Transport Layer Security

VA Virtualisation Administrator

VHD Virtual Hard Disk

VM Virtual Machine

VMM Virtual Machine Manager

VPN Virtual Private Network

UK United Kingdom

US United States

Page 18: Windows Server 2012 Hyper-V - NCSC Site · Security Procedures Windows Server 2012 Hyper-V Issue No: 1.1 October 2015 This document describes the manner in which this product should

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)1242 709141 Email: [email protected] © Crown Copyright 2015.