Serving up some server advice

Before we get to the guidance, it's worth noting that the apparent lack of server-specific guidance isn’t an oversight. We’ve been thinking about what we can usefully do in this area for quite a while.

However this is a thorny problem once you really dig into it. Servers can vary enormously in configuration, workload, and security posture, so it’s very hard to produce meaningful step-by-step guidance as we do for end-user platforms. 

Instead, our approach to providing advice has been to build sets of guidance around specific aspects of server configuration, such as TLS configuration, logging, and so on. I’ll come on to where you can find these in a moment.

At the same time, “cloud first” has become the default position, so the need for server configuration guidance has been slowly diminishing. Following this trend, we’ve been focusing more on helping our customers make use of cloud services.

Of course, there will always be use cases for staying with servers you manage yourself. So, to help with that, we have some recommendations from our existing publications that can be usefully applied to servers.

Many organisations are now moving - or already have moved - parts of their enterprise infrastructure into the cloud, and new digital services are now usually being built on cloud platforms. In the public sector this is being motivated by the government’s Cloud First policy. However, the potential for cost savings and improved functionality make the cloud appealing to just about everyone.

A lot of cloud services do the hard work of configuring and maintaining servers for you, including patching, security hardening, and implementing security functions like logging and auditing. This is usually true of Software as a Service (SaaS) which are entirely pre-made services and Platform as a Service (PaaS) where you provide the application, and the cloud provider maintains the server or container it runs on.

Your part of the bargain is to make sure you pick a good cloud provider, one you believe is putting the effort in on your behalf. We therefore recommend using the NCSC’s 14 Cloud Security Principles to figure out if a particular cloud service meets your security needs.

This is all well and good, but picking a cloud service doesn’t automatically make the need for server guidance go away. The more “do it yourself” cloud solutions, such as Infrastructure as a Service (IaaS) and container hosting, will usually need you to take full responsibility for security and put the same amount of effort into securing them as their on-premise equivalents. 

Whilst we are advocates of cloud as an alternative to servers, we're aware that for many organisations it's simply not possible to make this switch.

For those organisations, and anyone that just wants to improve their server security, we've put together a list of our existing publications that can be used to maker servers and their services more secure.

These publications focus on securing the servers themselves, looking at which setting can be enabled or disabled to best improve their security:

• Our EUD security principles provide the basis for all our guidance on the configuration of the platforms and can be applied to platforms and devices we don’t have guidance for. 
• We publish guidance for a variety of EUD platforms. Whilst we focus on desktop versions, our Ubuntu and Windows guidance can be used as starting points for setting up their server counterparts.  These cover many aspects that can be applied to servers as well - deployment scripts and policy settings are just two examples.
• We’ve written a blog post on the protection of management interfaces. These interfaces are used to perform privileged actions on systems on servers and as such require locking down. We've also blogged about Privileged Access Management, and the difference between browse up and browse down.
• Logging is an essential part of protecting your servers. This is something that sometimes gets implemented, but the log files are never analysed. Our guidance not only explains how to set up logging and analysis, but also sources of data that may assist with incident response and recovery.

This list focuses more on the applications that are being run on your servers, looking at how to secure the data in transit as well as the management of applications:

• Our 10 steps to secure configuration guidance gives you advice on securely configuring your services. You can apply these tips to your servers as well to minimise the risk of poor system configuration.
• We also have our Cyber Essentials pages that explain the most common cyber security threats. These contain many helpful pieces of advice including an easy-to-understand list of 5 technical controls you can put in place to help protect yourself.
• If you’re configuring a VPN server, you might want to consult our using IPsec to protect data guidance. Using IPsec to create a VPN gives confidence that the data cannot be read as it traverses a network. Our guidance gives two sets of configurations that should be used for OFFICIAL data: PRIME and Foundation. 
• Another way to protect data in transit is to use TLS. TLS encrypts data between applications and their users, or between services.  The guidance gives recommendations for how to configure TLS and secure server best practices.

These articles will help you if you're looking for generic advice, but if you need bespoke guidance for a specific platform we always suggest looking to the specific vendors for documentation. These vendors could be the operating system vendor (for example, RedHat or Microsoft), the appliance vendor, or the independent software vendor. 

A major benefit of using the vendor’s documentation is that it should be updated regularly to cover the latest releases.

As always, we’re really interested in your feedback.

Tom W
EUD Security Researcher