kriterion 0.0.1

data/standards/stig_microsoft_exchange_2010_client_access_server_role.json

@@ -0,0 +1,71 @@
+{
+  "name": "stig_microsoft_exchange_2010_client_access_server_role",
+  "date": "2012-05-31",
+  "description": "The Microsoft Exchange Server 2010 STIGs cover four of the five roles available with Microsoft Exchange Server 2010, plus core Exchange Server 2010 global requirements. The Email Services Policy STIG must also be reviewed for each site hosting email services. The core Exchange Server guidance must be reviewed on each server role prior to the role-specific guidance. Also, for the Client Access server, the IIS guidance must be reviewed prior to the OWA checks.",
+  "title": "Microsoft Exchange 2010 Client Access Server Role",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "EXCH-CA-100",
+      "title": "Encryption must be used for RPC client access.",
+      "description": "Failure to require secure connections to the client access server increases the potential for unintended decryption and data loss.  This setting controls whether client machines are forced to use secure channels to communicate with the server.  If this feature is enabled, clients will only be able to communicate with the server over secure communication channels.",
+      "severity": "medium"
+    },
+    {
+      "id": "EXCH-CA-101",
+      "title": "Encryption must be used for OWA access.",
+      "description": "Failure to require secure connections on a web site increases the potential for unintended decryption and data loss.  This setting controls whether client machines should be forced to use secure channels to communicate with this virtual directory.  If this feature is enabled, clients will only be able to communicate with the directory if they are capable of supporting secure communication with the server.\n\nIf Outlook Web App is approved for use, secure channels and FIPS level encryption are required, as well as appropriate certificate setting. The use of secure communication prevents eavesdroppers from reading or modifying communications between servers and clients.   The network and DMZ STIG identify criteria for OWA and Public Folder configuration in the network, including CAC enabled pre-authentication through an application firewall proxy, such as Microsoft ISA.\n\nNote: If OWA is not approved for use, this control is not applicable and the OWA virtual directory should be removed to eliminate the possibility of attack through this vector.",
+      "severity": "medium"
+    },
+    {
+      "id": "EXCH-CA-102",
+      "title": "The Microsoft Active Sync directory must be removed.",
+      "description": "To reduce the vectors through which a server can be attacked, unneeded application components should be disabled or removed.  By default, a virtual directory is installed for Active Sync, and the Exchange application default has Active Sync disabled.  If an attacker were to intrude into an Exchange Front-End server and reactivate Active Sync, this attack vector could once again be open, provided the virtual directory is present.  Once removed, the Active Sync functionality cannot be used without restoring the virtual directory, not a trivial process.  \n",
+      "severity": "medium"
+    },
+    {
+      "id": "EXCH-CA-103",
+      "title": "The Public Folder virtual directory must be removed if not in use by the site.",
+      "description": "To reduce the vectors through which a server can be attacked, unneeded application components should be disabled or removed.  By default, a virtual directory is installed for Public Folders.  If an attacker were to intrude into an Exchange Front-End server and be able to access the public folder web site, it would provide an additional attack vector, provided the virtual directory was present.  Once removed, the Public functionality cannot be used without restoring the virtual directory.  \n",
+      "severity": "low"
+    },
+    {
+      "id": "EXCH-CA-104",
+      "title": "Web email must use standard ports and protocols.",
+      "description": "PPSM standard defined ports and protocols must be used for all Exchange services.  The standard port for HTTP connections is 80 and the standard port for HTTPS\nconnections is 443.  \n\nChanging the ports to non-standard values provides only temporary and limited protection against automated attacks since these attacks will not likely connect to the custom port.  However, a determined attacker may still be able to determine which ports are used for the HTTP and HTTPS protocols by performing a comprehensive port scan.  \n\nNegative impacts to using nonstandard ports include complexity for the system administrator, custom configurations for connecting clients, risk of port conflict with non-exchange applications, and risk of incompatibility with standard port monitoring applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "EXCH-CA-105",
+      "title": "Forms-based Authentication must not be used.",
+      "description": "Identification and Authentication provide the foundation for access control.  Access to email services applications in the DoD require authentication using DoD Public Key Infrastructure (PKI) certificates.  The Exchange Receive Connector, which operates Outlook Web App (OWA), is used to enable web access to user email mailboxes.  This setting controls whether forms-based login should be used by the OWA web site. \n\nForms-based login enables a user to enter an Account and Password for the web session.   The form stores the username and password information in browser cookies, and enables the user's mailbox server to be located without user participation.  The cookies persist throughout the OWA session after which they are destroyed. \n\nBecause the DoD requires Common Access Card (CAC)-based authentication to applications, OWA access must be brokered through an application proxy (for example, Internet Security and Acceleration [ISA]), which performs CAC authentication using a proxy-hosted OWA form.  The authenticated request is then forwarded directly to OWA, where authentication is repeated without requiring the user to repeat authentication steps.  For this scenario to work, the Application Proxy server must have forms-based authentication enabled, and Exchange must have forms-based Authentication disabled.  \n\nIf forms-based Authentication is enabled on the Exchange Front End server, it is evidence that the application proxy server is either not correctly configured, or it may be missing.",
+      "severity": "high"
+    },
+    {
+      "id": "EXCH-CA-106",
+      "title": "The Microsoft Exchange forms-based authentication service must be disabled.",
+      "description": "Identification and Authentication provide the foundation for access control.  Access to email services applications in the DoD require authentication using DoD Public Key Infrastructure (PKI) certificates.  There are two sections to using form-based authentication the service must be running and the option to use forms-based authentication must be enabled. Forms-based login enables a user to enter a username and password to logon to the system.  By disabling the forms-based authentication service malicious users will not have the ability to enter users name and password to access a system.",
+      "severity": "medium"
+    },
+    {
+      "id": "EXCH-CA-107",
+      "title": "HTTP authenticated access must be set to Integrated Windows Authentication only.",
+      "description": "This feature controls the authentication method used to connect to the OWA virtual directories. \nEnsure this is set to Integrated Windows Authentication only.\nAnonymous access provides for no access control. Basic Authentication transmits the password in the clear and risks exposure, and the other methods are not recommended by Microsoft for this control. Failure to configure this as per the recommendation may result in unrestricted access to OWA virtual directory, passwords being sent in the clear, and/or the inability to correctly authenticate, depending on which change is made.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "EXCH-CA-108",
+      "title": "The Microsoft 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 malicious user to access other system features. Uninstalling or disabling the service will prevent the use of the IMAP4 protocol.",
+      "severity": "medium"
+    },
+    {
+      "id": "EXCH-CA-109",
+      "title": "The Microsoft 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 malicious user to access other system features. Uninstalling or disabling the service will prevent the use of the POP3 protocol.",
+      "severity": "medium"
+    }
+  ]
+}

