MS Exchange 2013 Mailbox Server Security Technical Implementation Guide

V1R3 2019-01-02       U_MS_Exchange_2013_Mailbox_STIG_V1R3_Manual-xccdf.xml
V1R2 2017-04-06       U_MS_Exchange_2013_Mailbox_STIG_V1R2_Manual-xccdf.xml
This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: [email protected]
Comparison
All 71
No Change 70
Updated 1
Added 0
Removed 0
V-69941 No Change
Findings ID: EX13-MB-000005 Rule ID: SV-84563r1_rule Severity: medium CCI: CCI-001403

Discussion

Unauthorized or malicious data changes can compromise the integrity and usefulness of the data. Automated attacks or malicious users with elevated privileges have the ability to effect change using the same mechanisms as email administrators.

Auditing changes to access mechanisms not only supports accountability and nonrepudiation for those authorized to define the environment but also enables investigation of changes made by others who may not be authorized.

Note: This administrator auditing feature audits all exchange changes regardless of the users' assigned role or permissions.

Checks

Open the Exchange Management Shell and enter the following command:

Get-AdminAuditLogConfig | Select Name, AdminAuditLogEnabled

If the value of AdminAuditLogEnabled is not set to True, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-AdminAuditLogConfig -AdminAuditLogEnabled $true
V-69943 No Change
Findings ID: EX13-MB-000010 Rule ID: SV-84565r1_rule Severity: medium CCI: CCI-000213

Discussion

Server certificates are required for many security features in Exchange; without them, the server cannot engage in many forms of secure communication.

Failure to implement valid certificates makes it virtually impossible to secure Exchange's communications.

Checks

Open the Exchange Management Shell and enter the following command:

Get-ExchangeCertificate | Select CertificateDomains, issuer

If the value of CertificateDomains does not indicate it is issued by the DoD, this is a finding.

Fix

Remove the non-DoD certificate and import the correct DoD certificates.
V-69945 No Change
Findings ID: EX13-MB-000015 Rule ID: SV-84567r1_rule Severity: medium CCI: CCI-001368

Discussion

Attackers can use automated messages to determine whether a user account is active, in the office, traveling, and so on. An attacker might use this information to conduct future attacks. Verify Automatic Forwards to remote domains are disabled, except for enterprise mail that must be restricted to forward-only to .mil and .gov. domains.

Before enabling this setting, first configure a remote domain.

Checks

Non-Enterprise Mail Check Content:

Open the Exchange Management Shell and enter the following command:

Get-RemoteDomain | Select Identity, AutoForwardEnabled

If the value of AutoForwardEnabled is not set to False, this is a finding.

Enterprise Mail Check Content:

If the value of AutoForwardEnabled is set to True, this is not a finding.

and

In the Exchange Management Shell, enter the following command:

Get-RemoteDomain

If the value of RemoteDomain is not set to a .mil and/or .gov domain(s), this is a finding.

Fix

Non-Enterprise Mail Fix Text:

Open the Exchange Management Shell and enter the following command:

Set-RemoteDomain -Identity <'IdentityName'> -AutoForwardEnabled $false

Note: The <IdentityName> value must be in quotes.

Enterprise Mail Fix Text:

New-RemoteDomain -Name <NewRemoteDomainName> -DomainName <SMTP Address>

Note: NewRemoteDomainName must either be a .mil or .gov domain.

Set-RemoteDomain -Identity <'RemoteDomainIdentity'> -AutoForwardEnabled $true

Note: The <RemoteDomainIdentity> value must be in quotes.
V-69947 No Change
Findings ID: EX13-MB-000020 Rule ID: SV-84569r1_rule Severity: medium CCI: CCI-000169

Discussion

A connectivity log is a record of the SMTP connection activity of the outbound message delivery queues to the destination Mailbox server, smart host, or domain. Connectivity logging is available on Hub Transport servers and Edge Transport servers. By default, connectivity logging is disabled. If events are not recorded, it may be difficult or impossible to determine the root cause of system problems or the unauthorized activities of malicious users.

Note: Transport configuration settings apply to the organization/global level of the Exchange SMTP path. By checking and setting them at the Hub server, the setting will apply to both Hub and Edge roles.

Checks

Open the Exchange Management Shell and enter the following command:

Get-TransportService | Select Name, Identity, ConnectivityLogEnabled

If the value of ConnectivityLogEnabled is not set to True, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-TransportService -Identity <'IdentityName'> -ConnectivityLogEnabled $true

Note: The <IdentityName> value must be in quotes.
V-69949 No Change
Findings ID: EX13-MB-000025 Rule ID: SV-84571r1_rule Severity: medium CCI: CCI-000169

Discussion

Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Diagnostic logging, however, characteristically produces large volumes of data and requires care in managing the logs to prevent risk of disk capacity denial-of-service conditions.

Exchange diagnostic logging is broken up into 29 main "services", each of which has anywhere from 2 to 26 "categories" of events to be monitored. Moreover, each category may be set to one of four levels of logging: Lowest, Low, Medium, and High, depending on how much detail one desires. The higher the level of detail, the more disk space required to store the audit material.

Diagnostic logging is intended to help administrators debug problems with their systems, not as a general-purpose auditing tool. Because the diagnostic logs collect a great deal of information, the log files may grow large very quickly. Diagnostic log levels may be raised for limited periods of time when attempting to debug relevant pieces of Exchange functionality. Once debugging has finished, diagnostic log levels should be reduced again.

Checks

Open the Exchange Management Shell and enter the following command:

Get-EventLogLevel

If Diagnostic of any EventLevel is not set to Lowest, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-EventLogLevel -Identity <'IdentityName\EventlogName'> -Level Lowest

Note: The <IdentityName\EventlogName> value must be in quotes.
V-69951 No Change
Findings ID: EX13-MB-000030 Rule ID: SV-84573r1_rule Severity: low CCI: CCI-000169

Discussion

Log files help establish a history of activities, and can be useful in detecting attack attempts. This item declares the fields that must be available in the audit log file in order to adequately research events that are logged.

Audit records should include the following fields to supply useful event accounting:
Object modified, Cmdlet name, Cmdlet parameters, Modified parameters, Caller, Succeeded, and Originating server.

Checks

Open the Exchange Management Shell and enter the following command:

Get-AdminAuditLogConfig | Select AdminAuditLogParameters

Note: The value of {*} indicates all parameters are being audited.

If the value of AdminAuditLogParameters is not set to {*}, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-AdminAuditLogConfig -AdminAuditLogParameters *
V-69953 No Change
Findings ID: EX13-MB-000035 Rule ID: SV-84575r1_rule Severity: low CCI: CCI-000133

Discussion

Logging provides a history of events performed and can also provide evidence of tampering or attack. Failure to create and preserve logs adds to the risk that suspicious events may go unnoticed and raises the potential that insufficient history will be available to investigate them.

This setting controls how log files are written. If circular logging is enabled, there is one log file stored with a default size of 1024 KB. Once the size limit has been reached, additional log entries overwrite the oldest log entries. If circular logging is disabled, once a log file reaches the size limit, a new log file is created.

Mailbox should not use circular logging. Logs should be written to a partition separate from the operating system, with log protection and backups being incorporated into the overall System Security plan.

Checks

Open the Exchange Management Shell and enter the following command:

Get-MailboxDatabase | Select Name, Identity, CircularLoggingEnabled

If the value of CircularLoggingEnabled is not set to False, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-MailboxDatabase -Identity <'IdentityName'> -CircularLoggingEnabled $false

Note: The <IdentityName> value must be in quotes.
V-69955 Updated
Findings ID: EX13-MB-000040 Rule ID: SV-84577r23_rule Severity: medium CCI: CCI-000133

Discussion

Log files help establish a history of activities and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. When “message tracking” is enabled, only the sender, recipients, time, and other delivery information are included by default. Information such as the subject and message body is not included.

However, the absence of the message subject line can make it difficult to locate a specific message in the log unless one knows roughly what time the message was sent. To simplify searches through these logs, Exchange offers the ability to include the message “subject line” in the log files and in the Message Tracking Center display. This can make it significantly easier to locate a specific message.

This feature creates larger log files and will contain information that may raise privacy and legal concerns. Enterprise policy should be consulted before this feature is enabled. Also, since the log files may contain sensitive information in the form of the subject line, the log files will need to be protected, commensurate with the sensitivity level, as the content may be of interest to an attacker.

For these reasons, it is recommended that subject logging not be enabled during regular production operations. Instead, treat this feature as a diagnostic that can be used if needed. The tradeoff is that finding the correct message in the message tracking logs will become more difficult since the administrator will need to search using only the time the message was sent and the message’s sender. This control will have no effect unless Message Tracking is enabled. However, the setting should be disabled in case message tracking is enabled in the future.

Checks

Open the Exchange Management Shell and enter the following command:

Get-TransportService | Select Name, Identity, MessageTrackingLogSubjectLoggingEnabled

If the value of
MessageTrackingLogSubjectLoggingEnabled is not set to “True”"False", this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-TransportService -Identity <'IdentityName'> - MessageTrackingLogSubjectLoggingEnabled $True

Note: The <IdentityName> value must be in quotes.
V-69957 No Change
Findings ID: EX13-MB-000045 Rule ID: SV-84579r2_rule Severity: medium CCI: CCI-000133

Discussion

A message tracking log provides a detailed log of all message activity as messages are transferred to and from a computer running Exchange.

If events are not recorded, it may be difficult or impossible to determine the root cause of system problems or the unauthorized activities of malicious users.

Checks

Open the Exchange Management Shell and enter the following command:

Get-TransportService | Select Name, Identity, MessageTrackingLogEnabled

