Windows Server Security Rule 2: Protect data with encryption

3 Replies • Leave your reply

What can you expect from this document?

This document covers some basic security best practices for data encryption.

These measures will help to increase the overall security, if combined with other security best practices.

What is the threat?

In order to keep your data safe, it´s highly advised to use encryption.

Proper usage of encryption can successfully mitigate an attack. Even if your data ends up in the hands of an attacker, he will not be able to access the data without the encryption key.

As this topic is very complex by nature, we can only give you advise on some use cases, however, we will try to provide useful links for further research.

First, let´s start with the basics.


Data States

Data in motion

The first type of data is data in motion. Data in motion is data that is currently traveling across a network or sitting in a computer’s RAM ready to be read, updated, or processed. Data crossing over networks to your server should be encrypted so that it cannot be read or manipulated by any machine or hacker between the data’s source and destination. This data in motion includes data moving across cables and wireless transmission. It can be emails or files transferred over file transfer protocol (FTP) or Remote Desktop Services (RDS).

Data at rest

Data at rest is a term that refers to data, that is permanently stored on a device or backup medium. It can be data stored on hard drives, backup tapes, in a cloud backup, or even on mobile devices. What makes it data at rest is that it is inactive data that is not currently being transmitted across a network or actively being read or processed. Data at rest is typically in a stable state. It is not moving through a system or network, and it is not processed by any application or the CPU.

Data in use

Data in use is data, which is processed by one or more applications. This is data currently in the process of being generated, updated, appended, or erased. Data in use also includes data, which is being viewed by users accessing it through various endpoints. Data in use is susceptible to different kinds of threats depending on where it is in the system and who is able to use it. The most vulnerable point for data in use is at the endpoints where users are able to access and interact with it.

Protection examples by data type and service:

This section contains helpful settings and hints that will help you in combination with other security baseline configuration options to improve overall security configuration.

Data in motion - NLA with Remote Desktop Services

Network Level Authentication (NLA) is an authentication method that can be used to enhance RD Session Host server security by requiring that the user be authenticated to the RD Session Host server before a session is created. This is done by using industry standard Transport Layer Security (TLS).

Network Level Authentication completes user authentication before you establish a remote desktop connection and the logon screen appears. This is a more secure authentication method that can help protect the remote computer from malicious users and malicious software. The advantages of Network Level Authentication are:

  • It requires fewer remote computer resources initially. The remote computer uses a limited number of resources before authenticating the user, rather than starting a full remote desktop connection as in previous versions.
  • It can help provide better security by reducing the risk of denial-of-service attacks.

To use Network Level Authentication, you must meet the following requirements:

  • The client computer must use Remote Desktop Connection 6.0 or later.
  • The client computer must use an operating system, such as Windows 7, Windows Vista, or , that supports the Credential Security Support Provider (CredSSP) protocol.
  • The RD Session Host server can only be used with Windows Server 2008 or higher.

To configure Network Level Authentication for a connection, proceed as follows:


Membership in the local Administrators group, or equivalent, is the minimum requirement to complete this procedure. Review details about using the appropriate accounts and group memberships at

  • On the RD Session Host server, open Remote Desktop Session Host Configuration.
  • To open Remote Desktop Session Host Configuration click Start, point to Administrative Tools, point to Remote Desktop Services, and then click Remote Desktop Session Host Configuration.
  • Under Connections, right-click the name of the connection.
  • Click Properties.
  • In the General tab, select the Allow connections only from computers running Remote Desktop with Network Level Authentication check box.

If the Allow connections only from computers running Remote Desktop with Network Level Authentication check box is selected and is not enabled, the Require user authentication for remote connections by using Network Level Authentication Group Policy setting has been enabled and has been applied to the RD Session Host server.

  • Click OK.

To determine whether a computer is running a version of Remote Desktop Connection that supports Network Level Authentication:

Start Remote Desktop Connection.

  • Click the icon in the upper-left corner of the Remote Desktop Connection dialog box
  • Click About.

Look for the phrase Network Level Authentication supported in the About Remote Desktop Connection dialog box.

Data in motion – Internet Information Server 8 and 8.5 (IIS):

If you’re running a website on IIS, we recommend you to:

  • Install a HTTPS certificate and enable HTTPs for your site
  • Disable the older protocols and ciphers through your registry.


You should always keep your server secure.

Should any of your visitors use an outdated browser, they might encounter some issues.

First of all, you need to install a certificate on the webserver:


The next step helps you to configure your cipher setting according to best practices. It is suggested to utilize the free tool IIS Crypto to avoid having to configure your cipher settings manually.

IIS Crypto was created to simplify enabling and disabling various protocols and cipher suites on servers running IIS, and it sets a few registry keys to enable/disable protocols, ciphers and hashes, as well as reorder cipher suites. All the changes are made following Microsoft’s best practices.

IS Crypto also supports pre-defined templates that can be set with a single button click:

Additional Recommendations:

Data at rest can be easily protected through mechanisms lie Full disk encryption, for example Microsoft Bitlocker or Encrypted File System (EFS). Azure RMs can be seen as hybrid, as it protects, data at rest, but can also protect data in transit as well.

Data in use is really tricky, as a local attacker with the corresponding privileges can extract fragments of data from memory, as they have to be processed in the clear at some point and very difficult if not impossible to achieve on current operating systems. A clear advice is to limit access to it.

Additional Information:

You can find additional information on the topics in these articles.

The contribution provided by Microsoft is intended to serve general information purposes and the content is AS IS without any express or implied warranties of any kind with respect to the accuracy, correctness or reliability. The information is provided without any warranty of fitness for a particular purpose. The information is compiled with the necessary care, however no liability is assumed in this respect, in particular with regard to the absence of errors, topicality with regard to the specific state of knowledge or use as the basis for the responsible decisions of the user.