data/standards/stig_microsoft_exchange_2010_core_server.json

@@ -0,0 +1,47 @@
+{
+  "name": "stig_microsoft_exchange_2010_core_server",
+  "date": "2012-05-31",
+  "description": "The Microsoft Exchange Server 2010 STIGs cover four of the five roles available with Microsoft Exchange Server 2010, plus core Exchange Server 2010 global requirements. The Email Services Policy STIG must also be reviewed for each site hosting email services. The core Exchange Server guidance must be reviewed on each server role prior to the role-specific guidance. Also, for the Client Access server, the IIS guidance must be reviewed prior to the OWA checks.",
+  "title": "Microsoft Exchange 2010 Core Server",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "Exch-110",
+      "title": "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. \n\nNote: The default installation directory is \\Program Files\\Microsoft\\Exchange Server\\V14.",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-111",
+      "title": "Exchange software must be monitored for change.",
+      "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.  Comparing system files against a baseline on a regular basis will detect the possibility of introduction of malicious code on the system.\n\nNote: A properly configured HBSS Policy Auditor 5.2 or later, File Integrity Monitor (FIM) module will meet the requirement for file integrity checking. The Asset module within HBSS does not meet this requirement.",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-112",
+      "title": "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, Back-end servers created to host mailboxes are dedicated to that task, and operate only the services needed for mailbox hosting.  (Back-end servers must also operate some Web services, but only to the degree that Exchange requires the IIS engine in order to function).   \n\nTo restrict attack vectors available with email message access, the protocols on the email servers should match offerings on the DoD standard desktop deployment.  These include Microsoft Outlook using MAPI, S/MIME enabled clients, and secured connections.  It also includes Outlook via VPN for offsite telework.  Browsers may access OWA provided it uses PKI/CAC access brokered through a reverse proxy Application Server.  \n\nBecause NNTP, POP3, and IMAP4 clients are not included in the standard desktop offering, they must be disabled.",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-113",
+      "title": "Global inbound message size must be set.",
+      "description": "Email system availability depends in part on best practices 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'.  \n\nNot setting a limit is likely to result in abuse and can lead to rapid filling of server disk space.\n\nNote: Transport configuration settings apply to the organization/global level of Exchange by checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-114",
+      "title": "Global outbound message size must be set.",
+      "description": "Email system availability depends in part on best practices 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'.  \n\nNot setting a limit is likely to result in abuse and can lead to rapid filling of server disk space.\n\nNote: Transport configuration settings apply to the organization/global level of Exchange by checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-115",
+      "title": "Global recipient count limit must be set.",
+      "description": "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.  Selecting the \"no limit\" radio button for this item is likely to result in abuse.\n\nNote: Transport configuration settings apply to the organization/global level of Exchange by checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.\n",
+      "severity": "low"
+    }
+  ]
+}