If the value of MessageTrackingLogEnabled is not set to “True”, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-TransportService -Identity <'IdentityName'> - MessageTrackingLogEnabled $True

Note: The <IdentityName> value must be in quotes.
V-69959 No Change
Findings ID: EX13-MB-000050 Rule ID: SV-84581r1_rule Severity: medium CCI: CCI-000154

Discussion

Monitors are automated "process watchers" that respond to performance changes and can be useful in detecting outages and alerting administrators where attention is needed. Exchange has built-in monitors that enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion.

This field offers choices of alerts when a "warning" or "critical" threshold is reached on the SMTP queue. A good rule of thumb (default) is to issue warnings when SMTP queue growth exceeds 10 minutes and critical messages when it exceeds 20 minutes, which should only exist occasionally. Frequent alerts against this counter may indicate a network or other issue (such as inbound ExchangeMER traffic) that directly impacts email delivery.

Notification choices include email alert to an email-enabled account (for example, an email Administrator) or invoke a script to take other action (for example, to add an Event to the Microsoft Application Event Log, where external monitors might detect it).

Checks

Note: If a third-party application is performing monitoring functions, the reviewer should verify the application is monitoring correctly and mark the vulnerability NA.

Open the Exchange Management Shell and enter the following command:

perfmon

In the left pane, expand and navigate Performance >> Data Collector Sets >> User Defined.

If no sets are defined or queues are not being monitored, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

perfmon

In the left pane, navigate to and select Performance >> Data Collector Sets >> User Defined.

Right-click on, navigate to, and configure User Defined >> New >> Data Collector Sets and configure the system to use the data collection set for monitoring the queues.
V-69961 No Change
Findings ID: EX13-MB-000055 Rule ID: SV-84583r1_rule Severity: medium CCI: CCI-000381

Discussion

It is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.

Applications are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions).

Examples of non-essential capabilities include, but are not limited to, advertising software or browser plug-ins not related to requirements or providing a wide array of functionality not required for every mission, but cannot be disabled.

All system errors in Exchange will result in outbound traffic that may be identified by an eavesdropper. For this reason, the "Report Fatal Errors to Microsoft" feature must be disabled.

Checks

Open the Exchange Management Shell and enter the following command:

Get-ExchangeServer –status | Select Name, Identity, ErrorReportingEnabled

For each Exchange Server, if the value of ErrorReportingEnabled is not set to False, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-ExchangeServer -Identity <'IdentityName'> -ErrorReportingEnabled $false

Note: The <IdentityName> value must be in quotes.

Repeat the process for each Exchange Server.
V-69963 No Change
Findings ID: EX13-MB-000060 Rule ID: SV-84585r1_rule Severity: medium CCI: CCI-000162

Discussion

Log files help establish a history of activities and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Audit log content must always be considered sensitive and in need of protection. Audit data available for modification by a malicious user can be altered to conceal malicious activity. Audit data might also provide a means for the malicious user to plan unauthorized activities that exploit weaknesses.

The contents of audit logs are protected against unauthorized access, modification, or deletion. Only authorized auditors and the audit functions should be granted Read and Write access to audit log data.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the authorized groups or users that should have read access to the audit data.

If any group or user has read access to the audit data that is not documented in the EDSP, this is a finding.

Fix

Update the EDSP.

Restrict any unauthorized groups' or users' read access to the audit logs.
V-69965 No Change
Findings ID: EX13-MB-000065 Rule ID: SV-84587r1_rule Severity: medium CCI: CCI-000381

Discussion

It is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.

Applications are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions).

Examples of non-essential capabilities include, but are not limited to, advertising software or browser plug-ins not related to requirements or providing a wide array of functionality not required for every mission, but cannot be disabled.

Customer Experience reports in Exchange will result in outbound traffic that may be identified by an eavesdropper. For this reason, the Customer Experience reports to Microsoft must not be sent.

Checks

Open the Exchange Management Shell and enter the following command:

Get-OrganizationConfig | Select CustomerFeedbackEnabled

If the value for CustomerFeedbackEnabled is not set to False, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-OrganizationConfig -CustomerFeedbackEnabled $false
V-69967 No Change
Findings ID: EX13-MB-000070 Rule ID: SV-84589r1_rule Severity: medium CCI: CCI-000163

Discussion

Log files help establish a history of activities and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Audit log content must always be considered sensitive and in need of protection. Audit data available for modification by a malicious user can be altered to conceal malicious activity. Audit data might also provide a means for the malicious user to plan unauthorized activities that exploit weaknesses.

The contents of audit logs are protected against unauthorized access, modification, or deletion. Only authorized auditors and the audit functions should be granted Read and Write access to audit log data.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the authorized groups or users that should have access to the audit data.

If any group or user has modify privileges for the audit data that is not documented in the EDSP, this is a finding.

Fix

Update the EDSP.

Restrict any unauthorized groups' or users' modify permissions for the audit logs.
V-69969 No Change
Findings ID: EX13-MB-000075 Rule ID: SV-84591r1_rule Severity: medium CCI: CCI-000164

Discussion

Log files help establish a history of activities and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Audit log content must always be considered sensitive and in need of protection. Audit data available for modification by a malicious user can be altered to conceal malicious activity. Audit data might also provide a means for the malicious user to plan unauthorized activities that exploit weaknesses.

The contents of audit logs are protected against unauthorized access, modification, or deletion. Only authorized auditors and the audit functions should be granted Read and Write access to audit log data.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the authorized groups or users that should have delete permissions for the audit data.

If any group or user has delete permissions for the audit data that is not documented in the EDSP, this is a finding.

Fix

Update the EDSP.

Restrict any unauthorized groups' or users' delete permissions for the audit logs.
V-69971 No Change
Findings ID: EX13-MB-000080 Rule ID: SV-84593r1_rule Severity: medium CCI: CCI-001348

Discussion

Log files help establish a history of activities and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Audit log content must always be considered sensitive and in need of protection.

Successful exploit of an application server vulnerability may well be logged by monitoring or audit processes when it occurs. Writing log and audit data to a separate partition where separate security contexts protect them may offer the ability to protect this information from being modified or removed by the exploit mechanism.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the audit logs' assigned partition.

By default, the logs are located on the application partition in \Program Files\Microsoft\Exchange Server\V15\Logging.

If the log files are not on a separate partition from the application, this is a finding.

Fix

Update the EDSP.

Configure the audit log location to be on a partition drive separate from the application.
V-69973 No Change
Findings ID: EX13-MB-000085 Rule ID: SV-84595r1_rule Severity: medium CCI: CCI-001749

Discussion

Scripts often provide a way for attackers to infiltrate a system, especially those downloaded from untrusted locations. By setting machine policy to prevent unauthorized script executions, unanticipated system impacts can be avoided. Failure to allow only signed remote scripts reduces the attack vector vulnerabilities from unsigned remote scripts.

Checks

Open the Exchange Management Shell and enter the following command:

Get-ExecutionPolicy

If the value returned is not RemoteSigned, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-ExecutionPolicy RemoteSigned
V-69975 No Change
Findings ID: EX13-MB-000090 Rule ID: SV-84597r1_rule Severity: medium CCI: CCI-000381

Discussion

The IMAP4 protocol is not approved for use within the DoD. It uses a clear-text-based user name and password and does not support the DoD standard for PKI for email access. User name and password could easily be captured from the network, allowing a malicious user to access other system features. Uninstalling or disabling the service will prevent the use of the IMAP4 protocol.

Checks

Open the Windows Power Shell and enter the following command:

Get-ItemProperty 'hklm:\system\currentcontrolset\services\MSExchangeIMAP4' | Select Start

Note: The hklm:\system\currentcontrolset\services\MSExchangeIMAP4 value must be in quotes.

If the value of Start is not set to 4, this is a finding.

Fix

Open the Windows Power Shell and enter the following command:

services.msc

Navigate to and double-click on Microsoft Exchange IMAP4 Backend.

Click on the "General" tab.

In the Startup Type: dropdown, select Disabled.

Click the OK button.
V-69977 No Change
Findings ID: EX13-MB-000095 Rule ID: SV-84599r1_rule Severity: medium CCI: CCI-000381

Discussion

The POP3 protocol is not approved for use within the DoD. It uses a clear-text-based user name and password and does not support the DoD standard for PKI for email access. User name and password could easily be captured from the network, allowing a malicious user to access other system features. Uninstalling or disabling the service will prevent the use of the POP3 protocol.

Checks

Open the Windows Power Shell and enter the following command:

Get-ItemProperty 'hklm:\system\currentcontrolset\services\MSExchangePOP3' | Select Start

Note: The hklm:\system\currentcontrolset\services\MSExchangePOP3 value must be in quotes.

If the value of Start is not set to 4, this is a finding.

Fix

Open the Windows Power Shell and enter the following command:

services.msc

Navigate to and double-click on Microsoft Exchange POP3 Backend.

Click on the "General" tab.

In the Startup Type: dropdown, select Disabled.

Click the OK button.
V-69979 No Change
Findings ID: EX13-MB-000100 Rule ID: SV-84601r1_rule Severity: medium CCI: CCI-001082

Discussion

In the same way that added security layers can provide a cumulative positive effect on security posture, multiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit to one application can lead to an exploit of other applications sharing the same security context. For example, an exploit to a web server process that leads to unauthorized administrative access to the host system can most likely lead to a compromise of all applications hosted by the same system.

Email services should be installed to a discrete set of directories, on a partition that does not host other applications. Email services should never be installed on a Domain Controller/Directory Services server.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the location where the Exchange Mailbox databases reside.

