{ "id": 369, "benchmarkId": "MS_Exchange_2019_Mailbox_Server_STIG", "slug": "microsoft_exchange_2019_mailbox_server", "status": "accepted", "statusDate": "2025-05-14T00:00:00.000Z", "title": "Microsoft Exchange 2019 Mailbox Server Security Technical Implementation Guide", "description": "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: disa.stig_spt@mail.mil.", "version": "2", "createdAt": "2025-10-21T11:30:38.201Z", "updatedAt": "2025-10-23T20:54:20.222Z", "groups": [ { "id": 18804, "benchmarkId": 369, "groupId": "V-259663", "title": "SRG-APP-000125", "description": "", "ruleId": "SV-259663r960948_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000058", "ruleTitle": "Exchange audit data must be on separate partitions.", "ruleVulnDiscussion": "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.\n\nSuccessful 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001348", "ruleFixText": "Update the EDSP to specify the audit logs' assigned partition or verify that this information is documented by the organization.\n\nConfigure the audit log location to be on a partition drive separate from the application.", "ruleFixId": "F-63310r942302_fix", "ruleCheckSystem": "C-63402r942301_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) or document that contains this information.\n\nDetermine the audit logs' assigned partition.\n\nBy default, the logs are located on the application partition in \\Program Files\\Microsoft\\Exchange Server\\V15\\Logging.\n\nIf the log files are not on a separate partition from the application, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18805, "benchmarkId": 369, "groupId": "V-259664", "title": "SRG-APP-000131", "description": "", "ruleId": "SV-259664r1015275_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000061", "ruleTitle": "Exchange local machine policy must require signed scripts.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-003992", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-ExecutionPolicy RemoteSigned", "ruleFixId": "F-63311r942305_fix", "ruleCheckSystem": "C-63403r942304_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-ExecutionPolicy\n\nIf the value returned is not \"RemoteSigned\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18786, "benchmarkId": 369, "groupId": "V-259645", "title": "SRG-APP-000014", "description": "", "ruleId": "SV-259645r960759_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000006", "ruleTitle": "Exchange must use encryption for RPC client access.", "ruleVulnDiscussion": "This setting controls whether client machines are forced to use secure channels to communicate with the server. If this feature is enabled, clients will only be able to communicate with the server over secure communication channels.\n\nFailure to require secure connections to the client access server increases the potential for unintended eavesdropping or data loss.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000068", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-RpcClientAccess -Server -EncryptionRequired $true", "ruleFixId": "F-63292r942248_fix", "ruleCheckSystem": "C-63384r942247_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-RpcClientAccess | Select-Object -Property Server, Name, EncryptionRequired\n\nIf the value of \"EncryptionRequired\" is not set to \"True\", this is a finding.\n\nNote: This is configured as \"True\" by default.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18787, "benchmarkId": 369, "groupId": "V-259646", "title": "SRG-APP-000014", "description": "", "ruleId": "SV-259646r960759_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000007", "ruleTitle": "Exchange must use encryption for Outlook Web App (OWA) access.", "ruleVulnDiscussion": "This setting controls whether client machines should be forced to use secure channels to communicate with this virtual directory. If this feature is enabled, clients will only be able to communicate with the directory if they are capable of supporting secure communication with the server.\n\nThe use of secure communication prevents eavesdroppers from reading or modifying communications between servers and clients. The network and DMZ STIG identify criteria for OWA and Public Folder configuration in the network, including Common Access Card (CAC)-enabled preauthentication through an application firewall proxy.\n\nFailure to require secure connections on a website increases the potential for unintended eavesdropping or data loss.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000068", "ruleFixText": "Ensure a trusted public certificate is installed for the Exchange server with the correct FQDNs that will service the domain. This will allow secure communications between clients and the server. This should be done before the server is put into production.\n\nOnce installed, in an elevated Exchange Management Shell, run the following cmdlet to associate the certificate with the IIS service:\n\nEnable-ExchangeCertificate -Thumbprint -Services IIS\n\nSet the OWA URL to use HTTPS instead of HTTP by updating the URLs to HTTPS. \n\nIf the website is \"http://mail.contoso.com\" for both internal and external (for example), run the following cmdlet to set it to HTTPS:\n\nSet-OwaVirtualDirectory -Identity \"\\owa (Default Web Site) -InternalUrl \"https://mail.contoso.com/owa\" -ExternalUrl \"https://mail.contoso.com/owa\"\n\nNote: If this change is made, it must be done for the ECP virtual directory as well. A warning notifies users that this must be done.\n\nOpen IIS Manager and locate the Exchange Server. In the navigation pane on the left, navigate to Sites >> Default Web Site >> owa. In the pane on the right, under /owa Home, in the IIS section, double-click \"SSL Settings\".\n\nCheck the box for \"Require SSL\".", "ruleFixId": "F-63293r942251_fix", "ruleCheckSystem": "C-63385r942250_chk", "ruleCheckContent": "Open an Exchange Management Shell and enter the following command:\n\nGet-ExchangeCertificate |Select-Object -Property Subject,Services,Thumbprint\n\nIf the certificate associated with the IIS service is not a trusted public certificate, this is a finding.\n\nIn the same Exchange Management Shell, run the following cmdlets:\n\nGet-OwaVirtualDirectory | Select-Object -Property internalurl, externalurl\n\nIf the value returned is not https://, this is a finding.\n\nOpen IIS Manager and locate the Exchange Server. In the navigation pane on the left, navigate to Sites >> Default Web Site >> owa. In the pane on the right, under /owa Home, in the IIS section, double-click \"SSL Settings\".\n\nIf the box \"Require SSL\" is not checked, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18793, "benchmarkId": 369, "groupId": "V-259652", "title": "SRG-APP-000089", "description": "", "ruleId": "SV-259652r960879_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000031", "ruleTitle": "Exchange connectivity logging must be enabled.", "ruleVulnDiscussion": "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 Mailbox servers in Exchange 2019 as it holds Mailbox, Client Access, and Hub Transport roles. This must also be completed on Edge Transport servers, as that is a separate role. 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.\n\nNote: Transport configuration settings apply to the organization/global level of the Exchange SMTP path. By checking and setting them on the Mailbox server, the setting will apply to both Hub and Edge server roles.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000169", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-TransportService -Identity <'IdentityName'> -ConnectivityLogEnabled $true\n\nNote: The value must be in quotes.", "ruleFixId": "F-63299r942269_fix", "ruleCheckSystem": "C-63391r942268_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-TransportService | Select-Object -Property Name, Identity, ConnectivityLogEnabled \n\nIf the value of \"ConnectivityLogEnabled\" is not set to \"True\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18788, "benchmarkId": 369, "groupId": "V-259647", "title": "SRG-APP-000014", "description": "", "ruleId": "SV-259647r960759_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000008", "ruleTitle": "Exchange must have forms-based authentication enabled.", "ruleVulnDiscussion": "Identification and Authentication provide the foundation for access control. Access to email services applications in the DOD requires authentication using DOD Public Key Infrastructure (PKI) certificates. Authentication for Outlook Web App (OWA) is used to enable web access to user email mailboxes and should assume that certificate-based authentication has been configured. This setting controls whether forms-based logon should be used by the OWA website. \n\nBecause the DOD requires Common Access Card (CAC)-based authentication to applications, OWA access must be brokered through an application proxy or other preauthenticator, which performs CAC authentication prior to arrival at the CA server. The authenticated request is then forwarded directly to OWA, where authentication is repeated without requiring the user to repeat authentication steps. For this scenario to work, the Application Proxy server must have forms-based authentication enabled, and Exchange must have forms-based Authentication disabled. \n\nIf forms-based Authentication is enabled on the Exchange CA server, it is evidence that the application proxy server is either not correctly configured, or it may be missing.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000068", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-OwaVirtualDirectory -Identity <'IdentityName'> -FormsAuthentication $false\n\nNote: must be in quotes.\n\nExample for the Identity Name: \\owa (Default website)\n\nRestart the IIS service.", "ruleFixId": "F-63294r942254_fix", "ruleCheckSystem": "C-63386r942253_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-OwaVirtualDirectory | Select-Object -Property ServerName, Name, Identity, *Authentication\n\nIf the value of \"FormsAuthentication\" is not set to \"False\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18789, "benchmarkId": 369, "groupId": "V-259648", "title": "SRG-APP-000027", "description": "", "ruleId": "SV-259648r960780_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000016", "ruleTitle": "Exchange must have administrator audit logging enabled.", "ruleVulnDiscussion": "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 any 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.\n\nNote: This administrator auditing feature audits all exchange changes regardless of the user's assigned role or permissions.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001403", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-AdminAuditLogConfig -AdminAuditLogEnabled $true", "ruleFixId": "F-63295r942257_fix", "ruleCheckSystem": "C-63387r942256_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command: \n\nGet-AdminAuditLogConfig | Select-Object -Property Name, AdminAuditLogEnabled\n\nIf the value of \"AdminAuditLogEnabled\" is not set to \"True\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18790, "benchmarkId": 369, "groupId": "V-259649", "title": "SRG-APP-000033", "description": "", "ruleId": "SV-259649r960792_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000019", "ruleTitle": "Exchange servers must use approved DOD certificates.", "ruleVulnDiscussion": "Server certificates are required for many security features in Exchange; without them, the server cannot engage in many forms of secure communication.\n\nFailure to implement valid certificates makes it virtually impossible to secure Exchange's communications.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000213", "ruleFixText": "Remove the non-DOD certificate and import the correct DOD certificates.", "ruleFixId": "F-63296r942260_fix", "ruleCheckSystem": "C-63388r942259_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command: \n\nGet-ExchangeCertificate | Select-Object -Property CertificateDomains, issuer \n\nIf the value of \"CertificateDomains\" does not indicate it is issued by the DOD, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18791, "benchmarkId": 369, "groupId": "V-259650", "title": "SRG-APP-000033", "description": "", "ruleId": "SV-259650r960792_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000020", "ruleTitle": "Exchange must have authenticated access set to integrated Windows authentication only.", "ruleVulnDiscussion": "To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DOD-approved PKIs, all DOD systems (e.g., networks, web servers, and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement.\n\nAccess control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system.\n\nThis requirement is applicable to access control enforcement applications (e.g., authentication servers) and other applications that perform information and system access control functions.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000213", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-OwaVirtualDirectory -Identity '' -WindowsAuthentication $true\n\nNote: The value must be in quotes.\n\nExample for the Identity Name: \\owa (Default website)", "ruleFixId": "F-63297r942263_fix", "ruleCheckSystem": "C-63389r942262_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-OwaVirtualDirectory | Select-Object -Property ServerName, Name, Identity,*Authentication\n\nIf the value of \"WindowsAuthentication\" is not set to \"True\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18792, "benchmarkId": 369, "groupId": "V-259651", "title": "SRG-APP-000038", "description": "", "ruleId": "SV-259651r960801_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000021", "ruleTitle": "Exchange auto-forwarding email to remote domains must be disabled or restricted.", "ruleVulnDiscussion": "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.\n\nBefore enabling this setting, configure a remote domain.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001368", "ruleFixText": "For Non-Enterprise Mail:\n\nOpen the Exchange Management Shell and enter the following command:\n\nSet-RemoteDomain -Identity <'IdentityName'> -AutoForwardEnabled $false \n\nNote: The value must be in quotes.\n\nFor Enterprise Mail:\n\nNew-RemoteDomain -Name -DomainName \n\nNote: must either be a .mil or .gov domain.\n\nSet-RemoteDomain -Identity <'RemoteDomainIdentity'> -AutoForwardEnabled $true\n\nNote: The value must be in quotes.", "ruleFixId": "F-63298r942266_fix", "ruleCheckSystem": "C-63390r942265_chk", "ruleCheckContent": "Note: This requirement is not applicable on classified or completely closed networks.\n\nFor Non-Enterprise Mail: \n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-RemoteDomain | Select-Object -Property Identity, AutoForwardEnabled\n\nIf the value of AutoForwardEnabled is not set to \"False\", this is a finding.\n\nFor Enterprise Mail:\n\nIf the value of \"AutoForwardEnabled\" is set to \"True\", this is not a finding.\n\nand \n\nIn the Exchange Management Shell, enter the following command:\n\nGet-RemoteDomain\n\nIf the value of \"RemoteDomain\" is not set to \".mil\" and/or \".gov\" domain(s), this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18794, "benchmarkId": 369, "groupId": "V-259653", "title": "SRG-APP-000089", "description": "", "ruleId": "SV-259653r960879_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000032", "ruleTitle": "The Exchange email diagnostic log level must be set to the lowest level.", "ruleVulnDiscussion": "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. \n\nExchange diagnostic logging is divided into 29 main \"services\", each of which has anywhere from two to 26 \"categories\" of events to be monitored. Each category may be set to one of four levels of logging: Lowest, Low, Medium, and High, depending on how much detail is required. Higher levels of detail require more disk space to store the audit material.\n\nDiagnostic 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 amount 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000169", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-EventLogLevel -Identity <'IdentityName\\EventlogName'> -Level Lowest\n\nNote: The value must be in quotes.", "ruleFixId": "F-63300r942272_fix", "ruleCheckSystem": "C-63392r942271_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-EventLogLevel\n\nIf the Diagnostic of any EventLevel is not set to \"Lowest\", this is a finding.\n\nNote: Default installation of Exchange has all Event Levels set to Lowest with exception of the following:\n\nMSExchange ADAccess\\Topology - Low\nMSExchangeADAccess\\Validation - Low\nMSExchange BackEndRehydration\\Configuration - Low\nMSExchange BackEndRehydration\\Server - 2\nMSExchange OAuth\\Configuration - Low\nMSExchange OAuth\\Server - 2\nMSExchange RBAC\\RBAC - Low\nMSExchangeADTopology\\Topology - Low\n\nAll of these must be set to \"Lowest\".", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18795, "benchmarkId": 369, "groupId": "V-259654", "title": "SRG-APP-000089", "description": "", "ruleId": "SV-259654r960879_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "EX19-MB-000033", "ruleTitle": "Exchange audit record parameters must be set.", "ruleVulnDiscussion": "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 to adequately research events that are logged. \n\nAudit records should include the following fields to supply useful event accounting: Object modified, Cmdlet name, Cmdlet parameters, Modified parameters, Caller, Succeeded, and Originating server.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000169", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-AdminAuditLogConfig -AdminAuditLogParameters *", "ruleFixId": "F-63301r942275_fix", "ruleCheckSystem": "C-63393r942274_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-AdminAuditLogConfig | Select-Object -Property AdminAuditLogParameters\n\nNote: The value of \"*\" indicates all parameters are being audited.\n\nIf the value of \"AdminAuditLogParameters\" is not set to \"*\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18796, "benchmarkId": 369, "groupId": "V-259655", "title": "SRG-APP-000090", "description": "", "ruleId": "SV-259655r960882_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000034", "ruleTitle": "The RBAC role for audit log management must be defined and restricted.", "ruleVulnDiscussion": "The RBAC role for the audit log management \"Audit Log Role\" should be defined in the Organizational or Enterprise Domain Security Plan (EDSP) to define the necessary personnel that are required to handle audit logs for the Microsoft Exchange application. \n\nGroup membership should be audited regularly by checking the EDSP regularly and determine who should and should not have group membership.\n\nThere are three built-in groups that automatically have membership: Organization Management, Compliance Management, and Records Management.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000171", "ruleFixText": "Refer to the EDSP on who should have the RBAC role \"Audit Log\". If a custom RBAC role is designated for the Audit Log role, ensure that the custom RBAC role group is populated.\n\nFollow the rule of least privilege.\n\nOtherwise, in an Exchange management shell, run the following:\n\n\"Add-RoleGroupMember -Identity \"Records Management\" -Member \"\n\nWhere is the personnel responsible for handling audit logs.", "ruleFixId": "F-63302r942278_fix", "ruleCheckSystem": "C-63394r942277_chk", "ruleCheckContent": "Refer to the EDSP on who should be in the RBAC role group \"Audit Log\". It is automatically assigned to those in the Organization Management role group.\n\nIn an Exchange management shell, run the following cmdlet:\n\nGet-RoleGroup \"Records Management\"|Get-RoleGroupMember\n\nUnless specified in the EDSP that custom role group is specified for this permission, if this role group is empty this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18797, "benchmarkId": 369, "groupId": "V-259656", "title": "SRG-APP-000098", "description": "", "ruleId": "SV-259656r960900_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000040", "ruleTitle": "Exchange email subject line logging must be disabled.", "ruleVulnDiscussion": "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 is included by default. Information such as the subject and message body is not included.\n\nHowever, 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.\n\nHowever, 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, because 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.\n\nFor 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 because 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000133", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-Transportservice -MessageTrackingLogSubjectLoggingEnabled $False", "ruleFixId": "F-63303r942281_fix", "ruleCheckSystem": "C-63395r942280_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-TransportService | Select-Object -Property Name, Identity, MessageTrackingLogSubjectLoggingEnabled\n\nIf the value of \"MessageTrackingLogSubjectLoggingEnabled\" is not set to \"False\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18798, "benchmarkId": 369, "groupId": "V-259657", "title": "SRG-APP-000098", "description": "", "ruleId": "SV-259657r960900_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000041", "ruleTitle": "Exchange message tracking logging must be enabled.", "ruleVulnDiscussion": "A message tracking log provides a detailed log of all message activity as messages are transferred to and from a computer running Exchange.\n\nIf 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000133", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-TransportService -MessageTrackingLogEnabled $true\n\nNote: The value must be in quotes.", "ruleFixId": "F-63304r942284_fix", "ruleCheckSystem": "C-63396r942283_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-TransportService | Select-Object -Property Name, MessageTrackingLogEnabled\n\nIf the value of MessageTrackingLogEnabled is not set to True, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18799, "benchmarkId": 369, "groupId": "V-259658", "title": "SRG-APP-000098", "description": "", "ruleId": "SV-259658r960900_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "EX19-MB-000042", "ruleTitle": "Exchange circular logging must be disabled.", "ruleVulnDiscussion": "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.\n\nThis setting controls how log files are written. If circular logging is enabled, one log file is 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.\n\nMailbox 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000133", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-MailboxDatabase -Identity <'IdentityName'> -CircularLoggingEnabled $false\n\nNote: The value must be in quotes.", "ruleFixId": "F-63305r942287_fix", "ruleCheckSystem": "C-63397r942286_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-MailboxDatabase | Select-Object -Property Name, Identity, CircularLoggingEnabled\n\nIf the value of \"CircularLoggingEnabled\" is not set to \"False\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18800, "benchmarkId": 369, "groupId": "V-259659", "title": "SRG-APP-000111", "description": "", "ruleId": "SV-259659r960918_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000048", "ruleTitle": "Exchange queue monitoring must be configured with threshold and action.", "ruleVulnDiscussion": "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.\n\nThis 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 happen occasionally. Frequent alerts against this counter may indicate a network or other issue (such as inbound ExchangeMER traffic) that directly impacts email delivery.\n\nNotification 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).", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000154", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nperfmon\n\nIn the left pane, navigate to and select Performance >> Data Collector Sets >> User Defined.\n\nRight-click and navigate to User Defined >> New >> Data Collector Sets and configure the system to use the data collection set for monitoring the queues.", "ruleFixId": "F-63306r942290_fix", "ruleCheckSystem": "C-63398r942289_chk", "ruleCheckContent": "Note: If a third-party application is performing monitoring functions, the reviewer should verify the application is monitoring correctly and mark the vulnerability not applicable (NA).\n\nOpen the Exchange Management Shell and enter the following command:\n\nperfmon\nGet-MonitoringItemHelp -Identity -Server \n\nIf no sets are defined or queues are not being monitored, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18801, "benchmarkId": 369, "groupId": "V-259660", "title": "SRG-APP-000118", "description": "", "ruleId": "SV-259660r960930_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000052", "ruleTitle": "Exchange must protect audit data against unauthorized read access.", "ruleVulnDiscussion": "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.\n\nThe 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000162", "ruleFixText": "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.\n\nRestrict any unauthorized groups' or users' \"Read\" access to the audit logs.", "ruleFixId": "F-63307r942293_fix", "ruleCheckSystem": "C-63399r942292_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) or document that contains this information. \n\nDetermine the authorized groups or users that should have \"Read\" access to the audit data.\n\nBy default, the logs are located on the application partition in \\Program Files\\Microsoft\\Exchange Server\\V15\\Logging.\n\nIf any group or user has \"Read\" access to the audit data that is not documented in the EDSP, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18802, "benchmarkId": 369, "groupId": "V-259661", "title": "SRG-APP-000119", "description": "", "ruleId": "SV-259661r960933_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000053", "ruleTitle": "Exchange must protect audit data against unauthorized access.", "ruleVulnDiscussion": "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.\n\nThe 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000163", "ruleFixText": "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.\n\nRestrict any unauthorized groups' or users' modify permissions for the audit logs.", "ruleFixId": "F-63308r942296_fix", "ruleCheckSystem": "C-63400r942295_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) or document that contains this information. \n\nDetermine the authorized groups or users that should have access to the audit data.\n\nBy default, the logs are located on the application partition in \\Program Files\\Microsoft\\Exchange Server\\V15\\Logging.\n\nIf any group or user has modify privileges for the audit data that is not documented in the EDSP, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18803, "benchmarkId": 369, "groupId": "V-259662", "title": "SRG-APP-000120", "description": "", "ruleId": "SV-259662r960936_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000054", "ruleTitle": "Exchange must protect audit data against unauthorized deletion.", "ruleVulnDiscussion": "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.\n\nThe 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000164", "ruleFixText": "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.\n\nRestrict any unauthorized groups' or users' \"Delete\" permissions for the audit logs.", "ruleFixId": "F-63309r942299_fix", "ruleCheckSystem": "C-63401r942298_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) or document that contains this information.\n\nDetermine the authorized groups or users that should have \"Delete\" permissions for the audit data.\n\nBy default, the logs are located on the application partition in \\Program Files\\Microsoft\\Exchange Server\\V15\\Logging.\n\nIf any group or user has \"Delete\" permissions for the audit data that is not documented in the EDSP, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18806, "benchmarkId": 369, "groupId": "V-259665", "title": "SRG-APP-000141", "description": "", "ruleId": "SV-259665r960963_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000063", "ruleTitle": "Exchange Send Fatal Errors to Microsoft must be disabled.", "ruleVulnDiscussion": "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.\n\nApplications 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).\n\nExamples of nonessential 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.\n\nAll 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000381", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-ExchangeServer -Identity <'IdentityName'> -ErrorReportingEnabled $false\n\nNote: The value must be in quotes.\n\nRepeat the process for each Exchange Server.", "ruleFixId": "F-63312r942308_fix", "ruleCheckSystem": "C-63404r942307_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-ExchangeServer -status | Select-Object -Property Name, Identity, ErrorReportingEnabled\n\nFor each Exchange Server, if the value of \"ErrorReportingEnabled\" is not set to \"False\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18807, "benchmarkId": 369, "groupId": "V-259666", "title": "SRG-APP-000141", "description": "", "ruleId": "SV-259666r960963_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000064", "ruleTitle": "Exchange must not send customer experience reports to Microsoft.", "ruleVulnDiscussion": "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.\n\nApplications 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).\n\nExamples of nonessential 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.\n\nCustomer 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000381", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-OrganizationConfig -CustomerFeedbackEnabled $false", "ruleFixId": "F-63313r942311_fix", "ruleCheckSystem": "C-63405r942310_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-OrganizationConfig | Select-Object -Property CustomerFeedbackEnabled\n\nIf the value for \"CustomerFeedbackEnabled\" is not set to \"False\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18808, "benchmarkId": 369, "groupId": "V-259667", "title": "SRG-APP-000141", "description": "", "ruleId": "SV-259667r960963_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000065", "ruleTitle": "The Exchange Internet Message Access Protocol 4 (IMAP4) service must be disabled.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000381", "ruleFixText": "Open the Windows PowerShell in an Elevated Prompt and enter the following commands:\n\nGet-Service -Name MSExchangeIMAPBE,MSExchangeImap4 |ForEach-Object {Set-Service -Name $_.Name -StartupType Disabled}", "ruleFixId": "F-63314r942314_fix", "ruleCheckSystem": "C-63406r942313_chk", "ruleCheckContent": "Note: This requirement applies to IMAP4. IMAP Secure is not restricted and does not apply to this requirement.\n\nOpen the Windows PowerShell and enter the following command:\n\nGet-Service -Name MSExchangeIMAPBE,MSExchangeImap4 |Select-Object -Property Name,StartType\n\nIf ANY of the IMAP services StartType is NOT set to \"Disabled\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18809, "benchmarkId": 369, "groupId": "V-259668", "title": "SRG-APP-000141", "description": "", "ruleId": "SV-259668r960963_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000066", "ruleTitle": "The Exchange Post Office Protocol 3 (POP3) service must be disabled.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000381", "ruleFixText": "Open the Windows PowerShell in an Elevated Prompt and enter the following commands:\n\nGet-Service -Name MSExchangePop3,MSExchangePOP3BE |ForEach-Object {Set-Service -Name $_.Name -StartupType Disabled}", "ruleFixId": "F-63315r942317_fix", "ruleCheckSystem": "C-63407r942316_chk", "ruleCheckContent": "Get-Service -Name MSExchangePop3,MSExchangePOP3BE |Select-Object -Property Name,StartType\n\nIf any of the POP3 services StartType is NOT set to \"Disabled\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18810, "benchmarkId": 369, "groupId": "V-259669", "title": "SRG-APP-000211", "description": "", "ruleId": "SV-259669r961095_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000105", "ruleTitle": "Exchange Mailbox databases must reside on a dedicated partition.", "ruleVulnDiscussion": "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.\n\nEmail 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001082", "ruleFixText": "Update the EDSP to specify the location where the Exchange Mailbox databases reside or verify that this information is documented by the organization.\n\nConfigure the mailbox databases on a dedicated partition.\n\nEnsure the drive that its being moved to has enough space for the database and logs (if not moving the logs to their own partition). Consult the EDSP and ensure that this is done within a maintenance window as this will incur downtime for any users connected to this mailbox database. Ensure backups are not running at the time this needs to be done. If this server is in a Database Availability Group, this cannot be done until all replicated copies of that database are removed first. Then the move operation can be performed. Once completed, replicated copies can be recreated appropriately.\n\nIn an Exchange Management Shell, run the following (assuming copies of the database is removed if replicated or if it is a single copy database):\n\nMove-DatabasePath -Identity \"\" -EdbFilePath \":\\PathToDatabase\\\" -LogFolderPath \":\\LogFolderPath\\\"\n\nExample:\nMove-DatabasePath -Identity \"Database1\" -EdbFilePath \"D:\\MailboxDBs\\Database1.edb\" -LogFolderPath \"D:\\MailboxDBLogs\\\"", "ruleFixId": "F-63316r945442_fix", "ruleCheckSystem": "C-63408r942319_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) or document that contains this information.\n\nDetermine the location where the Exchange Mailbox databases reside.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-MailboxDatabase | Select-Object -Property Name, Identity, EdbFilePath\n\nOpen Windows Explorer, navigate to the mailbox databases, and verify they are on a dedicated partition.\n\nIf the mailbox databases are not on a dedicated partition, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18844, "benchmarkId": 369, "groupId": "V-259705", "title": "SRG-APP-000435", "description": "", "ruleId": "SV-259705r961620_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000230", "ruleTitle": "Exchange must not send delivery reports to remote domains.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002385", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-RemoteDomain -Identity <'IdentityName'> -DeliveryReportEnabled $false\n\nNote: The value must be in quotes.", "ruleFixId": "F-63352r942428_fix", "ruleCheckSystem": "C-63444r942427_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-RemoteDomain | Select-Object -Property Identity, DeliveryReportEnabled\n\nIf the value of \"DeliveryReportEnabled\" is not set to \"False\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18811, "benchmarkId": 369, "groupId": "V-259670", "title": "SRG-APP-000213", "description": "", "ruleId": "SV-259670r961101_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000106", "ruleTitle": "Exchange internet-facing send connectors must specify a smart host.", "ruleVulnDiscussion": "When identifying a \"Smart Host\" for the email environment, a logical Send connector is the preferred method.\n\nA 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.\n\nFailure 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001178", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-SendConnector -Identity <'IdentityName'> -SmartHosts <'IP Address of Smart Host'> -DNSRoutingEnabled $false\n\nNote: The and values must be in quotes.\n\nRepeat the procedure for each Send connector.", "ruleFixId": "F-63317r942323_fix", "ruleCheckSystem": "C-63409r942322_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-SendConnector | Select-Object -Property Name, Identity, SmartHosts\n\nIdentify the internet-facing connectors.\n\nFor each Send connector, if the value of \"SmartHosts\" does not return the Smart Host IP address, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18812, "benchmarkId": 369, "groupId": "V-259671", "title": "SRG-APP-000231", "description": "", "ruleId": "SV-259671r961128_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000115", "ruleTitle": "Exchange mailboxes must be retained until backups are complete.", "ruleVulnDiscussion": "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.\n\nIt 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001199", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-MailboxDatabase -Identity <'IdentityName'> -RetainDeletedItemsUntilBackup $true\n\nNote: The value must be in quotes.", "ruleFixId": "F-63318r942326_fix", "ruleCheckSystem": "C-63410r942325_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-MailboxDatabase| Select-Object -Property Name, Identity, RetainDeletedItemsUntilBackup\n\nIf the value of \"RetainDeletedItemsUntilBackup\" is not set to \"True\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18813, "benchmarkId": 369, "groupId": "V-259672", "title": "SRG-APP-000231", "description": "", "ruleId": "SV-259672r961128_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000116", "ruleTitle": "Exchange email forwarding must be restricted.", "ruleVulnDiscussion": "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\".\n\nUse of forwarding set by an administrator interferes with nonrepudiation requirements that each end user be responsible for creation and destination of email data.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001199", "ruleFixText": "Update the EDSP.\n\nOpen the Exchange Management Shell and enter the following command:\n\nSet-Mailbox -Identity <'IdentityName'> -ForwardingSMTPAdddress $null\n\nNote: The value must be in quotes.", "ruleFixId": "F-63319r942329_fix", "ruleCheckSystem": "C-63411r942328_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP). \n\nDetermine any accounts that have been authorized to have email auto-forwarded.\n\nNote: If email auto-forwarding is not being used, this check is not applicable.\n\nOpen the Exchange Management Shell and enter the following commands:\n\nGet-Mailbox | Select-Object -Property Name, Identity, Forward* \n\nNote: The asterisk (*) will grab both ForwardingAddress and ForwardingSMTPAddress.\n\nIf any user has a forwarding SMTP address and is not documented in the EDSP, this is a finding.\n\nNote: 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.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18814, "benchmarkId": 369, "groupId": "V-259673", "title": "SRG-APP-000231", "description": "", "ruleId": "SV-259673r961128_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000117", "ruleTitle": "Exchange email-forwarding SMTP domains must be restricted.", "ruleVulnDiscussion": "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\".\n\nUse of forwarding set by an administrator interferes with nonrepudiation requirements that each end user be responsible for creation and destination of email data.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001199", "ruleFixText": "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.\n\nFor domains that are listed in the EDSP to allow AutoForwarding, open the Exchange Management Shell and enter the following command:\n\nSet-RemoteDomain -Identity -AutoForwardEnabled $true\n\nIf the Remote Domain is NOT listed in the EDSP to allow for AutoForwarding, open the Exchange Management Shell and enter the following command:\n\nSet-RemoteDomain -Identity [RemoteDomainIdentity] -AutoForwardingEnabled $false", "ruleFixId": "F-63320r942332_fix", "ruleCheckSystem": "C-63412r942331_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) or document that contains this information.\n\nDetermine any accounts that have been authorized to have email auto-forwarded.\n\nNote: If email auto-forwarding is not being used, this check is not applicable (NA).\n\nOpen the Exchange Management Shell and enter the following commands:\n\nGet-RemoteDomain | Select Name, Identity, DomainName, AutoForwardEnabled |Format-List\n\nIf any domain for a user forwarding SMTP address is not documented in the EDSP, this is a finding.\n\nNote: 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.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18815, "benchmarkId": 369, "groupId": "V-259674", "title": "SRG-APP-000246", "description": "", "ruleId": "SV-259674r961152_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "EX19-MB-000121", "ruleTitle": "Exchange mailbox stores must mount at startup.", "ruleVulnDiscussion": "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.\n\nCorrect 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).", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001094", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-MailboxDatabase -Identity <'IdentityName'> -MountAtStartup $true\n\nNote: The value must be in quotes.", "ruleFixId": "F-63321r942335_fix", "ruleCheckSystem": "C-63413r942334_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-MailboxDatabase | Select-Object -Property Name, Identity, MountAtStartup\n\nIf the value of \"MountAtStartup\" is not set to \"True\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18816, "benchmarkId": 369, "groupId": "V-259675", "title": "SRG-APP-000246", "description": "", "ruleId": "SV-259675r961152_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "EX19-MB-000122", "ruleTitle": "Exchange mail quota settings must not restrict receiving mail.", "ruleVulnDiscussion": "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.\n\nFailure to allow mail receipt may impede users from receiving mission-critical data.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001094", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-MailboxDatabase -Identity <'IdentityName'> -ProhibitSendReceiveQuota Unlimited\n\nNote: The value must be in quotes.\n\nor\n\nEnter the value as identified by the EDSP that has obtained a signoff with risk acceptance.", "ruleFixId": "F-63322r942338_fix", "ruleCheckSystem": "C-63414r942337_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-MailboxDatabase | Select-Object -Property Name, Identity, ProhibitSendReceiveQuota\n\nIf the value of \"ProhibitSendReceiveQuota\" is not set to \"Unlimited\", this is a finding.\n\nor\n\nIf the value of \"ProhibitSendReceiveQuota\" is set to an alternate value and has signoff and risk acceptance in the EDSP, this is not a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18817, "benchmarkId": 369, "groupId": "V-259676", "title": "SRG-APP-000246", "description": "", "ruleId": "SV-259676r961152_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "EX19-MB-000123", "ruleTitle": "Exchange mail quota settings must not restrict sending mail.", "ruleVulnDiscussion": "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. \n\nThis control prohibits the user from sending an email when the mailbox limit reaches the prohibit send quota value.\n\nNote: Best practice for this setting is to prohibit the user from sending email when the mailbox reaches 90 percent of capacity.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001094", "ruleFixText": "Update the EDSP to specify the value for the Prohibit Send Quota limit or verify that this information is documented by the organization.\n\nOpen the Exchange Management Shell and enter the following command:\n\nSet-MailboxDatabase -Identity <'IdentityName'> -ProhibitSendQuota <'QuotaLimit'>\n\nNote: The and values must be in quotes.", "ruleFixId": "F-63323r942341_fix", "ruleCheckSystem": "C-63415r942340_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) or document that contains this information.\n\nDetermine the value for the Prohibit Send Quota limit.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-MailboxDatabase | Select-Object -Property Name, Identity, ProhibitSendQuota\n\nIf the value of \"ProhibitSendQuota\" is not set to the site's Prohibit Send Quota limit, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18818, "benchmarkId": 369, "groupId": "V-259677", "title": "SRG-APP-000247", "description": "", "ruleId": "SV-259677r961155_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "EX19-MB-000124", "ruleTitle": "Exchange Message size restrictions must be controlled on Receive connectors.", "ruleVulnDiscussion": "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.\n\nThis 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).", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001095", "ruleFixText": "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.\n\nOpen the Exchange Management Shell and enter the following command:\n\nSet-ReceiveConnector -Identity <'IdentityName'> -MaxMessageSize <'MaxReceiveSize'>\n\nNote: The and values must be in quotes.\n\nor\n\nEnter the value as identified by the EDSP that has obtained a signoff with risk acceptance.\n\nRepeat the procedure for each Receive connector.", "ruleFixId": "F-63324r942344_fix", "ruleCheckSystem": "C-63416r942343_chk", "ruleCheckContent": "Review the EDSP or document that contains this information.\n\nDetermine the global maximum message receive size and whether signoff with risk acceptance is documented for the Receive connector to have a different value.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-ReceiveConnector | Select-Object -Property Name, Identity, MaxMessageSize\n\nIdentify internet-facing connectors.\n\nFor each Receive connector, if the value of \"MaxMessageSize\" is not the same as the global value, this is a finding.\n\nor\n\nIf \"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.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18819, "benchmarkId": 369, "groupId": "V-259678", "title": "SRG-APP-000247", "description": "", "ruleId": "SV-259678r961155_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "EX19-MB-000125", "ruleTitle": "The Exchange Receive Connector Maximum Hop Count must be 60.", "ruleVulnDiscussion": "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.\n\nRecent 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001095", "ruleFixText": "Update the EDSP to specify the \"MaxHopCount\" value or verify that this information is documented by the organization.\n\nOpen the Exchange Management Shell and enter the following command:\n\nSet-ReceiveConnector -MaxHopCount 60\n\nor \n\nEnter the value as identified by the EDSP that has obtained a signoff with risk acceptance.\n\nRepeat the procedure for each Receive connector.", "ruleFixId": "F-63325r942347_fix", "ruleCheckSystem": "C-63417r942346_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) or document that contains this information.\n\nDetermine the Max Hop Count value for Receive connectors.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-ReceiveConnector | Select-Object -Property Name, MaxHopCount\n\nFor each Receive connector, if the value of \"MaxHopCount\" is not set to \"60\", this is a finding.\n\nor\n\nIf 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.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18820, "benchmarkId": 369, "groupId": "V-259679", "title": "SRG-APP-000247", "description": "", "ruleId": "SV-259679r961155_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "EX19-MB-000126", "ruleTitle": "The Exchange send connector connections count must be limited.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001095", "ruleFixText": "Update the EDSP to specify the \"MaxOutboundConnections\" value.\n\nOpen the Exchange Management Shell and enter the following command:\n\nSet-TransportService -Identity <'IdentityName'> -MaxOutboundConnections 1000\n\nNote: The value must be in quotes.\n\nor\n\nEnter the value as identified by the EDSP that has obtained a signoff with risk acceptance.", "ruleFixId": "F-63326r942350_fix", "ruleCheckSystem": "C-63418r942349_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP).\n\nDetermine the value for SMTP Server Maximum Outbound Connections.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-TransportService | Select-Object -Property Name, Identity, MaxOutboundConnections\n\nIf the value of \"MaxOutboundConnections\" is not set to \"1000\", this is a finding.\n\nor\n\nIf \"MaxOutboundConnections\" is set to a value other than \"1000\" and has signoff and risk acceptance in the EDSP, this is not a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18821, "benchmarkId": 369, "groupId": "V-259681", "title": "SRG-APP-000247", "description": "", "ruleId": "SV-259681r961155_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "EX19-MB-000128", "ruleTitle": "Exchange message size restrictions must be controlled on send connectors.", "ruleVulnDiscussion": "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. \n\nThis 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).", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001095", "ruleFixText": "Update the EDSP to specify the \"MaxMessageSize\" value or verify that this information is documented by the organization.\n\nOpen the Exchange Management Shell and enter the following command:\n\nSet-SendConnector -Identity <'IdentityName'> -MaxMessageSize \n\nNote: The value must be in quotes.\n\nor\n\nEnter the value as identified by the EDSP that has obtained a signoff with risk acceptance.\n\nRepeat the procedures for each Send connector.", "ruleFixId": "F-63328r942356_fix", "ruleCheckSystem": "C-63420r942355_chk", "ruleCheckContent": "Review the EDSP or document that contains this information. \n\nDetermine the maximum message send size.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-SendConnector | Select-Object -Property Name, Identity, MaxMessageSize\n\nFor each Send connector, if the value of \"MaxMessageSize\" is not the same as the global value, this is a finding.\n\nor\n\nIf \"MaxMessageSize\" is set to a numeric value different from the maximum message send size value documented in the EDSP, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18822, "benchmarkId": 369, "groupId": "V-259682", "title": "SRG-APP-000247", "description": "", "ruleId": "SV-259682r961155_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "EX19-MB-000129", "ruleTitle": "The Exchange global inbound message size must be controlled.", "ruleVulnDiscussion": "Email system availability depends in part on best practice strategies for setting tuning configurations. Message size limits should be set to 10 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.\n\nMessage 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001095", "ruleFixText": "Update the EDSP to specify the \"MaxReceiveSize\" value or verify that this information is documented by the organization.\n\nOpen the Exchange Management Shell and enter the following command:\n\nSet-TransportConfig -MaxReceiveSize 10MB\n\nor\n\nEnter the value as identified by the EDSP that has obtained a signoff with risk acceptance.", "ruleFixId": "F-63329r942359_fix", "ruleCheckSystem": "C-63421r942358_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) or document that contains this information.\n\nDetermine the global maximum message receive size.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-TransportConfig | Select-Object -Property Name, Identity, MaxReceiveSize\n\nIf the value of \"MaxReceiveSize\" is not set to \"10MB\", this is a finding.\n\nor\n\nIf \"MaxReceiveSize\" is set to an alternate value and has signoff and risk acceptance in the EDSP, this is not a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18823, "benchmarkId": 369, "groupId": "V-259683", "title": "SRG-APP-000247", "description": "", "ruleId": "SV-259683r961155_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "EX19-MB-000130", "ruleTitle": "The Exchange global outbound message size must be controlled.", "ruleVulnDiscussion": "Email system availability depends in part on best practice strategies for setting tuning configurations. Message size limits should be set to 10 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.\n\nMessage 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001095", "ruleFixText": "Update the EDSP to specify the \"MaxSendSize\" value or verify that this information is documented by the organization.\n\nOpen the Exchange Management Shell and enter the following command:\n\nSet-TransportConfig -MaxSendSize 10MB\n\nor\n\nEnter the value as identified by the EDSP that has obtained a signoff with risk acceptance.", "ruleFixId": "F-63330r942362_fix", "ruleCheckSystem": "C-63422r942361_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) or document that contains this information.\n\nDetermine the global maximum message send size.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-TransportConfig | Select-Object -Property Name, Identity, MaxSendSize\n\nIf the value of \"MaxSendSize\" is not set to \"10MB\", this is a finding.\n\nor\n\nIf \"MaxSendSize\" is set to an alternate value and has signoff and risk acceptance in the EDSP, this is not a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18824, "benchmarkId": 369, "groupId": "V-259684", "title": "SRG-APP-000247", "description": "", "ruleId": "SV-259684r961155_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "EX19-MB-000131", "ruleTitle": "The Exchange Outbound Connection Limit per Domain Count must be controlled.", "ruleVulnDiscussion": "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. \n\nBy 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001095", "ruleFixText": "Update the EDSP to specify the \"MaxPerDomainOutboundConnection\" value or verify that this information is documented by the organization.\n\nOpen the Exchange Management Shell and enter the following command:\n\nSet-TransportService -Identity <'IdentityName'> -MaxPerDomainOutboundConnections 20\n\nNote: The value must be in quotes.\n\nor\n\nEnter the value as identified by the EDSP that has obtained a signoff with risk acceptance.", "ruleFixId": "F-63331r942365_fix", "ruleCheckSystem": "C-63423r942364_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) or document that contains this information.\n\nDetermine the value for Maximum Outbound Domain Connections.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-TransportService | Select-Object -Property Name, Identity, MaxPerDomainOutboundConnections\n\nIf the value of \"MaxPerDomainOutboundConnections\" is not set to \"20\", this is a finding.\n\nor\n\nIf \"MaxPerDomainOutboundConnections\" is set to a value other than \"20\" and has signoff and risk acceptance in the EDSP, this is not a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18825, "benchmarkId": 369, "groupId": "V-259685", "title": "SRG-APP-000247", "description": "", "ruleId": "SV-259685r961155_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "EX19-MB-000132", "ruleTitle": "The Exchange Outbound Connection Timeout must be 10 minutes or less.", "ruleVulnDiscussion": "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.\n\nOnce established, connections 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001095", "ruleFixText": "Update the EDSP to specify the \"ConnectionInactivityTimeOut\" value.\n\nOpen the Exchange Management Shell and enter the following command:\n\nSet-SendConnector -Identity <'IdentityName'> -ConnectionInactivityTimeOut 00:10:00\n\nNote: The value must be in quotes.\n\nor\n\nEnter the value as identified by the EDSP that has obtained a signoff with risk acceptance.", "ruleFixId": "F-63332r942368_fix", "ruleCheckSystem": "C-63424r942367_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) or document that contains this information.\n\nDetermine the Connection Timeout value.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-SendConnector | Select-Object -Property Name, Identity, ConnectionInactivityTimeOut\n\nFor each Send connector, if the value of \"ConnectionInactivityTimeOut\" is not set to \"00:10:00\", this is a finding.\n\nor\n\nIf \"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.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18826, "benchmarkId": 369, "groupId": "V-259686", "title": "SRG-APP-000261", "description": "", "ruleId": "SV-259686r961161_rule", "ruleWeight": "10.0", "ruleSeverity": "high", "ruleVersion": "EX19-MB-000134", "ruleTitle": "Exchange servers must have an approved DOD email-aware virus protection software installed.", "ruleVulnDiscussion": "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.\n\nEmail-aware antivirus engines must be Exchange 2019 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001308", "ruleFixText": "Update the EDSP to specify the organization's antivirus strategy.\n\nInstall and configure a DOD-approved compatible Exchange 2019 email-aware antivirus scanner product.", "ruleFixId": "F-63333r942371_fix", "ruleCheckSystem": "C-63425r942370_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP).\n\nDetermine the antivirus strategy.\n\nVerify the email-aware antivirus scanner product is Exchange 2019 compatible and DOD approved. \n\nIf email servers are using an email-aware antivirus scanner product that is not DOD approved and Exchange 2019 compatible, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18827, "benchmarkId": 369, "groupId": "V-259687", "title": "SRG-APP-000261", "description": "", "ruleId": "SV-259687r961161_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000135", "ruleTitle": "Exchange internal receive connectors must not allow anonymous connections.", "ruleVulnDiscussion": "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.\n\nSMTP 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.\n\nRelays 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001308", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-ReceiveConnector -Identity ['IdentityName'] -PermissionGroups and enter a valid value user group.\n\nNote: The value must be in quotes.\n\nExample: Set-ReceiveConnector -Identity <'IdentityName'> -PermissionGroups ExchangeUsers\n\nRepeat the procedures for each Receive connector. This will remove the AnonymousUsers value simultaneously.", "ruleFixId": "F-63334r942374_fix", "ruleCheckSystem": "C-63426r942373_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-ReceiveConnector | Select-Object -Property Name, Identity, PermissionGroups |Format-List\n\nFor each Receive connector, if the value of \"PermissionGroups\" is \"AnonymousUsers\" for any receive connector, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18828, "benchmarkId": 369, "groupId": "V-259688", "title": "SRG-APP-000261", "description": "", "ruleId": "SV-259688r961161_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000136", "ruleTitle": "Exchange external/internet-bound automated response messages must be disabled.", "ruleVulnDiscussion": "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.\n\nAutomated 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001308", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-RemoteDomain -Identity <'IdentityName'> -AllowedOOFType 'InternalLegacy'\n\nNote: The and InternalLegacy values must be in quotes.", "ruleFixId": "F-63335r942377_fix", "ruleCheckSystem": "C-63427r942376_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-RemoteDomain | Select-Object -Property Name, DomainName, Identity, AllowedOOFType\n\nIf the value of \"AllowedOOFType\" is not set to \"InternalLegacy\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18829, "benchmarkId": 369, "groupId": "V-259689", "title": "SRG-APP-000261", "description": "", "ruleId": "SV-259689r961161_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000137", "ruleTitle": "Exchange must have anti-spam filtering installed.", "ruleVulnDiscussion": "Originators of spam messages are constantly changing their techniques 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.\n\nExchange 2019 provides both anti-spam and anti-malware protection out of the box. The Exchange 2019 anti-spam and anti-malware product capabilities are limited but still provide some protection.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001308", "ruleFixText": "Update the EDSP with the anti-spam mechanism used.\n\nInstall the AntiSpam module.\n\nOpen the Exchange Management Shell and enter the following command:\n\n& $env:ExchangeInstallPath\\Scripts\\Install-AntiSpamAgents.ps1", "ruleFixId": "F-63336r942380_fix", "ruleCheckSystem": "C-63428r945436_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP).\n\nNote: 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.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-ContentFilterConfig |Select-Object -Property Name, Enabled |Format-Table \n\nIf no value is returned, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18830, "benchmarkId": 369, "groupId": "V-259690", "title": "SRG-APP-000261", "description": "", "ruleId": "SV-259690r961161_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000138", "ruleTitle": "Exchange must have anti-spam filtering enabled.", "ruleVulnDiscussion": "Originators of spam messages are constantly changing their techniques 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.\n\nExchange 2019 provides both anti-spam and anti-malware protection out of the box. The Exchange 2019 anti-spam and anti-malware product capabilities are limited but still provide some protection.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001308", "ruleFixText": "Update the EDSP with the anti-spam mechanism used.\n\nOpen the Exchange Management Shell and enter the following command for any values that were not set to \"True\":\n\nSet-ContentFilterConfig -Enabled $true\n\nSet-SenderFilterConfig -Enabled $true\n\nSet-SenderIDConfig -Enabled $true\n\nSet-SenderReputationConfig -Enabled $true", "ruleFixId": "F-63337r942383_fix", "ruleCheckSystem": "C-63429r942382_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP).\n\nNote: 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.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-ContentFilterConfig | Select-Object -Property Name, Enabled|Format-Table; \nGet-SenderFilterConfig |Select-Object -Property Name, Enabled |Format-Table; \nGet-SenderIDConfig |Select-Object -Property Name, Enabled |Format-Table; \nGet-SenderReputationConfig |Select-Object -Property Name, Enabled |Format-Table\n\nIf any of the above values returned are not set to \"True\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18831, "benchmarkId": 369, "groupId": "V-259691", "title": "SRG-APP-000261", "description": "", "ruleId": "SV-259691r961161_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000139", "ruleTitle": "Exchange must have anti-spam filtering configured.", "ruleVulnDiscussion": "Originators of spam messages are constantly changing their techniques 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.\n\nExchange 2019 provides both anti-spam and anti-malware protection out of the box. The Exchange 2019 anti-spam and anti-malware product capabilities are limited but still provide some protection.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001308", "ruleFixText": "Note: Configure the IP addresses of every internal SMTP server. If the Mailbox server is the only SMTP server running the anti-spam agents, configure the IP address of the Mailbox server.\n\nUpdate the EDSP with the anti-spam mechanism used.\n\nOpen the Exchange Management Shell and enter the following command:\n\nSingle SMTP server address:\n\nSet-TransportConfig -InternalSMTPServers @{Add=''}\n\nMultiple SMTP server addresses:\n\nSet-TransportConfig -InternalSMTPServers @{Add='',''}", "ruleFixId": "F-63338r945438_fix", "ruleCheckSystem": "C-63430r945437_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP).\n\nNote: 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.\n\nDetermine the internal SMTP servers.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-TransportConfig | Format-List InternalSMTPServers\n\nIf any internal SMTP server IP address returned does not reflect the list of accepted SMTP server IP addresses, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18832, "benchmarkId": 369, "groupId": "V-259692", "title": "SRG-APP-000261", "description": "", "ruleId": "SV-259692r961161_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000140", "ruleTitle": "Exchange must not send automated replies to remote domains.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001308", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-RemoteDomain -Identity <'IdentityName'> -AutoReplyEnabled $false\n\nNote: The value must be in quotes.", "ruleFixId": "F-63339r942389_fix", "ruleCheckSystem": "C-63431r942388_chk", "ruleCheckContent": "Note: Automated replies to .mil or .gov sites are allowed.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-RemoteDomain | Select-Object -Property Name, Identity, AutoReplyEnabled\n\nIf the value of \"AutoReplyEnabled\" is set to \"True\" and is configured to only reply to .mil or .gov sites, this is not a finding.\n\nIf the value of \"AutoReplyEnabled\" is not set to \"False\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18833, "benchmarkId": 369, "groupId": "V-259693", "title": "SRG-APP-000261", "description": "", "ruleId": "SV-259693r961161_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "EX19-MB-000142", "ruleTitle": "The Exchange Global Recipient Count Limit must be set.", "ruleVulnDiscussion": "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.\n\nThe 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001308", "ruleFixText": "Update the EDSP to specify the global maximum message recipient count.\n\nSet-TransportConfig -MaxRecipientEnvelopeLimit 5000\n\nor\n\nEnter the value as identified by the EDSP that has obtained a signoff with risk acceptance.\n\nRestart the Microsoft Exchange Information Store service.", "ruleFixId": "F-63340r942392_fix", "ruleCheckSystem": "C-63432r942391_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP).\n\nDetermine the global maximum message recipient count.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-TransportConfig | Select-Object -Property Name, Identity, MaxRecipientEnvelopeLimit\n\nIf the value of \"MaxRecipientEnvelopeLimit\" is not set to \"5000\", this is a finding.\n\nor\n\nIf \"MaxRecipientEnvelopeLimit\" is set to an alternate value and has signoff and risk acceptance in the EDSP, this is not a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18834, "benchmarkId": 369, "groupId": "V-259694", "title": "SRG-APP-000272", "description": "", "ruleId": "SV-259694r1015276_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000146", "ruleTitle": "Exchange antimalware agent must be enabled and configured.", "ruleVulnDiscussion": "Microsoft Exchange 2019 offers built-in antimalware protection for messages going through the transport pipeline. When enabled, the default settings are configured to automatically update.\n\nExchange's built-in Malware Agent is not designed to address all malicious code protection workloads. This workload is best handled by third-party antivirus and intrusion prevention software.\n\nSites must use an approved DOD scanner. Exchange Malware software has a limited scanning capability and does not scan files that are downloaded, opened, or executed.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-004964", "ruleFixText": "Open the Exchange Management Shell and run the following command:\n\n& $env:ExchangeInstallPath\\Scripts\\Enable-AntimalwareScanning.ps1\n\nThis will automatically enable the anti-malware agent. After the script completes, run the following cmdlet to complete the process:\n\nRestart-Service MSExchangeTransport\n\nThis may take up to 10 minutes to take effect.", "ruleFixId": "F-63341r942395_fix", "ruleCheckSystem": "C-63433r942394_chk", "ruleCheckContent": "Open the Exchange Management Shell and run the following cmdlets:\n\nGet-TransportAgent \"Malware Agent\"\n\nIf the identity \"Malware Agent\" is not set to \"Enabled\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18835, "benchmarkId": 369, "groupId": "V-259695", "title": "SRG-APP-000272", "description": "", "ruleId": "SV-259695r1015277_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000147", "ruleTitle": "The Exchange malware scanning agent must be configured for automatic updates.", "ruleVulnDiscussion": "Antimalware protection in Exchange Server 2019 helps combat viruses and spyware in an email messaging environment. Viruses infect other programs and data, and they spread throughout computer looking for programs to infect. Spyware gathers personal information (for example, sign-in information and personal data) and sends it back to its author.\n\nThe antimalware protection in Exchange Server was introduced in Exchange 2013 and is provided by the Transport agent named Malware Agent. The agent scans messages as they travel through the Transport service on a Mailbox server.\n\nTo ensure increased effectiveness of the Malware Agent, ensuring its signatures are automatically updated is imperative. Not doing so can lead to system compromise.\n\nThe Malware agent is installed during the initial installation of Microsoft Exchange server and if installed, is set for automatic updates by default.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-004964", "ruleFixText": "In an elevated Exchange management shell, run the following cmdlet:\n\nSet-MalwareFilteringServer -Identity -UpdateFrequency \n\nWhere is the name of the Exchange Server and is the update frequency (in minutes).\n\nRefer to the Enterprise Domain Security Plan (EDSP) for the update cadence that best aligns with the user's organization.", "ruleFixId": "F-63342r986144_fix", "ruleCheckSystem": "C-63434r942397_chk", "ruleCheckContent": "In Exchange Management shell, run the following cmdlet:\n\nGet-MalwareFilteringServer |Select-Object -Property Name, *Update*\n\nIf the property \"Update frequency\" is not set, this is a finding.\n\nIf the Malware agent is not installed, then this is not applicable.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18836, "benchmarkId": 369, "groupId": "V-259697", "title": "SRG-APP-000295", "description": "", "ruleId": "SV-259697r1043182_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "EX19-MB-000158", "ruleTitle": "The Exchange receive connector timeout must be limited.", "ruleVulnDiscussion": "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.\n\nConnections, 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002361", "ruleFixText": "Update the EDSP to specify the Connection Timeout value.\n\nOpen the Exchange Management Shell and enter the following command:\n\nSet-ReceiveConnector -Identity <'IdentityName'> -ConnectionTimeout 00:10:00\n\nNote: The value must be in quotes.\n\nor \n\nEnter the value as identified by the EDSP that has obtained a signoff with risk acceptance.", "ruleFixId": "F-63344r942404_fix", "ruleCheckSystem": "C-63436r942403_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) and determine the Connection Timeout value.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-ReceiveConnector | Select-Object -Property Name, Identity, ConnectionTimeout\n\nFor each Receive connector, if the value of \"ConnectionTimeout\" is not set to \"00:10:00\", this is a finding.\n\nor\n\nIf \"ConnectionTimeout\" is set to other than \"00:10:00\" and has signoff and risk acceptance in the EDSP, this is not a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18837, "benchmarkId": 369, "groupId": "V-259698", "title": "SRG-APP-000340", "description": "", "ruleId": "SV-259698r961353_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000173", "ruleTitle": "Role-Based Access Control must be defined for privileged and nonprivileged users.", "ruleVulnDiscussion": "Role Based Access Control (RBAC) is the permissions model used in Microsoft Exchange Server 2013, 2016, and 2019. With RBAC, there is no need to modify and manage access control lists (ACLs), which was done in Exchange Server 2007. ACLs created several challenges in Exchange 2007, such as modifying ACLs without causing unintended consequences, maintaining ACL modifications through upgrades, and troubleshooting problems that occurred due to using ACLs in a nonstandard way.\n\nRBAC enables users to control, at both broad and granular levels, what administrators and end-users can do. RBAC also enables users to more closely align the roles assigned to users and administrators to the actual roles they hold within the organization. In Exchange 2007, the server permissions model applied only to the administrators who managed the Exchange 2007 infrastructure. Starting with Exchange 2013, RBAC now controls both the administrative tasks that can be performed and the extent to which users can now administer their own mailbox and distribution groups.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002235", "ruleFixText": "Update the EDSP and define which users should and should not have elevated privileges within the organization.\n\nFollow the rule of least privilege and ensure that administrators are given just enough access to complete their job.\n\nReferenced Document: https://docs.microsoft.com/en-us/exchange/understanding-management-role-groups-exchange-2013-help?view=exchserver-2019", "ruleFixId": "F-63345r942407_fix", "ruleCheckSystem": "C-63437r945441_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) to verify which users should be in each built-in RBAC management role group. \n\nIf this is not found, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18838, "benchmarkId": 369, "groupId": "V-259699", "title": "SRG-APP-000378", "description": "", "ruleId": "SV-259699r1015278_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000194", "ruleTitle": "The Exchange application directory must be protected from unauthorized access.", "ruleVulnDiscussion": "Default product installations may provide more generous access permissions than are necessary to run the application. By examining and tailoring access permissions to provide the least amount of privilege possible more closely, attack vectors that align with user permissions are less likely to access more highly secured areas.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-003980", "ruleFixText": "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.\n\nNavigate to the Exchange application directory and remove or modify the group or user access permissions.\n\nNote: The default installation directory is \\Program Files\\Microsoft\\Exchange Server\\V15.", "ruleFixId": "F-63346r942410_fix", "ruleCheckSystem": "C-63438r942409_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) or document that contains this information.\n\nDetermine the authorized groups and users that have access to the Exchange application directories.\n\nVerify the access permissions on the directory match the access permissions listed in the EDSP.\n\nIf any group or user has different access permissions, this is a finding.\n\nNote: The default installation directory is \\Program Files\\Microsoft\\Exchange Server\\V15.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18845, "benchmarkId": 369, "groupId": "V-259706", "title": "SRG-APP-000435", "description": "", "ruleId": "SV-259706r961620_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000231", "ruleTitle": "Exchange must not send nondelivery reports to remote domains.", "ruleVulnDiscussion": "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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002385", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-RemoteDomain -Identity <'IdentityName'> -NDREnabled $false\n\nNote: The value must be in quotes.", "ruleFixId": "F-63353r942431_fix", "ruleCheckSystem": "C-63445r942430_chk", "ruleCheckContent": "Note: For the purpose of this requirement, \"remote\" refers to those domains external to the DODIN, whether classified or unclassified. NDRs between DODIN networks is permitted.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-RemoteDomain | Select-Object -Property Name, Identity, NDREnabled\n\nIf the value of \"NDREnabled\" is not set to \"False\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18839, "benchmarkId": 369, "groupId": "V-259700", "title": "SRG-APP-000380", "description": "", "ruleId": "SV-259700r961461_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000196", "ruleTitle": "An Exchange software baseline copy must exist.", "ruleVulnDiscussion": "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. \n\nThe 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001813", "ruleFixText": "Update the EDSP to specify the software baseline, procedures, and implementation artifacts or verify that this information is documented by the organization.", "ruleFixId": "F-63347r942413_fix", "ruleCheckSystem": "C-63439r942412_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP) or document that contains this information.\n\nDetermine the software baseline.\n\nReview the application software baseline procedures and implementation artifacts.\n\nNote the list of files and directories included in the baseline procedure for completeness.\n\nIf an email software copy exists to serve as a baseline and is available for comparison during scanning efforts, this is not a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18840, "benchmarkId": 369, "groupId": "V-259701", "title": "SRG-APP-000381", "description": "", "ruleId": "SV-259701r1015279_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000197", "ruleTitle": "Exchange software must be monitored for unauthorized changes.", "ruleVulnDiscussion": "Monitoring software files for changes against a baseline on a regular basis may help detect the possible introduction of malicious code on a system.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-003938", "ruleFixText": "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.\n\nMonitor the software files (e.g., *.exe, *.bat, *.com, *.cmd, and *.dll) on Exchange servers for unauthorized changes against a baseline on a weekly basis.\n\nNote: This can be done with the use of various monitoring tools.", "ruleFixId": "F-63348r942416_fix", "ruleCheckSystem": "C-63440r942415_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP).\n\nDetermine 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.\n\nIf software files are not monitored for unauthorized changes, this is a finding.\n\nNote: An approved and properly configured solution will contain both a list of baselines that includes all system file locations and a file comparison task that is scheduled to run at least weekly.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18841, "benchmarkId": 369, "groupId": "V-259702", "title": "SRG-APP-000383", "description": "", "ruleId": "SV-259702r961470_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000198", "ruleTitle": "Exchange services must be documented, and unnecessary services must be removed or disabled.", "ruleVulnDiscussion": "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.\n\nExchange Server has role-based server deployment to enable protocol path control and logical separation of network traffic types.\n\nFor 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).\n\nBecause 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001762", "ruleFixText": "Update the EDSP to specify the services required for the system to function.\n\nRemove or disable any services that are not required.", "ruleFixId": "F-63349r942419_fix", "ruleCheckSystem": "C-63441r942418_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP).\n\nNote: Required services will vary among organizations 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.\n\nOpen a Windows PowerShell and enter the following command:\n\nGet-Service | Where-Object {$_.status -eq 'running'}\n\nNote: The command returns a list of installed services and the status of that service.\n\nIf the services required are not documented in the EDSP, this is a finding.\n\nIf any undocumented or unnecessary services are running, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18842, "benchmarkId": 369, "groupId": "V-259703", "title": "SRG-APP-000391", "description": "", "ruleId": "SV-259703r961494_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000203", "ruleTitle": "Exchange Outlook Anywhere clients must use NTLM authentication to access email.", "ruleVulnDiscussion": "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.\n\nNote: 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001953", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nFor InternalClientAuthenticationMethod:\n\nSet-OutlookAnywhere -Identity ' -InternalClientAuthenticationMethod NTLM\n\nFor ExternalClientAuthenticationMethod:\n\nSet-OutlookAnywhere -Identity ' -ExternalClientAuthenticationMethod NTLM", "ruleFixId": "F-63350r942422_fix", "ruleCheckSystem": "C-63442r942421_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-OutlookAnywhere\n\nGet-OutlookAnywhere | Select-Object -Property Name, Identity, InternalClientAuthenticationMethod, ExternalClientAuthenticationMethod\n\nIf the value of \"InternalClientAuthenticationMethod\" and the value of \"ExternalClientAuthenticationMethod\" are not set to NTLM, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18843, "benchmarkId": 369, "groupId": "V-259704", "title": "SRG-APP-000431", "description": "", "ruleId": "SV-259704r961608_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000229", "ruleTitle": "The Exchange email application must not share a partition with another application.", "ruleVulnDiscussion": "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.\n\nEmail 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002530", "ruleFixText": "Update the EDSP with the location of where Exchange is installed.\n\nInstall Exchange on a dedicated application directory or partition separate than that of the operating system.", "ruleFixId": "F-63351r942425_fix", "ruleCheckSystem": "C-63443r942424_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP).\n\nDetermine if the directory Exchange is installed:\n\n1. Open Windows Explorer.\n2. Navigate to where Exchange is installed. \n\nIf 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.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18846, "benchmarkId": 369, "groupId": "V-259707", "title": "SRG-APP-000435", "description": "", "ruleId": "SV-259707r961620_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000232", "ruleTitle": "The Exchange SMTP automated banner response must not reveal server details.", "ruleVulnDiscussion": "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: \n\n220 exchange.mydomain.org Microsoft ESMTP MAIL Service ready at Tuesday, 23 Nov 2021 13:43:00 -0500\n\nChanging the response to hide local configuration details reduces the attack profile of the target.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002385", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-ReceiveConnector -Identity <'IdentityName'> -Banner '220 SMTP Server Ready'\n\nNote: The and 220 SMTP Server Ready values must be in quotes.\n\nRepeat the procedures for each Receive connector.", "ruleFixId": "F-63354r942434_fix", "ruleCheckSystem": "C-63446r942433_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-ReceiveConnector | Select-Object -Property Name, Identity, Banner\n\nFor each Receive connector, if the value of \"Banner\" is not set to \"220 SMTP Server Ready\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18847, "benchmarkId": 369, "groupId": "V-259708", "title": "SRG-APP-000435", "description": "", "ruleId": "SV-259708r961620_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000233", "ruleTitle": "Exchange internal send connectors must use an authentication level.", "ruleVulnDiscussion": "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.\n\nThe 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.\n\nIndividually, 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002385", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-SendConnector -Identity <'IdentityName'> -TlsAuthLevel DomainValidation\n\nNote: The value must be in quotes.\n\nRepeat the procedure for each Send connector.", "ruleFixId": "F-63355r942437_fix", "ruleCheckSystem": "C-63447r942436_chk", "ruleCheckContent": "Open the Exchange Management Shell and enter the following command:\n\nGet-SendConnector | Select-Object -Property Name, Identity, TlsAuthLevel\n\nFor each Send connector, if the value of \"TlsAuthLevel\" is not set to \"DomainValidation\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18848, "benchmarkId": 369, "groupId": "V-259709", "title": "SRG-APP-000435", "description": "", "ruleId": "SV-259709r961620_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000234", "ruleTitle": "Exchange must provide mailbox databases in a highly available and redundant configuration.", "ruleVulnDiscussion": "Exchange Server mailbox databases and any data contained in those mailboxes should be protected. This can be accomplished by configuring Mailbox servers and databases for high availability and site resilience.\n\nA database availability group (DAG) is a component of the Mailbox server high availability and site resilience framework built into Microsoft Exchange Server 2019. 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.\n\nA DAG is a boundary for mailbox database replication and database and server switchovers and failovers.\n\nAny 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.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002385", "ruleFixText": "Update the EDSP to specify how Exchange Mailbox databases use redundancy.\n\nAdd two or more Mailbox servers to the database availability group.\n\nAdd a database copy to one or more member servers within the database availability group.", "ruleFixId": "F-63356r942440_fix", "ruleCheckSystem": "C-63448r942439_chk", "ruleCheckContent": "Review the Email Domain Security Plan (EDSP).\n\nDetermine if a Database Availability Group exists.\nFrom Exchange Admin Center:\n1. In the pane on the left, navigate to \"servers\". \n2. In the pane on the right, navigate to the \"database availability groups\" tab.\n3. Verify a database availability group is configured with member servers.\n\nIf two or more member servers are not listed, this is a finding.\n\nFrom Exchange PowerShell, run the following cmdlet:\n\nGet-DatabaseAvailabilityGroup\n\nIf no DatabaseAvailabilityGroup is listed or a Database Availability Group is listed but has no member servers, this is a finding.\n\nDetermine if the Exchange Mailbox databases are using redundancy.\nFrom Exchange Admin Center:\n1. In the pane on the left, navigate to \"servers\".\n2. In the pane on the right, navigate to the \"databases\" tab.\n3. For each database, check the column \"SERVERS WITH COPIES\".\n\nUnless specified in the EDSP, if the \"SERVERS WITH COPIES\" column does not have two or more servers listed, this is a finding.\n\nFrom Exchange PowerShell, run the following cmdlet:\n\nGet-MailboxDatabaseCopyStatus -Identity \n\nUnless specified in the EDSP, if the output of this cmdlet does not show more than one copy, this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18849, "benchmarkId": 369, "groupId": "V-259710", "title": "SRG-APP-000439", "description": "", "ruleId": "SV-259710r961632_rule", "ruleWeight": "10.0", "ruleSeverity": "high", "ruleVersion": "EX19-MB-000236", "ruleTitle": "The application must protect the confidentiality and integrity of transmitted information.", "ruleVulnDiscussion": "Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered.\n\nThis requirement applies only to those applications that are either distributed or can allow access to data nonlocally. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, applications need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPsec.\n\nCommunication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.\n\nSatisfies: SRG-APP-000219", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001184", "ruleFixText": "Open the Exchange Management Shell and enter the following command:\n\nSet-ReceiveConnector -Identity <'IdentityName'> -AuthMechanism 'Tls'\n\nNote: The value must be in quotes.\n\nRepeat the procedures for each Receive connector.", "ruleFixId": "F-63357r942443_fix", "ruleCheckSystem": "C-63449r942442_chk", "ruleCheckContent": "Note: AuthMechanism may include other mechanisms as long as the \"Tls\" is identified.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-ReceiveConnector | Select-Object -Property Name, Identity, AuthMechanism\n\nFor each Receive connector, if the value of \"AuthMechanism\" is not set to \"Tls\", this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18850, "benchmarkId": 369, "groupId": "V-259711", "title": "SRG-APP-000456", "description": "", "ruleId": "SV-259711r961683_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000244", "ruleTitle": "Exchange must have the most current, approved Cumulative Update installed.", "ruleVulnDiscussion": "Failure to install the most current Exchange Cumulative Update (CU) leaves a system vulnerable to exploitation. Current CUs correct known security and system vulnerabilities.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002605", "ruleFixText": "Consult the EDSP for the accepted update process within the organization.\n\nInstall the most current, approved CU. Microsoft recommends as a best practice to always install the latest CU when creating a new server. Existing servers keep as up-to-date as possible and backup any customizations. Follow any additional recommendations by going to the following website:\nhttps://learn.microsoft.com/en-us/Exchange/plan-and-deploy/install-cumulative-updates?view=exchserver-2019\n\nAll Exchange 2019 updates can be found on the Microsoft Exchange update site:\nhttps://learn.microsoft.com/en-us/Exchange/new-features/updates?view=exchserver-2019\n\nExchange CUs must be manually downloaded. Since CUs are full installations of Exchange, there is no need to install the \"Release to Manufacturer\" version first. However, once installed, it cannot be uninstalled. Installation must be done on a test server first before placing in production to ensure that it does not disrupt services or conflict with existing configurations.\n\nNote: Some CUs will require an Active Directory Schema extension, which adds new Exchange attributes. Consult the EDSP and ensure appropriate permissions before beginning an update.\n\nNote: Security updates (SUs) can be downloaded and triggered through Windows Updates by going to Windows Update >>Advanced Options >> \"Choose how updates are installed\" and select the box \"Give me updates for other Microsoft products when I update Windows\" if the Exchange server is connected to the web or internal Windows Update Services.", "ruleFixId": "F-63358r942446_fix", "ruleCheckSystem": "C-63450r942445_chk", "ruleCheckContent": "Determine the most current, approved service pack.\n\nOpen the Exchange Management Shell and enter the following command:\n\nGet-ExchangeServer | Select-Object -Property Name, AdminDisplayVersion |Format-List\n\nIf the value of \"AdminDisplayVersion\" does not return the most current, approved Cumulative Update (CU), this is a finding.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" }, { "id": 18851, "benchmarkId": 369, "groupId": "V-259712", "title": "SRG-APP-000516", "description": "", "ruleId": "SV-259712r961863_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "EX19-MB-000283", "ruleTitle": "Exchange must be configured in accordance with the security configuration settings based on DOD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs.", "ruleVulnDiscussion": "Configuring Exchange to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DOD that reflects the most restrictive security posture consistent with operational requirements.\n\nConfiguration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the application, including the parameters required to satisfy other security control requirements.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000366", "ruleFixText": "Configure web ports to be ports 80 and 443, as specified by PPSM standards.\n\nIn an Exchange Management Shell, run the following cmdlet on the \"Default Web Site\":\n\nSet-WebBinding -Name 'Default Web Site' -BindingInformation \"127.0.0.1:443:\" -PropertyName Port -Value 443\n\nSet-WebBinding -Name 'Default Web Site' -BindingInformation \":443:\" -PropertyName Port -Value 443\n\nNote: This does not apply to the Exchange Back End website.", "ruleFixId": "F-63359r942449_fix", "ruleCheckSystem": "C-63451r942448_chk", "ruleCheckContent": "Open a Windows PowerShell Module and enter the following commands:\n\nGet-Website | Select-Object -Property Name\n\nGet-WebBinding -Name <'WebSiteName'> | Format-List\n\nIf the Web binding values returned are not on standard port 80 for HTTP connections or port 443 for HTTPS connections, this is a finding.\n\nNote: This is excluding the Exchange Back End website which uses 81/444.\n\nRepeat the process for each website.", "createdAt": "2025-10-21T11:30:38.523Z", "updatedAt": "2025-10-21T11:30:38.523Z" } ], "profiles": [ { "id": 3254, "benchmarkId": 369, "profileId": "MAC-1_Classified", "title": "I - Mission Critical Classified", "description": "", "createdAt": "2025-10-21T11:30:38.647Z", "updatedAt": "2025-10-21T11:30:38.647Z" }, { "id": 3255, "benchmarkId": 369, "profileId": "MAC-1_Public", "title": "I - Mission Critical Public", "description": "", "createdAt": "2025-10-21T11:30:38.647Z", "updatedAt": "2025-10-21T11:30:38.647Z" }, { "id": 3256, "benchmarkId": 369, "profileId": "MAC-1_Sensitive", "title": "I - Mission Critical Sensitive", "description": "", "createdAt": "2025-10-21T11:30:38.647Z", "updatedAt": "2025-10-21T11:30:38.647Z" }, { "id": 3257, "benchmarkId": 369, "profileId": "MAC-2_Classified", "title": "II - Mission Support Classified", "description": "", "createdAt": "2025-10-21T11:30:38.647Z", "updatedAt": "2025-10-21T11:30:38.647Z" }, { "id": 3258, "benchmarkId": 369, "profileId": "MAC-2_Public", "title": "II - Mission Support Public", "description": "", "createdAt": "2025-10-21T11:30:38.647Z", "updatedAt": "2025-10-21T11:30:38.647Z" }, { "id": 3259, "benchmarkId": 369, "profileId": "MAC-2_Sensitive", "title": "II - Mission Support Sensitive", "description": "", "createdAt": "2025-10-21T11:30:38.647Z", "updatedAt": "2025-10-21T11:30:38.647Z" }, { "id": 3260, "benchmarkId": 369, "profileId": "MAC-3_Classified", "title": "III - Administrative Classified", "description": "", "createdAt": "2025-10-21T11:30:38.647Z", "updatedAt": "2025-10-21T11:30:38.647Z" }, { "id": 3261, "benchmarkId": 369, "profileId": "MAC-3_Public", "title": "III - Administrative Public", "description": "", "createdAt": "2025-10-21T11:30:38.647Z", "updatedAt": "2025-10-21T11:30:38.647Z" }, { "id": 3262, "benchmarkId": 369, "profileId": "MAC-3_Sensitive", "title": "III - Administrative Sensitive", "description": "", "createdAt": "2025-10-21T11:30:38.647Z", "updatedAt": "2025-10-21T11:30:38.647Z" } ] }