Security considerations for common enterprise IT decisions
Guidance for organisations when making decisions about the design and operation of enterprise IT services which handle OFFICIAL information.
This guidance will be expanded and updated during development of the next release based on the feedback and requests we receive.
Let us know the topics you’ve found useful and where you would like more by contacting [email protected].
This paper covers some common security answers to technology questions related to OFFICIAL enterprise IT. The vast majority of user needs for enterprise IT solutions share much commonality. Where there is a similar business context, similar user needs and similar threat, there should be a common approach to technology. The HMG Classifications Policy defines OFFICIAL and the corresponding threat model. While the OFFICIAL tier is broad, it is largely applicable to the technology challenges faced across Government.
In this paper, we’ve identified some of the typical technology decisions that are made during the design and implementation of enterprise IT services. For some of these technology decisions we include a typical approach to follow; for others we provide important security considerations. This paper should be read in the context of a wider suite of CESG guidance, which places greater emphasis on better management of cyber security risks when making technology decisions - rather than simply focussing on process. When making these technology decisions, security will be considered alongside other important factors such as usability, cost, strategic fit, local policies and compliance.
Although this guidance is intended to support common technology decisions for the majority of services, the decision is always yours to make. If there is something unique or specific about your situation we recommend that you gain a deeper understanding of the security implications and seek expert advice if you need to.
A range of complementary guidance is now available at GOV.UK in support of this:
CESG is in the process of consolidating this next generation of IA advice and guidance on a new web platform. We will continue to produce concise, relevant and digestible advice on how to tackle common technology questions posed across Government. Please take a look at our [How to approach technology and information risk management] guide, which provides guidance on the effective management of risk regardless of the method used.
An example enterprise IT service
There are many different ways in which your enterprise IT system can be built and configured, and it is for you to decide how best to do so. However, to help describe security considerations for common enterprise IT decisions it helps for us to be able to refer to a typical enterprise IT service. The diagram above depicts an example logical architecture, showing some of the basic components of a typical enterprise IT service which supports remote access.
In a typical scenario we expect:
- smartphones, laptops and tablets to be issued to a single user for their sole use
- end user devices to connect to an enterprise network over various untrusted networks, such as the internet or mobile networks
- all traffic from end user devices to the corporate network to be encapsulated in a VPN
- the user to interact with many services, including those internal to the enterprise, within the government community, or public cloud services. The connections to all of these are made via the enterprise.
Common decisions related to users
Can I reduce the number of passwords my users have to enter?
Yes, more passwords does not mean better security.
Help users by designing a chain of trust into your systems to allow implicit authentication of the user to different services from a previous authentication mechanism. Single sign-on (SSO) technologies can also reduce the burden on users by authenticating them once and then brokering access to other services, without further user interaction.
You can reduce the number of authentication prompts a user receives by holistically considering how:
- the user authenticates to a device
- the device authenticates to the network
- the user authenticates to services
Example
If a user unlocks their encrypted laptop by authenticating with a short password and a USB token, and the laptop authenticates to the enterprise VPN (without any user interaction) using a certificate on the device, then the user is implicitly authenticated to the VPN service because their device certificate is only available after the laptop was unlocked.
Do I need to use two-factor authentication?
You should strongly authenticate users before granting them access to sensitive data or privileged functions, using two-factor authentication is a good way to achieve this.
When two-factor authentication is used well, it can enhance the user experience of your service, for example by allowing shorter and more memorable passwords. You can further enhance user experience and security by using this strong authentication as part of a chain of trust or single sign-on mechanism.
Two-factor authentication also makes it harder for attackers to mount successful attacks by compromising user credentials. Instead of being able to simply replay a captured password, an attacker needs to hijack an already-authenticated session or compromise both authentication factors.
Do my software developers need administrative privileges on their devices?
No, most activities associated with software development do not require local administrative (or ‘root’) privileges.
Identify why the developers desire administrative access and address those issues first. For example, consider relaxing specific security controls such as application whitelisting. Providing a good modern toolset for them and responding quickly to their requirements, so that they do not need to install additional software, can also help.
When it is necessary to grant administrative privileges, for example to enable certain debugging modes for testing, use virtualisation to provide a separated environment. You can minimise the exposure to malware by restricting native internet access, including email, from testing environments. The impact of a successful attack can be minimised by using a local device account that does not have access to corporate data and services.
Common decisions related to end user devices
Can I use end user device platform X? Can I use web browser Y?
Yes, you can use any but you should understand the risks of doing so. We have guidance to help with each of these choices.
Platforms and browsers are not simply secure or insecure; the security of each is multi-faceted. We’ve developed sets of security principles and configuration guidance for each that can be used to compare the risks of selecting different options.
To help make your decision, please see the relevant guidance:
Can I use mobile device management solution X?
Yes, you can use any, but you should understand the risks of doing so. We set out the most important considerations below.
Mobile device management solutions are used to remotely configure and audit devices. They typically require client and server components although they do not necessarily have to be supplied by the same vendor.
When deciding which solution to deploy you should consider:
- the supported features and policies that you need (our per-platform security guidance provides some recommendations)
- whether to deploy ‘on-premise’ or ‘in the cloud’ (if you are considering a cloud-based MDM service, use our cloud security principles to structure your assessment of it)
- what independent assurance you need (if any)
- the vendor’s reputation and security track record
Should I allow users to connect their personal devices to my enterprise IT services? Can I do BYOD?
We can’t directly answer this for you. Think about what information and services, if any, you want staff to be able to access using their own devices. It’s your responsibility to protect the data, not the device owners’.
You could consider other ownership models, such as ‘choose your own device’, that achieve your business and security needs.
If you want to use a BYOD approach, read our Bring Your Own Device Guidance. It provides information on architectural approaches, device security and enterprise considerations.
Do I require third party antivirus or anti-malware software on all of my end user devices?
We recommend that untrusted content or media from outside your organisation are tested for presence of malicious code before being rendered on end user devices. This testing can be performed within enterprise systems, or depending on the end user device platform, this may be possible on the devices themselves.
Anti-virus or anti-malware products typically aim to identify malicious code and prevent it from running. If your devices are well maintained and configured to only run whitelisted applications then the devices will be harder to attack, particularly if all content accessed by the device has been routed through enterprise-side security services, such as web and email content filtering. If this is the case, then there is limited additional benefit from antivirus or anti-malware software on the devices.
If your devices are running legacy platforms, are not well configured or maintained, or if content arriving at the device has not been subjected to enterprise-side content scanning, then you should deploy third party antivirus or anti-malware software to the device. More information on this topic can be found in the Enterprise Considerations section of the End User Devices Security and Configuration Guidance.
Should I allow end user devices to connect through captive portals?
No, for the majority of users this isn’t appropriate. Allowing the use of captive portals increases the risk of malware and data transmitted from a device being intercepted. It also increases the risk of a device being attacked by malware; Kaspersky recently identified an attack on a hotel’s guest Wi-Fi network.
Being able to access a captive portal means the device has direct internet access and isn’t protected by your network-based monitoring tools, which help to detect and prevent attacks.
If you need to allow end user devices to connect through captive portals, reduce the risk by ensuring that the browser and operating system are patched and educating users to establish a VPN session as soon as possible.
Do I need to use a VPN for users working away from the office?
Yes. A device-wide VPN will provide the best level of protection for information as it travels over an untrusted network. It also ensures that all communications benefit from the protections provided within the enterprise, such as web content filtering.
Without a VPN, it is technically possible for the same level of protection to be afforded to data in transit between the enterprise and the device, but every individual application would need to be evaluated to ensure it adequately protects the confidentiality and integrity of data in transit.
Without a device-wide VPN, it is difficult to ensure that all communications to and from the device are routed via the enterprise. It is difficult to gain a high degree of confidence that the device has not been attacked or compromised by unmonitored communications. It is also not possible to constrain the sites and services accessed by users, which may have legal or HR implications.
We recommend you use a VPN product or component which you are confident in the design and implementation of. One way of getting that confidence is to use one of the VPN products that have been assessed through the Commercial Product Assurance to have the characteristics of a well-designed and implemented VPN gateway or VPN client.
Should I use a TLS or IPsec VPN?
Either can be configured to be good enough. Both IPsec and TLS (often incorrectly referred to as SSL, a legacy protocol) can be configured to protect the integrity and confidentiality of data; the choice is predominately an architectural decision.
IPsec
IPsec is an open standard which fully supports the design described above. Because it’s an open standard it is possible to use standards-compliant VPN clients from one vendor with standards-compliant VPN gateways from a different vendor. This is useful if you want to avoid vendor lock-in or have a single VPN gateway that supports multiple device platforms. When choosing cryptographic parameters, we recommend using the PSN End State cryptographic profile.
TLS
For TLS VPN gateways there are no recognised standards for part of the communications (specifically how IP packets are encapsulated within TLS). Vendors have each taken a proprietary approach to designing their products. If suitable cryptographic parameters are set for the TLS VPN, then the encapsulation method should have minimal impact on the cryptographic security of the VPN. We recommend using Combination 1 of the Suite B profile for TLS.
Common decisions related to services
Can I store OFFICIAL data in a public cloud service?
Yes. Use the Cloud Security Principles to help you assess the risks and decide you are comfortable with them.
There are a wide range of cloud services available, with different levels of security maturity. There is also a wide range of OFFICIAL data which may need different protections or have contractual or legal limitations on where it can be processed or stored.
Use the Cloud Security Principles to structure your assessments of the security properties for a shortlist of options. Choose a service which offers you an adequate level of confidence in its implementation of the security principles that you care about. Since services and the threats to your data change over time, it’s important to review your choice on a regular basis.
Configuration guidance for Google Apps for Work and Microsoft Office 365 has been created as a response to a request for guidance on cloud services from a government department. They should not be read as an endorsement of these particular services - you will still need to assess the risks against your requirements when choosing a service.
Should I rely on the security of WPA2 to protect data in my enterprise Wi-Fi network?
No, in most scenarios we recommend the use of a VPN to protect your data.
Due to weaknesses in many common configurations of WPA2, and the difficulty in gaining confidence in implementation of cryptography in wireless access points, we recommend that a VPN is used to protect the confidentiality and integrity of data passing over enterprise Wi-Fi networks.
Another aspect besides the confidentiality and integrity of the data is the control of access to the network. Many organisations will wish to authenticate devices before allowing them to join the network, for example, to ensure staff are able to connect and receive a good level of service. WPA2 is recognised as the best available standard for authenticating devices to the Wi-Fi network.
When deploying WPA2 it is best practice to configure it in ‘Enterprise mode’ (also referred to as 802.1X). In this mode, individual clients should be issued individual certificates for authentication, meaning that no client should be able to decrypt the communications sent to another client.
It is possible to securely operate a guest Wi-Fi network in addition to an enterprise Wi-Fi network using a single set of wireless access points. The different logical wireless networks can use different authentication options, meaning that an Enterprise mode network can be operated for enterprise users as described above, whilst a captive portal can be provided to authenticate guests. For partners with devices which cannot authenticate against a captive portal then bypasses can be put in place on the guest network for the IP addresses of VPN gateways required. This approach prevents the lesser trusted devices from joining the enterprise access network, helping reduce the exposure of enterprise end user devices to attack from external devices.
When do I need to use a CLAS consultant?
The most important thing is to make sure you have people with the right skills and experience working on your project.
The CESG Certified Professional (CCP) scheme defines a number of roles and levels that anyone can be assessed against to prove they have those skills. For difficult technical security problems you might need someone with specialist security knowledge or experience, such as a Security Architect. When you need help understanding and making security decisions around information risk governance, the Security and Information Risk Advisor role would be more appropriate.
The CESG Listed Advisor Scheme (CLAS) is a community of security consultants covering a wide range of specialisms and expertise. All CLAS consultants have assessed CCP skills. Rather than only looking for a “CLAS consultant”, we recommend you look for someone with the right skills and competencies for the particular challenge you have.
Appendix: Cryptographic Profiles
PSN End State Cryptographic Profile
| Module / Algorithm type | Description |
|---|---|
| ESP | |
| Encryption | AES-128 in GCM-128 |
| IKEv2 | |
| Encryption | AES-128 in GCM-128 |
| Pseudo-random function | HMAC-SHA256-128 |
| Diffie-Hellman group | 256bit random ECP (RFC5903), Group 19 |
| Authentication | ECDSA-256 with SHA256 on P-256 curve |
Combination 1 of the Suite B profile for TLS
| Algorithm type | Description |
|---|---|
| Protocol | TLS v1.2 |
| Encryption | AES with 128-bit key in GCM mode |
| Pseudo-random function | TLS PRF (with SHA-256) |
| Authentication | ECDSA-256 with SHA-256 on P-256 curve |
| Key Exchange | ECDH using P-256 curve |