data/standards/stig_microsoft_exchange_2010_edge_transport_server_role.json

@@ -0,0 +1,233 @@
+{
+  "name": "stig_microsoft_exchange_2010_edge_transport_server_role",
+  "date": "2012-05-31",
+  "description": "The Microsoft Exchange Server 2010 STIGs cover four of the five roles available with Microsoft Exchange Server 2010, plus core Exchange Server 2010 global requirements. The Email Services Policy STIG must also be reviewed for each site hosting email services. The core Exchange Server guidance must be reviewed on each server role prior to the role-specific guidance. Also, for the Client Access server, the IIS guidance must be reviewed prior to the OWA checks.",
+  "title": "Microsoft Exchange 2010 Edge Transport Server Role",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "Exch-ED-200",
+      "title": "SMTP automated banner response must be set.",
+      "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, 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 (OS) 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.   \nFor 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": "Exch-ED-201",
+      "title": "Receive Connector message size must be controlled.",
+      "description": "This setting can be used to limit the total size of messages at the connector level. This includes the message header, the message body, and any attachments. For internal message flow, Exchange Server uses the custom X-MS-Exchange-Organization-OriginalSize: message header to record the original message size of the message as it enters the Exchange Server organization. Whenever the message is checked against the specified message size limits, the lower value of the current message size or the original message size header is used. The size of the message can change because of content conversion, encoding, and agent processing. This setting somewhat limits the impact a malicious user or a computer with malware can have on the Exchange infrastructure by restricting the size of incoming messages.",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-ED-202",
+      "title": "Receive Connector connections count  must  be controlled.",
+      "description": "Email system availability depends in part on best practices strategies for setting tuning. This configuration controls the maximum number of simultaneous inbound connections allowed to the server.   By default, the number of simultaneous inbound connections is unlimited.  If a limit is set and is too low, the connections pool may get filled.  If attackers perceive there is a limit, they could deny service to the Simple Mail Transfer Protocol (SMTP) server using a limited connection count.\n",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-ED-203",
+      "title": "Receive Connector timeout must be limited.",
+      "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 idle connections may be maintained for unnecessarily long time periods, preventing new connections from being established.  \n",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-ED-204",
+      "title": "Receive Connector must restrict relay access.",
+      "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.   A fourth configuration, \"allow all except the list below\", should never be used.   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": "Exch-ED-205",
+      "title": "Internal Receive Connectors must be encrypted.",
+      "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": "Exch-ED-206",
+      "title": "Internal Receive Connectors must use Domain Security (Mutual Authentication TLS).",
+      "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 the 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": "Exch-ED-207",
+      "title": "Internet Receive Connectors must offer TLS before using basic authentication.",
+      "description": "Sending unencrypted email over the Internet increases the risk that messages can be intercepted or altered. Transport Layer Security (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": "Exch-ED-208",
+      "title": "Receive Connectors must control the message count per inbound session.",
+      "description": "Email system availability depends in part on best practices strategies for setting tuning configurations.  This setting controls the maximum number of messages allowed in a single SMTP session by breaking large numbers of messages into multiple sessions.  Failure to control message counts as they arrive adds risk that a sending domain could monopolize email resources by not controlling message counts per session as inbound messages arrive. Microsoft best practice recommends setting this to a value of 300.",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-ED-209",
+      "title": "Receive Connectors must control the number of recipients 'chunked' on a single message.",
+      "description": "Email system availability depends in part on best practices strategies for setting tuning configurations. This setting is used when two Exchange servers send or receive email. The chunking setting enables large message bodies to be relayed by the remote server to the Receive Connector in multiple, smaller chunks.",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-ED-210",
+      "title": "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 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.\n",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-ED-211",
+      "title": "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 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.\n",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-ED-212",
+      "title": "Send Connectors delivery retries must be controlled.",
+      "description": "This setting controls the rate at which delivery attempts from the home domain are retried, user notification is issued, and expiration timeout when the message will be discarded.  \n\nIf delivery retry attempts are too frequent, servers will generate network congestion. If too far apart, then 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 Exchange by checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-ED-213",
+      "title": "Send Connector message size must be controlled.",
+      "description": "This setting can be used to limit the total size of messages at the connector level. This includes the message header, the message body, and any attachments. For internal message flow, Exchange Server uses the custom X-MS-Exchange-Organization-OriginalSize: message header to record the original message size of the message as it enters the Exchange Server organization. Whenever the message is checked against the specified message size limits, the lower value of the current message size or the original message size header is used. The size of the message can change because of content conversion, encoding, and agent processing. This setting somewhat limits the impact a malicious user or a computer with malware can have on the Exchange infrastructure by restricting the size of incoming messages.",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-ED-214",
+      "title": "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 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\nNote: Transport configuration settings apply to the organization/global level of Exchange by checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.  \n",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-ED-215",
+      "title": "Send connections per domain must be set.",
+      "description": "This configuration controls the maximum number of simultaneous outbound connections to 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 100 simultaneous outbound connections from a domain should be sufficient.  The value may be adjusted if justified by local site conditions..\n\nNote: Transport configuration settings apply to the organization/global level of Exchange by checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.\n",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-ED-216",
+      "title": "Internal Send Connectors must use Domain Security (Mutual Authentication TLS).",
+      "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 the 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": "Exch-ED-217",
+      "title": "Internal Send Connectors must be encrypted.",
+      "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 the 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": "Exch-ED-219",
+      "title": "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 Exchange by checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-ED-220",
+      "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": "Exch-ED-221",
+      "title": "Exchange must not send non-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 non-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": "Exch-ED-222",
+      "title": "External/Internet bound automated response messages must be disabled.",
+      "description": "SPAM originators, in an effort to refine mailing lists, sometimes use a technique where they monitor transmissions for automated bounce back messages such as \"Out of Office\" messages.  Automated messages include such items as Out of Office responses, non-delivery 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.  \n   \nThe \"Default\" format applies to all domains.  However, if a new format is created and applied to a specific domain, that domain will use the new format's configuration while all other domains (those without specially designated formats) will use the Default format.   Automated messages must be disabled to prevent inadvertent information disclosure about email recipients.",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-ED-223",
+      "title": "Auto-forwarding email must be disabled.\n",
+      "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. Before enabling this setting first configure a remote domain.",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-ED-224",
+      "title": "Exchange must not send auto 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": "Exch-ED-225",
+      "title": "Attachment filtering must remove undesirable attachments by file type.",
+      "description": "By performing filtering at the perimeter, up to 90% of SPAM, malware, and other undesirable messages are eliminated from the message stream rather than admitting them into the Mail server environment. Attachments 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  \n",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-ED-227",
+      "title": "Non-existent 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.  \nThose not rejected, of course, are deemed to exist, and are therefore used in future SPAM mailings. \n\nTo prevent this disclosure of existing email accounts to Spammers, this feature should not be employed.  Instead, it is recommended that all messages be received, then evaluated and disposed of without enabling the sender to determine recipients that are  existing vs. non-existing.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-ED-228",
+      "title": "Tarpitting interval must be set.\n",
+      "description": "Tarpitting is the practice of artificially delaying server responses for specific 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 such email traffic so that the cost of sending spam increases for the person or organization sending the spam. Tarpitting makes directory harvest attacks too costly to automate efficiently.\n\nRecipient Lookup functionality enables the sending server to determine whether an email address is valid or invalid. As mentioned earlier, when the recipient of an inbound message is a known recipient, the Edge Transport server sends back a \"OK\" SMTP response to the sending server. This functionality provides an ideal environment for a directory harvest attack.\n\nA directory harvest attack is an attempt to collect valid email addresses from a particular organization so that the email addresses can be added to a spam database. Because all spam income relies on trying to make people open email messages, addresses known to be active are a commodity that malicious users, or spammers, pay for. Because the SMTP protocol provides feedback for known senders and unknown senders, a spammer can write an automated program that uses common names or dictionary terms to construct email addresses to a specific domain. The program collects all email addresses that return a \"Recipient OK\" SMTP response and discards all email addresses that return a \"User unknown\" SMTP session error. The spammer can then sell the valid email addresses or use them as recipients for unsolicited messages.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-ED-229",
+      "title": "Filtered messages must be archived.",
+      "description": "As messages are filtered by the Email sanitization process, an archive must be specified and managed by the Email administrators.  The archive may 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. The archive repository may also serve as a base for analysis of filtered content, to report and trend the types of undesirable Email content being captured.  Failure to specify and manage a filtered message archive adds to the risk of email environment pollution.  By not archiving filtered messages it is less likely administrators would be able to analyze and refine the filtering process.  The act of identifying a mailbox causes this feature to be enabled.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-ED-230",
+      "title": "Messages with a blank sender field must be filtered.",
+      "description": "By performing filtering at the perimeter, up to 90% 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 resource and risk infection while evaluating them, it is recommended that these messages be filtered immediately upon receipt and not forwarded to end users.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-ED-231",
+      "title": "Blank sender field action type must be set.",
+      "description": "By performing filtering at the perimeter, up to 90% 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 resource and risk infection while evaluating them, it is recommended that these messages be filtered immediately upon receipt and not forwarded to end users.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-ED-232",
+      "title": "Accepted domains must be verified.",
+      "description": "Exchange may be configured to except email for multiple domain names. This setting controls which domains the server will accept mail. This check verifies the email server is not excepting email for unauthorized domains.",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-ED-233",
+      "title": "Sender reputation must be enabled.",
+      "description": "By performing filtering at the perimeter, up to 90% 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 anti-spam 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": "Exch-ED-234",
+      "title": "Sender reputation must be configured.",
+      "description": "By performing filtering at the perimeter, up to 90% 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 anti-spam 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": "Exch-ED-236",
+      "title": "SPAM evaluation filter must be enabled.",
+      "description": "By performing filtering at the perimeter, up to 90% 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.\nSPAM evaluation (heuristic) 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": "Exch-ED-237",
+      "title": "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, which has been estimated as comprising up to 90% 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' Services vendor provides a value for this field usually the DNS suffix for their domain.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-ED-238",
+      "title": "Session request from unauthorized senders must be rejected.",
+      "description": "Sender Identification (SID) is an email anti-spam sanitization process.  Sender ID uses DNS MX record lookups to verify the 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.      \n\nBy rejecting session initiations from senders who cannot be validated via Sender ID, potential SPAM is eliminated because it is evaluated prior to being admitted to the domain.   \n",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-ED-239",
+      "title": "Sender Identification process must be enabled.",
+      "description": "Sender Identification (SID) is an email anti-spam sanitization process.  Sender ID uses DNS MX record lookups to verify the 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.",
+      "severity": "medium"
+    }
+  ]
+}