Open the Exchange Management Shell and enter the following command:

Get-MailboxDatabase | Select Name, Identity, EdbFilePath

Open Windows Explorer and navigate to and verify the mailbox databases are on a dedicated partition.

If the mailbox databases are not on a dedicated partition, this is a finding.

Fix

Update the EDSP.

Configure the mailbox databases on a dedicated partition.
V-69981 No Change
Findings ID: EX13-MB-000105 Rule ID: SV-84603r1_rule Severity: medium CCI: CCI-001178

Discussion

When identifying a "Smart Host" for the email environment, a logical Send connector is the preferred method.

A Smart Host acts as an Internet-facing concentrator for other email servers. Appropriate hardening can be applied to the Smart Host, rather than at multiple locations throughout the enterprise.

Failure to identify a Smart Host could default to each email server performing its own lookups (potentially through protective firewalls). Exchange servers should not be Internet facing and should therefore not perform any Smart Host functions. When the Exchange servers are Internet facing, they must be configured to identify the Internet-facing server that is performing the Smart Host function.

Checks

Open the Exchange Management Shell and enter the following command:

Get-SendConnector | Select Name, Identity, SmartHosts

Identify the Internet-facing connectors.

For each Send connector, if the value of SmartHosts does not return the Smart Host IP Address, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-SendConnector -Identity <'IdentityName'> -SmartHosts <'IP Address of Smart Host'> -DNSRoutingEnabled $false

Note: The <IdentityName> and <IP Address of Smart Host> values must be in quotes.

Repeat the procedure for each Send connector.
V-69983 No Change
Findings ID: EX13-MB-000110 Rule ID: SV-84605r1_rule Severity: medium CCI: CCI-001184

Discussion

The Simple Mail Transfer Protocol (SMTP) Receive connector is used by Exchange to send and receive messages from server to server using SMTP protocol. This setting controls the encryption strength used for client connections to the SMTP Receive connector. With this feature enabled, only clients capable of supporting secure communications will be able to send mail using this SMTP server. Where secure channels are required, encryption can also be selected.

The use of secure communication prevents eavesdroppers from reading or modifying communications between mail clients and servers. While sensitive message bodies should be encrypted by the sender at the client, requiring a secure connection from the client to the server adds protection by encrypting the sender and recipient information that cannot be encrypted by the sender.

Individually, channel security and encryption have been compromised by attackers. Used together, email becomes a more difficult target, and security is heightened. Failure to enable this feature gives eavesdroppers an opportunity to read or modify messages between the client and server.

Checks

Open the Exchange Management Shell and enter the following command:

Get-ReceiveConnector | Select Name, Identity, AuthMechanism

For each Receive connector, if the value of AuthMechanism is not set to Tls, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-ReceiveConnector -Identity <'IdentityName'> -AuthMechanism 'Tls'

Note: The <IdentityName> value must be in quotes.

Repeat the procedures for each Receive connector.
V-69985 No Change
Findings ID: EX13-MB-000115 Rule ID: SV-84607r1_rule Severity: medium CCI: CCI-001184

Discussion

The Simple Mail Transfer Protocol (SMTP) connector is used by Exchange to send and receive messages from server to server. There are several controls that work together to provide security between internal servers. This setting controls the authentication method used for communications between servers. With this feature enabled, only servers capable of supporting domain authentication will be able to send and receive mail within the domain.

The use of secure communication prevents eavesdroppers from reading or modifying communications between mail clients and servers. While sensitive message bodies should be encrypted by the sender at the client, requiring a secure connection from server to server adds protection by encrypting the sender and recipient information that cannot be encrypted by the sender.

Individually, channel security and encryption can be compromised by attackers. Used together, email becomes a more difficult target, and security is heightened. Failure to enable this feature gives eavesdroppers an opportunity to read or modify messages between servers.

Checks

Open the Exchange Management Shell and enter the following command:

Get-SendConnector | Select Name, Identity, DomainSecureEnabled

For each Send connector, if the value of DomainSecureEnabled is not set to True, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-SendConnector -Identity <'IdentityName'> -DomainSecureEnabled $true

Note: The <IdentityName> value must be in quotes.

Repeat the procedures for each Send connector.
V-69987 No Change
Findings ID: EX13-MB-000120 Rule ID: SV-84609r1_rule Severity: medium CCI: CCI-001184

Discussion

The Simple Mail Transfer Protocol (SMTP) connector is used by Exchange to send and receive messages from server to server. There are several controls that work together to provide security between internal servers. This setting controls the encryption method used for communications between servers. With this feature enabled, only servers capable of supporting Transport Layer Security (TLS) will be able to send and receive mail within the domain.

The use of secure communication prevents eavesdroppers from reading or modifying communications between mail clients and servers. While sensitive message bodies should be encrypted by the sender at the client, requiring a secure connection from server to server adds protection by encrypting the sender and recipient information that cannot be encrypted by the sender.

Individually, channel security and encryption can be compromised by attackers. Used together, email becomes a more difficult target, and security is heightened. Failure to enable this feature gives eavesdroppers an opportunity to read or modify messages between servers.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the internal SMTP Domain.

Open the Exchange Management Shell and enter the following command:

Get-SendConnector | Select Name, Identity, TlsDomain

For each Send connector, if the value of TlsDomain is not set to the value of the internal <SMTP Domain>, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-SendConnector -Identity <'IdentityName'> -TlsDomain <'SMTP Domain'>

Note: The <IdentityName> and <SMTP Domain> values must be in quotes.

Repeat the procedure for each Send connector.
V-69989 No Change
Findings ID: EX13-MB-000125 Rule ID: SV-84611r1_rule Severity: medium CCI: CCI-001199

Discussion

Backup and recovery procedures are an important part of overall system availability and integrity. Complete backups reduce the chance of accidental deletion of important information and make it possible to have complete recoveries.

It is not uncommon for users to receive and delete documents in the scope of a single backup cycle. This setting ensures at least one backup has been run on the folder store before the message physically disappears. By enabling this setting, all messages written to recipients who have accounts on this store will reside in backups even if they have been deleted by the user before the backup has run.

Checks

If public folders are not used, this check is not applicable.

Open the Exchange Management Shell and enter the following command:

Get-PublicFolderDatabase | Select Name, Identity, RetainDeletedItemsUntilBackup

If the value of RetainDeletedItemsUntilBackup is not set to True, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-PublicFolderDatabase -Identity <'IdentityName'> -RetainDeletedItemsUntilBackup $true

Note: The <IdentityName> value must be in quotes.
V-69991 No Change
Findings ID: EX13-MB-000130 Rule ID: SV-84613r1_rule Severity: low CCI: CCI-001199

Discussion

Email system availability depends in part on best practice strategies for setting tuning configurations. Unauthorized or accidental restoration of public folder data risks data loss or corruption.

This setting controls whether the public folder store can be overwritten by a restore from backup, which will cause loss of all information added after the backup was created. It should only be enabled during maintenance windows or following an outage (immediately before a restore is to be made), and cleared again immediately afterward.

During production windows, this feature must be disabled.

Checks

If public folders are not used, this check is not applicable.

Open the Exchange Management Shell and enter the following command:

Get-PublicFolderDatabase| Select Name, Identity, AllowFileRestore

If the value of AllowFileRestore is not set to False, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-PublicFolderDatabase -Identity <'IdentityName'> -AllowFileRestore $false

Note: The <IdentityName> value must be in quotes.
V-69993 No Change
Findings ID: EX13-MB-000135 Rule ID: SV-84615r1_rule Severity: medium CCI: CCI-001199

Discussion

Backup and recovery procedures are an important part of overall system availability and integrity. Complete backups reduce the chance of accidental deletion of important information and make it possible to have complete recoveries.

It is not uncommon for users to receive and delete messages in the scope of a single backup cycle. This setting ensures at least one backup has been run on the mailbox store before the message physically disappears. By enabling this setting, all messages written to recipients who have accounts on this store will reside in backups even if they have been deleted by the user before the backup has run.

Checks

Open the Exchange Management Shell and enter the following command:

Get-MailboxDatabase| Select Name, Identity, RetainDeletedItemsUntilBackup

If the value of RetainDeletedItemsUntilBackup is not set to True, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-MailboxDatabase -Identity <'IdentityName'> -RetainDeletedItemsUntilBackup $true

Note: The <IdentityName> value must be in quotes.
V-69995 No Change
Findings ID: EX13-MB-000140 Rule ID: SV-84617r1_rule Severity: low CCI: CCI-001199

Discussion

Email system availability depends in part on best practice strategies for setting tuning configurations. Unauthorized or accidental restoration of mailbox data risks data loss or corruption.

This setting controls whether the mailbox store can be overwritten by a backup, which will cause loss of all information added after the backup was created. It should only be enabled during maintenance windows or following an outage (immediately before a restore is to be made), and cleared again immediately afterward.

During production windows, this feature must be disabled.

Checks

Open the Exchange Management Shell and enter the following command:

Get-MailboxDatabase| Select Name, Identity, AllowFileRestore

If the value of AllowFileRestore is not set to False, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-MailboxDatabase -Identity <'IdentityName'> -AllowFileRestore $false

Note: The <IdentityName> value must be in quotes.
V-69997 No Change
Findings ID: EX13-MB-000145 Rule ID: SV-84619r2_rule Severity: medium CCI: CCI-001199

Discussion

Auto-forwarded email accounts do not meet the requirement for digital signature and encryption of CUI and PII IAW DoDI 8520.2 (reference ee) and DoD Director for Administration and Management memorandum, "Safeguarding Against and Responding to the Breach of Personally Identifiable Information".

