S 5.100 Protection of communications from and to Exchange systems

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

A Groupware server communicates with Groupware clients, browsers, phone and communication applications, and other Groupware systems. Data is also exchanged between individual Groupware system components. Communication takes place using the local network and/or external networks. In both cases, data requiring protection is transmitted. This does not only include the data used by the users for authentication (e.g. user name and password), but also business information and personal data in the private environment.

For this reason, it is necessary to decide which protection mechanism will be used to secure communications.

When transmitting data requiring protection to and from Groupware systems, the data should be encrypted, if possible. Various methods can be used to protect the data. It is therefore necessary to decide which method is the most favourable in terms of the costs and benefits. The decision must be documented so that it can be understood later.

Use of IPSec

IPSec provides general security for communication at the IP level: All data packets are encrypted and their integrity is protected. One advantage of this method is that no additional configurations must be performed at the Microsoft Exchange system level when using IPsec, since IPSec protection is configured at the operating system level.

There are several possible solutions for protecting the email communication:

Due to the high distribution of the IP internet protocol, IPSec or other VPN solutions are generally used at this point. IPSec allows for protecting IP connections between locations, between end devices, and even between end devices and locations. Both fixedly pre-configured keys (Preshared Keys) and Public Key Infrastructures (PKI) can be used for key management.

In order to protect the Exchange communication on the basis of IPSec, all computers participating in email routing must communicate using IPsec.

In pure Windows networks (versions Windows 2000 and higher), IPSec is available without any additional licences by default. However, its configuration needs to be administered. Additional information can be found in S 5.90 Use of IPSec under Windows.

Use of TLS/SSL

The use of SSL is generally recommended for all HTTP-based accesses. This also applies to the internal communication between the components of the Microsoft Exchange system and other components providing SSL security as an option. Encrypting the transmission routes between a client and a Microsoft Exchange server makes sense and is necessary in all application scenarios. This particularly applies to the transmission of sensitive data using untrustworthy communication channels, the internet for example. The SSL and/or TLS protocol (see also S 5.66 Use of TLS/SSL) should be used for the aforementioned, especially in a Microsoft Exchange environment. The decision regarding the optional or forced use of SSL/TLS should be made depending on the location of the accessing clients and the protection requirements of the transmitted data. Encrypting the transmission route also allows for using weaker authentication mechanisms such as the password-based clear text authentication, for example.

Securing the client-server communication

If a Microsoft Outlook client is configured as Exchange client, communication can be protected. If Microsoft Outlook only uses the internet protocols (POP3, IMAP4, SMTP, NNTP) for accessing the Exchange server, the connection should be secured by means of TLS. This is generally applicable to the access to other email servers as well.

One of the possible scenarios for the use of SSL/TLS results from the option of accessing an Exchange server using Outlook Web Access (OWA). In this case, the transmission routes must be encrypted between the web browser and the IIS server (required here).

A variety of services offered by a Microsoft Exchange system can be accessed over the HTTP protocol. Client access to the mailbox memories is normally performed using HTTP. Generally, the HTTP services must be configured securely so that, on the one hand, accesses transmitting data requiring protection are protected by SSL/TLS, and on the other hand, only the services needed are activated.

Here, the RPC interfaces and WebDAV interfaces accessible via HTTP are related to specific risks:

RPC interface

The RPC interface must be protected with SSL as a matter of principle. Further information can be found in S 2.481 Planning the use of Exchange for Outlook Anywhere

WebDAV interface

The WebDAV (Web-based Distributed Authoring and Versioning) protocol allows users to access information using the HTTP protocol as if it were stored in a file system. Since WebDAV access may result in local file system accesses of the client for Exchange, the local file system must be protected against unauthorised access. In this, the protection of the data made available using WebDAV should be in the focus. However, if an attacker can use WebDAV to access the local file system, further attacks may be prepared this way. For this reason, access to WebDAV should only be granted after authentication and should be protected using SSL. In addition, it is always necessary to ensure the authorisations have been assigned stringently.

Securing the server-server communication

In Exchange, server-server communication must be encrypted if confidential data is transmitted using insecure networks or if the authentication on a server is performed using clear text authentication.

The encryption mechanisms available depend on the Exchange connectors used. Therefore, the encryption mechanisms made available by a connector must also be taken into consideration when selecting a connector.

Securing the message communication

At the message level, S/MIME- and OpenPGP-based programs have prevailed in practice regarding the protection of emails. S/MIME key management requires the operation of a Public Key Infrastructure (PKI). On the contrary, PGP relies on open key management and does not require the configuration of a central PKI.

Normally, third party manufacturers implement the protection at message level as a plug-in solution for one or several email clients (see S 5.110 Securing email using SPHINX (S/MIME)).

Solutions for encryption and signing individual files are also available at the file system level, e.g. in the form of Shell extensions. Files protected this way may be sent as file attachments via email.

Public Key Infrastructure

Microsoft Outlook offers an integrated S/MIME-based email encryption mechanism. This mechanism uses the trust relationships of a Public Key Infrastructure that can be operated with the help of a proprietary Windows Enterprise CA (Certificate Authority) or a third party CA. The root certificates signed by a CA must be available to the system. For this, the root certificates deemed trustworthy should be configured centrally for all Outlook clients using a Windows group policy.

Further security precautions

In order to guarantee secure PKI operation, the following precautions must be taken:

In addition to the generally known system components of Microsoft Exchange Server, the components responsible for operating Exchange with encryption and signature functionality must be secured.

When revoking one or several user certificates, the period of validity of the Certificate Revocation List plays a decisive role. It is recommended to immediately publish the CRL after a revocation took place and not to wait for the next scheduled time of publication. However, it must be observed that, the moment a new CRL is published, the old list does not automatically become invalid resulting in the clients already disposing of a valid CRL not having to use the new list. Therefore, it is generally recommendable to equip CRLs with a relatively short period of validity so that the clients must renew their CRLs at the corresponding frequency.

The documents in the Microsoft Technet describe how these requirements are to be implemented specifically; for version 2010 in the following documents, for example:

Review questions:

© Federal Office for Information Security. All rights reserved.