Microsoft Exchange 2016 Mailbox Server Security Technical Implementation Guide

Version

EX16-MB-000110

Vuln IDs

V-228364
V-80643

Rule IDs

SV-228364r508018_rule
SV-95353

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 that 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: C-30597r496888_chk

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: F-30582r496889_fix

Open the Exchange Management Shell and enter the following command: Set-ExchangeServer -Identity <'IdentityName'> -ErrorReportingEnabled $false Note: The <IdentityName> value must be in single quotes. Repeat the process for each Exchange Server.

Exchange must protect audit data against unauthorized read access.

AU-9 - Medium - CCI-000162 - V-228365 - SV-228365r508018_rule

RMF Control

AU-9

Severity

CCI

CCI-000162

Version

EX16-MB-000120

Vuln IDs

V-228365
V-80645

Rule IDs

SV-228365r508018_rule
SV-95355

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: C-30598r496891_chk

Review the Email Domain Security Plan (EDSP) or document that contains this information. 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: F-30583r496892_fix

Update the EDSP to specify the authorized groups or users that should have "Read" access to the audit data or verify that this information is documented by the organization. Restrict any unauthorized groups' or users' "Read" access to the audit logs.

Exchange must not send Customer Experience reports to Microsoft.

CM-7 - Medium - CCI-000381 - V-228366 - SV-228366r508018_rule

RMF Control

CM-7

Severity

CCI

Version

EX16-MB-000130

Vuln IDs

V-228366
V-80647

Rule IDs

SV-228366r508018_rule
SV-95357

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 that 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 must not be sent to Microsoft.

Checks: C-30599r496894_chk

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: F-30584r496895_fix

Open the Exchange Management Shell and enter the following command: Set-OrganizationConfig -CustomerFeedbackEnabled $false

Exchange must protect audit data against unauthorized access.

AU-9 - Medium - CCI-000163 - V-228367 - SV-228367r508018_rule

RMF Control

AU-9

Severity

CCI

CCI-000163

Version

EX16-MB-000140

Vuln IDs

V-228367
V-80649

Rule IDs

SV-228367r508018_rule
SV-95359

Checks: C-30600r496897_chk

Review the Email Domain Security Plan (EDSP) or document that contains this information. 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: F-30585r496898_fix

Update the EDSP to specify the authorized groups or users that should have access to the audit data or verify that this information is documented by the organization. Restrict any unauthorized groups' or users' modify permissions for the audit logs.

Exchange must protect audit data against unauthorized deletion.

AU-9 - Medium - CCI-000164 - V-228368 - SV-228368r508018_rule

RMF Control

AU-9

Severity

CCI

CCI-000164

Version

EX16-MB-000150

Vuln IDs

V-228368
V-80651

Rule IDs

SV-228368r508018_rule
SV-95361

Checks: C-30601r496900_chk

Review the Email Domain Security Plan (EDSP) or document that contains this information. 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: F-30586r496901_fix

Update the EDSP to specify the authorized groups or users that should have "Delete" permissions for the audit data or verify that this information is documented by the organization. Restrict any unauthorized groups' or users' "Delete" permissions for the audit logs.

Exchange Audit data must be on separate partitions.

AU-9 - Medium - CCI-001348 - V-228369 - SV-228369r508018_rule

RMF Control

AU-9

Severity

CCI

CCI-001348

Version

EX16-MB-000160

Vuln IDs

V-228369
V-80653

Rule IDs

SV-228369r508018_rule
SV-95363

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: C-30602r496903_chk

Review the Email Domain Security Plan (EDSP) or document that contains this information. 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: F-30587r496904_fix

Update the EDSP to specify the audit logs' assigned partition or verify that this information is documented by the organization. Configure the audit log location to be on a partition drive separate from the application.

Exchange Local machine policy must require signed scripts.

CM-5 - Medium - CCI-001749 - V-228370 - SV-228370r508018_rule

RMF Control

CM-5

Severity

CCI

CCI-001749

Version

EX16-MB-000170

Vuln IDs

V-228370
V-80655

Rule IDs

SV-228370r508018_rule
SV-95365

Scripts often provide a way for attackers to infiltrate a system, especially scripts 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: C-30603r496906_chk