data/standards/stig_microsoft_exchange_2010_hub_transport_server_role.json

@@ -0,0 +1,125 @@
+{
+  "name": "stig_microsoft_exchange_2010_hub_transport_server_role",
+  "date": "2012-05-31",
+  "description": "The Microsoft Exchange Server 2010 STIGs cover four of the five roles available with Microsoft Exchange Server 2010, plus core Exchange Server 2010 global requirements. The Email Services Policy STIG must also be reviewed for each site hosting email services. The core Exchange Server guidance must be reviewed on each server role prior to the role-specific guidance. Also, for the Client Access server, the IIS guidance must be reviewed prior to the OWA checks.",
+  "title": "Microsoft Exchange 2010 Hub Transport Server Role",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "EXCH-HB-322",
+      "title": "Send Connectors must use a Smart Hosts.",
+      "description": "In the case of identifying a 'Smart Host' for the email environment, the connector level is the preferred location for this configuration because flow control in this routing group will be retained even if future changes occur at the Receive Connector level.   \n\nA 'Smart Host' (Edge Transport Server) Role acts as an Internet Facing Concentrator for other email servers.  Appropriate hardening can be applied to the Edge Transport Server (Email Secure Gateway) role rather than at multiple locations throughout the enterprise.   The 'Smart Host' performs all Domain Name Service (DNS) lookups to determine mail routing and offers some proxy-type benefits.  \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.  They must, however, be configured to identify the server that is performing the \"Smart Host\" function.",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-HB-201",
+      "title": "Receive Connector message size must be controlled.",
+      "description": "This setting can be used to limit the total size of messages at the connector level. This includes the message header, the message body, and any attachments. For internal message flow, Exchange Server uses the custom X-MS-Exchange-Organization-OriginalSize: message header to record the original message size of the message as it enters the Exchange Server organization. Whenever the message is checked against the specified message size limits, the lower value of the current message size or the original message size header is used. The size of the message can change because of content conversion, encoding, and agent processing. This setting somewhat limits the impact a malicious user or a computer with malware can have on the Exchange infrastructure by restricting the size of incoming messages.",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-HB-202",
+      "title": "Receive Connector connections count  must  be controlled.",
+      "description": "Email system availability depends in part on best practices strategies for setting tuning. This configuration controls the maximum number of simultaneous inbound connections allowed to the server.   By default, the number of simultaneous inbound connections is unlimited.  If a limit is set and is too low, the connections pool may get filled.  If attackers perceive there is a limit, they could deny service to the Simple Mail Transfer Protocol (SMTP) server using a limited connection count.\n",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-HB-203",
+      "title": "Receive Connector timeout must be limited.",
+      "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 idle connections may be maintained for unnecessarily long time periods, preventing new connections from being established.  \n",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-HB-204",
+      "title": "Receive Connector must restrict relay access.",
+      "description": "This control is used to limit the servers that may use this server as a relay.  If an 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 that 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.  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": "Exch-HB-205",
+      "title": "Receive Connector connection must be encrypted.",
+      "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 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 the client and server.",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-HB-206",
+      "title": "Receive Connectors must use Domain Security (Mutual Authentication TLS).",
+      "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 the 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": "Exch-HB-208",
+      "title": "Receive Connectors must control the message count per inbound session.",
+      "description": "Email system availability depends in part on best practices strategies for setting tuning configurations.  This setting controls the maximum number of messages allowed in a single SMTP session by breaking large numbers of messages into multiple sessions.  Failure to control message counts as they arrive adds risk that a sending domain could monopolize email resources by not controlling message counts per session as inbound messages arrive. Microsoft best practice recommends setting this to a value of 300.",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-HB-209",
+      "title": "Receive Connectors must control the number of recipients 'chunked' on a single message.",
+      "description": "Email system availability depends in part on best practices strategies for setting tuning configurations. This setting is used when two Exchange servers send or receive email. The chunking setting enables large message bodies to be relayed by the remote server to the Receive Connector in multiple, smaller chunks.",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-HB-210",
+      "title": "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 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.\n",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-HB-211",
+      "title": "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 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.\n",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-HB-212",
+      "title": "Send Connector delivery retries must be controlled.",
+      "description": "This setting controls the rate at which delivery attempts from the home domain are retried, user notification is issued, and expiration timeout when the message will be discarded.  \n\nIf delivery retry attempts are too frequent, servers will generate network congestion. If too far apart, then 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 Exchange by checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-HB-213",
+      "title": "Send Connector message size must be controlled.",
+      "description": "This setting can be used to limit the total size of messages at the connector level. This includes the message header, the message body, and any attachments. For internal message flow, Exchange Server uses the custom X-MS-Exchange-Organization-OriginalSize: message header to record the original message size of the message as it enters the Exchange Server organization. Whenever the message is checked against the specified message size limits, the lower value of the current message size or the original message size header is used. The size of the message can change because of content conversion, encoding, and agent processing. This setting somewhat limits the impact a malicious user or a computer with malware can have on the Exchange infrastructure by restricting the size of incoming messages.",
+      "severity": "medium"
+    },
+    {
+      "id": "Exch-HB-214",
+      "title": "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 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\nNote: Transport configuration settings apply to the organization/global level of Exchange by checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-HB-215",
+      "title": "Send connections per domain must be set.",
+      "description": "This configuration controls the maximum number of simultaneous outbound connections to 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 100 simultaneous outbound connections from a domain should be sufficient.  The value may be adjusted downward if justified by local site conditions.\n\nNote: Transport configuration settings apply to the organization/global level of Exchange by checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.",
+      "severity": "low"
+    },
+    {
+      "id": "Exch-HB-216",
+      "title": "Send Connectors must use Domain Security (Mutual Authentication TLS).",
+      "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 the 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": "Exch-HB-217",
+      "title": "Send Connectors must be encrypted.",
+      "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 the 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": "Exch-HB-218",
+      "title": "Email application directory permissions must be restricted.",
+      "description": "Default product installations may provide more generous permissions than are necessary to run the application.  By examining and tailoring 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": "Exch-HB-219",
+      "title": "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 Exchange by checking and setting them at the Hub server the setting will apply to both Hub and Edge roles.",
+      "severity": "medium"
+    }
+  ]
+}