Use of forwarding set by an administrator interferes with nonrepudiation requirements that each end user be responsible for creation and destination of email data.

Checks

Review the Email Domain Security Plan (EDSP).

Determine any accounts that have been authorized to have email auto-forwarded.

Note: If email auto-forwarding is not being used, this check is not applicable. .

Open the Exchange Management Shell and enter the following commands:

Get-Mailbox | select Name, ForwardingSMTPAddress
If any user has a forwarding SMTP address and is not documented in the EDSP, this is a finding.

Note: If no remote SMTP domain matching the mail-enabled user or contact that allows forwarding is configured for users identified with a forwarding address, this function will not work properly.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set-Mailbox | select Name, ForwardingSMTPAddress $null

V-69999 No Change
Findings ID: EX13-MB-000150 Rule ID: SV-84621r1_rule Severity: medium CCI: CCI-001199

Discussion

Auto-forwarded email accounts do not meet the requirement for digital signature and encryption of CUI and PII IAW DoDI 8520.2 (reference ee) and DoD Director for Administration and Management memorandum, "Safeguarding Against and Responding to the Breach of Personally Identifiable Information".

Use of forwarding set by an administrator interferes with nonrepudiation requirements that each end user be responsible for creation and destination of email data.

Checks

Review the Email Domain Security Plan (EDSP).

Determine any accounts that have been authorized to have email auto-forwarded.

Note: If email auto-forwarding is not being used, this check is not applicable.

Open the Exchange Management Shell and enter the following commands:

Get-RemoteDomain | Select Name, Identity, DomainName, AutoForwardEnabled

If any domain for a user forwarding SMTP address is not documented in the EDSP, this is a finding.

Note: If no remote SMTP domain matching the mail-enabled user or contact that allows forwarding is configured for users identified with a forwarding address, this function will not work properly.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set- RemoteDomain -Identity <RemoteDomainIdParameter>
V-70001 No Change
Findings ID: EX13-MB-000155 Rule ID: SV-84623r1_rule Severity: low CCI: CCI-001094

Discussion

Mail quota settings control the maximum sizes of a user’s mailbox and the system’s response if these limits are exceeded. Mailbox data that is not monitored against a quota increases the risk of mail loss due to filled disk space, which can also render the system unavailable.

Failure to allow mail receipt may impede users from receiving mission-critical data.

Checks

Open the Exchange Management Shell and enter the following command:

Get-MailboxDatabase | Select Name, Identity, ProhibitSendReceiveQuota

If the value of ProhibitSendReceiveQuota is not set to Unlimited, this is a finding.

or

If the value of ProhibitSendReceiveQuote is set to an alternate value and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-MailboxDatabase -Identity <'IdentityName'> -ProhibitSendReceiveQuota Unlimited

Note: The <IdentityName> value must be in quotes.

or

The value as identified by the EDSP that has obtained a signoff with risk acceptance.
V-70003 No Change
Findings ID: EX13-MB-000160 Rule ID: SV-84625r1_rule Severity: low CCI: CCI-001094

Discussion

Mail quota settings control the maximum sizes of a user’s mailbox and the system’s response if these limits are exceeded. Mailbox data that is not monitored against a quota increases the risk of mail loss due to filled disk space, which can also render the system unavailable. There are multiple controls, which supply graduated levels of opportunity to respond before risking email service loss.

This control prohibits the user from sending an email when the mailbox limit reaches the prohibit send quota value.

Note: Best practice for this setting is to prohibit the user from sending email when the mailbox reaches 90 percent of capacity.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the value for Prohibit Send Quota Limit.

Open the Exchange Management Shell and enter the following command:

Get-MailboxDatabase | Select Name, Identity, ProhibitSendQuota

If the value of ProhibitSendQuota is not set to the site's Prohibit Send Quota Limit, this is a finding.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set-MailboxDatabase -Identity <'IdentityName'> -ProhibitSendQuota <'QuotaLimit'>

Note: The <IdentityName> and <QuotaLimit> values must be in quotes.
V-70005 No Change
Findings ID: EX13-MB-000165 Rule ID: SV-84627r1_rule Severity: low CCI: CCI-001094

Discussion

Mail quota settings control the maximum sizes of a user’s mailbox and the system’s response if these limits are exceeded. Mailbox data that is not monitored against a quota increases the risk of mail loss due to filled disk space, which can also render the system unavailable. There are multiple controls, which supply graduated levels of opportunity to respond before risking data loss.

This control sends the user a warning message that the mailbox is reaching its limit. The user at this point can still send and receive email.

Note: Best practice is to send this warning when the mailbox reaches 75 percent of capacity.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the value for Issue Warning Quota.

Open the Exchange Management Shell and enter the following command:

Get-MailboxDatabase | Select Name, Identity, IssueWarningQuota

If the value of IssueWarningQuota is not set to the site's Issue Warning Quota, this is a finding.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set-MailboxDatabase -Identity <'IdentityName'> -IssueWarningQuota <'WarningQuota'>

Note: The <IdentityName> and <WarningQuota> values must be in quotes.
V-70007 No Change
Findings ID: EX13-MB-000170 Rule ID: SV-84629r1_rule Severity: low CCI: CCI-001094

Discussion

Administrator responsibilities include the ability to react to unplanned maintenance tasks or emergency situations that may require Mailbox data manipulation. Occasionally, there may be a need to start the server with "unmounted" data stores if manual maintenance is being performed on them. Failure to uncheck the "do not mount on startup" condition will result in unavailability of mail services.

Correct configuration of this control will prevent unplanned outages due to being enabled. When maintenance is being performed, care should be taken to clear the check box upon task completion so mail stores are available to users (unmounted mailbox stores are not available to users).

Checks

Open the Exchange Management Shell and enter the following command:

Get-MailboxDatabase | Select Name, Identity, MountAtStartup

If the value of MountAtStartup is not set to True, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-MailboxDatabase -Identity <'IdentityName'> -MountAtStartup $true

Note: The <IdentityName> value must be in quotes.
V-70009 No Change
Findings ID: EX13-MB-000175 Rule ID: SV-84631r1_rule Severity: low CCI: CCI-001095

Discussion

Email system availability depends in part on best practice strategies for setting tuning configurations. For message size restrictions, multiple places exist to set or override inbound or outbound message size. Failure to control the configuration strategy can result in loss of data or system availability.

This setting enables the administrator to control the maximum message size on receive connectors. Using connectors to control size limits may necessitate applying message size limitations in multiple places, with the potential of introducing conflicts and impediments in the mail flow. Changing this setting at the connector overrides the global one. Therefore, if operational needs require it, the connector value may be set lower than that of the global value with the rationale documented in the Email Domain Security Plan (EDSP).

Checks

Review the Email Domain Security Plan (EDSP).

Determine the global maximum message receive size and whether signoff with risk acceptance is documented for the Receive connector to have a different value.

Open the Exchange Management Shell and enter the following command:

Get-ReceiveConnector | Select Name, Identity, MaxMessageSize

Identify Internet-facing connectors.

For each Receive connector, if the value of MaxMessageSize is not the same as the global value, this is a finding.

or

If MaxMessageSize is set to a numeric value different from the global value and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set-ReceiveConnector -Identity <'IdentityName'> -MaxMessageSize <'MaxReceiveSize'>

Note: The <IdentityName> and <MaxReceiveSize> values must be in quotes.

or

The value as identified by the EDSP that has obtained a signoff with risk acceptance.

Repeat the procedure for each Receive connector.
V-70011 No Change
Findings ID: EX13-MB-000180 Rule ID: SV-84633r1_rule Severity: low CCI: CCI-001095

Discussion

Email system availability depends in part on best practice strategies for setting tuning configurations.

This configuration controls the maximum number of recipients who will receive a copy of a message at one time. This tunable value is related to throughput capacity and can enable the ability to optimize message delivery.

Note: There are two types of default Receive connecters:
Client Servername: Accepts SMTP connections from all non-MAPI clients, such as POP and IMAP. As POP and IMAP are not authorized for use in DoD, these should not be present. Their default value for MaxRecipientsPerMessage is 200.
Default Servername: Accepts connections from other Hub Transport servers and any Edge Transport servers. Their default value for MaxRecipientsPerMessage is 5000.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the Maximum Recipients per Message value.

Open the Exchange Management Shell and enter the following command:

Get-ReceiveConnector | Select Name, Identity, MaxRecipientsPerMessage

For each Receive connector, evaluate the MaxRecipientsPerMessage value.

For each Receive connector, if the value of MaxRecipientsPerMessage is not set to 5000, this is a finding.

or

If the value of Maximum Recipients per Message is set to a value other than 5000 and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set-ReceiveConnector -Identity <'IdentityName'> -MaxRecipientsPerMessage 5000

Note: The <IdentityName> value must be in quotes.

or

The value as identified by the EDSP that has obtained a signoff with risk acceptance.

Repeat the procedure for each Receive connector.
V-70013 No Change
Findings ID: EX13-MB-000185 Rule ID: SV-84635r1_rule Severity: low CCI: CCI-001095

Discussion

For Receive connectors, unclear naming as to direction and purpose increases risk that messages may not flow as intended, troubleshooting efforts may be impaired, or incorrect assumptions may be made about the completeness of the configuration.

Collectively, connectors should account for all connections required for the overall email topology design. Simple Mail Transfer Protocol (SMTP) connectors, when listed, must name purpose and direction clearly, and their counterparts on servers to which they connect should be recognizable as their partners.

Checks

Open the Exchange Management Shell and enter the following command:

Get-ReceiveConnector | Select Name, Identity

Review the naming for connectors.