Open the Exchange Management Shell and enter the following command: Get-ExecutionPolicy If the value returned is not "RemoteSigned", this is a finding.

Fix: F-30588r496907_fix

Open the Exchange Management Shell and enter the following command: Set-ExecutionPolicy RemoteSigned

The Exchange Internet Message Access Protocol 4 (IMAP4) service must be disabled.

CM-7 - Medium - CCI-000381 - V-228371 - SV-228371r557506_rule

RMF Control

CM-7

Severity

CCI

Version

EX16-MB-000180

Vuln IDs

V-228371
V-80657

Rule IDs

SV-228371r557506_rule
SV-95367

IMAP4 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: C-30604r557505_chk

Note: This requirement applies to IMAP4. IMAP Secure is not restricted and does not apply to this requirement. 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 single quotes. If the value of "Start" is not set to "4", this is a finding.

Fix: F-30589r496910_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.

The Exchange Post Office Protocol 3 (POP3) service must be disabled.

CM-7 - Medium - CCI-000381 - V-228372 - SV-228372r508018_rule

RMF Control

CM-7

Severity

CCI

Version

EX16-MB-000190

Vuln IDs

V-228372
V-80659

Rule IDs

SV-228372r508018_rule
SV-95369

POP3 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 POP3.

Checks: C-30605r496912_chk

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 single quotes. If the value of "Start" is not set to "4", this is a finding.

Fix: F-30590r496913_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.

Exchange Mailbox databases must reside on a dedicated partition.

SC-2 - Medium - CCI-001082 - V-228373 - SV-228373r508018_rule

RMF Control

SC-2

Severity

CCI

CCI-001082

Version

EX16-MB-000200

Vuln IDs

V-228373
V-80661

Rule IDs

SV-228373r508018_rule
SV-95371

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: C-30606r496915_chk

Review the Email Domain Security Plan (EDSP) or document that contains this information. 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, navigate to the mailbox databases, and verify they are on a dedicated partition. If the mailbox databases are not on a dedicated partition, this is a finding.

Fix: F-30591r496916_fix

Update the EDSP to specify the location where the Exchange Mailbox databases reside or verify that this information is documented by the organization. Configure the mailbox databases on a dedicated partition.

Exchange Internet-facing Send connectors must specify a Smart Host.

SC-20 - Medium - CCI-001178 - V-228374 - SV-228374r508018_rule

RMF Control

SC-20

Severity

CCI

CCI-001178

Version

EX16-MB-000210

Vuln IDs

V-228374
V-80663

Rule IDs

SV-228374r508018_rule
SV-95373

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: C-30607r496918_chk

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: F-30592r496919_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 single quotes. Repeat the procedure for each Send connector.

Exchange internal Receive connectors must require encryption.

SC-23 - Medium - CCI-001184 - V-228375 - SV-228375r557511_rule

RMF Control

SC-23

Severity

CCI

CCI-001184

Version

EX16-MB-000220

Vuln IDs

V-228375
V-80665

Rule IDs

SV-228375r557511_rule
SV-95375

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. Multiple values can be separated by commas, but some values have dependencies and exclusions. AuthMechanism may include other mechanisms as long as the "Tls" is identified. • Only use the value "None" by itself. • The value "BasicAuthRequireTLS" requires the values "BasicAuth" and "Tls". • The only other value that can be used with ExternalAuthoritative is "Tls". • The value "Tls" is required when the value of the RequireTLS parameter is "$true". • The value "ExternalAuthoritative" requires the value of the PermissionGroups parameter be set to "ExchangeServers".

Checks: C-30608r557510_chk

Note: AuthMechanism may include other mechanisms as long as the "Tls" is identified. 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: F-30593r496922_fix

Open the Exchange Management Shell and enter the following command: Set-ReceiveConnector -Identity <'IdentityName'> -AuthMechanism 'Tls' Note: The <IdentityName> value must be in single quotes. Repeat the procedures for each Receive connector.

Exchange Mailboxes must be retained until backups are complete.

SC-28 - Medium - CCI-001199 - V-228376 - SV-228376r508018_rule

RMF Control

SC-28

Severity

CCI

CCI-001199

Version

EX16-MB-000270

Vuln IDs

V-228376
V-80667

Rule IDs

