ms_logo_grey

Rule 2: Protect your data through encryption

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: Prerequisites: 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 http://go.microsoft.com/fwlink/?LinkId=83477.

  1. 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.
  2. Under Connections, right-click the name of the connection.
  3. Click Properties.
  4. In the General tab, select the Allow connections only from computers running Remote Desktop with Network Level Authentication check box.
  5. 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.
  6. Click OK.

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

  1. Start Remote Desktop Connection.
  2. Click the icon in the upper-left corner of the Remote Desktop Connection dialog box
  3. Click About.
  4. 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.

Note:

  1. You should always keep your server secure.
  2. 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:

  1. Open the ZIP file containing your certificate. Save the file named your_domain_name.cer to the desktop of the web server you are securing.
  2. Open the Internet Information Services (IIS) Manager.
  3. Click on the server name.
  4. From the center pane, double-click Server Certificates

    IIS_1

  5. In the right navigation bar, click Complete Certificate Request.... The Complete Certificate Request wizard window opens.
  6. Click "..."
  7. Select the .cer file, that was provided to you by DigiCert.
  8. In the Friendly Name field, enter the appropriate friendly name. Note: The friendly name is not part of the certificate itself. It is only used by the server administrator to easily distinguish the certificate.
  9. Select a certificate store for the new certificate.

    cert_request

  10. Click OK. The certificate will be installed.
  11. Once the SSL Certificate has been successfully installed to the server, you will need to assign that certificate to the appropriate website using IIS.
  12. In the Connections menu in the main Internet Information Services (IIS) Manager window, select the name of the server to which the certificate was installed.
  13. Under Sites, select the site to be secured with SSL.
  14. In the right navigation bar click Bindings....

    cert_bindings

    The Site Bindings window opens.
  15. In the Site Bindings window, click Add.... The Add Site Binding window opens.
  16. In the Type field, select the protocol https.
  17. In the field IP adress, enter the IP address of the site. Alternatively, you can enter All Unassigned.
  18. In the field Port, enter the port over which traffic will be secured by SSL.
  19. In the field SSL Certificate, enter the name of the certificate, which was installed in step 10.
  20. Click "OK."
  21. Your SSL/TLS certificate is now installed and the website has been configured to accept secure connections.

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:

  • PCI – Disables everything except TLS 1.0, TLS 1.1, TLS 1.2, AES 128, AES 256, DH, and PKCS.
  • FIPS 140-2 – Disables everything except TLS 1.0, TLS 1.1, TLS 1.2, AES 128, AES 256, DH, and PKCS.
  • BEST PRACTICES – The same as PCI, but also reorders the cipher suite

    iis_crypto

    Once used, IIS Crypto modifies some registry key and child nodes. Each registry key has an “Enabled” value that is set, while protocols have an additional value named “DisabledByDefault” that is also set.

    To enable/disable protocols, ciphers and hashes,IIS Crypto modifies the registry key and child nodes here:

    HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL


    For more information, please check: https://www.nartac.com/Blog/post/2013/04/19/IIS-Crypto-Explained.aspx

    It was tested on Windows Server 2003, 2008, 2008 R2 and 2012 and 2012 R2.

    Important note for servers running Remote Desktop Services (RDS): The default security layer in RDP is set to “Negotiate”, which supports both SSL (TLS 1.0) and the RDP Security Layer. However, if you set the security layer to SSL (TLS 1.0) and disable TLS 1.0 in IIS Crypto you will be unable to connect to RDP.

    To check your settings, open Remote Desktop Session Host Configuration in Administrative Tools and double click RDP-Tcp under the Connections group. If it is set to SSL (TLS 1.0), make sure that you do not disable TLS 1.0 in IIS Crypto.

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.

Content provided by 1&1

Comments

Tags: Windows