If the connectors are not clearly named for purpose and direction, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-ReceiveConnector -Name <'NewReceiveConnectorName'> -Identity <'IdentityName'>

Note: Both the <NewSendReceiveName> and <IdentityName> value must be in quotes.
V-70015 No Change
Findings ID: EX13-MB-000190 Rule ID: SV-84637r1_rule Severity: low CCI: CCI-001095

Discussion

Email system availability depends in part on best practice strategies for setting tuning configurations. This setting controls the maximum number of hops (email servers traversed) a message may take as it travels to its destination. Part of the original Internet protocol implementation, the hop count limit prevents a message being passed in a routing loop indefinitely. Messages exceeding the maximum hop count are discarded undelivered.

Recent studies indicate that virtually all messages can be delivered in fewer than 60 hops. If the hop count is set too low, messages may expire before they reach their destinations. If set too high, an undeliverable message may cycle between servers, raising the risk of network congestion.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the value for Receive connectors.

Open the Exchange Management Shell and enter the following command:

Get-ReceiveConnector | Select Name, MaxHopCount

For each Receive connector, if the value of MaxHopCount is not set to 60, this is a finding.

or

If the value of MaxHopCount is set to a value other than 60 and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set-ReceiveConnector -MaxHopCount 60

or

The value as identified by the EDSP that has obtained a signoff with risk acceptance.

Repeat the procedure for each Receive connector.
V-70017 No Change
Findings ID: EX13-MB-000195 Rule ID: SV-84639r1_rule Severity: low CCI: CCI-001095

Discussion

For Send connectors, unclear naming as to direction and purpose increases risk that messages may not flow as intended, troubleshooting efforts may be impaired, or incorrect assumptions may be made about the completeness of the configuration.

Collectively, connectors should account for all connections required for the overall email topology design. Simple Mail Transfer Protocol (SMTP) connectors, when listed, must name purpose and direction clearly, and their counterparts on servers to which they connect should be recognizable as their partners.

Checks

Open the Exchange Management Shell and enter the following command:

Get-SendConnector | Select Name, Identity

Determine the naming for the Send connectors.

For each Send connector, if the connectors are not clearly named for purpose and direction, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-SendConnector -Name <'NewSendConnectorName'> -Identity <'IdentityName'>

Note: Both the <NewSendConnectorName> and <IdentityName> value must be in quotes.

Repeat the procedure for each Send connector.
V-70019 No Change
Findings ID: EX13-MB-000200 Rule ID: SV-84641r1_rule Severity: low CCI: CCI-001095

Discussion

This setting controls the rate at which delivery attempts from the home domain are retried and user notifications are issued and notes the expiration time when the message will be discarded.

If delivery retry attempts are too frequent, servers will generate network congestion. If too far apart, messages may remain queued longer than necessary, potentially raising disk resource requirements.

The default values of these fields should be adequate for most environments. Administrators may wish to modify the values as a result, but changes should be documented in the System Security Plan.

Note: Transport configuration settings apply to the organization/global level of the Exchange SMTP path. By checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the value for Transient Failure Retry Count.

Open the Exchange Management Shell and enter the following command:

Get-TransportService | Select Name, Identity, TransientFailureRetryCount

If the value of TransientFailureRetryCount is not set to 10 or less, this is a finding.

or

If the value of TransientFailureRetryCount is set to more than 10 or has signoff and risk acceptance in the EDSP, this is not a finding.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set-TransportService -Identity <'IdentityName'> -TransientFailureRetryCount 10

Note: The <ServerIdentity> value must be in quotes.

or

The value as identified by the EDSP that has obtained a signoff with risk acceptance.
V-70021 No Change
Findings ID: EX13-MB-000205 Rule ID: SV-84643r1_rule Severity: low CCI: CCI-001095

Discussion

Email system availability depends in part on best practice strategies for setting tuning configurations. For message size restrictions, multiple places exist to set or override inbound or outbound message size. Failure to control the configuration strategy can result in loss of data or system availability.

This setting enables the administrator to control the maximum message size on a Send connector. Using connectors to control size limits may necessitate applying message size limitations in multiple places, with the potential of introducing conflicts and impediments in the mail flow. Changing this setting at the connector overrides the global one. Therefore, if operational needs require it, the connector value may be set lower than the global value with the rationale documented in the Email Domain Security Plan (EDSP).

Checks

Review the Email Domain Security Plan (EDSP).

Determine the maximum message send size.

Open the Exchange Management Shell and enter the following command:

Get-SendConnector | Select Name, Identity, MaxMessageSize

For each Send connector, if the value of MaxMessageSize is not the same as the global value, this is a finding.

or

If MaxMessageSize is set to a numeric value different from the maximum message send size value documented in the EDSP, this is a finding.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set-SendConnector -Identity <'IdentityName'> -MaxMessageSize <MaxSendSize>

Note: The <IdentityName> value must be in quotes.

or

The value as identified by the EDSP that has obtained a signoff with risk acceptance.

Repeat the procedures for each Send connector.
V-70023 No Change
Findings ID: EX13-MB-000210 Rule ID: SV-84645r1_rule Severity: low CCI: CCI-001095

Discussion

The Exchange Send connector setting controls the maximum number of simultaneous outbound connections allowed for a given SMTP connector and can be used to throttle the SMTP service if resource constraints warrant it. If the limit is too low, connections may be dropped. If too high, some domains may use a disproportionate resource share, denying access to other domains. Appropriate tuning reduces risk of data delay or loss.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the value for SMTP Server Maximum Outbound Connections.

Open the Exchange Management Shell and enter the following command:

Get-TransportService | Select Name, Identity, MaxOutboundConnections

If the value of MaxOutboundConnections is not set to 1000, this is a finding.

or

If the value of MaxOutboundConnections is set to a value other than 1000 and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set-TransportServer -Identity <'IdentityName'> -MaxOutboundConnections 1000

Note: The <IdentityName> value must be in quotes.

or

The value as identified by the EDSP that has obtained a signoff with risk acceptance.
V-70025 No Change
Findings ID: EX13-MB-000215 Rule ID: SV-84647r1_rule Severity: low CCI: CCI-001095

Discussion

Email system availability depends in part on best practice strategies for setting tuning configurations. Message size limits should be set to 10 megabytes at most, but often are smaller, depending on the organization. The key point in message size is that it should be set globally and should not be set to "unlimited". Selecting "unlimited" on either field is likely to result in abuse and can contribute to excessive server disk space consumption.

Message size limits may also be applied on SMTP connectors, Public Folders, and on the user account under AD. Changes at these lower levels are discouraged, as the single global setting is usually sufficient. This practice prevents conflicts that could impact availability and simplifies server administration.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the global maximum message receive size.

Open the Exchange Management Shell and enter the following command:

Get-TransportConfig | Select Name, Identity, MaxReceiveSize

If the value of MaxReceiveSize is not set to 10MB, this is a finding.

or

If the value of MaxReceiveSize is set to an alternate value and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set-TransportConfig -MaxReceiveSize 10MB

or

The value as identified by the EDSP that has obtained a signoff with risk acceptance.
V-70027 No Change
Findings ID: EX13-MB-000220 Rule ID: SV-84649r1_rule Severity: low CCI: CCI-001095

Discussion

Email system availability depends in part on best practice strategies for setting tuning configurations. Message size limits should be set to 10 megabytes at most, but often are smaller, depending on the organization. The key point in message size is that it should be set globally and should not be set to "unlimited". Selecting "unlimited" on either field is likely to result in abuse and can contribute to excessive server disk space consumption.

Message size limits may also be applied on send and receive connectors, Public Folders, and on the user account under AD. Changes at these lower levels are discouraged, as the single global setting is usually sufficient. This practice prevents conflicts that could impact availability and it simplifies server administration.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the global maximum message send size.

Open the Exchange Management Shell and enter the following command:

Get-TransportConfig | Select Name, Identity, MaxSendSize

If the value of MaxSendSize is not set to 10MB, this is a finding.

or

If the value of MaxSendSize is set to an alternate value and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set-TransportConfig -MaxSendSize 10MB

or

The value as identified by the EDSP that has obtained a signoff with risk acceptance.
V-70029 No Change
Findings ID: EX13-MB-000225 Rule ID: SV-84651r1_rule Severity: low CCI: CCI-001095

Discussion

Email system availability depends in part on best practice strategies for setting tuning configurations. This configuration controls the maximum number of simultaneous outbound connections from a domain and works in conjunction with the Maximum Outbound Connections Count setting as a delivery tuning mechanism. If the limit is too low, connections may be dropped. If too high, some domains may use a disproportionate resource share, denying access to other domains. Appropriate tuning reduces risk of data delay or loss.

By default, a limit of 20 simultaneous outbound connections from a domain should be sufficient. The value may be adjusted if justified by local site conditions.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the value for Maximum Domain Connections

Open the Exchange Management Shell and enter the following command:

Get-TransportService | Select Name, Identity, MaxPerDomainOutboundConnections

If the value of MaxPerDomainOutboundConnections is not set to 20, this is a finding.

or

If the value of MaxPerDomainOutboundConnections is set to a value other than 20 and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set-TransportService -Identity <'IdentityName'> -MaxPerDomainOutboundConnections 20

Note: The <IdentityName> value must be in quotes.

or

The value as identified by the EDSP that has obtained a signoff with risk acceptance.
V-70031 No Change
Findings ID: EX13-MB-000230 Rule ID: SV-84653r1_rule Severity: low CCI: CCI-001095

Discussion

Email system availability depends in part on best practice strategies for setting tuning configurations. This configuration controls the number of idle minutes before the connection is dropped. It works in conjunction with the Maximum Outbound Connections Count setting.