SV-228376r508018_rule
SV-95377

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: C-30609r496924_chk

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: F-30594r496925_fix

Open the Exchange Management Shell and enter the following command: Set-MailboxDatabase -Identity <'IdentityName'> -RetainDeletedItemsUntilBackup $true Note: The <IdentityName> value must be in single quotes.

Exchange email forwarding must be restricted.

SC-28 - Medium - CCI-001199 - V-228377 - SV-228377r508018_rule

RMF Control

SC-28

Severity

CCI

CCI-001199

Version

EX16-MB-000290

Vuln IDs

V-228377
V-80669

Rule IDs

SV-228377r508018_rule
SV-95379

Auto-forwarded email accounts do not meet the requirement for digital signature and encryption of Controlled Unclassified Information (CUI) and Personally Identifiable Information (PII) in accordance with 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: C-30610r496927_chk

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, Identity, Filter 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: F-30595r496928_fix

Update the EDSP. Open the Exchange Management Shell and enter the following command: Set-Mailbox -Identity <'IdentityName'> -ForwardingSMTPAdddress $null Note: The <IdentityName> value must be in quotes.

Exchange email-forwarding SMTP domains must be restricted.

SC-28 - Medium - CCI-001199 - V-228378 - SV-228378r508018_rule

RMF Control

SC-28

Severity

CCI

CCI-001199

Version

EX16-MB-000300

Vuln IDs

V-228378
V-80671

Rule IDs

SV-228378r508018_rule
SV-95381

Checks: C-30611r496930_chk

Review the Email Domain Security Plan (EDSP) or document that contains this information. 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 (NA). 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: F-30596r496931_fix

Update the EDSP to specify any accounts that have been authorized to have email auto-forwarded or verify that this information is documented by the organization. Open the Exchange Management Shell and enter the following command: Set- RemoteDomain -Identity <RemoteDomainIdParameter>

Exchange Mail quota settings must not restrict receiving mail.

SC-5 - Low - CCI-001094 - V-228379 - SV-228379r508018_rule

RMF Control

SC-5

Severity

CCI

CCI-001094

Version

EX16-MB-000310

Vuln IDs

V-228379
V-80673

Rule IDs

SV-228379r508018_rule
SV-95383

Checks: C-30612r496933_chk

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 "ProhibitSendReceiveQuota" is set to an alternate value and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix: F-30597r496934_fix

Open the Exchange Management Shell and enter the following command: Set-MailboxDatabase -Identity <'IdentityName'> -ProhibitSendReceiveQuota Unlimited Note: The <IdentityName> value must be in single quotes. or Enter the value as identified by the EDSP that has obtained a signoff with risk acceptance.

Exchange Mail Quota settings must not restrict receiving mail.

SC-5 - Low - CCI-001094 - V-228380 - SV-228380r508018_rule

RMF Control

SC-5

Severity

CCI

CCI-001094

Version

EX16-MB-000320

Vuln IDs

V-228380
V-80675

Rule IDs

SV-228380r508018_rule
SV-95385

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. Multiple controls 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: C-30613r496936_chk

Review the Email Domain Security Plan (EDSP) or document that contains this information. Determine the value for the 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: F-30598r496937_fix

Update the EDSP to specify the value for the Prohibit Send Quota limit or verify that this information is documented by the organization. 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 single quotes.

Exchange Mailbox Stores must mount at startup.

SC-5 - Low - CCI-001094 - V-228381 - SV-228381r508018_rule

RMF Control

SC-5

Severity

CCI

CCI-001094

Version

EX16-MB-000340

Vuln IDs

V-228381
V-80677

Rule IDs

SV-228381r508018_rule
SV-95387

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: C-30614r496939_chk

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: F-30599r496940_fix

Open the Exchange Management Shell and enter the following command: Set-MailboxDatabase -Identity <'IdentityName'> -MountAtStartup $true Note: The <IdentityName> value must be in single quotes.

Exchange Message size restrictions must be controlled on Receive connectors.

SC-5 - Low - CCI-001095 - V-228382 - SV-228382r508018_rule

RMF Control

SC-5

Severity

CCI

Version

EX16-MB-000350

Vuln IDs

V-228382
V-80679

Rule IDs

