kriterion 0.0.1

data/standards/stig_email_services_policy.json

@@ -0,0 +1,137 @@
+{
+  "name": "stig_email_services_policy",
+  "date": "2015-08-07",
+  "description": "Email Services Policy STIG requirements must be evaluated on each system review, regardless of the email product or release level.  These policies ensure conformance to DoD requirements that govern email services deployment and operations. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil. ",
+  "title": "Email Services Policy STIG",
+  "version": "2",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-18857",
+      "title": "Annual procedural reviews must be conducted at the site.",
+      "description": "A regular review of current email security policies and procedures is necessary to maintain the desired security posture of Email services. Policies and procedures should be measured against current Department of Defense (DoD) policy, Security Technical Implementation Guide (STIG) guidance, vendor-specific guidance and recommendations, and site-specific or other security policy.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18864",
+      "title": "Email Configuration Management (CM) procedures must be implemented. ",
+      "description": "Uncontrolled, untested, or unmanaged changes can result in an unreliable security posture. All software libraries related to email services must be reviewed, considered, and the responsibility for CM assigned to ensure no libraries or configurations are left unaddressed. This is true even if CM responsibilities appear to cross organizational boundaries. \n\nEnsure patches, configurations, and upgrades are addressed. Process steps should have specific procedures and responsibilities assigned to individuals.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18865",
+      "title": "Email Administrator role must be assigned and authorized by the ISSO. ",
+      "description": "Separation of roles supports operational security for application as well as human resources. Roles accompanied by elevated privileges, such as that of the Email Administrator, must be carefully regulated and monitored.\n\nAll appointments to Information Assurance (IA) roles, such as Authorizing Officer (AO), System Security Manager (ISSM), and Information Systems Security Officer (ISSO) must be in writing, and include assigned duties and appointment criteria such as training, clearance and IT designation. The Email Administrator role is assigned and controlled by the ISSM. The ISSM role owns the responsibility to document responsibilities, privileges, training and scope for the Email Administrator role. It is with this definition that the ISSO is able to monitor assigned resources, ensuring that intended tasks are completed, and that elevated privileges are not used for purposes beyond their intended tasks.\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-18867",
+      "title": "Email Services must be documented in the EDSP (Email Domain Security Plan). ",
+      "description": "A System Security Plan defines the security procedures and policies applicable to the Automated Information System (AIS). The Email Domain Security Plan (EDSP) defines the security settings and other protections for email systems. It may be implemented as a stand-alone document, or as a section within an umbrella System Security document, provided it contains the unique values engineered for that domain. Without a System Security Plan, unqualified personnel may be assigned responsibilities that they are incapable of meeting and email security may become prone to an inconsistent or incomplete implementation. Because email systems are sufficiently unique, an EDSP is recommended. \n\nFor some email data categories, the product specific STIG provides required security settings. For other categories, values can vary among domains, depending on the implementation and system sizing requirements. For example, tuning variables such as log sizes, mailbox quota limits, and partner domain security are engineered for optimal security and performance, and should therefore be documented so reviews can assess whether they are set as intended. Assigned administrator names by role enable assessment of roles separation and least privilege permissions, as well as the ability to identify unauthorized access of processes or data. Back-up and recovery artifacts, SPAM reputation providers, and anti-virus vendors may differ by domain, and will require operational support information to be recorded, for example, license agreements, product copy locations, and storage requirements. \n\nNIST publication SP800-18, which is publicly available, is entitled “Guide for Developing Security Plans for Federal Information Systems”. It gives both guidelines and a template for security plan creation, and can serve as a base for development if one is needed. At this writing, the document can be found at the following link: http://csrc.nist.gov/publications/PubsSPs.html. \n\nSecurity controls applicable to email systems may not be tracked and followed if they are not identified in the EDSP. Omission of security control consideration could lead to an exploit of email system vulnerabilities or compromise of email information.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18868",
+      "title": "Email software installation account usage must be logged.",
+      "description": "Email Administrator or application owner accounts are granted more enhanced privileges than non-privileged users. It is especially important to grant access to privileged accounts to only those persons who are qualified and authorized to use them. Each use of the account should be logged to demonstrate this accountability. ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18869",
+      "title": "Email audit trails must be reviewed daily. ",
+      "description": "Access to email servers and software are logged to establish a history of actions taken in the system. Unauthorized access or use of the system could indicate an attempt to bypass established permissions. \n\nReviewing the log history can lead to discovery of unauthorized access attempts. Reviewing the logs daily helps to ensure prompt attention is given to any suspicious activities discovered therein. ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18877",
+      "title": "Email Administrator Groups must ensure least privilege.  ",
+      "description": "When an oversight responsibility is assigned to the same person performing the actions being overseen, the function of oversight is compromised. When the responsibility to manage or control one application or activity is assigned to one party yet another party is also assigned the privilege to the same actions, then neither party can logically be held responsible for those action. By separating responsibility and permissions by role, accountability can be as granular as needed. \n\nRole Based Access Control (RBAC) strategies for email administration include server role administration, permissions within server roles, and task based assignments.  Further granularity is possible, and often makes sense to do, enabling each role to operate using the least possible permissions to perform the role.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18878",
+      "title": "Automated audit reporting tools must be available. ",
+      "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. Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. However, audit record collection may quickly overwhelm storage resources and an auditor’s ability to review it in a productive manner. Add to that, an audit trail that is not monitored for detection of suspicious activities provides little value. Regular or daily review of audit logs not only leads to the earliest possible notice of a compromise, but can also minimize the extent of the compromise. \n\nAutomated Log Monitoring gives the additional boost to the monitoring process, in that noteworthy events are more immediately detected, provided they have been defined to the automated monitoring process. Log data can be mined for specific events, and upon detection, they can be analyzed to provide choices for alert methods, reports, trend analyses, attack scenario solutions. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18879",
+      "title": "Email audit records must be retained for 1 year.",
+      "description": "Audit data retention serves as a history that can aid in determining actions executed by users and administrators. Reasons for such research include both malicious actions that may have been perpetrated, as well as legal evidence that might be needed for proof of activity. \n\nAudit data records are required to be retained for a period of 1 year. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18880",
+      "title": "Audit logs must be documented and included in backups. ",
+      "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 logs are essential to the investigation and prosecution of unauthorized access to email services software and data. Unless audit logs are available for review, the extent of data compromise may not be determined and the vulnerability exploited may not be discovered. Undiscovered vulnerabilities could lead to additional or prolonged compromise of the data.\n\nAudit records should be backed up not less than weekly on to a different system or media than the system being audited, to ensure preservation of audit history. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18881",
+      "title": "The email backup and recovery strategy must be documented and tested on an INFOCON compliant frequency. ",
+      "description": "A disaster recovery plan exists that provides for the smooth transfer of all mission or business essential functions to an alternate site for the duration of an event with little or no loss of operational continuity.\n \nThe backup and recovery plan should include business recovery, system contingency, facility disaster recovery plans and plan acceptance.\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-18882",
+      "title": "Email backup and recovery data must be protected. ",
+      "description": "All automated information systems are at risk of data loss due to disaster or compromise. Failure to provide adequate protection to the backup and recovery data exposes it to risk of potential theft or damage that may ultimately prevent a successful restoration, should the need become necessary. Adequate protection ensures that backup components can be used to provide transparent or easy recovery from losses or operations outages.\n\nBackup files need the same protections against unauthorized access when stored on backup media as when online and actively in use by the email system. Included in this category are physical media, online configuration file copies, and any user data that may need to be restored. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18883",
+      "title": "Email backups must meet schedule and storage requirements. ",
+      "description": "Hardware failures or other (sometimes physical) disasters can cause data loss to active applications, and precipitate the need for expedient recovery.  Ensuring backups are conducted on an agreed schedule creates a timely copy from which to recover active systems. Storing backup contents at a separate physical location protects the backup data from site-specific physical disasters. Backup schedule and storage location are determined in accordance with the MAC category and confidentiality level of the system. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18884",
+      "title": "Email critical software copies must be stored off-site in a fire-rated container.",
+      "description": "There is always potential that accidental loss can cause system loss and that restoration will be needed. In the event that the installation site is compromised, damaged or destroyed copies of critical software media may be needed to recover the systems and become operational. \n\nCopies of the operating system (OS) and other critical software, such as email services applications must be created and stored off-site in a fire-rated container. If a site experiences loss or compromise of the installed software libraries, available copies can reduce the risk and shorten the time period for a successful email services recovery. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-18885",
+      "title": "Email acceptable use policy must be documented in the Email Domain Security Plan (EDSP).",
+      "description": "Email is only as secure as the recipient, which is ultimately person who is receiving messages. Also to consider, the surest way to prevent SPAM and other malware from entering the email message transport path is by using secure IA measures at the point of origin. Here again, this is ultimately a person, who is sending messages. \n\nAn Email Acceptable Use Policy is a set of rules that describe expected user behavior with regard to email messages. Formal creation and use of an Email Acceptable Use policy protects both organization and users by declaring boundaries, operational processes, and user training for such tasks as Help Desk procedures, legal considerations and email based threats that may be encountered. \n\nThe Email Acceptable Use Policy should be distributed to and signed by each email user, as a requirement for obtaining an email account. ",
+      "severity": "low"
+    },
+    {
+      "id": "V-18886",
+      "title": "Email Acceptable Use Policy must contain required elements. ",
+      "description": "Email is only as secure as the recipient, which is ultimately the person who is receiving messages. Also to consider, the surest way to prevent SPAM and other malware from entering the email message transport path is by using secure IA measures at the point of origin. Here again, this is ultimately a person, who is sending messages. \n\nEmail Acceptable Use Policy statements must include user education and expectations, as well as penalties and legal ramifications surrounding noncompliance. Examples of elements may include such items as classification and sensitivity labeling, undesirable message recognition such as for SPAM, Phishing, or bogus certificates. \n\nThere should also be process information, such as the Email Acceptable Use Policy location, review frequency, email services offered (Outlook, web based email), and email services forbidden (such as access via alternate email products). Users may also need to know other useful information, such as mailbox size quotas, attachment limitations, and procedural steps for making help desk requests. \n\nEmail tools, rules, and alerts descriptions plus official formats of email based announcements that may originate from the Email Administration team should be documented to prevent users being fooled or compromised by social engineering exploits. It may also be advantageous to have an ‘official’ method of communicating, enabling users to then recognize non-authentic requests and report them.",
+      "severity": "low"
+    },
+    {
+      "id": "V-19546",
+      "title": "Email domains must be protected by an Edge Server at the email transport path. ",
+      "description": "Separation of roles supports operational security for application and protocol services. Since 2006, Microsoft best practices had taken the direction of creating operational “roles” for servers within email services. The Edge Transport server role (also called an Email Secure Gateway) was created to focus authentication and sanitization tasks in one server, to provide Internet facing protection for internal email servers. \n\nIn the email services infrastructure, it has become imperative that inbound messages be examined prior to their being forwarded into the enclave, primarily due to the amount of SPAM and malware contained in the message stream. Similarly, outbound messages must be examined, so an organization might locate, or perhaps intercept, messages with potential data spillage of sensitive or important information. The Edge Transport email server role, which could be implemented using a number of comparable products, is designed to perform protective measures for both inbound and outbound messages. Its charter is to face the Internet, and to scrutinize all SMTP traffic, to determine whether to grant continued passage for messages to their destination. \n\nInbound email sanitization steps include (but are not limited to) processes, such as sender authentication and evaluation, content scoring (SPAM, spoofing, and phishing detection), antivirus sanitization and quarantine services, and results reporting. Outbound messages are typically examined for SPAM and malware origination. \n\nFailure to implement an Email Edge Transport server role may increase risk of compromise by allowing undesirable inbound messages could to reach the internal servers and networks. Failure to examine outbound traffic may increase risk of domain blacklisting if SPAM or malware is traced back to the source domain. Attempting to sanitize email after it arrives inside the domain is not an acceptable or effective security measure. By using an Edge Transport Server (Email Secure Gateway), any SMTP-specific attack vectors are more optimally secured.",
+      "severity": "high"
+    },
+    {
+      "id": "V-19548",
+      "title": "Email domains must be protected by transaction proxy at the client access path. ",
+      "description": "Separation of email server roles supports operational security for application and protocol services. The HTTP path to web sites is a proven convenience in requiring only a browser to access them, but is simultaneously a well known attack vector for people and applications that would attempt to gain unwelcome admittance to internal networks. \n\nWeb-based email applications, such as Exchange Outlook Web App (OWA), are classified as 'internal' or 'private' web servers. As with all web servers in the DoD, Internet-sourced email requests must be encrypted, authenticated, and proxied prior to permitting the transaction to access internally hosted email data. For email domains using Microsoft Exchange Client Access (CA) servers, Microsoft recommends and supports that all email CA servers reside inside enclaves (rather than a DMZ location) where firewalls would separate them from the other email servers. DoD PKI approved mechanisms for authentication are required for email access in the DoD. Multiple products exist that could meet the intent of this requirement, such as combination firewall and proxy servers, multi-tasking load balancers or shared authentication services for Internet-sourced traffic.",
+      "severity": "high"
+    },
+    {
+      "id": "V-33389",
+      "title": "Email acceptable use policy must be renewed annually. ",
+      "description": "An Email Acceptable Use Policy is a set of rules that describe IA operation and expected user behavior with regard to email services. Formal creation and use of an Email Acceptable Use policy protects both organization and users by declaring boundaries, operational processes, and user training surrounding helpdesk procedures, legal constraints and email based threats that may be encountered. \n\nThe Email Acceptable Use Policy must be annually updated, then subject to renewal by users. Requiring signed acknowledgement of the policy would constitute continued access to the email system.",
+      "severity": "low"
+    },
+    {
+      "id": "V-35227",
+      "title": "Transaction proxies protecting email domains must interrupt and inspect web traffic on the client access path prior to its entry to the enclave.",
+      "description": "Separation of email server roles supports operational security for application and protocol services. The HTTP path to web sites is a proven convenience in requiring only a browser to access them, but is simultaneously a well known attack vector for people and applications that would attempt to gain unwelcome admittance to internal networks. \n\nWeb-based email applications, such as Exchange Outlook Web App (OWA), are classified as 'internal' or 'private' web servers. As with all web servers in the DoD, Internet-sourced email requests must be encrypted, authenticated, and proxied prior to permitting the transaction to access internally hosted email data. DoD PKI approved mechanisms for authentication are required for email access in the DoD. Internet-sourced web traffic using TLS encryption is also required, however must have the encryption offloaded, and the transaction interrupted before allowing it into the enclave without some inspection. Multiple products exist that could meet the intent of this requirement, such as combination firewall and proxy servers, multi-tasking load balancers or shared authentication services for Internet-sourced traffic.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-39139",
+      "title": "Email client services for Commercial Mobile Devices must be documented in the Email Domain Security Plan (EDSP). ",
+      "description": "Commercial Mobile Devices (CMDs) introduce additional IA concerns to email systems because of the additional guidance pertaining specifically to CMDs. The Department of Defense (DoD) Chief Information Officer (CIO) put forth specific guidance concerning CMD implementation on 6 Apr 2011. The memo states, \"Email redirection from the email server (e.g., Exchange Server) to the device shall be controlled via centrally managed server.\" Therefore the native clients used on CMD cannot access the email system directly but instead must be managed by mobile email management (MEM) services. \n\nThe Exchange configuration relies on Exchange ActiveSync (EAS) as the client communication protocol. Natively, EAS is an inbound initiated, bidirectional protocol, which is problematic for DoD networks. Acceptable implementations avoid inbound initiated connections and use external secure network operation centers (NOC) in secure tunnels from the management servers residing in the DoD to the NOC and from the NOC to the CMD.\n\nFor email systems that do not deliver email directly to the device but rather use browser access to DoD email systems, this requirement would not apply but client-access path guidance does (EMG3-108 Email).\n\nThe EDSP must include the functional architecture of the integration of the email system, required MEM, NOC if used, and CMDs. Protocols communicating with the CMD or NOC must be secured to protect sensitive DoD data from being compromised using accepted FIPS 140-2 approved modules.",
+      "severity": "medium"
+    }
+  ]
+}