Connections, once established, may incur delays in message transfer. The default of 10 minutes is a reasonable window in which to resume activities without maintaining idle connections for excessive intervals. If the timeout period is too long, idle connections may be maintained for unnecessarily long time periods, preventing new connections from being established. Sluggish connectivity increases the risk of lost data. A value of 10 or less is optimal.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the Connection Timeout value.

Open the Exchange Management Shell and enter the following command:

Get-SendConnector | Select Name, Identity, ConnectionInactivityTimeOut

For each Send connector, if the value of ConnectionInactivityTimeOut is not set to 00:10:00, this is a finding.

or

If ConnectionInactivityTimeOut is set to other than 00:10:00 and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set-SendConnector -Identity <'IdentityName'> -ConnectionInactivityTimeOut 00:10:00

Note: The <IdentityName> value must be in quotes.

or

The value as identified by the EDSP that has obtained a signoff with risk acceptance.
V-70033 No Change
Findings ID: EX13-MB-000235 Rule ID: SV-84655r1_rule Severity: medium CCI: CCI-001308

Discussion

This control is used to limit the servers that may use this server as a relay. If a Simple Mail Transport Protocol (SMTP) sender does not have a direct connection to the Internet (for example, an application that produces reports to be emailed) then it will need to use an SMTP Receive connector that does have a path to the Internet (for example, a local email server) as a relay.

SMTP relay functions must be protected so third parties are not able to hijack a relay service for their own purposes. Most commonly, hijacking of relays is done by spammers to disguise the source of their messages and may also be used to cover the source of more destructive attacks.

Relays can be restricted in one of three ways: by blocking relays (restrict to a blank list of servers), by restricting use to lists of valid servers, or by restricting use to servers that can authenticate. Because authenticated connections are the most secure for SMTP Receive connectors, it is recommended that relays allow only servers that can authenticate.

Checks

Open the Exchange Management Shell and enter the following command:

Get-ReceiveConnector | Select Name, Identity, PermissionGroups

For each Receive connector, if the value of PermissionGroups is AnonymousUsers for any receive connector, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-ReceiveConnector -Identity <'IdentityName'> -PermissionGroups and enter a valid value user group.

Note: The <IdentityName> value must be in quotes.

Example: Set-ReceiveConnector -Identity <'IdentityName'> -PermissionGroups ExchangeUsers

This is an Example only: Set-ReceiveConnector -Identity <'IdentityName'> -PermissionGroups ExchangeUsers

Repeat the procedures for each Receive connector.
V-70035 No Change
Findings ID: EX13-MB-000240 Rule ID: SV-84657r1_rule Severity: medium CCI: CCI-001308

Discussion

Spam originators, in an effort to refine mailing lists, sometimes monitor transmissions for automated bounce-back messages. Automated messages include such items as "Out of Office" responses, nondelivery messages, or automated message forwarding.

Automated bounce-back messages can be used by a third party to determine if users exist on the server. This can result in the disclosure of active user accounts to third parties, paving the way for possible future attacks.

Checks

Open the Exchange Management Shell and enter the following command:

Get-RemoteDomain | Select Name, DomainName, Identity, AllowedOOFType

If the value of AllowedOOFType is not set to InternalLegacy, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-RemoteDomain -Identity <'IdentityName'> -AllowedOOFType 'InternalLegacy'

Note: The <IdentityName> and InternalLegacy values must be in quotes.
V-70037 No Change
Findings ID: EX13-MB-000245 Rule ID: SV-84659r1_rule Severity: medium CCI: CCI-001308

Discussion

Originators of spam messages are constantly changing their techniques in order to defeat spam countermeasures; therefore, spam software must be constantly updated to address the changing threat. A manual update procedure is labor intensive and does not scale well in an enterprise environment. This risk may be mitigated by using an automatic update capability. Spam protection mechanisms include, for example, signature definitions, rule sets, and algorithms.

Exchange 2013 provides both antispam and antimalware protection out of the box. The Exchange 2013 antispam and antimalware product capabilities are limited but still provide some protection.

Checks

Update the EDSP.

Note: If using another DoD-approved antispam product for email or a DoD-approved email gateway spamming device, such as Enterprise Email Security Gateway (EEMSG), this is not applicable.

Open the Exchange Management Shell and enter the following command:

Get-ContentFilterConfig | Format-Table Name,Enabled

If no value is returned, this is a finding.

Fix

Update the EDSP.

Install the AntiSpam module.

Open the Exchange Management Shell and enter the following command:

& $env:ExchangeInstallPath\Scripts\Install-AntiSpamAgents.ps1
V-70039 No Change
Findings ID: EX13-MB-000250 Rule ID: SV-84661r1_rule Severity: medium CCI: CCI-001308

Discussion

Originators of spam messages are constantly changing their techniques in order to defeat spam countermeasures; therefore, spam software must be constantly updated to address the changing threat. A manual update procedure is labor intensive and does not scale well in an enterprise environment. This risk may be mitigated by using an automatic update capability. Spam protection mechanisms include, for example, signature definitions, rule sets, and algorithms.

Exchange 2013 provides both antispam and antimalware protection out of the box. The Exchange 2013 antispam and antimalware product capabilities are limited but still provide some protection.

Checks

Review the Email Domain Security Plan (EDSP).

Note: If using another DoD-approved antispam product for email or a DoD-approved email gateway spamming device, such as Enterprise Email Security Gateway (EEMSG), this is not applicable.

Open the Exchange Management Shell and enter the following command:

Get-ContentFilterConfig | Format-Table Name,Enabled; Get-SenderFilterConfig | Format-Table Name,Enabled; Get-SenderIDConfig | Format-Table Name,Enabled; Get-SenderReputationConfig | Format-Table Name,Enabled

If any of the following values returned are not set to True, this is a finding:

Set-ContentFilterConfig
Set-SenderFilterConfig
Set-SenderIDConfig
Set-SenderReputationConfig

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command for any values that were not set to True:

Set-ContentFilterConfig -Enabled $true

Set-SenderFilterConfig -Enabled $true

Set-SenderIDConfig -Enabled $true

Set-SenderReputationConfig -Enabled $true
V-70041 No Change
Findings ID: EX13-MB-000255 Rule ID: SV-84663r1_rule Severity: medium CCI: CCI-001308

Discussion

Originators of spam messages are constantly changing their techniques in order to defeat spam countermeasures; therefore, spam software must be constantly updated to address the changing threat. A manual update procedure is labor intensive and does not scale well in an enterprise environment. This risk may be mitigated by using an automatic update capability. Spam protection mechanisms include, for example, signature definitions, rule sets, and algorithms.

Exchange 2013 provides both antispam and antimalware protection out of the box. The Exchange 2013 antispam and antimalware product capabilities are limited but still provide some protection.

Checks

Review the Email Domain Security Plan (EDSP).

Note: If using another DoD-approved antispam product for email or a DoD-approved email gateway spamming device, such as Enterprise Email Security Gateway (EEMSG), this is not applicable.

Determine the Internal SMTP servers.

Open the Exchange Management Shell and enter the following command:

Get-TransportConfig | Format-List InternalSMTPServers

If any internal SMTP server IP address returned does not reflect the list of accepted SMTP server IPs, this is a finding.

Fix

Note: Configure the IP addresses of every internal SMTP server. If the Mailbox server is the only SMTP server running the antispam agents, configure the IP address of the Mailbox server.

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Single SMTP server address:

Set-TransportConfig -InternalSMTPServers @{Add='<ip address1>'}

Multiple SMTP server addresses:

Set-TransportConfig -InternalSMTPServers @{Add='<ip address1>','<ip address2>'}
V-70043 No Change
Findings ID: EX13-MB-000260 Rule ID: SV-84665r1_rule Severity: medium CCI: CCI-001308

Discussion

Attackers can use automated messages to determine whether a user account is active, in the office, traveling, and so on. An attacker might use this information to conduct future attacks. Remote users will not receive automated "Out Of Office" delivery reports. This setting can be used to determine if all the servers in the Organization can send "Out of Office" messages.

Checks

Open the Exchange Management Shell and enter the following command:

Get-RemoteDomain | Select Name, Identity, AutoReplyEnabled

If the value of AutoReplyEnabled is not set to False, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-RemoteDomain -Identity <'IdentityName'> -AutoReplyEnabled $false

Note: The <IdentityName> value must be in quotes.
V-70045 No Change
Findings ID: EX13-MB-000265 Rule ID: SV-84667r1_rule Severity: high CCI: CCI-001308

Discussion

With the proliferation of trojans, viruses, and spam attaching themselves to email messages (or attachments), it is necessary to have capable email-aware antivirus (AV) products to scan messages and identify any resident malware. Because email messages and their attachments are formatted to the MIME standard, a flat-file AV scanning engine is not suitable for scanning email message stores.

Email-aware antivirus engines must be Exchange 2013 compliant. Competent email scanners will have the ability to scan mail stores, attachments (including zip or other archive files) and mail queues and to issue warnings or alerts if malware is detected. As with other AV products, a necessary feature to include is the ability for automatic updates.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the antivirus strategy.

Verify the email-aware antivirus scanner product is Exchange 2013 compatible and DoD-approved.

If email servers are using an email-aware antivirus scanner product that is not DoD-approved and Exchange 2013 compatible, this is a finding.

Fix

Update the EDSP.

Install and configure a DoD-approved compatible Exchange 2013 email-aware antivirus scanner product.
V-70047 No Change
Findings ID: EX13-MB-000270 Rule ID: SV-84669r1_rule Severity: low CCI: CCI-001308

Discussion