SV-228382r508018_rule
SV-95389

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 the global value with the rationale documented in the Email Domain Security Plan (EDSP).

Checks: C-30615r496942_chk

Review the EDSP or document that contains this information. 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: F-30600r496943_fix

Update the EDSP to specify the global maximum message receive size and, if operationally necessary, to document signoff with risk acceptance for the Receive connector to have a different value, or verify that this information is documented by the organization. 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 single quotes. or Enter the value as identified by the EDSP that has obtained a signoff with risk acceptance. Repeat the procedure for each Receive connector.

Exchange Receive connectors must control the number of recipients per message.

SC-5 - Low - CCI-001095 - V-228383 - SV-228383r557508_rule

RMF Control

SC-5

Severity

CCI

Version

EX16-MB-000360

Vuln IDs

V-228383
V-80681

Rule IDs

SV-228383r557508_rule
SV-95391

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: C-30616r557507_chk

Note: This requirement applies to IMAP4. IMAP Secure is not restricted and does not apply to this requirement. Review the Email Domain Security Plan (EDSP) or document that contains this information. 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 "MaxRecipientsPerMessage" is set to a value other than "5000" and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix: F-30601r496946_fix

Update the EDSP to specify the "MaxRecipientsPerMessage" value or verify that this information is documented by the organization. Open the Exchange Management Shell and enter the following command: Set-ReceiveConnector -Identity <'IdentityName'> -MaxRecipientsPerMessage 5000 Note: The <IdentityName> value must be in single quotes. or Enter the value as identified by the EDSP that has obtained a signoff with risk acceptance. Repeat the procedure for each Receive connector.

The Exchange Receive Connector Maximum Hop Count must be 60.

SC-5 - Low - CCI-001095 - V-228384 - SV-228384r508018_rule

RMF Control

SC-5

Severity

CCI

Version

EX16-MB-000380

Vuln IDs

V-228384
V-80683

Rule IDs

SV-228384r508018_rule
SV-95393

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 the hop count is set too high, an undeliverable message may cycle between servers, raising the risk of network congestion.

Checks: C-30617r496948_chk

Review the Email Domain Security Plan (EDSP) or document that contains this information. Determine the Max Hop Count 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: F-30602r496949_fix

Update the EDSP to specify the "MaxHopCount" value or verify that this information is documented by the organization. Open the Exchange Management Shell and enter the following command: Set-ReceiveConnector -MaxHopCount 60 or Enter the value as identified by the EDSP that has obtained a signoff with risk acceptance. Repeat the procedure for each Receive connector.

Exchange Message size restrictions must be controlled on Send connectors.

SC-5 - Low - CCI-001095 - V-228385 - SV-228385r508018_rule

RMF Control

SC-5

Severity

CCI

Version

EX16-MB-000410

Vuln IDs

V-228385
V-80685

Rule IDs

SV-228385r508018_rule
SV-95395

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: C-30618r496951_chk

Review the Email Domain Security Plan (EDSP) or document that contains this information. 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: F-30603r496952_fix

Update the EDSP to specify the "MaxMessageSize" value or verify that this information is documented by the organization. Open the Exchange Management Shell and enter the following command: Set-SendConnector -Identity <'IdentityName'> -MaxMessageSize <MaxSendSize> Note: The <IdentityName> value must be in single quotes. or Enter the value as identified by the EDSP that has obtained a signoff with risk acceptance. Repeat the procedures for each Send connector.

The Exchange Send connector connections count must be limited.

SC-5 - Low - CCI-001095 - V-228386 - SV-228386r508018_rule

RMF Control

SC-5

Severity

CCI

Version

EX16-MB-000420

Vuln IDs

V-228386
V-80687

Rule IDs

SV-228386r508018_rule
SV-95397

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 the limit is 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: C-30619r496954_chk

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 "MaxOutboundConnections" is set to a value other than "1000" and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix: F-30604r496955_fix

Update the EDSP to specify the "MaxOutboundConnections" value. Open the Exchange Management Shell and enter the following command: Set-TransportServer -Identity <'IdentityName'> -MaxOutboundConnections 1000 Note: The <IdentityName> value must be in single quotes. or Enter the value as identified by the EDSP that has obtained a signoff with risk acceptance.