data/standards/stig_exchange_2010_client_access_server.json

@@ -0,0 +1,179 @@
+{
+  "name": "stig_exchange_2010_client_access_server",
+  "date": "2017-01-03",
+  "description": "The Microsoft Exchange Server 2010 STIGs cover four of the five roles available with Microsoft Exchange Server 2010. The Email Services Policy STIG must also be reviewed for each site hosting email services. Also, for the Client Access server, the IIS guidance must be reviewed prior to the OWA checks. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.",
+  "title": "Exchange 2010 Client Access Server STIG",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-33559",
+      "title": "Encryption must be used for RPC client access.\n",
+      "description": "This setting controls whether client machines are forced to use secure channels to communicate with the server.  If this feature is enabled, clients will only be able to communicate with the server over secure communication channels.\n\nFailure to require secure connections to the client access server increases the potential for unintended eavesdropping or data loss.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33562",
+      "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": "V-33570",
+      "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"
+    },
+    {
+      "id": "V-33571",
+      "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.  \n\nBy default, a virtual directory is installed for Public Folders.  If an attacker were to intrude into an Exchange CA server and be able to access the public folder web site, it would provide an additional attack vector, provided the virtual directory was present.  \n\nOnce removed, the Public functionality cannot be used without restoring the virtual directory.  ",
+      "severity": "low"
+    },
+    {
+      "id": "V-33584",
+      "title": "Web email must use standard ports  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": "V-33585",
+      "title": "Encryption must be used for OWA access.",
+      "description": "This setting controls whether client machines should be forced to use secure channels to communicate with this virtual directory.  If this feature is enabled, clients will only be able to communicate with the directory if they are capable of supporting secure communication with the server.\n\nThe use of secure communication prevents eavesdroppers from reading or modifying communications between servers and clients.   The network and DMZ STIG identify criteria for OWA and Public Folder configuration in the network, including CAC enabled pre-authentication through an application firewall proxy.\n\nFailure to require secure connections on a web site increases the potential for unintended eavesdropping or data loss.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33588",
+      "title": "Forms-based Authentication must not be enabled.",
+      "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.  Authentication for Outlook Web App (OWA) is used to enable web access to user email mailboxes and should assume that certificate-based authentication has been configured.  This setting controls whether forms-based login should be used by the OWA web site. \n\nBecause the DoD requires Common Access Card (CAC)-based authentication to applications, OWA access must be brokered through an application proxy or other pre-authenticator, which performs CAC authentication prior to arrival at the CA server.  The authenticated request is then forwarded directly to OWA, where authentication is repeated without requiring the user to repeat authentication steps.  For this scenario to work, the Application Proxy server must have forms-based authentication enabled, and Exchange must have forms-based Authentication disabled.  \n\nIf forms-based Authentication is enabled on the Exchange CA server, it is evidence that the application proxy server is either not correctly configured, or it may be missing.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33606",
+      "title": "Email Diagnostic log level must be set to low or 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. \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.\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 huge 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.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33607",
+      "title": "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-33608",
+      "title": "The Send Fatal Errors to Microsoft 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.   This setting enables an automated log entry to be sent to Microsoft giving general details about the nature and location of the error.   Microsoft, in turn, uses this information to improve the robustness of their product.\n\nWhile this type of debugging information would not ordinarily contain sensitive information, it may alert eavesdroppers to the existence of problems in your Exchange organization. At the very least, it could alert them to (possibly) advantageous timing to mount an attack.  At worst, it may provide them with information as to which aspects of Exchange are causing problems and might be vulnerable (or at least sensitive) to attack.   \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-33609",
+      "title": "Administrator audit logging must be 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 affect change using the same mechanisms as email administrators.  \n\nAuditing changes to access mechanisms not only supports accountability and non-repudiation 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-33610",
+      "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.  \n\nIf an attacker were to intrude into an Exchange CA server and reactivate Active Sync, this attack vector could once again be open, provided the virtual directory is present.\n\nOnce removed, the Active Sync functionality cannot be used without restoring the virtual directory, not a trivial process.  \n",
+      "severity": "low"
+    },
+    {
+      "id": "V-33611",
+      "title": "Audit data must be protected 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-33613",
+      "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33616",
+      "title": "Exchange must not send Customer Experience reports to Microsoft.",
+      "description": "Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. This setting enables an automated entry to be sent to Microsoft giving general details about how the product is used.  Microsoft, in turn, uses this information to improve the robustness of their product.\n\nWhile this type of information does not ordinarily contain sensitive information, it may alert eavesdroppers to the existence of the environment and its configurations.  It could alert them to (possibly) advantageous timing or weaknesses toward which to mount an attack. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33617",
+      "title": "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. \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-33618",
+      "title": "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.  By writing log and audit data to a separate partition where separate security contexts protect them, it may offer the ability to protect this information from being modified or removed by the exploit mechanism.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33619",
+      "title": "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\nThe intent of this check is for system administrators to have awareness of performance changes on their network. \n\nNotification choices include email an 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.\n\nData elements configured to be monitored should be specific to the organization’s network.\n.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33620",
+      "title": "Email software must be monitored for change on INFOCON frequency schedule.",
+      "description": "The INFOCON system provides a framework within which the Commander USSTRATCOM regional commanders, service chiefs, base/post/camp/station/vessel commanders, or agency directors can increase the measurable readiness of their networks to match operational priorities. The readiness strategy provides the ability to continuously maintain and sustain one’s own information systems and networks throughout their schedule of deployments, exercises, and operational readiness life cycle independent of network attacks or threats. The system provides a framework of prescribed actions and cycles necessary for reestablishing the confidence level and security of information systems for the commander and thereby supporting the entire Global Information Grid (GIG) (SD 527-1 Purpose).\n\nThe Exchange software files and directories are vulnerable to unauthorized changes if not adequately protected.  An unauthorized change could affect the integrity or availability of email services overall. For this reason, all application software installations must monitor for change against a software baseline that is preserved when installed, and updated periodically as patches or upgrades are installed. Automated and manual schedules for software change monitoring must be compliant with SD527-1 frequencies. \n\nNote: 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.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33621",
+      "title": "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. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33623",
+      "title": "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-33625",
+      "title": "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-33626",
+      "title": "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. \nFailure to implement valid certificates makes it virtually impossible to secure Exchange's communications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33629",
+      "title": "The current, approved service pack must be installed.\n",
+      "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. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33632",
+      "title": "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-33645",
+      "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.\n\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. \n\nFailure 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-39167",
+      "title": "Exchange ActiveSync (EAS) must only use certificate-based authentication to access email.",
+      "description": "Identification and Authentication provide the foundation for access control. For EAS to be used effectively on DoD networks, client certificate authentication must be used for communications between the MEM and email server. Additionally, the internal and external URLs must be set to the same address, since all EAS traffic must be tunneled to the device from the MEM.\n\nThe risk associated with email synchronization with CMD should be mitigated by the introduction of MEM products and is specified in the DoD CIO memo dated 6 Apr 2011. The memo states specifically, \"Email redirection from the email server (e.g., Exchange Server) to the device shall be controlled via centrally managed server.\" When EAS is used on DoD networks, the devices must be managed by an MEM.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-39172",
+      "title": "IIS must map client certificates to an approved certificate server",
+      "description": "For EAS to be used effectively on DoD networks, client certificate authentication must be used for communications between the MEM and email server. Identification and Authentication provide the foundation for access control. IIS must be mapped to an approved certificate server for client certificates. Additionally, the internal and external URLs must be set to the same address, since all EAS traffic must be tunneled to the device from the MEM.\n\nThe risk associated with email syncronization with CMD should be mitigated by the introduction of MEM products and is specified in the DoD CIO memo dated 6 Apr 2011. The memo states specifically, \"Email redirection from the email server (e.g., Exchange Server) to the device shall be controlled via centrally managed server.\" When EAS is used on DoD networks, the devices must be managed by an MEM.",
+      "severity": "medium"
+    }
+  ]
+}