Email system availability depends in part on best practice strategies for setting tuning configurations. The Global Recipient Count Limit field is used to control the maximum number of recipients that can be specified in a single message sent from this server. Its primary purpose is to minimize the chance of an internal sender spamming other recipients, since spam messages often have a large number of recipients. Spam prevention can originate from both outside and inside organizations. While inbound spam is evaluated as it arrives, controls such as this one help prevent spam that might originate inside the organization.

The Recipient Count Limit is global to the Exchange implementation. Lower-level refinements are possible; however, in this configuration strategy, setting the value once at the global level facilitates a more available system by eliminating potential conflicts among multiple settings. A value of less than or equal to 5000 is probably larger than is needed for most organizations but is small enough to minimize usefulness to spammers and is easily handled by Exchange. An unexpanded distribution is handled as one recipient. Specifying “unlimited” may result in abuse.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the global maximum message recipient count.

Open the Exchange Management Shell and enter the following command:

Get-TransportConfig | Select Name, Identity, MaxRecipientEnvelopeLimit

If the value of MaxRecipientEnvelopeLimit is not set to 5000, this is a finding.

or

If the value of MaxRecipientEnvelopeLimit value is set to an alternate value and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix

Update the EDSP.

Set-TransportConfig -MaxRecipientEnvelopeLimit 5000

or

The value as identified by the EDSP that has obtained a signoff with risk acceptance.

Restart the Microsoft Exchange Information Store service.
V-70049 No Change
Findings ID: EX13-MB-000275 Rule ID: SV-84671r1_rule Severity: low CCI: CCI-002361

Discussion

Email system availability depends in part on best practice strategies for setting tuning. This configuration controls the number of idle minutes before the connection is dropped. It works in conjunction with the Maximum Inbound Connections Count setting.

Connections, once established, may incur delays in message transfer. If the timeout period is too long, there is risk that idle connections may be maintained for unnecessarily long time periods, preventing new connections from being established.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the Connection Timeout value.

Open the Exchange Management Shell and enter the following command:

Get-ReceiveConnector | Select Name, Identity, ConnectionTimeout

For each Receive connector, if the value of ConnectionTimeout is not set to 00:10:00, this is a finding.

or

If ConnectionTimeout is set to other than 00:10:00 and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set-ReceiveConnector -Identity <'IdentityName'> -ConnectionTimeout 00:10:00

Note: The <IdentityName> value must be in quotes.

or

The value as identified by the EDSP that has obtained a signoff with risk acceptance.
V-70051 No Change
Findings ID: EX13-MB-000280 Rule ID: SV-84673r1_rule Severity: low CCI: CCI-001879

Discussion

This setting controls the maximum sizes of a public folder and the system’s response if these limits are exceeded. There are two available controls and the system response when the quota has been exceeded.

The first control sends an email warning to Folder Owners roles, alerting them that the folder has exceeded its quota. The second level prevents posting any additional items to the folder.

As a practical matter, Level 1 serves the purpose of prompting owners to manage their folders. Level 2 impedes users in their ability to work and is not required where folder use interruption is not acceptable. Public Folder Storage Quota Limitations are not a substitute for overall disk space monitoring.

Checks

If public folders are not used, this check is not applicable.

Review the Email Domain Security Plan (EDSP).

Determine the value for ProhibitPostQuota.

Open the Exchange Management Shell and enter the following command:

Get-PublicFolderDatabase | Select Name, Identity, ProhibitPostQuota

If the value of ProhibitPostQuota is not set to the ProhibitPostQuota values documented in the EDSP, this is a finding.

Fix

Update the EDSP.

Open the Exchange Management Shell and enter the following command:

Set-PublicFolderDatabase -Identity <'IdentityName'> -ProhibitPostQuota <'QuotaLimit'>

Note: The <IdentityName> and <QuotaLimit> values must be in quotes.
V-70053 No Change
Findings ID: EX13-MB-003031 Rule ID: SV-84675r1_rule Severity: medium CCI: CCI-001242

Discussion

Malicious code protection mechanisms include, but are not limited, to, anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated.

Malicious code includes viruses, worms, Trojan horses, and Spyware. It is not enough to simply have the software installed; this software must periodically scan the system to search for malware on an organization-defined frequency.

Exchange's built-in Malware Agent is not designed to address all malicious code protection workloads. This workload is best handled by third-party anti-virus and intrusion prevention software.

Site must utilize an approved DoD scanner. Exchange Malware software has a limited scanning capability and does not scan files that are downloaded, opened, or executed.

Checks

Site must utilize an approved DoD third party malicious code scanner.

Consult with System Administrator to demonstrate the application being used to provide malicious code protection in the Exchange implementation.

If System Administrator is unable to demonstrate a third party malicious code protection application, this is a finding.

If System Administrator is unaware of a third party malicious code protection application, this is a finding.

Fix

Following vendor best practice guidance, install and configure the third party malicious code protection application.
V-70055 No Change
Findings ID: EX13-MB-003030 Rule ID: SV-84677r1_rule Severity: medium CCI: CCI-001242

Discussion

Malicious code protection mechanisms include, but are not limited, to, anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated.

Malicious code includes viruses, worms, Trojan horses, and Spyware. It is not enough to simply have the software installed; this software must periodically scan the system to search for malware on an organization-defined frequency.

Exchange's built-in Malware Agent is not designed to address all malicious code protection workloads. This workload is best handled by third-party anti-virus and intrusion prevention software.

Site must utilize an approved DoD scanner. Exchange Malware software has a limited scanning capability and does not scan files that are downloaded, opened, or executed.

Checks

Open the Exchange Management Shell and enter the following command:

Get-TransportAgent "Malware Agent"

If the value of Enabled is set to True, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

& env:ExchangeInstallPath\Scripts\Disable-Antimalwarescanning.ps1
V-70057 No Change
Findings ID: EX13-MB-000345 Rule ID: SV-84679r1_rule Severity: low CCI: CCI-000366

Discussion

Administrator responsibilities include the ability to react to unplanned maintenance tasks or emergency situations that may require Public Folder Store data manipulation. Occasionally, there may be a need to start the server with "unmounted" data stores if manual maintenance is being performed on them. Failure to uncheck the "do not mount on startup" condition will result in unavailability of Public Folder services.

Correct configuration of this control will prevent unplanned outages due to being enabled. When maintenance is being performed, care should be taken to clear the check box task completion so public folder stores are available to users (unmounted public folder stores are not available to users).

Checks

If public folders are not used, this check is not applicable.

Open the Exchange Management Shell and enter the following command:

Get-PublicFolderDatabase | Select Name, Identity, MountAtStartup

If the value of MountAtStartup is not set to True, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-PublicFolderDatabase -Identity <'IdentityName'> -MountAtStartup $true

Note: The <IdentityName> value must be in quotes.
V-70059 No Change
Findings ID: EX13-MB-000340 Rule ID: SV-84681r1_rule Severity: medium CCI: CCI-002605

Discussion

Failure to install the most current Exchange service pack leaves a system vulnerable to exploitation. Current service packs correct known security and system vulnerabilities.

Checks

Determine the most current, approved service pack.

Open the Exchange Management Shell and enter the following command:

Get-ExchangeServer | fl Name, AdminDisplayVersion

If the value of AdminDisplayVersion does not return the most current, approved service pack, this is a finding.

Fix

Install the most current, approved service pack.
V-70061 No Change
Findings ID: EX13-MB-000335 Rule ID: SV-84683r1_rule Severity: medium CCI: CCI-002385

Discussion

To protect Exchange Server mailbox databases and the data they contain by configuring Mailbox servers and databases for high availability and site resilience.

A database availability group (DAG) is a component of the Mailbox server high availability and site resilience framework built into Microsoft Exchange Server 2013. A DAG is a group of Mailbox servers that hosts a set of databases and provides automatic database-level recovery from failures that affect individual servers or databases.
A DAG is a boundary for mailbox database replication and database and server switchovers and failovers.

Any server in a DAG can host a copy of a mailbox database from any other server in the DAG. When a server is added to a DAG, it works with the other servers in the DAG to provide automatic recovery from failures that affect mailbox databases, such as a disk, server, or network failure.

Checks

Review the Email Domain Security Plan (EDSP).

Determine if the Exchange Mailbox databases are using redundancy.

Open an Exchange Admin Center.

Navigate to and select Microsoft Exchange >> Microsoft Exchange On - Premises <server.domain> >> Organization Configuration >> Mailbox.

In the right pane, if two or more Mailbox servers are not listed, this is a finding.

Fix

Update the EDSP.

Add two or more Mailbox servers to the database availability group.
V-70063 No Change
Findings ID: EX13-MB-000330 Rule ID: SV-84685r1_rule Severity: medium CCI: CCI-002385

Discussion

The Simple Mail Transfer Protocol (SMTP) connector is used by Exchange to send and receive messages from server to server. Several controls work together to provide security between internal servers. This setting controls the encryption method used for communications between servers. With this feature enabled, only servers capable of supporting Transport Layer Security (TLS) will be able to send and receive mail within the domain.

The use of secure communication prevents eavesdroppers from reading or modifying communications between mail clients and servers. While sensitive message bodies should be encrypted by the sender at the client, requiring a secure connection from server to server adds protection by encrypting the sender and recipient information that cannot be encrypted by the sender.

Individually, channel security and encryption can be compromised by attackers. Used together, email becomes a more difficult target, and security is heightened. Failure to enable this feature gives eavesdroppers an opportunity to read or modify messages between servers.

Checks

Open the Exchange Management Shell and enter the following command:

Get-SendConnector | Select Name, Identity, TlsAuthLevel

