APP.5.3 General Email Client and Server
Email is one of the most widely used and oldest internet applications. Emails are used to send text and attached files. An email address is required for this...
Description
Introduction
Email is one of the most widely used and oldest internet applications. Emails are used to send text and attached files. An email address is required for this.
To use email, email servers are needed that receive and send electronic messages. Typically, email clients used to access email services retrieve messages intended for them from the email server using the POP3 or IMAP protocols and themselves send messages to the email server using the SMTP protocol, which then forwards them to another email server as needed.
Since email is widely used especially in businesses and government agencies, email servers are frequently the target of attacks.
Email clients are also a focus of attacks. They are attacked, for example, by malware being sent via email. In addition, emails are also frequently used as a tool for social engineering attacks.
For these reasons, the secure operation and use of email applications is of particular importance.
Objective
The objective of this building block is to protect the information processed by email clients and on email servers.
Scope and Modeling
The building block APP.5.3 General Email Client and Server must be applied to every email client and server in the information domain.
This building block contains requirements for general email clients and servers. Requirements for server platforms, operating systems, and clients are not part of this building block. These are found in the building blocks SYS.1.1 General Server and SYS.2.1 General Client as well as in the respective operating-system-specific building blocks.
The building block APP.5.3 General Email Client and Server is usually used in an information domain in conjunction with another specific building block of the APP.5 Email/Groupware/Communication layer. These must also be implemented separately. These building blocks include, among others, APP.5.2 Microsoft Exchange and Outlook.
Requirements for logging and data backup are found in the building blocks OPS.1.1.5 Logging and CON.3 Data Backup Concept.
Groupware functions that offer not only email but also other functions such as managing contact data and calendars are not addressed in this building block. Likewise, purely cloud-based solutions are not addressed, such as those found as part of Microsoft 365 or Google G Suite. General requirements for these are found in the building block OPS.2.2 Cloud Use. Web browsers used to access webmail services via websites are also not addressed. Requirements for web browsers are found in the building block APP.1.2 Web Browser.
Threat Landscape
Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to represent the threat landscape. The following specific threats and vulnerabilities are of particular relevance for the building block APP.5.3 General Email Client and Server.
Inadequate Planning of Email Use
Email applications cannot be used securely in an institution without appropriately documented rules and a defined security procedure. If the procedural, organizational, and technical rules are neglected in the planning of email systems, this could result in internal and external attacks.
For example, an undersized email server can fail due to a large number of incoming emails. If no adequate security measures are planned, it is also possible that email clients become more susceptible to emails containing malware.
Incorrect Settings of Email Clients and Servers
Since an email infrastructure can be very complex, numerous security problems can arise from the many possible settings and mutually influencing parameters.
For example, an email server can reject legitimate emails from other servers due to a misconfiguration. In addition, essential settings could be ignored or disregarded, e.g. transport encryption of emails.
Furthermore, incorrect configuration in email clients can cause them to execute malicious code in emails. These security vulnerabilities can lead to a significant loss of availability, integrity, and confidentiality of information.
Many institutions do not use security mechanisms that allow other email servers to verify whether an email actually originates from the specified sender address. Furthermore, an incorrectly configured email server can be misused to send spam emails.
Unreliability of Email
Email applications allow data to be exchanged quickly and conveniently. However, this is not always reliable. For example, messages can be lost due to faulty email servers or disrupted transmission paths. Causes include spam filters that filter out and discard legitimate messages. Emails can also be lost if the destination address was not correctly specified. In the worst case, confidential information may have been sent to incorrect destination addresses.
Malware in Emails
There are various ways in which malware can be spread using emails during an attack. On the one hand, malicious code can be contained directly in an email. If the email client is not correctly configured, the code is executed when the email is opened.
Another possibility is that files with malware are sent as attachments to emails. If such emails are not filtered out by spam or virus filters and the attachments are opened, the malware is executed. This can lead to extensive damage to other IT systems as well, for example when ransomware (often referred to as “ransomware trojans”) is executed.
Social Engineering
Emails are often used in attacks to obtain confidential information or to induce personnel to other harmful behavior. For example, during an attack an email can be sent that purportedly comes from supervisors and contains instructions that harm the institution (so-called CEO fraud). Often the instructions are to transfer money to accounts abroad.
It is also possible that a forged email from an ostensibly trustworthy source calls for credentials to be entered on a website (phishing). The credentials thus obtained can then be used for further actions in an attack.
The danger of social engineering is amplified when the institution does not regularly train and raise awareness about these threats.
Interception and Manipulation of Emails
Emails are generally sent unencrypted and without digital signatures. Therefore, during an attack, emails can be intercepted and even arbitrarily modified. In this way, confidential information can be disclosed or false information can be distributed. It is also possible that malware can be introduced in this way.
Requirements
The following are the specific requirements of the building block APP.5.3 General Email Client and Server. The Information Security Officer (ISO) is responsible for ensuring that all requirements are fulfilled and verified in accordance with the established security concept. The ISO MUST always be involved in strategic decisions.
Further roles are defined in the IT-Grundschutz Compendium. They should be filled insofar as this is reasonable and appropriate.
| Responsibilities | Roles |
|---|---|
| Primarily responsible | IT Operations |
| Additional responsibilities | Users, Supervisors |
Exactly one role should be Primarily responsible. Beyond that, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, this role is listed in square brackets after the requirement heading. The use of singular or plural says nothing about how many people should fill these roles.
Basic Requirements
The following requirements MUST be fulfilled with priority for this building block.
APP.5.3.A1 Secure Configuration of Email Clients (B)
The institution MUST specify a secure configuration for the email clients. The email clients MUST be made available to users in a preconfigured state.
The institution SHOULD ensure that security-relevant parts of the configuration cannot be changed by users. If this is not possible, the institution MUST point out that the configuration MUST NOT be independently changed.
Before file attachments from emails are opened, they MUST be checked for malware. File attachments MUST be checked on the client or on the email server. Email clients MUST be configured so that they do not automatically interpret any HTML code or other active content in emails. Preview functions for file attachments MUST be configured so that they do not automatically interpret files. Email filter rules and the automatic forwarding of emails MUST be restricted to necessary use cases.
Email clients MUST use secure transport encryption for communication with email servers over untrusted networks.
APP.5.3.A2 Secure Operation of Email Servers (B)
For receiving emails over untrusted networks, email servers MUST offer secure transport encryption. The receipt of emails over unencrypted connections SHOULD be disabled. When email servers independently send emails to other email servers, they SHOULD use secure transport encryption. IT Operations SHOULD disable the sending of emails via insecure networks over unencrypted connections.
IT Operations MUST configure the email server so that email clients can only access mailboxes using secure transport encryption when this occurs over untrusted networks.
The institution MUST define all permitted email protocols and services. IT Operations MUST take protective measures against Denial-of-Service (DoS) attacks. If messages are stored on an email server, IT Operations MUST establish and document an appropriate size limit for the server-side mailbox. IT Operations MUST also configure the email server so that it cannot be misused as a spam relay.
APP.5.3.A3 Data Backup and Archiving of Emails (B)
IT Operations MUST regularly back up the data of email servers and clients. For this, the institution MUST regulate how the sent and received emails of email clients and the emails on the servers are backed up. The institution SHOULD also take into account when archiving that emails may only be stored locally on clients.
APP.5.3.A4 Spam and Virus Protection on the Email Server (B)
IT Operations MUST ensure that incoming and outgoing emails on email servers, particularly their attachments, are checked for spam characteristics and harmful content. The introduction and use of email filtering programs MUST be coordinated with data protection officers and the employee representatives.
The institution MUST define how to handle encrypted emails that cannot be decrypted by the antivirus program.
Standard Requirements
Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be fulfilled.
APP.5.3.A5 Defining Substitution Rules for Email Use (S) [Supervisors]
The institution SHOULD define substitution rules for the processing of emails. If emails are forwarded, the persons being substituted SHOULD at minimum be informed of this. When forwarding emails, data protection aspects MUST be taken into account. The institution SHOULD establish rules for the auto-reply function in email programs that describe how this function can be used securely. When the auto-reply function is used, no internal information SHOULD be disclosed.
APP.5.3.A6 Definition of a Security Policy for Email (S)
The institution SHOULD create a security policy for the use of emails and regularly update it. The institution SHOULD inform all users and administrators of new or changed security requirements for email applications. The email security policy SHOULD be consistent with the institution’s applicable overarching security policies. The institution SHOULD verify that the security policy is being applied correctly.
The email security policy for users SHOULD specify:
- which access rights exist,
- how emails are checked for forged sender addresses,
- how transmitted information can be secured,
- how the integrity of emails is to be verified,
- which open email distribution lists may be used,
- whether emails may be used for private purposes,
- how to handle emails and mailboxes of departing persons,
- whether and how webmail services may be used,
- who is responsible for group mailboxes,
- how file attachments should be handled, and
- whether users may activate the HTML display of emails.
The email security policy SHOULD additionally contain configuration options for email applications for administrators, as well as specifications for possible access by other servers to an email server. Information about authorized access points from which an email server may be accessed SHOULD also be included in the policy.
The email security policy SHOULD regulate the handling of newsgroups and mailing lists.
APP.5.3.A7 Training on Email Client Security Mechanisms for Users (S)
The institution SHOULD inform personnel about what risks arise when email applications are used and how emails can be handled securely. This SHOULD occur in addition to general training and awareness-raising. The institution SHOULD raise awareness of the dangers that can arise when email attachments are opened. Training SHOULD also address how emails with forged sender addresses can be identified.
The institution SHOULD warn against participating in email chain letters or subscribing to too many mailing lists.
APP.5.3.A8 Handling of Spam by Users (S) [Users]
In general, users SHOULD ignore and delete all spam emails. Users SHOULD NOT reply to unwanted emails. They SHOULD NOT follow links in these emails. If the institution has a central spam management system, users SHOULD forward spam emails to it and then delete the emails.
APP.5.3.A9 Extended Security Measures on the Email Server (S)
The institution’s email servers SHOULD check incoming emails using the Sender Policy Framework (SPF) and with the help of DomainKeys Identified Mail (DKIM). The institution SHOULD itself use DKIM and SPF to authenticate emails it sends.
If SPF is used, all email servers authorized to send for a domain SHOULD be listed in the SPF record. The SPF record SHOULD contain the “-all” parameter. The softfail parameter ("~") SHOULD only be used for testing purposes.
The institution SHOULD use Domain-based Message Authentication, Reporting and Conformance (DMARC) to define how emails it sends are to be verified by the receiving email server. DMARC records SHOULD specify that emails are rejected in the event of failure. DMARC reports SHOULD be regularly evaluated. The institution SHOULD define whether DMARC reports on received emails are to be sent to other institutions.
The institution SHOULD secure email communication via DANE and MTA-STS.
Requirements for High Protection Needs
The following are exemplary proposals for requirements for this building block that go beyond the level of protection that corresponds to the state of the art. The proposals SHOULD be considered when there are high protection needs. The specific determination is made within the context of an individual risk analysis.
APP.5.3.A10 End-to-End Encryption and Signature (H)
The institution SHOULD use end-to-end encryption as well as digital signatures for emails. ONLY protocols that correspond to the current state of the art SHOULD be used for encryption and signing.
APP.5.3.A11 Use of Redundant Email Servers (H)
The institution SHOULD operate redundant email servers. The redundant email servers SHOULD be listed with appropriate priority in the MX records of the affected domains. The institution SHOULD define how emails are synchronized between the email servers.
APP.5.3.A12 Monitoring Public Block Lists (H)
IT Operations SHOULD regularly check whether the institution’s email servers are listed on public spam or block lists.
APP.5.3.A13 TLS Reporting (H)
The institution SHOULD use TLS reporting. It SHOULD be defined whether TLS reports are to be sent to other institutions.
Additional Information
Good to Know
The International Organization for Standardization (ISO) provides requirements for the operation of email services in standard ISO/IEC 27001:2013 in chapter 13.2.3.
The Information Security Forum (ISF) provides requirements for the operation of email services in its standard “The Standard of Good Practice for Information Security” in chapter CF2.3.3.
The National Institute of Standards and Technology (NIST) describes in its “Guidelines on Electronic Mail Security” how email applications can be operated securely.
The Federal Office for Information Security (BSI) provides information in the document “BSI TR-03108 Secure Email Transport” about how emails can be sent securely.