The Exchange global inbound message size must be controlled.

SC-5 - Low - CCI-001095 - V-228387 - SV-228387r508018_rule

RMF Control

SC-5

Severity

CCI

Version

EX16-MB-000430

Vuln IDs

V-228387
V-80689

Rule IDs

SV-228387r508018_rule
SV-95399

Email system availability depends in part on best practice strategies for setting tuning configurations. Message size limits should be set to 10 megabytes (MB) 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 "MaxReceiveSize" 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 Active Directory (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: C-30620r496957_chk

Review the Email Domain Security Plan (EDSP) or document that contains this information. 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 "MaxReceiveSize" is set to an alternate value and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix: F-30605r496958_fix

Update the EDSP to specify the "MaxReceiveSize" value or verify that this information is documented by the organization. Open the Exchange Management Shell and enter the following command: Set-TransportConfig -MaxReceiveSize 10MB or Enter the value as identified by the EDSP that has obtained a signoff with risk acceptance.

The Exchange global outbound message size must be controlled.

SC-5 - Low - CCI-001095 - V-228388 - SV-228388r508018_rule

RMF Control

SC-5

Severity

CCI

Version

EX16-MB-000440

Vuln IDs

V-228388
V-80691

Rule IDs

SV-228388r508018_rule
SV-95401

Email system availability depends in part on best practice strategies for setting tuning configurations. Message size limits should be set to 10 megabytes (MB) 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 "MaxReceiveSize" 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 Active Directory (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: C-30621r496960_chk

Review the Email Domain Security Plan (EDSP) or document that contains this information. 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 "MaxSendSize" is set to an alternate value and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix: F-30606r496961_fix

Update the EDSP to specify the "MaxSendSize" value or verify that this information is documented by the organization. Open the Exchange Management Shell and enter the following command: Set-TransportConfig -MaxSendSize 10MB or Enter the value as identified by the EDSP that has obtained a signoff with risk acceptance.

The Exchange Outbound Connection Limit per Domain Count must be controlled.

SC-5 - Low - CCI-001095 - V-228389 - SV-228389r508018_rule

RMF Control

SC-5

Severity

CCI

Version

EX16-MB-000450

Vuln IDs

V-228389
V-80693

Rule IDs

SV-228389r508018_rule
SV-95403

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 as a delivery tuning mechanism. If the limit is too low, connections may be dropped. If the limit is 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: C-30622r496963_chk

Review the Email Domain Security Plan (EDSP) or document that contains this information. Determine the value for Maximum Outbound 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 "MaxPerDomainOutboundConnections" is set to a value other than "20" and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix: F-30607r496964_fix

Update the EDSP to specify the "MaxPerDomainOutboundConnection" value or verify that this information is documented by the organization. Open the Exchange Management Shell and enter the following command: Set-TransportService -Identity <'IdentityName'> -MaxPerDomainOutboundConnections 20 Note: The <IdentityName> value must be in single quotes. or Enter the value as identified by the EDSP that has obtained a signoff with risk acceptance.

The Exchange Outbound Connection Timeout must be 10 minutes or less.

SC-5 - Low - CCI-001095 - V-228390 - SV-228390r508018_rule

RMF Control

SC-5

Severity

CCI

Version

EX16-MB-000460

Vuln IDs

V-228390
V-80695

Rule IDs

SV-228390r508018_rule
SV-95405

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: C-30623r496966_chk

Review the Email Domain Security Plan (EDSP) or document that contains this information. 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 a value other than "00:10:00" and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix: F-30608r496967_fix

Update the EDSP to specify the "ConnectionInactivityTimeOut" value. 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 single quotes. or Enter the value as identified by the EDSP that has obtained a signoff with risk acceptance.

Exchange Internal Receive connectors must not allow anonymous connections.

SI-8 - Medium - CCI-001308 - V-228391 - SV-228391r508018_rule

RMF Control

SI-8

Severity

CCI

Version

EX16-MB-000470

Vuln IDs

V-228391
V-80697

Rule IDs

SV-228391r508018_rule
SV-95407

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), 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: C-30624r496969_chk

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: F-30609r496970_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 single quotes. Example: Set-ReceiveConnector -Identity <'IdentityName'> -PermissionGroups ExchangeUsers Repeat the procedures for each Receive connector.

Exchange external/Internet-bound automated response messages must be disabled.

SI-8 - Medium - CCI-001308 - V-228392 - SV-228392r508018_rule

RMF Control

SI-8

Severity

CCI

Version

EX16-MB-000480

Vuln IDs

V-228392
V-80699

Rule IDs

SV-228392r508018_rule
SV-95409

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, and 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: C-30625r496972_chk

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: F-30610r496973_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 single quotes.

Exchange must have anti-spam filtering installed.

SI-8 - Medium - CCI-001308 - V-228393 - SV-228393r508018_rule

RMF Control

SI-8

Severity

CCI

Version

EX16-MB-000490

Vuln IDs

V-228393
V-80701

Rule IDs

SV-228393r508018_rule
SV-95411

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 2016 provides both anti-spam and anti-malware protection out of the box. The Exchange 2016 anti-spam and anti-malware product capabilities are limited but still provide some protection.

Checks: C-30626r496975_chk

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 (NA). 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: F-30611r496976_fix

Update the EDSP with the anti-spam mechanism used. Install the AntiSpam module. Open the Exchange Management Shell and enter the following command: & $env:ExchangeInstallPath\Scripts\Install-AntiSpamAgents.ps1

Exchange must have anti-spam filtering enabled.

SI-8 - Medium - CCI-001308 - V-228394 - SV-228394r508018_rule

RMF Control

SI-8

Severity

CCI

Version

EX16-MB-000500

Vuln IDs

V-228394
V-80703

Rule IDs

SV-228394r508018_rule
SV-95413

Checks: C-30627r496978_chk

Review the Email Domain Security Plan (EDSP). Note: If using another DoD-approved anti-spam product for email or a DoD-approved email gateway spamming device, such as Enterprise Email Security Gateway (EEMSG), this is not applicable (NA). 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: F-30612r496979_fix

Update the EDSP with the anti-spam mechanism used. 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

Exchange must have anti-spam filtering configured.

SI-8 - Medium - CCI-001308 - V-228395 - SV-228395r508018_rule

RMF Control

SI-8

Severity

CCI

Version

EX16-MB-000510

Vuln IDs

V-228395
V-80705

Rule IDs

SV-228395r508018_rule
SV-95415

Checks: C-30628r496981_chk

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 (NA). 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 IP addresses, this is a finding.

Fix: F-30613r496982_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 with the anti-spam mechanism used. 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>'}

Exchange must not send automated replies to remote domains.

SI-8 - Medium - CCI-001308 - V-228396 - SV-228396r508018_rule

RMF Control

SI-8

Severity

CCI

Version

EX16-MB-000520

Vuln IDs

V-228396
V-80707

Rule IDs

SV-228396r508018_rule
SV-95417

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: C-30629r497053_chk

Note: Automated replies to .MIL or .GOV sites are allowed. Open the Exchange Management Shell and enter the following command: Get-RemoteDomain | Select Name, Identity, AutoReplyEnabled If the value of “AutoReplyEnabled” is set to “True” and is configured to only Reply to .MIL or .GOV sites, this is not a finding. If the value of "AutoReplyEnabled" is not set to "False", this is a finding.

Fix: F-30614r496985_fix

Open the Exchange Management Shell and enter the following command: Set-RemoteDomain -Identity <'IdentityName'> -AutoReplyEnabled $false Note: The <IdentityName> value must be in single quotes.

Exchange servers must have an approved DoD email-aware virus protection software installed.

SI-8 - High - CCI-001308 - V-228397 - SV-228397r508018_rule

RMF Control

SI-8

Severity

CCI

Version

EX16-MB-000530

Vuln IDs

V-228397
V-80709

Rule IDs

SV-228397r508018_rule
SV-95419

With the proliferation of trojans, viruses, and spam attaching themselves to email messages (or attachments), it is necessary to have capable email-aware anti-virus (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 anti-virus engines must be Exchange 2016 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: C-30630r496987_chk

Review the Email Domain Security Plan (EDSP). Determine the anti-virus strategy. Verify the email-aware anti-virus scanner product is Exchange 2016 compatible and DoD approved. If email servers are using an email-aware anti-virus scanner product that is not DoD approved and Exchange 2016 compatible, this is a finding.

Fix: F-30615r496988_fix

Update the EDSP to specify the organization's anti-virus strategy. Install and configure a DoD-approved compatible Exchange 2016 email-aware anti-virus scanner product.

The Exchange Global Recipient Count Limit must be set.

SI-8 - Low - CCI-001308 - V-228398 - SV-228398r508018_rule

RMF Control

SI-8

Severity

CCI

Version

EX16-MB-000540

Vuln IDs

V-228398
V-80711

Rule IDs

SV-228398r508018_rule
SV-95421

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: C-30631r496990_chk

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 "MaxRecipientEnvelopeLimit" is set to an alternate value and has signoff and risk acceptance in the EDSP, this is not a finding.

Fix: F-30616r496991_fix

Update the EDSP to specify the global maximum message recipient count. Set-TransportConfig -MaxRecipientEnvelopeLimit 5000 or Enter the value as identified by the EDSP that has obtained a signoff with risk acceptance. Restart the Microsoft Exchange Information Store service.

The Exchange Receive connector timeout must be limited.

AC-12 - Low - CCI-002361 - V-228399 - SV-228399r508018_rule

RMF Control

AC-12

Severity

CCI

CCI-002361

Version

EX16-MB-000550

Vuln IDs

V-228399
V-80713

Rule IDs

SV-228399r508018_rule
SV-95423

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: C-30632r496993_chk

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: F-30617r496994_fix

Update the EDSP to specify the Connection Timeout value. 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 single quotes. or Enter the value as identified by the EDSP that has obtained a signoff with risk acceptance.

The Exchange application directory must be protected from unauthorized access.

CM-11 - Medium - CCI-001812 - V-228400 - SV-228400r508018_rule

RMF Control

CM-11

Severity

CCI

CCI-001812

Version

EX16-MB-000570

Vuln IDs

V-228400
V-80715

Rule IDs

SV-228400r508018_rule
SV-95425

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: C-30633r496996_chk

Review the Email Domain Security Plan (EDSP) or document that contains this information. 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: F-30618r496997_fix

Update the EDSP to specify the authorized groups and users that have access to the Exchange application directories or verify that this information is documented by the organization. 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.

An Exchange software baseline copy must exist.

CM-5 - Medium - CCI-001813 - V-228401 - SV-228401r508018_rule

RMF Control

CM-5

Severity

CCI

CCI-001813

Version

EX16-MB-000580

Vuln IDs

V-228401
V-80729

Rule IDs

SV-228401r508018_rule
SV-95439

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: C-30634r496999_chk

Review the Email Domain Security Plan (EDSP) or document that contains this information. 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: F-30619r497000_fix

Update the EDSP to specify the software baseline, procedures, and implementation artifacts or verify that this information is documented by the organization.

Exchange software must be monitored for unauthorized changes.

CM-5 - Medium - CCI-001814 - V-228402 - SV-228402r508018_rule

RMF Control

CM-5

Severity

CCI

CCI-001814

Version

EX16-MB-000590

Vuln IDs

V-228402
V-80731

Rule IDs

SV-228402r508018_rule
SV-95441

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: C-30635r497002_chk

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: F-30620r497003_fix

Update the EDSP to specify that the organization monitors system files on servers for unauthorized changes against a baseline on a weekly basis or verify that this information is documented by the organization. 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.

Exchange services must be documented and unnecessary services must be removed or disabled.

CM-7 - Medium - CCI-001762 - V-228403 - SV-228403r557509_rule

RMF Control

CM-7

Severity

CCI

CCI-001762

Version

EX16-MB-000600

Vuln IDs

V-228403
V-80733

Rule IDs

SV-228403r557509_rule
SV-95443

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 Post Office Protocol 3 (POP3) and Internet Message Access Protocol 4 (IMAP4) clients are not included in the standard desktop offering, they must be disabled. While IMAP4 is restricted, IMAP Secure is not restricted and does not apply to this requirement.

Checks: C-30636r497005_chk

Review the Email Domain Security Plan (EDSP). Note: Required services will vary among 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 Information System Security Officer (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, this is a finding. If any undocumented or unnecessary services are running, this is a finding.

Fix: F-30621r497006_fix

Update the EDSP to specify the services required for the system to function. Remove or disable any services that are not required.

Exchange Outlook Anywhere clients must use NTLM authentication to access email.

IA-2 - Medium - CCI-001953 - V-228404 - SV-228404r508018_rule

RMF Control

IA-2

Severity

CCI

CCI-001953

Version

EX16-MB-000610

Vuln IDs

V-228404
V-80735

Rule IDs

SV-228404r508018_rule
SV-95445

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 Outlook Anywhere that requires a direct SSL connection from Outlook to the Certificate Authority (CA) server. There is also a constraint where Microsoft supports that the CA server must participate in the Active Director (AD) domain inside the enclave. For this reason, Outlook Anywhere must be deployed only for enclave-sourced Outlook users.

Checks: C-30637r497008_chk

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" are not set to NTLM, this is a finding.

Fix: F-30622r497009_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

The Exchange Email application must not share a partition with another application.

SC-39 - Medium - CCI-002530 - V-228405 - SV-228405r508018_rule

RMF Control

SC-39

Severity

CCI

CCI-002530

Version

EX16-MB-000620

Vuln IDs

V-228405
V-80737

Rule IDs

SV-228405r508018_rule
SV-95447

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: C-30638r497011_chk

Review the Email Domain Security Plan (EDSP). Determine if 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 operating system and does not have other applications installed (unless approved by the Information System Security Officer [ISSO]), this is not a finding.

Fix: F-30623r497012_fix

Update the EDSP with the location of where Exchange is installed. Install Exchange on a dedicated application directory or partition separate than that of the operating system.

Exchange must not send delivery reports to remote domains.

SC-5 - Medium - CCI-002385 - V-228406 - SV-228406r508018_rule

RMF Control

SC-5

Severity

CCI

Version

EX16-MB-000630

Vuln IDs

V-228406
V-80745

Rule IDs

SV-228406r508018_rule
SV-95455

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 Exchange Management Console (EMC) or the New-RemoteDomain cmdlet.

Checks: C-30639r497014_chk

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: F-30624r497015_fix

Open the Exchange Management Shell and enter the following command: Set-RemoteDomain -Identity <'IdentityName'> -DeliveryReportEnabled $false Note: The <IdentityName> value must be in single quotes.

Exchange must not send nondelivery reports to remote domains.

SC-5 - Medium - CCI-002385 - V-228407 - SV-228407r508018_rule

RMF Control

SC-5

Severity

CCI

Version

EX16-MB-000640

Vuln IDs

V-228407
V-80747

Rule IDs

SV-228407r508018_rule
SV-95457

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 Exchange Management Console (EMC) or the New-RemoteDomain cmdlet.

Checks: C-30640r497017_chk

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: F-30625r497018_fix

Open the Exchange Management Shell and enter the following command: Set-RemoteDomain -Identity <'IdentityName'> -NDREnabled $false Note: The <IdentityName> value must be in single quotes.

The Exchange SMTP automated banner response must not reveal server details.

SC-5 - Medium - CCI-002385 - V-228408 - SV-228408r508018_rule

RMF Control

SC-5

Severity

CCI

Version

EX16-MB-000650

Vuln IDs

V-228408
V-80749

Rule IDs

SV-228408r508018_rule
SV-95459

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: C-30641r497020_chk

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: F-30626r497021_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 single quotes. Repeat the procedures for each Receive connector.

Exchange Internal Send connectors must use an authentication level.

SC-5 - Medium - CCI-002385 - V-228409 - SV-228409r508018_rule

RMF Control

SC-5

Severity

CCI

Version

EX16-MB-000660

Vuln IDs

V-228409
V-80751

Rule IDs

SV-228409r508018_rule
SV-95461

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: C-30642r497023_chk

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: F-30627r497024_fix

Open the Exchange Management Shell and enter the following command: Set-SendConnector -Identity <'IdentityName'> -TlsAuthLevel DomainValidation Note: The <IdentityName> value must be in single quotes. Repeat the procedure for each Send connector.

Exchange must provide Mailbox databases in a highly available and redundant configuration.

SC-5 - Medium - CCI-002385 - V-228410 - SV-228410r508018_rule

RMF Control

SC-5

Severity

CCI