data/standards/stig_exchange_2010_edge_transport_server.json

@@ -0,0 +1,389 @@
+{
+  "name": "stig_exchange_2010_edge_transport_server",
+  "date": "2017-01-03",
+  "description": "The Microsoft Exchange Server 2010 STIGs cover four of the five roles available with Microsoft Exchange Server 2010. The Email Services Policy STIG must also be reviewed for each site hosting email services. Also, for the Client Access server, the IIS guidance must be reviewed prior to the OWA checks. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.",
+  "title": "Exchange 2010 Edge Transport Server STIG",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-33556",
+      "title": "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 FORGERY 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.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33557",
+      "title": "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. Messages from blank senders, known SPAMMERS, or 0-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-33558",
+      "title": "SMTP IP Allow List Connection 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. Messages from blank senders, known SPAMMERS, or 0-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-33560",
+      "title": "SMTP IP Allow List entries must be empty. ",
+      "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. Messages from blank senders, known SPAMMERS, or 0-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.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33561",
+      "title": "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 the need to apply 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 and documented in the EDSP.",
+      "severity": "low"
+    },
+    {
+      "id": "V-33563",
+      "title": "Internet Receive Connector connections count must be set to default.",
+      "description": "Email system availability depends in part on best practices 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 get 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-33565",
+      "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 connections may be maintained for unnecessarily long time periods, preventing new connections from being established.  \n",
+      "severity": "low"
+    },
+    {
+      "id": "V-33566",
+      "title": "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-33567",
+      "title": "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-33568",
+      "title": "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. 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, 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-33569",
+      "title": "Internet facing 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": "V-33572",
+      "title": "Receive Connectors must control the number of recipients per message.  ",
+      "description": "Email system availability depends in part on best practices 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: This Receive connector 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: This Receive connector accepts connections from other Hub Transport servers and any Edge Transport servers. Their default value for MaxRecipientsPerMessage is 5000.",
+      "severity": "low"
+    },
+    {
+      "id": "V-33574",
+      "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. 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 that large message bodies can be relayed by the remote sender to the receive connector in multiple, smaller chunks.",
+      "severity": "low"
+    },
+    {
+      "id": "V-33575",
+      "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 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.\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-33576",
+      "title": "Auto-forwarding email to remote domains must be disabled or restricted.\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, 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-33578",
+      "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 SPAM batches so that the cost effectiveness of sending SPAM is reduced and directory harvest attacks may be thwarted.  \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.  A program can be written to collect email addresses that return a 'Recipient OK' SMTP response and discards 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-33579",
+      "title": "Receive Connector Maximum Hop Count must be 60.",
+      "description": "Email system availability depends in part on best practices 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.\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-33581",
+      "title": "Recipient 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. Messages from blank senders, known SPAMMERS, or 0-day attack modifications must be enabled to be effective. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33583",
+      "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 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-33586",
+      "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 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, 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 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-33587",
+      "title": "Message size restrictions must be controlled on Send 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 a send connector. Using connectors to control size limits may necessitate the need to apply 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 and documented in the EDSP.",
+      "severity": "low"
+    },
+    {
+      "id": "V-33589",
+      "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",
+      "severity": "low"
+    },
+    {
+      "id": "V-33590",
+      "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 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-33592",
+      "title": "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-33594",
+      "title": "Internet facing send Connectors must specify a Smart Host.",
+      "description": "In the case of 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, however, be configured to identify the Internet facing server that is performing the 'Smart Host' function.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33596",
+      "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 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-33598",
+      "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-33599",
+      "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": "V-33601",
+      "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.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33603",
+      "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": "V-33606",
+      "title": "Email Diagnostic log level must be set to low or 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. \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.\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 huge 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.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33608",
+      "title": "The Send Fatal Errors to Microsoft 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.   This setting enables an automated log entry to be sent to Microsoft giving general details about the nature and location of the error.   Microsoft, in turn, uses this information to improve the robustness of their product.\n\nWhile this type of debugging information would not ordinarily contain sensitive information, it may alert eavesdroppers to the existence of problems in your Exchange organization. At the very least, it could alert them to (possibly) advantageous timing to mount an attack.  At worst, it may provide them with information as to which aspects of Exchange are causing problems and might be vulnerable (or at least sensitive) to attack.   \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-33611",
+      "title": "Audit data must be protected 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-33613",
+      "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33616",
+      "title": "Exchange must not send Customer Experience reports to Microsoft.",
+      "description": "Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. This setting enables an automated entry to be sent to Microsoft giving general details about how the product is used.  Microsoft, in turn, uses this information to improve the robustness of their product.\n\nWhile this type of information does not ordinarily contain sensitive information, it may alert eavesdroppers to the existence of the environment and its configurations.  It could alert them to (possibly) advantageous timing or weaknesses toward which to mount an attack. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33618",
+      "title": "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.  By writing log and audit data to a separate partition where separate security contexts protect them, it may offer the ability to protect this information from being modified or removed by the exploit mechanism.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33619",
+      "title": "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\nThe intent of this check is for system administrators to have awareness of performance changes on their network. \n\nNotification choices include email an 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.\n\nData elements configured to be monitored should be specific to the organization’s network.\n.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33620",
+      "title": "Email software must be monitored for change on INFOCON frequency schedule.",
+      "description": "The INFOCON system provides a framework within which the Commander USSTRATCOM regional commanders, service chiefs, base/post/camp/station/vessel commanders, or agency directors can increase the measurable readiness of their networks to match operational priorities. The readiness strategy provides the ability to continuously maintain and sustain one’s own information systems and networks throughout their schedule of deployments, exercises, and operational readiness life cycle independent of network attacks or threats. The system provides a framework of prescribed actions and cycles necessary for reestablishing the confidence level and security of information systems for the commander and thereby supporting the entire Global Information Grid (GIG) (SD 527-1 Purpose).\n\nThe Exchange software files and directories are vulnerable to unauthorized changes if not adequately protected.  An unauthorized change could affect the integrity or availability of email services overall. For this reason, all application software installations must monitor for change against a software baseline that is preserved when installed, and updated periodically as patches or upgrades are installed. Automated and manual schedules for software change monitoring must be compliant with SD527-1 frequencies. \n\nNote: 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.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33621",
+      "title": "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. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33622",
+      "title": "Accepted domains must be 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-33623",
+      "title": "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-33624",
+      "title": "Global inbound message size must be controlled.  ",
+      "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’.   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 it simplifies server administration. \n\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-33625",
+      "title": "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-33626",
+      "title": "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. \nFailure to implement valid certificates makes it virtually impossible to secure Exchange's communications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33627",
+      "title": "Global outbound message size must be controlled. ",
+      "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’.   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-33629",
+      "title": "The current, approved service pack must be installed.\n",
+      "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. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33630",
+      "title": "Global recipient count limit must be set.",
+      "description": "Email system availability depends in part on best practices 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.\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-33631",
+      "title": "Messages with malformed from address 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.   For example, messages with malformed or incorrect 'purported responsible sender' data in the message header could be (best case) created by using RFI non-compliant software, but is more likely to be SPAM.     \n\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33632",
+      "title": "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-33633",
+      "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33634",
+      "title": "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, 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.   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. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33635",
+      "title": "Outbound Connection Limit per Domain Count must be controlled.\n",
+      "description": "Email system availability depends in part on best practices 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-33636",
+      "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.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33637",
+      "title": "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. 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 *.adp *.csh *.ksh *.msp *.sct *.htm *.dcr *.app *.exe *.lnk *.mst *.shb *.html *.plg *.asx *.fxp *.mda *.ops *.shs *.htc *.spl *.bas *.hlp *.mdb *.pcd *.url *.mht *.swf\n*.bat *.hta *.mde *.pif *.vb *.mhtml  *.chm *.inf *.mdt *.prf *.vbe *.shtm  *.cmd *.ins *.mdw *.prg *.vbs *.shtml \n*.com *.isp *.mdz *.reg *.wsc *.stm \n*.cpl *.js *.msc *.scf *.wsf  \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33638",
+      "title": "Sender reputation filter must identify SPAM block level. ",
+      "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": "V-33639",
+      "title": "Sender reputation filter 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": "V-33640",
+      "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": "V-33641",
+      "title": "Sender Filter must block accepted domains at the edge. ",
+      "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 block messages originating from specific sources. Most Black List 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 0-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-33642",
+      "title": "Filtered messages must be archived.",
+      "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. 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.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33643",
+      "title": "Messages with 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-33644",
+      "title": "Messages with blank senders must be rejected. ",
+      "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": "V-33646",
+      "title": "Outbound Connection Timeout must be 10 or less. ",
+      "description": "Email system availability depends in part on best practices 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.\n",
+      "severity": "low"
+    },
+    {
+      "id": "V-60981",
+      "title": "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. 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"
+    }
+  ]
+}