For each Send connector, if the value of TlsAuthLevel is not set to DomainValidation, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-SendConnector -Identity <'IdentityName'> -TlsAuthLevel DomainValidation

Note: The <IdentityName> value must be in quotes.

Repeat the procedure for each Send connector.
V-70065 No Change
Findings ID: EX13-MB-000325 Rule ID: SV-84687r1_rule Severity: medium CCI: CCI-002385

Discussion

Automated connection responses occur as a result of FTP or Telnet connections, when connecting to those services. They report a successful connection by greeting the connecting client and stating the name, release level, and (often) additional information regarding the responding product. While useful to the connecting client, connection responses can also be used by a third party to determine operating system or product release levels on the target server. The result can include disclosure of configuration information to third parties, paving the way for possible future attacks. For example, when querying the SMTP service on port 25, the default response looks similar to this one:

220 exchange.mydomain.org Microsoft ESMTP MAIL Service, Version: 6.0.3790.211 ready at Wed, 2 Feb 2005 23:40:00 -0500

Changing the response to hide local configuration details reduces the attack profile of the target.

Checks

Open the Exchange Management Shell and enter the following command:

Get-ReceiveConnector | Select Name, Identity, Banner

For each Receive connector, if the value of Banner is not set to 220 SMTP Server Ready, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-ReceiveConnector -Identity <'IdentityName'> -Banner '220 SMTP Server Ready'

Note: The <IdentityName> and 220 SMTP Server Ready values must be in quotes.

Repeat the procedures for each Receive connector.
V-70067 No Change
Findings ID: EX13-MB-000285 Rule ID: SV-84689r1_rule Severity: medium CCI: CCI-001812

Discussion

Default product installations may provide more generous access permissions than are necessary to run the application. By examining and tailoring access permissions to more closely provide the least amount of privilege possible, attack vectors that align with user permissions are less likely to access more highly secured areas.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the authorized groups and users that have access to the Exchange application directories.

Verify the access permissions on the directory match the access permissions listed in the EDSP.

If any group or user has different access permissions, this is a finding.

Note: The default installation directory is \Program Files\Microsoft\Exchange Server\V15.

Fix

Update the EDSP.

Navigate to the Exchange application directory and remove or modify the group or user access permissions.

Note: The default installation directory is \Program Files\Microsoft\Exchange Server\V15.
V-70069 No Change
Findings ID: EX13-MB-000290 Rule ID: SV-84691r1_rule Severity: medium CCI: CCI-001813

Discussion

Exchange software, as with other application software installed on a host system, must be included in a system baseline record and periodically reviewed; otherwise, unauthorized changes to the software may not be discovered. This effort is a vital step to securing the host and the applications, as it is the only method that may provide the ability to detect and recover from otherwise undetected changes, such as those that result from worm or bot intrusions.

The Exchange software and configuration baseline is created and maintained for comparison during scanning efforts. Operational procedures must include baseline updates as part of configuration management tasks that change the software and configuration.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the software baseline.

Review the application software baseline procedures and implementation artifacts.

Note the list of files and directories included in the baseline procedure for completeness.

If an email software copy exists to serve as a baseline and is available for comparison during scanning efforts, this is not a finding.

Fix

Implement an email software baseline process and update the EDSP.
V-70071 No Change
Findings ID: EX13-MB-000295 Rule ID: SV-84693r1_rule Severity: medium CCI: CCI-001814

Discussion

Monitoring software files for changes against a baseline on a regular basis may help detect the possible introduction of malicious code on a system.

Checks

Review the Email Domain Security Plan (EDSP).

Determine whether the site monitors system files (e.g., *.exe, *.bat, *.com, *.cmd, and *.dll) on servers for unauthorized changes against a baseline on a weekly basis.

If software files are not monitored for unauthorized changes, this is a finding.

Note: A properly configured HBSS Policy Auditor File Integrity Monitor (FIM) module will meet the requirement for file integrity checking. The Asset module within HBSS does not meet this requirement.

Fix

Update the EDSP.

Monitor the software files (e.g., *.exe, *.bat, *.com, *.cmd, and *.dll) on Exchange servers for unauthorized changes against a baseline on a weekly basis.

Note: This can be done with the use of various monitoring tools.
V-70073 No Change
Findings ID: EX13-MB-000300 Rule ID: SV-84695r1_rule Severity: medium CCI: CCI-001762

Discussion

Unneeded but running services offer attackers an enhanced attack profile, and attackers are constantly watching to discover open ports with running services. By analyzing and disabling unneeded services, the associated open ports become unresponsive to outside queries, and servers become more secure as a result.

Exchange Server has role-based server deployment to enable protocol path control and logical separation of network traffic types.

For example, a server implemented in the Client Access role (i.e., Outlook Web App [OWA]) is configured and tuned as a web server using web protocols. A client access server exposes only web protocols (HTTP/HTTPS) enabling system administrators to optimize the protocol path and disable all services unnecessary for Exchange web services. Similarly, servers created to host mailboxes are dedicated to that task and must operate only the services needed for mailbox hosting. (Exchange servers must also operate some Web services, but only to the degree that Exchange requires the IIS engine in order to function).

Because POP3 and IMAP4 clients are not included in the standard desktop offering, they must be disabled.

Checks

Review the Email Domain Security Plan (EDSP).

Note: Required services will vary between organizations and will vary depending on the role of the individual system. Organizations will develop their own list of services, which will be documented and justified with the ISSO. The site’s list will be provided for any security review. Services that are common to multiple systems can be addressed in one document. Exceptions for individual systems should be identified separately by system.

Open a Windows PowerShell and enter the following command:

Get-Service | Where-Object {$_.status -eq 'running'}

Note: The command returns a list of installed services and the status of that service.

If the services required are not documented in the EDSP or undocumented or unnecessary services are running, this is a finding.

If any undocumented or unnecessary services are running, this is a finding.

Fix

Update the EDSP with the services required for the system to function.

Remove or disable any services that are not required.
V-70075 No Change
Findings ID: EX13-MB-000305 Rule ID: SV-84697r1_rule Severity: medium CCI: CCI-001953

Discussion

Identification and authentication provide the foundation for access control. Access to email services applications require NTLM authentication. Outlook Anywhere, if authorized for use by the site, must use NTLM authentication when accessing email.

Note: There is a technical restriction in Exchange OA that requires a direct SSL connection from Outlook to the CA server. There is also a constraint where Microsoft supports that the CA server must participate in the AD domain inside the enclave. For this reason, Outlook Anywhere must be deployed only for enclave-sourced Outlook users.

Checks

Open the Exchange Management Shell and enter the following command:

Get-OutlookAnywhere

Get-OutlookAnywhere | Select Name, Identity, InternalClientAuthenticationMethod, ExternalClientAuthenticationMethod

If the value of InternalClientAuthenticationMethod and the value of ExternalClientAuthenticationMethod is not set to NTLM, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

For InternalClientAuthenticationMethod:

Set-OutlookAnywhere -Identity '<IdentityName'> -InternalClientAuthenticationMethod NTLM

For ExternalClientAuthenticationMethod:

Set-OutlookAnywhere -Identity '<IdentityName'> -ExternalClientAuthenticationMethod NTLM
V-70077 No Change
Findings ID: EX13-MB-000310 Rule ID: SV-84699r1_rule Severity: medium CCI: CCI-002530

Discussion

In the same way that added security layers can provide a cumulative positive effect on security posture, multiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit to one application can lead to an exploit of other applications sharing the same security context. For example, an exploit to a web server process that leads to unauthorized administrative access to the host system can most likely lead to a compromise of all applications hosted by the same system.

Email services should be installed on a partition that does not host other applications. Email services should never be installed on a Domain Controller/Directory Services server.

Checks

Review the Email Domain Security Plan (EDSP).

Determine the directory Exchange is installed.

Open Windows Explorer.

Navigate to where Exchange is installed.

If Exchange resides on a directory or partition other than that of the OS and does not have other applications installed (unless approved by the ISSO), this is not a finding.

Fix

Update the EDSP.

Install Exchange on a dedicated application directory or partition separate than that of the OS.
V-70079 No Change
Findings ID: EX13-MB-000315 Rule ID: SV-84701r1_rule Severity: medium CCI: CCI-002385

Discussion

Attackers can use automated messages to determine whether a user account is active, in the office, traveling, and so on. An attacker might use this information to conduct future attacks. Ensure that delivery reports to remote domains are disabled. Before enabling this setting, first configure a remote domain using the EMC or the New-RemoteDomain cmdlet.

Checks

Open the Exchange Management Shell and enter the following command:

Get-RemoteDomain | Select Identity, DeliveryReportEnabled

If the value of DeliveryReportEnabled is not set to False, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-RemoteDomain -Identity <'IdentityName'> -DeliveryReportEnabled $false

Note: The <IdentityName> value must be in quotes.
V-70081 No Change
Findings ID: EX13-MB-000320 Rule ID: SV-84703r1_rule Severity: medium CCI: CCI-002385

Discussion

Attackers can use automated messages to determine whether a user account is active, in the office, traveling, and so on. An attacker might use this information to conduct future attacks. Ensure that nondelivery reports to remote domains are disabled. Before enabling this setting, first configure a remote domain using the EMC or the New-RemoteDomain cmdlet.

Checks

Open the Exchange Management Shell and enter the following command:

Get-RemoteDomain | Select Name, Identity, NDREnabled

If the value of NDREnabled is not set to False, this is a finding.

Fix

Open the Exchange Management Shell and enter the following command:

Set-RemoteDomain -Identity <'IdentityName'> -NDREnabled $false

Note: The <IdentityName> value must be in quotes.