kriterion 0.0.1

data/standards/stig_ms_exchange_2013_edge_transport_server.json

@@ -0,0 +1,443 @@
+{
+  "name": "stig_ms_exchange_2013_edge_transport_server",
+  "date": "2017-01-04",
+  "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.",
+  "title": "MS Exchange 2013 Edge Transport Server Security Technical Implementation Guide",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-69783",
+      "title": "Exchange must limit the Receive connector timeout.",
+      "description": "Email system availability depends in part on best practices 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 connections may be maintained for unnecessarily long time periods, preventing new connections from being established.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69785",
+      "title": "Exchange servers must use approved DoD certificates.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69787",
+      "title": "Exchange must have accepted domains configured.",
+      "description": "Exchange may be configured to accept email for multiple domain names. This setting identifies the domains for which the server will accept mail. This check verifies the email server is not accepting email for unauthorized domains.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69789",
+      "title": "Exchange must have auto-forwarding of email to remote domains disabled or restricted.",
+      "description": "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 Automatic Forwards to remote domains are disabled, except for enterprise email that must be restricted to forward-only to .mil and .gov. domains.\n\nBefore enabling this setting, first configure a remote domain.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69791",
+      "title": "Exchange external Receive connectors must be domain secure-enabled.",
+      "description": "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 authentication method used for communications between servers. With this feature enabled, messages can be securely passed from a partner domain securely.\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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69793",
+      "title": "The Exchange email Diagnostic log level must be set to the lowest level.",
+      "description": "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 broken up into 29 main \"services\", each of which has anywhere from 2 to 26 \"categories\" of events to be monitored. Moreover, each category may be set to one of four levels of logging: Lowest, Low, CAT II, and High, depending on how much detail one desires. The higher the level of detail, the more disk space required to store the audit material.\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 deal of information, the log files may grow large very quickly. Diagnostic log levels may be raised for limited periods of time when attempting to debug relevant pieces of Exchange functionality. Once debugging has finished, diagnostic log levels should be reduced again.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69795",
+      "title": "Exchange Connectivity logging must be enabled.",
+      "description": "A connectivity log is a record of the SMTP connection activity of the outbound message delivery queues to the destination mailbox server, smart host, or domain. Connectivity logging is available on Hub Transport servers and Edge Transport servers. By default, connectivity logging is disabled. If events are not recorded, it may be difficult or impossible to determine the root cause of system problems or the unauthorized activities of malicious users.\n\nNOTE: Transport configuration settings apply to the organization/global level of the Exchange SMTP path. By checking and setting them at the Hub server, the setting will apply to both Hub and Edge roles.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69797",
+      "title": "Exchange Queue monitoring must be configured with threshold and action.",
+      "description": "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 exist occasionally. Frequent alerts against this counter may indicate a network or other issue (such as inbound SPAMMER 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).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69799",
+      "title": "Exchange must not send Customer Experience reports to Microsoft.",
+      "description": "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 non-essential capabilities include, but are not limited to, advertising software or browser plug-ins not related to requirements or providing a wide array of functionality not required for every mission, but cannot be disabled.\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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69801",
+      "title": "Exchange Audit data must be protected against unauthorized access (read access).",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69803",
+      "title": "Exchange Send Fatal Errors to Microsoft must be disabled.",
+      "description": "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 non-essential capabilities include, but are not limited to, advertising software or browser plug-ins not related to requirements or providing a wide array of functionality not required for every mission, but cannot be disabled.\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 to Microsoft must not be sent.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69805",
+      "title": "Exchange audit data must be protected against unauthorized access for modification.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69807",
+      "title": "Exchange audit data must be protected against unauthorized access for deletion.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69809",
+      "title": "Exchange audit data must be on separate partitions.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69811",
+      "title": "The Exchange local machine policy must require signed scripts.",
+      "description": "Scripts, especially those downloaded from untrusted locations, often provide a way for attackers to infiltrate a system. By setting machine policy to prevent unauthorized script executions, unanticipated system impacts can be avoided.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69813",
+      "title": "Exchange Internet-facing Send connectors must specify a Smart Host.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69815",
+      "title": "Exchange internal Send connectors must use domain security (mutual authentication Transport Layer Security).",
+      "description": "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 authentication method used for communications between servers. With this feature enabled, only servers capable of supporting domain authentication will be able to send and receive mail within the domain.\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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69817",
+      "title": "Exchange Internet-facing Receive connectors must offer Transport Layer Security (TLS) before using basic authentication.",
+      "description": "Sending unencrypted email over the Internet increases the risk that messages can be intercepted or altered. TLS is designed to protect confidentiality and data integrity by encrypting email messages between servers and thereby reducing the risk of eavesdropping, interception, and alteration. This setting forces Exchange to offer TLS before using basic authentication.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69819",
+      "title": "Exchange Outbound Connection Timeout must be 10 minutes or less.",
+      "description": "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\nConnections, once established, may incur delays in message transfer. The default of 10 minutes is a reasonable window in which to resume activities without maintaining idle connections for excessive intervals. If the timeout period is too long, idle connections may be maintained for unnecessarily long time periods, preventing new connections from being established. Sluggish connectivity increases the risk of lost data. A value of 10 or less is optimal.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69821",
+      "title": "Exchange Outbound Connection Limit per Domain Count must be controlled.",
+      "description": "Email system availability depends in part on best practice strategies for setting tuning configurations. This configuration controls the maximum number of simultaneous outbound connections from a domain and works in conjunction with the Maximum Outbound Connections Count setting as a delivery tuning mechanism. If the limit is too low, connections may be dropped. If the limit is too high, some domains may use a disproportionate resource share, denying access to other domains. Appropriate tuning reduces the 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69823",
+      "title": "Exchange Global Outbound Message size must be controlled.",
+      "description": "Email system availability depends in part on best practice strategies for setting tuning configurations. Message size limits should be set to 10 megabytes at most but often are smaller, depending on the organization. The key point in message size is that it should be set globally, and it should not be set to \"unlimited\". Selecting \"unlimited\" on either field is likely to result in abuse and can contribute to excessive server disk space consumption. \n\nMessage size limits may also be applied on Send and Receive connectors, public folders, and the user account in Active Directory. 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.",
+      "severity": "low"
+    },
+    {
+      "id": "V-69825",
+      "title": "Exchange Global Inbound Message size must be controlled.",
+      "description": "Email system availability depends in part on best practice strategies for setting tuning configurations. Message size limits should be set to 10 megabytes at most but often are smaller, depending on the organization. The key point in message size is that it should be set globally, and it should not be set to \"unlimited\". Selecting \"unlimited\" on either field is likely to result in abuse and can contribute to excessive server disk space consumption. \n\nMessage size limits may also be applied on Send and Receive connectors, public folders, and the user account in Active Directory. 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.",
+      "severity": "low"
+    },
+    {
+      "id": "V-69827",
+      "title": "Exchange Send connector connections count must be limited.",
+      "description": "This 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 the risk of data delay or loss.",
+      "severity": "low"
+    },
+    {
+      "id": "V-69829",
+      "title": "Exchange message size restrictions must be controlled on Send connectors.",
+      "description": "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 EDSP.",
+      "severity": "low"
+    },
+    {
+      "id": "V-69831",
+      "title": "Exchange Send connectors delivery retries must be controlled.",
+      "description": "This setting controls the rate at which delivery attempts from the home domain are retried and user notifications are issued and notes the expiration time when the message will be discarded.  \n\nIf delivery retry attempts are too frequent, servers will generate network congestion. If they are too far apart, messages may remain queued longer than necessary, potentially raising disk resource requirements.\n\nThe default values of these fields should be adequate for most environments. Administrators may wish to modify the values, but changes should be documented in the System Security Plan.\n\nNOTE: Transport configuration settings apply to the organization/global level of the Exchange SMTP path. By checking and setting them at the Hub server, the setting will apply to both Hub and Edge roles.",
+      "severity": "low"
+    },
+    {
+      "id": "V-69833",
+      "title": "Exchange Send connectors must be clearly named.",
+      "description": "For Send connectors, unclear naming as to direction and purpose increases risk that messages may not flow as intended, troubleshooting efforts may be impaired, or incorrect assumptions may be made about the completeness of the configuration.  \n\nCollectively, connectors should account for all connections required for the overall email topology design. Simple Mail Transfer Protocol (SMTP) connectors, when listed, must name purpose and direction clearly, and their counterparts on servers to which they connect should be recognizable as their partners.",
+      "severity": "low"
+    },
+    {
+      "id": "V-69835",
+      "title": "Exchange Receive connector Maximum Hop Count must be 60.",
+      "description": "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 from 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 set too high, an undeliverable message may cycle between servers, raising the risk of network congestion.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69837",
+      "title": "Exchange Receive connectors must be clearly named.",
+      "description": "For receive connectors, unclear naming as to direction and purpose increases risk that messages may not flow as intended, troubleshooting efforts may be impaired, or incorrect assumptions may be made about the completeness of the configuration.  \n\nCollectively, connectors should account for all connections required for the overall email topology design. Simple Mail Transfer Protocol (SMTP) connectors, when listed, must name purpose and direction clearly, and their counterparts on servers to which they connect should be recognizable as their partners.",
+      "severity": "low"
+    },
+    {
+      "id": "V-69839",
+      "title": "Exchange Receive connectors must control the number of recipients chunked on a single message.",
+      "description": "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 enable \"chunking\" on received messages as they arrive at the domain. This is done so large message bodies can be relayed by the remote sender to the Receive connector in multiple, smaller chunks.",
+      "severity": "low"
+    },
+    {
+      "id": "V-69855",
+      "title": "Exchange Receive connectors must control the number of recipients per message.",
+      "description": "Email system availability depends in part on best practice strategies for setting tuning configurations. \n\nThis configuration controls the maximum number of recipients who will receive a copy of a message at one time. This tunable value is related to throughput capacity and can enable the ability to optimize message delivery. \n\nNote: There are two types of default Receive connecters:\n\n\"Client Servername\" accepts SMTP connections from all non-MAPI clients, such as POP and IMAP. As POP and IMAP are not authorized for use in DoD, these should not be present. Their default value for MaxRecipientsPerMessage is 200.\n\n\"Default Servername\" accepts connections from other Hub Transport servers and any Edge Transport servers. Their default value for MaxRecipientsPerMessage is 5000.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69857",
+      "title": "The Exchange Internet Receive connector connections count must be set to default.",
+      "description": "Email system availability depends in part on best practice strategies for setting tuning configurations. This configuration controls the maximum number of simultaneous inbound connections allowed to the SMTP server. \n\nBy default, the number of simultaneous inbound connections is 5000. If a limit is set too low, the connections pool may be filled. If attackers perceive the limit is too low, they could deny service to the Simple Mail Transfer Protocol (SMTP) server by using a connection count that exceeds the limit set. By setting the default configuration to 5000, attackers would need many more connections to cause denial of service.",
+      "severity": "low"
+    },
+    {
+      "id": "V-69859",
+      "title": "Exchange Message size restrictions must be controlled on Receive connectors.",
+      "description": "Email system availability depends in part on best practices 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 EDSP.",
+      "severity": "low"
+    },
+    {
+      "id": "V-69861",
+      "title": "Exchange messages with a blank sender field must be rejected.",
+      "description": "By performing filtering at the perimeter, up to 90 percent of spam, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment. Anonymous email (messages with blank sender fields) cannot be replied to. Messages formatted in this way may be attempting to hide their true origin to avoid responses or to spam any receiver with impunity while hiding their source of origination.\n\nRather than spend resources and risk infection while evaluating them, it is recommended that these messages be filtered immediately upon receipt and not forwarded to end users.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69863",
+      "title": "Exchange messages with a blank sender field must be filtered.",
+      "description": "By performing filtering at the perimeter, up to 90 percent of spam, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment. Anonymous email (messages with blank sender fields) cannot be replied to. Messages formatted in this way may be attempting to hide their true origin to avoid responses or to spam any receiver with impunity while hiding their source of origination.  \n\nRather than spend resources and risk infection while evaluating them, it is recommended that these messages be filtered immediately upon receipt and not forwarded to end users.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69865",
+      "title": "Exchange filtered messages must be archived.",
+      "description": "By performing filtering at the perimeter, up to 90 percent of spam, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment. This significantly reduces the attack vector for inbound email-borne spam and malware. \n\nAs messages are filtered, it is prudent to temporarily host them in an archive for evaluation by administrators or users. The archive can be used to recover messages that might have been inappropriately filtered, preventing data loss, and to provide a base of analysis that can provide future filter refinements.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69867",
+      "title": "The Exchange Sender filter must block unaccepted domains.",
+      "description": "Spam origination sites and other sources of suspected email-borne malware have the ability to corrupt, compromise, or otherwise limit availability of email servers. Limiting exposure to unfiltered inbound messages can reduce the risk of spam and malware impacts. \n\nThe Global Deny list blocks messages originating from specific sources. Most blacklist filtering is done using a commercial Block List service, because eliminating threats from known spammers prevents the messages being evaluated inside the enclave where there is more risk they can do harm. \n\nAdditional sources should also be blocked to supplement the contents of the commercial Block List service. For example, during a zero-day threat action, entries can be added and then removed when the threat is mitigated. An additional best practice is to enter the enterprise’s home domains in the Deny List, because inbound email with a \"from\" address of the home domain is very likely to be spoofed spam.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69869",
+      "title": "Exchange nonexistent recipients must not be blocked.",
+      "description": "Spam originators, in an effort to refine mailing lists, sometimes use a technique where they first create fictitious names and then monitor rejected emails for non-existent recipients. Those not rejected are deemed to exist and are used in future spam mailings. \n\nTo prevent this disclosure of existing email accounts to spammers, email to nonexistent recipients must not be blocked. Instead, it is recommended that all messages be received, then evaluated and disposed of without enabling the sender to determine existent vs. nonexistent recipients.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69871",
+      "title": "The Exchange Sender Reputation filter must be enabled.",
+      "description": "By performing filtering at the perimeter, up to 90 percent of spam, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment. Sender Reputation is antispam functionality that blocks messages according to many characteristics of the sender. Sender Reputation relies on persisted data about the sender to determine what action, if any, to take on an inbound message. This setting enables the Sender Reputation function.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69873",
+      "title": "The Exchange Sender Reputation filter must identify the spam block level.",
+      "description": "By performing filtering at the perimeter, up to 90 percent of spam, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment. Sender Reputation is antispam functionality that blocks messages according to many characteristics of the sender. Sender Reputation relies on persisted data about the sender to determine what action, if any, to take on an inbound message. This setting enables the threshold at which an email will be considered spam.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69875",
+      "title": "Exchange Attachment filtering must remove undesirable attachments by file type.",
+      "description": "By performing filtering at the perimeter, up to 90 percent of spam, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the mail server environment. \n\nAttachments are being used more frequently for different forms of attacks. By filtering undesirable attachments a large percent of malicious code can be prevented from entering the system. Attachments must be controlled at the entry point into the email environment to prevent successful attachment-based attacks. The following is a basic list of known attachments that should be filtered from Internet mail attachments:\n\n*.ade  *.crt  *.jse  *.msi  *.scr  *.wsh  *.dir\n*.adp  *.csh  *.ksh  *.msp  *.sct  *.htm  *.dcr\n*.app  *.exe  *.lnk  *.mst  *.shb  *.html  *.plg\n*.asx  *.fxp  *.mda  *.ops  *.shs  *.htc  *.spl\n*.bas  *.hlp  *.mdb  *.pcd  *.url  *.mht  *.swf\n*.bat  *.hta  *.mde  *.pif  *.vb  *.mhtml  *.zip\n*.chm  *.inf  *.mdt  *.prf  *.vbe  *.shtm  \n*.cmd  *.ins  *.mdw  *.prg  *.vbs  *.shtml  \n*.com  *.isp  *.mdz  *.reg  *.wsc  *.stm  \n*.cpl  *.js  *.msc  *.scf  *.wsf  *.xml",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69877",
+      "title": "The Exchange Spam Evaluation filter must be enabled.",
+      "description": "By performing filtering at the perimeter, up to 90 percent of spam, malware, and other undesirable messages may be eliminated from the transport message stream, preventing their entry into the Exchange environment. This significantly reduces the attack vector for inbound email-borne spam and malware.\n\nSpam Evaluation filters scan inbound email messages for evidence of spam and other attacks that primarily use \"social engineering\" techniques. Upon evaluation completion, a rating is assigned to each message estimating the likelihood of its being spam. Upon arrival at the destination mailbox, the junk mail filter threshold (also configurable) determines whether the message will be withheld from delivery, delivered to the junk mail folder, or delivered to the user’s inbox.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69879",
+      "title": "The Exchange Block List service provider must be identified.",
+      "description": "Block List filtering is a sanitization process performed on email messages prior to their arrival at the destination mailbox. By performing this process at the email perimeter, threats can be eliminated outside the enclave, where there is less risk they can do harm.\n \nBlock List services (sometimes called Reputation Data services) are fee-based data providers that collect the IP addresses of known spammers and other malware purveyors. Block List service subscribers benefit from more effective spam elimination. (Spam is estimated to compose up to 90 percent of inbound mail volume.) Failure to specify a Block List provider risks that manual email administration effort would be needed to maintain and update larger Block Lists than a single email site administrator could conveniently or accurately maintain. \n\nThe Block List service vendor provides a value for this field, usually the Domain Name System (DNS) suffix for its domain.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69881",
+      "title": "Exchange messages with malformed From address must be rejected.",
+      "description": "Sender Identification (SID) is an email antispam sanitization process. Sender ID uses DNS MX record lookups to verify the Simple Mail Transfer Protocol (SMTP) sending server is authorized to send email for the originating domain.\n \nFailure to implement Sender ID risks that spam could be admitted into the email domain that originates from rogue servers. Most spam content originates from domains where the IP address has been spoofed prior to sending, thereby avoiding detection. For example, messages with malformed or incorrect \"purported responsible sender\" data in the message header could be (best case) created by using RFI noncompliant software but is more likely to be spam.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69883",
+      "title": "The Exchange Global Recipient Count Limit must be set.",
+      "description": "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 ensures 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.",
+      "severity": "low"
+    },
+    {
+      "id": "V-69885",
+      "title": "Exchange must not send automated replies to remote domains.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69887",
+      "title": "Exchange  external/Internet-bound automated response messages must be disabled.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69889",
+      "title": "The Exchange Recipient filter must be enabled.",
+      "description": "Email system availability depends in part on best practice strategies for setting tuning configurations. Careful tuning reduces the risk that system or network congestion will contribute to availability impacts. \n\nFilters that govern inbound email evaluation can significantly reduce spam, phishing, and spoofed emails. Messages from blank senders, known spammers, or zero-day attack modifications must be enabled to be effective.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69891",
+      "title": "The Exchange tarpitting interval must be set.",
+      "description": "Tarpitting is the practice of artificially delaying server responses for specific Simple Mail Transfer Protocol (SMTP) communication patterns that indicate high volumes of spam or other unwelcome messages. The intent of tarpitting is to slow down the communication process for spam batches to reduce the cost effectiveness of sending spam and thwart directory harvest attacks.  \n\nA directory harvest attack is an attempt to collect valid email addresses from a particular organization so the email addresses can be added to a spam database. A program can be written to collect email addresses that return a \"Recipient OK\" SMTP response and discard all email addresses that return a \"User unknown\" SMTP response.\n\nTarpitting makes directory harvest attacks too costly to automate efficiently.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69893",
+      "title": "Exchange internal Receive connectors must not allow anonymous connections.",
+      "description": "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, relay hijacking 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69895",
+      "title": "Exchange Simple Mail Transfer Protocol (SMTP) IP Allow List entries must be empty.",
+      "description": "Email system availability depends in part on best practice strategies for setting tuning configurations. Careful tuning reduces the risk that system or network congestion will contribute to availability impacts. \n\nFilters that govern inbound email evaluation can significantly reduce spam, phishing, and spoofed emails. Filters for messages from blank senders, known spammers, or zero-day attack modifications must be enabled to be effective. \n\nHaving items identified in the Allow List causes other spam evaluation steps to be bypassed and therefore should be used only with an abundance of caution. If spammers were to learn of entries in the Allow List, it could enable them to plan a denial of service attack (or other attack) by spoofing that source.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69897",
+      "title": "The Exchange Simple Mail Transfer Protocol (SMTP) IP Allow List Connection filter must be enabled.",
+      "description": "Email system availability depends in part on best practice strategies for setting tuning configurations. Careful tuning reduces the risk that system or network congestion will contribute to availability impacts. \n\nFilters that govern inbound email evaluation can significantly reduce spam, phishing, and spoofed emails. Filters for messages from blank senders, known spammers, or zero-day attack modifications must be enabled to be effective. \n\nHaving items identified in the Allow List causes other spam evaluation steps to be bypassed and therefore should be used only with an abundance of caution. If spammers were to learn of entries in the Allow List, it could enable them to plan a denial of service attack (or other attack) by spoofing that source.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69899",
+      "title": "The Exchange Simple Mail Transfer Protocol (SMTP) Sender filter must be enabled.",
+      "description": "Email system availability depends in part on best practices strategies for setting tuning configurations. Careful tuning reduces the risk that system or network congestion will contribute to availability impacts. \n\nFilters that govern inbound email evaluation can significantly reduce spam, phishing, and spoofed emails. Filters for messages from blank senders, known spammers, or zero-day attack modifications must be enabled to be effective. \n\nFailure to enable the filter will result in no action taken. This setting should always be enabled.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69901",
+      "title": "Exchange must have antispam filtering installed.",
+      "description": "Originators of spam messages are constantly changing their techniques in order to defeat spam countermeasures; therefore, spam software must be constantly updated to address the changing threat. Spam protection mechanisms include, for example, signature definitions, rule sets, and algorithms.\n\nExchange 2013 provides both antispam and antimalware protection out of the box. The Exchange 2013 antispam and antimalware product capabilities are limited but still provide some protection.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69903",
+      "title": "Exchange must have antispam filtering enabled.",
+      "description": "Originators of spam messages are constantly changing their techniques in order to defeat spam countermeasures; therefore, spam software must be constantly updated to address the changing threat. Spam protection mechanisms include, for example, signature definitions, rule sets, and algorithms.\n\nExchange 2013 provides both antispam and antimalware protection out of the box. The Exchange 2013 antispam and antimalware product capabilities are limited but still provide some protection.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69905",
+      "title": "Exchange must have antispam filtering configured.",
+      "description": "Originators of spam messages are constantly changing their techniques in order to defeat spam countermeasures; therefore, spam software must be constantly updated to address the changing threat. A manual update procedure is labor intensive and does not scale well in an enterprise environment. This risk may be mitigated by using an automatic update capability. Spam protection mechanisms include, for example, signature definitions, rule sets, and algorithms.\n\nExchange 2013 provides both antispam and antimalware protection out of the box. The Exchange 2013 antispam and antimalware product capabilities are limited but still provide some protection.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69907",
+      "title": "Exchange Sender Identification Framework must be enabled.",
+      "description": "Email is only as secure as the recipient. When the recipient is an email server accepting inbound messages, authenticating the sender enables the receiver to better assess message quality and to validate the sending domain as authentic. One or more authentication techniques used in combination can be effective in reducing spam, phishing, and forger attacks. \n\nThe Sender ID Framework (SIDF) receiver accesses specially formatted DNS records (SPF format) that contain the IP address of authorized sending servers for the sending domain that can be compared to data in the email message header. Receivers are able to validate the authenticity of the sending domain, helping to avoid receiving inbound messages from phishing or other spam domains.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69909",
+      "title": "Exchange must strip hyperlink email sources from non-.mil domains.",
+      "description": "Active hyperlinks within an email are susceptible to attacks of malicious software or malware. The hyperlink could lead to a malware infection or redirect the website to another fraudulent website without the user's consent or knowledge. \n\nExchange does not have a built-in message filtering capability. DoD Enterprise Email (DEE) has created a custom resolution to filter messages from non-.mil users that have hyperlinks in the message body. The hyperlink within the messages will be modified, preventing end users from automatically clicking links.",
+      "severity": "high"
+    },
+    {
+      "id": "V-69911",
+      "title": "The Exchange application directory must be protected from unauthorized access.",
+      "description": "Default product installations may provide more generous access permissions than are necessary to run the application. By examining and tailoring access permissions to more closely provide the least amount of privilege possible, attack vectors that align with user permissions are less likely to access more highly secured areas.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69913",
+      "title": "The Exchange software baseline copy must exist.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69915",
+      "title": "Exchange software must be monitored for unauthorized changes.",
+      "description": "Monitoring software files for changes against a baseline on a regular basis may help detect the possible introduction of malicious code on a system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69917",
+      "title": "Exchange services must be documented and unnecessary services must be removed or disabled.",
+      "description": "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.\n\nSimilarly, 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 POP3 and IMAP4 clients are not included in the standard desktop offering, they must be disabled.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69919",
+      "title": "Exchange software must be installed on a separate partition from the OS.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69921",
+      "title": "The Exchange SMTP automated banner response must not reveal server details.",
+      "description": "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 about 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, Version: 6.0.3790.211 ready at Wed, 2 Feb 2005 23:40:00 -0500\n\nChanging the response to hide local configuration details reduces the attack profile of the target.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69923",
+      "title": "Exchange must not send nondelivery reports to remote domains.",
+      "description": "Attackers can use automated messages to determine whether a user account is active, in the office, traveling, and so on. An attacker might use this information to conduct future attacks. Ensure that nondelivery reports to remote domains are disabled. Before enabling this setting, first configure a remote domain using the EMC or the New-RemoteDomain cmdlet.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69925",
+      "title": "Exchange must not send delivery reports to remote domains.",
+      "description": "Attackers can use automated messages to determine whether a user account is active, in the office, traveling, and so on. An attacker might use this information to conduct future attacks. Ensure that delivery reports to remote domains are disabled. Before enabling this setting, first configure a remote domain using the EMC or the New-RemoteDomain cmdlet.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69927",
+      "title": "Exchange must provide redundancy.",
+      "description": "Denial of Service (DoS) is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.\n\nThis requirement addresses the configuration of applications to mitigate the impact of DoS attacks that have occurred or are ongoing on application availability. For each application, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or restricting the number of sessions the application opens at one time). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks.",
+      "severity": "high"
+    },
+    {
+      "id": "V-69929",
+      "title": "Exchange internal Send connectors must use an authentication level.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69931",
+      "title": "Exchange internal Receive connectors must require encryption.",
+      "description": "The Simple Mail Transfer Protocol (SMTP) Receive connector is used by Exchange to send and receive messages from server to server using SMTP protocol. This setting controls the encryption strength used for client connections to the SMTP Receive connector. With this feature enabled, only clients capable of supporting secure communications will be able to send mail using this SMTP server. Where secure channels are required, encryption can also be selected. \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 the client to the server adds protection by encrypting the sender and recipient information that cannot be encrypted by the sender.  \n\nIndividually, channel security and encryption have been compromised by attackers. Used together, email becomes a more difficult target, and security is heightened. Failure to enable this feature gives eavesdroppers an opportunity to read or modify messages between the client and server.",
+      "severity": "high"
+    },
+    {
+      "id": "V-69933",
+      "title": "Exchange internal Send connectors must require encryption.",
+      "description": "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.",
+      "severity": "high"
+    },
+    {
+      "id": "V-69935",
+      "title": "Exchange must have the most current, approved service pack installed.",
+      "description": "The organization (including any contractor to the organization) must promptly install security-relevant software updates (e.g., patches, service packs, hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69937",
+      "title": "The applications built-in Malware Agent must be disabled.",
+      "description": "Malicious code protection mechanisms include, but are not limited, to, anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. \n\nMalicious code includes viruses, worms, Trojan horses, and Spyware. It is not enough to simply have the software installed; this software must periodically scan the system to search for malware on an organization-defined frequency. \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 anti-virus and intrusion prevention software.\n\nSite must utilize an approved DoD scanner. Exchange Malware software has a limited scanning capability and does not scan files that are downloaded, opened, or executed.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69939",
+      "title": "A DoD-approved third party Exchange-aware malicious code protection application must be implemented.",
+      "description": "Malicious code protection mechanisms include, but are not limited, to, anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. \n\nMalicious code includes viruses, worms, Trojan horses, and Spyware. It is not enough to simply have the software installed; this software must periodically scan the system to search for malware on an organization-defined frequency. \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 anti-virus and intrusion prevention software.\n\nSite must utilize an approved DoD scanner. Exchange Malware software has a limited scanning capability and does not scan files that are downloaded, opened, or executed.",
+      "severity": "medium"
+    }
+  ]
+}

data/standards/stig_ms_exchange_2013_mailbox_server.json

@@ -0,0 +1,437 @@
+{
+  "name": "stig_ms_exchange_2013_mailbox_server",
+  "date": "2017-04-06",
+  "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.",
+  "title": "MS Exchange 2013 Mailbox Server Security Technical Implementation Guide",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-69941",
+      "title": "Exchange must have Administrator audit logging enabled.",
+      "description": "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. \n\nAuditing 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 users' assigned role or permissions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69943",
+      "title": "Exchange Servers must use approved DoD certificates.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69945",
+      "title": "Exchange auto-forwarding email to remote domains must be disabled or restricted.",
+      "description": "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, first configure a remote domain.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69947",
+      "title": "Exchange Connectivity logging must be enabled.",
+      "description": "A connectivity log is a record of the SMTP connection activity of the outbound message delivery queues to the destination Mailbox server, smart host, or domain. Connectivity logging is available on Hub Transport servers and Edge Transport servers. By default, connectivity logging is disabled. If events are not recorded, it may be difficult or impossible to determine the root cause of system problems or the unauthorized activities of malicious users.\n\nNote: Transport configuration settings apply to the organization/global level of the Exchange SMTP path. By checking and setting them at the Hub server, the setting will apply to both Hub and Edge roles.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69949",
+      "title": "The Exchange Email Diagnostic log level must be set to the lowest level.",
+      "description": "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 broken up into 29 main \"services\", each of which has anywhere from 2 to 26 \"categories\" of events to be monitored. Moreover, each category may be set to one of four levels of logging: Lowest, Low, Medium, and High, depending on how much detail one desires. The higher the level of detail, the more disk space required to store the audit material.\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 deal of information, the log files may grow large very quickly. Diagnostic log levels may be raised for limited periods of time when attempting to debug relevant pieces of Exchange functionality. Once debugging has finished, diagnostic log levels should be reduced again.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69951",
+      "title": "Exchange Audit record parameters must be set.",
+      "description": "Log files help establish a history of activities, and can be useful in detecting attack attempts. This item declares the fields that must be available in the audit log file in order to adequately research events that are logged. \n\nAudit records should include the following fields to supply useful event accounting: \nObject modified, Cmdlet name, Cmdlet parameters, Modified parameters, Caller, Succeeded, and Originating server.",
+      "severity": "low"
+    },
+    {
+      "id": "V-69953",
+      "title": "Exchange Circular Logging must be disabled.",
+      "description": "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, there is one log file stored with a default size of 1024 KB. Once the size limit has been reached, additional log entries overwrite the oldest log entries. If circular logging is disabled, once a log file reaches the size limit, a new log file is created. \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.",
+      "severity": "low"
+    },
+    {
+      "id": "V-69955",
+      "title": "Exchange Email Subject Line logging must be disabled.",
+      "description": "Log files help establish a history of activities and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. When “message tracking” is enabled, only the sender, recipients, time, and other delivery information are included by default. Information such as the subject and message body is not included.\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\nThis feature creates larger log files and will contain information that may raise privacy and legal concerns. Enterprise policy should be consulted before this feature is enabled. Also, since the log files may contain sensitive information in the form of the subject line, the log files will need to be protected, commensurate with the sensitivity level, as the content may be of interest to an attacker.  \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 since the administrator will need to search using only the time the message was sent and the message’s sender. This control will have no effect unless Message Tracking is enabled. However, the setting should be disabled in case message tracking is enabled in the future.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69957",
+      "title": "Exchange Message Tracking Logging must be enabled.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69959",
+      "title": "Exchange Queue monitoring must be configured with threshold and action.",
+      "description": "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 exist 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).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69961",
+      "title": "Exchange Send Fatal Errors to Microsoft must be disabled.",
+      "description": "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 non-essential capabilities include, but are not limited to, advertising software or browser plug-ins not related to requirements or providing a wide array of functionality not required for every mission, but cannot be disabled.\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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69963",
+      "title": "Exchange must protect audit data against unauthorized read access.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69965",
+      "title": "Exchange must not send Customer Experience reports to Microsoft.",
+      "description": "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 non-essential capabilities include, but are not limited to, advertising software or browser plug-ins not related to requirements or providing a wide array of functionality not required for every mission, but cannot be disabled.\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 to Microsoft must not be sent.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69967",
+      "title": "Exchange must protect audit data against unauthorized access.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69969",
+      "title": "Exchange must protect audit data against unauthorized deletion.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69971",
+      "title": "Exchange Audit data must be on separate partitions.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69973",
+      "title": "Exchange Local machine policy must require signed scripts.",
+      "description": "Scripts often provide a way for attackers to infiltrate a system, especially those downloaded from untrusted locations. By setting machine policy to prevent unauthorized script executions, unanticipated system impacts can be avoided. Failure to allow only signed remote scripts reduces the attack vector vulnerabilities from unsigned remote scripts.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69975",
+      "title": "The Exchange IMAP4 service must be disabled.",
+      "description": "The IMAP4 protocol is not approved for use within the DoD. It uses a clear-text-based user name and password and does not support the DoD standard for PKI for email access. User name and password could easily be captured from the network, allowing a malicious user to access other system features. Uninstalling or disabling the service will prevent the use of the IMAP4 protocol.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69977",
+      "title": "The Exchange POP3 service must be disabled.",
+      "description": "The POP3 protocol is not approved for use within the DoD. It uses a clear-text-based user name and password and does not support the DoD standard for PKI for email access. User name and password could easily be captured from the network, allowing a malicious user to access other system features. Uninstalling or disabling the service will prevent the use of the POP3 protocol.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69979",
+      "title": "Exchange Mailbox databases must reside on a dedicated partition.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69981",
+      "title": "Exchange Internet-facing Send connectors must specify a Smart Host.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69983",
+      "title": "Exchange internal Receive connectors must require encryption.",
+      "description": "The Simple Mail Transfer Protocol (SMTP) Receive connector is used by Exchange to send and receive messages from server to server using SMTP protocol. This setting controls the encryption strength used for client connections to the SMTP Receive connector. With this feature enabled, only clients capable of supporting secure communications will be able to send mail using this SMTP server. Where secure channels are required, encryption can also be selected. \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 the client to the server adds protection by encrypting the sender and recipient information that cannot be encrypted by the sender.  \n\nIndividually, channel security and encryption have been compromised by attackers. Used together, email becomes a more difficult target, and security is heightened. Failure to enable this feature gives eavesdroppers an opportunity to read or modify messages between the client and server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69985",
+      "title": "Exchange internal Send connectors must use Domain Security (mutual authentication Transport Layer Security).",
+      "description": "The Simple Mail Transfer Protocol (SMTP) connector is used by Exchange to send and receive messages from server to server. There are several controls that work together to provide security between internal servers. This setting controls the authentication method used for communications between servers. With this feature enabled, only servers capable of supporting domain authentication will be able to send and receive mail within the domain.\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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69987",
+      "title": "Exchange internal Send connectors must require encryption.",
+      "description": "The Simple Mail Transfer Protocol (SMTP) connector is used by Exchange to send and receive messages from server to server. There are several controls that work together to provide security between internal servers. This setting controls the encryption method used for communications between servers. With this feature enabled, only servers capable of supporting Transport Layer Security (TLS) will be able to send and receive mail within the domain.\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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69989",
+      "title": "Exchange Public Folder stores must be retained until backups are complete.",
+      "description": "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 documents in the scope of a single backup cycle. This setting ensures at least one backup has been run on the folder store before the message physically disappears. By enabling this setting, all messages written to recipients who have accounts on this store will reside in backups even if they have been deleted by the user before the backup has run.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69991",
+      "title": "The Exchange Public Folder database must not be overwritten by a restore.",
+      "description": "Email system availability depends in part on best practice strategies for setting tuning configurations. Unauthorized or accidental restoration of public folder data risks data loss or corruption.  \n\nThis setting controls whether the public folder store can be overwritten by a restore from backup, which will cause loss of all information added after the backup was created. It should only be enabled during maintenance windows or following an outage (immediately before a restore is to be made), and cleared again immediately afterward.  \n\nDuring production windows, this feature must be disabled.",
+      "severity": "low"
+    },
+    {
+      "id": "V-69993",
+      "title": "Exchange Mailboxes must be retained until backups are complete.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69995",
+      "title": "The Exchange Mailbox database must not be overwritten by a restore.",
+      "description": "Email system availability depends in part on best practice strategies for setting tuning configurations. Unauthorized or accidental restoration of mailbox data risks data loss or corruption.   \n\nThis setting controls whether the mailbox store can be overwritten by a backup, which will cause loss of all information added after the backup was created. It should only be enabled during maintenance windows or following an outage (immediately before a restore is to be made), and cleared again immediately afterward.\n\nDuring production windows, this feature must be disabled.",
+      "severity": "low"
+    },
+    {
+      "id": "V-69997",
+      "title": "Exchange email forwarding must be restricted.",
+      "description": "Auto-forwarded email accounts do not meet the requirement for digital signature and encryption of CUI and PII IAW DoDI 8520.2 (reference ee) and DoD Director for Administration and Management memorandum, \"Safeguarding Against and Responding to the Breach of Personally Identifiable Information\".\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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-69999",
+      "title": "Exchange email-forwarding SMTP domains must be restricted.",
+      "description": "Auto-forwarded email accounts do not meet the requirement for digital signature and encryption of CUI and PII IAW DoDI 8520.2 (reference ee) and DoD Director for Administration and Management memorandum, \"Safeguarding Against and Responding to the Breach of Personally Identifiable Information\".\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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70001",
+      "title": "Exchange Mail quota settings must not restrict receiving mail.",
+      "description": "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.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70003",
+      "title": "Exchange Mail Quota settings must not restrict receiving mail.",
+      "description": "Mail quota settings control the maximum sizes of a user’s mailbox and the system’s response if these limits are exceeded. Mailbox data that is not monitored against a quota increases the risk of mail loss due to filled disk space, which can also render the system unavailable. There are multiple controls, which supply graduated levels of opportunity to respond before risking email service loss. \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.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70005",
+      "title": "The Exchange Mail Store storage quota must issue a warning.",
+      "description": "Mail quota settings control the maximum sizes of a user’s mailbox and the system’s response if these limits are exceeded. Mailbox data that is not monitored against a quota increases the risk of mail loss due to filled disk space, which can also render the system unavailable. There are multiple controls, which supply graduated levels of opportunity to respond before risking data loss. \n\nThis control sends the user a warning message that the mailbox is reaching its limit. The user at this point can still send and receive email.\n \nNote: Best practice is to send this warning when the mailbox reaches 75 percent of capacity.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70007",
+      "title": "Exchange Mailbox Stores must mount at startup.",
+      "description": "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).",
+      "severity": "low"
+    },
+    {
+      "id": "V-70009",
+      "title": "Exchange Message size restrictions must be controlled on Receive connectors.",
+      "description": "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 that of the global value with the rationale documented in the Email Domain Security Plan (EDSP).",
+      "severity": "low"
+    },
+    {
+      "id": "V-70011",
+      "title": "Exchange Receive connectors must control the number of recipients per message.",
+      "description": "Email system availability depends in part on best practice strategies for setting tuning configurations. \n\nThis configuration controls the maximum number of recipients who will receive a copy of a message at one time. This tunable value is related to throughput capacity and can enable the ability to optimize message delivery. \n\nNote: There are two types of default Receive connecters:\nClient Servername: Accepts SMTP connections from all non-MAPI clients, such as POP and IMAP. As POP and IMAP are not authorized for use in DoD, these should not be present. Their default value for MaxRecipientsPerMessage is 200.\nDefault Servername: Accepts connections from other Hub Transport servers and any Edge Transport servers. Their default value for MaxRecipientsPerMessage is 5000.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70013",
+      "title": "Exchange Receive connectors must be clearly named.",
+      "description": "For Receive connectors, unclear naming as to direction and purpose increases risk that messages may not flow as intended, troubleshooting efforts may be impaired, or incorrect assumptions may be made about the completeness of the configuration.  \n\nCollectively, connectors should account for all connections required for the overall email topology design. Simple Mail Transfer Protocol (SMTP) connectors, when listed, must name purpose and direction clearly, and their counterparts on servers to which they connect should be recognizable as their partners.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70015",
+      "title": "The Exchange Receive Connector Maximum Hop Count must be 60.",
+      "description": "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 set too high, an undeliverable message may cycle between servers, raising the risk of network congestion.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70017",
+      "title": "Exchange Send connectors must be clearly named.",
+      "description": "For Send connectors, unclear naming as to direction and purpose increases risk that messages may not flow as intended, troubleshooting efforts may be impaired, or incorrect assumptions may be made about the completeness of the configuration.  \n\nCollectively, connectors should account for all connections required for the overall email topology design. Simple Mail Transfer Protocol (SMTP) connectors, when listed, must name purpose and direction clearly, and their counterparts on servers to which they connect should be recognizable as their partners.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70019",
+      "title": "Exchange Send connectors delivery retries must be controlled.",
+      "description": "This setting controls the rate at which delivery attempts from the home domain are retried and user notifications are issued and notes the expiration time when the message will be discarded.  \n\nIf delivery retry attempts are too frequent, servers will generate network congestion. If too far apart, messages may remain queued longer than necessary, potentially raising disk resource requirements.\n\nThe default values of these fields should be adequate for most environments. Administrators may wish to modify the values as a result, but changes should be documented in the System Security Plan.\n\nNote: Transport configuration settings apply to the organization/global level of the Exchange SMTP path. By checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70021",
+      "title": "Exchange Message size restrictions must be controlled on Send connectors.",
+      "description": "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).",
+      "severity": "low"
+    },
+    {
+      "id": "V-70023",
+      "title": "The Exchange Send connector connections count must be limited.",
+      "description": "The Exchange Send connector setting controls the maximum number of simultaneous outbound connections allowed for a given SMTP connector and can be used to throttle the SMTP service if resource constraints warrant it. If the limit is too low, connections may be dropped. If too high, some domains may use a disproportionate resource share, denying access to other domains. Appropriate tuning reduces risk of data delay or loss.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70025",
+      "title": "The Exchange global inbound message size must be controlled.",
+      "description": "Email system availability depends in part on best practice strategies for setting tuning configurations. Message size limits should be set to 10 megabytes at most, but often are smaller, depending on the organization. The key point in message size is that it should be set globally and should not be set to \"unlimited\". Selecting \"unlimited\" on either field is likely to result in abuse and can contribute to excessive server disk space consumption. \n\nMessage size limits may also be applied on SMTP connectors, Public Folders, and on the user account under AD. Changes at these lower levels are discouraged, as the single global setting is usually sufficient. This practice prevents conflicts that could impact availability and simplifies server administration.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70027",
+      "title": "The Exchange global outbound message size must be controlled.",
+      "description": "Email system availability depends in part on best practice strategies for setting tuning configurations. Message size limits should be set to 10 megabytes at most, but often are smaller, depending on the organization. The key point in message size is that it should be set globally and should not be set to \"unlimited\". Selecting \"unlimited\" on either field is likely to result in abuse and can contribute to excessive server disk space consumption. \n\nMessage size limits may also be applied on send and receive connectors, Public Folders, and on the user account under AD. Changes at these lower levels are discouraged, as the single global setting is usually sufficient. This practice prevents conflicts that could impact availability and it simplifies server administration.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70029",
+      "title": "The Exchange Outbound Connection Limit per Domain Count must be controlled.",
+      "description": "Email system availability depends in part on best practice strategies for setting tuning configurations. This configuration controls the maximum number of simultaneous outbound connections from a domain and works in conjunction with the Maximum Outbound Connections Count setting as a delivery tuning mechanism. If the limit is too low, connections may be dropped. If too high, some domains may use a disproportionate resource share, denying access to other domains. Appropriate tuning reduces risk of data delay or loss. \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.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70031",
+      "title": "The Exchange Outbound Connection Timeout must be 10 minutes or less.",
+      "description": "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\nConnections, once established, may incur delays in message transfer. The default of 10 minutes is a reasonable window in which to resume activities without maintaining idle connections for excessive intervals. If the timeout period is too long, idle connections may be maintained for unnecessarily long time periods, preventing new connections from being established. Sluggish connectivity increases the risk of lost data. A value of 10 or less is optimal.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70033",
+      "title": "Exchange Internal Receive connectors must not allow anonymous connections.",
+      "description": "This control is used to limit the servers that may use this server as a relay. If a Simple Mail Transport Protocol (SMTP) sender does not have a direct connection to the Internet (for example, an application that produces reports to be emailed) then it will need to use an SMTP Receive connector that does have a path to the Internet (for example, a local email server) as a relay.\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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70035",
+      "title": "Exchange external/Internet-bound automated response messages must be disabled.",
+      "description": "Spam originators, in an effort to refine mailing lists, sometimes monitor transmissions for automated bounce-back messages. Automated messages include such items as \"Out of Office\" responses, nondelivery messages, or automated message forwarding.\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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70037",
+      "title": "Exchange must have antispam filtering installed.",
+      "description": "Originators of spam messages are constantly changing their techniques in order to defeat spam countermeasures; therefore, spam software must be constantly updated to address the changing threat. A manual update procedure is labor intensive and does not scale well in an enterprise environment. This risk may be mitigated by using an automatic update capability. Spam protection mechanisms include, for example, signature definitions, rule sets, and algorithms.\n\nExchange 2013 provides both antispam and antimalware protection out of the box. The Exchange 2013 antispam and antimalware product capabilities are limited but still provide some protection.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70039",
+      "title": "Exchange must have antispam filtering enabled.",
+      "description": "Originators of spam messages are constantly changing their techniques in order to defeat spam countermeasures; therefore, spam software must be constantly updated to address the changing threat. A manual update procedure is labor intensive and does not scale well in an enterprise environment. This risk may be mitigated by using an automatic update capability. Spam protection mechanisms include, for example, signature definitions, rule sets, and algorithms.\n\nExchange 2013 provides both antispam and antimalware protection out of the box. The Exchange 2013 antispam and antimalware product capabilities are limited but still provide some protection.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70041",
+      "title": "Exchange must have antispam filtering configured.",
+      "description": "Originators of spam messages are constantly changing their techniques in order to defeat spam countermeasures; therefore, spam software must be constantly updated to address the changing threat. A manual update procedure is labor intensive and does not scale well in an enterprise environment. This risk may be mitigated by using an automatic update capability. Spam protection mechanisms include, for example, signature definitions, rule sets, and algorithms.\n\nExchange 2013 provides both antispam and antimalware protection out of the box. The Exchange 2013 antispam and antimalware product capabilities are limited but still provide some protection.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70043",
+      "title": "Exchange must not send automated replies to remote domains.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70045",
+      "title": "Exchange servers must have an approved DoD email-aware virus protection software installed.",
+      "description": "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 2013 compliant. Competent email scanners will have the ability to scan mail stores, attachments (including zip or other archive files) and mail queues and to issue warnings or alerts if malware is detected. As with other AV products, a necessary feature to include is the ability for automatic updates.",
+      "severity": "high"
+    },
+    {
+      "id": "V-70047",
+      "title": "The Exchange Global Recipient Count Limit must be set.",
+      "description": "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.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70049",
+      "title": "The Exchange Receive connector timeout must be limited.",
+      "description": "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.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70051",
+      "title": "The Exchange Public Store storage quota must be limited.",
+      "description": "This setting controls the maximum sizes of a public folder and the system’s response if these limits are exceeded. There are two available controls and the system response when the quota has been exceeded. \n\nThe first control sends an email warning to Folder Owners roles, alerting them that the folder has exceeded its quota. The second level prevents posting any additional items to the folder.  \n\nAs a practical matter, Level 1 serves the purpose of prompting owners to manage their folders. Level 2 impedes users in their ability to work and is not required where folder use interruption is not acceptable. Public Folder Storage Quota Limitations are not a substitute for overall disk space monitoring.",
+      "severity": "low"
+    },
+    {
+      "id": "V-70053",
+      "title": "A DoD-approved third party Exchange-aware malicious code protection application must be implemented.",
+      "description": "Malicious code protection mechanisms include, but are not limited, to, anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. \n\nMalicious code includes viruses, worms, Trojan horses, and Spyware. It is not enough to simply have the software installed; this software must periodically scan the system to search for malware on an organization-defined frequency. \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 anti-virus and intrusion prevention software.\n\nSite must utilize an approved DoD scanner. Exchange Malware software has a limited scanning capability and does not scan files that are downloaded, opened, or executed.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70055",
+      "title": "The applications built-in Malware Agent must be disabled.",
+      "description": "Malicious code protection mechanisms include, but are not limited, to, anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. \n\nMalicious code includes viruses, worms, Trojan horses, and Spyware. It is not enough to simply have the software installed; this software must periodically scan the system to search for malware on an organization-defined frequency. \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 anti-virus and intrusion prevention software.\n\nSite must utilize an approved DoD scanner. Exchange Malware software has a limited scanning capability and does not scan files that are downloaded, opened, or executed.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70057",
+      "title": "Exchange Public Folder Stores must mount at startup.",
+      "description": "Administrator responsibilities include the ability to react to unplanned maintenance tasks or emergency situations that may require Public Folder Store data manipulation. Occasionally, there may be a need to start the server with \"unmounted\" data stores if manual maintenance is being performed on them. Failure to uncheck the \"do not mount on startup\" condition will result in unavailability of Public Folder services.\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 task completion so public folder stores are available to users (unmounted public folder stores are not available to users).",
+      "severity": "low"
+    },
+    {
+      "id": "V-70059",
+      "title": "Exchange must have the most current, approved service pack installed.",
+      "description": "Failure to install the most current Exchange service pack leaves a system vulnerable to exploitation. Current service packs correct known security and system vulnerabilities.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70061",
+      "title": "Exchange must provide Mailbox databases in a highly available and redundant configuration.",
+      "description": "To protect Exchange Server mailbox databases and the data they contain 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 2013. A DAG is a group of Mailbox servers that hosts a set of databases and provides automatic database-level recovery from failures that affect individual servers or databases.\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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70063",
+      "title": "Exchange Internal Send connectors must use an authentication level.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70065",
+      "title": "The Exchange SMTP automated banner response must not reveal server details.",
+      "description": "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, Version: 6.0.3790.211 ready at Wed, 2 Feb 2005 23:40:00 -0500\n\nChanging the response to hide local configuration details reduces the attack profile of the target.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70067",
+      "title": "The Exchange application directory must be protected from unauthorized access.",
+      "description": "Default product installations may provide more generous access permissions than are necessary to run the application. By examining and tailoring access permissions to more closely provide the least amount of privilege possible, attack vectors that align with user permissions are less likely to access more highly secured areas.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70069",
+      "title": "An Exchange software baseline copy must exist.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70071",
+      "title": "Exchange software must be monitored for unauthorized changes.",
+      "description": "Monitoring software files for changes against a baseline on a regular basis may help detect the possible introduction of malicious code on a system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70073",
+      "title": "Exchange services must be documented and unnecessary services must be removed or disabled.",
+      "description": "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 POP3 and IMAP4 clients are not included in the standard desktop offering, they must be disabled.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70075",
+      "title": "Exchange Outlook Anywhere (OA) clients must use NTLM authentication to access email.",
+      "description": "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 OA that requires a direct SSL connection from Outlook to the CA server. There is also a constraint where Microsoft supports that the CA server must participate in the AD domain inside the enclave. For this reason, Outlook Anywhere must be deployed only for enclave-sourced Outlook users.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70077",
+      "title": "The Exchange Email application must not share a partition with another application.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70079",
+      "title": "Exchange must not send delivery reports to remote domains.",
+      "description": "Attackers can use automated messages to determine whether a user account is active, in the office, traveling, and so on. An attacker might use this information to conduct future attacks. Ensure that delivery reports to remote domains are disabled. Before enabling this setting, first configure a remote domain using the EMC or the New-RemoteDomain cmdlet.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-70081",
+      "title": "Exchange must not send nondelivery reports to remote domains.",
+      "description": "Attackers can use automated messages to determine whether a user account is active, in the office, traveling, and so on. An attacker might use this information to conduct future attacks. Ensure that nondelivery reports to remote domains are disabled. Before enabling this setting, first configure a remote domain using the EMC or the New-RemoteDomain cmdlet.",
+      "severity": "medium"
+    }
+  ]
+}