Exchange Server Güvenliği Teknik Uygulama Kılavuzu

Mehmet Sait YILMAZ 25/01/2024

2 1 saatte okunur

Aşağıdaki klavuz tüm Excahnge Sever rollerini kapsar. Dikkatlice gözden geçirilmelidir.

Başlık	Açıklama	İşlem	Kontrol
The Microsoft Exchange IMAP4 service must be disabled.	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.	Open the Windows Power Shell and enter the following command: services.msc Double click the ‘Microsoft Exchange IMAP4’ service and select the General tab. Set the ‘Startup Type’ to ‘Disabled’, click ok.	Open the Windows Power Shell and enter the following command: Get-ItemProperty ‘hklm:\system\currentcontrolset\services\MSExchangeIMAP4’ \| Select Start If the value of ‘Start’ is not set to ‘4’, this is a finding.
HTTP authenticated access must be set to Integrated Windows Authentication only.	This feature controls the authentication method used to connect to the OWA virtual directories. Ensure this is set to Integrated Windows Authentication only. Anonymous access provides for no access control. Basic Authentication transmits the password in the clear and risks exposure, and the other methods are not recommended by Microsoft for this control. Failure to configure this as per the recommendation may result in unrestricted access to OWA virtual directory, passwords being sent in the clear, and/or the inability to correctly authenticate, depending on which change is made.	Open the Exchange Management Shell and enter the following command: Set-OwaVirtualDirectory -WindowsAuthentication $true -Identity ‘<IdentityName>’	Open the Exchange Management Shell and enter the following command: Get-OwaVirtualDirectory -server ‘<Identity Name>’ \| Select Name,Identity,*Authentication If the ‘WindowsAuthentication’ is not ‘True’, this is a finding. If any other result for ‘WindowsAuthentication’ is set to ‘True’, this is a finding. NOTE: Typical results for this command would result in this display: Name : owa (Default Web Site) Identity : <Identity Name>\owa (Default Web Site) BasicAuthentication : False WindowsAuthentication : True DigestAuthentication : False FormsAuthentication : False LiveIdAuthentication : False
Email Diagnostic log level must be set to low or lowest level.	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. Exchange 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. Diagnostic 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.	Open the Exchange Management Shell and enter the following command: Set-EventLogLevel -Identity <ServiceName\Name> -Level Lowest or Set-EventLogLevel -Identity <ServiceName\Name> -Level Low	Open the Exchange Management Shell and enter the following command: Get-EventLogLevel If any Diagnostic “EventLevel” is not set to “Low” or “Lowest”, this is a finding.
Outlook Anywhere (OA) clients must use NTLM authentication to access email.	Identification and Authentication provide the foundation for access control. Access to email services applications require NTLM authentication. Outlook Anywhere, if authorized for use by the site, must use NTLM authentication when accessing email. Note: There is a technical restriction in Exchange 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.	Open the Exchange Management Shell and enter the following command: Set-OutlookAnywhere -ClientAuthenticationMethod NTLM	Open the Exchange Management Shell and enter the following command: Get-OutlookAnywhere If the value of ‘Client Authentication Method’ is not set to ‘NTLM’, this is a finding.
The Send Fatal Errors to Microsoft must be disabled.	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. While 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. All system errors in Exchange will result in outbound traffic that may be identified by an eavesdropper. For this reason, the ‘Report Fatal Errors to Microsoft’ feature must be disabled.	Open the Exchange Management Shell and enter the following command: Set-ExchangeServer -Identity <‘ServerName’> -ErrorReportingEnabled $false	Open the Exchange Management Shell and enter the following command: Get-ExchangeServer –status \| Select Name, Identity, ErrorReportingEnabled If the value of ‘ErrorReportingEnabled’ is not set to ‘False’, this is a finding.
Administrator audit logging must be enabled.	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. Auditing 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. Note: This administrator auditing feature audits all exchange changes regardless of the users’ assigned role or permissions.	Open the Exchange Management Shell and enter the following command: Set-AdminAuditLogConfig -AdminAuditLogEnabled $true	Open the Exchange Management Shell and enter the following command: Get-AdminAuditLogConfig \| Select AdminAuditLogEnabled If the value of ‘AdminAuditLogEnabled’ is not set to ‘True’, this is a finding.
The current, approved service pack must be installed.	Failure to install the most current Exchange service pack leaves a system vulnerable to exploitation. Current service packs correct known security and system vulnerabilities.	Update the system with the latest approved service pack or a supported release.	Open the Exchange Management Shell and enter the following command: Get-ExchangeServer \| fl name, AdminDisplayVersion If the value of ‘AdminDisplayVersion’ does not return Version 14.2 (Build 247.5) or greater, this is a finding.
Encryption must be used for OWA access.	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. The use of secure communication prevents eavesdroppers from reading or modifying communications between servers and clients. The network and DMZ STIG identify criteria for OWA and Public Folder configuration in the network, including CAC enabled pre-authentication through an application firewall proxy. Failure to require secure connections on a web site increases the potential for unintended eavesdropping or data loss.	Configure the OWA site to require SSL port 443.	Open the Windows PowerShell Modules and enter the following command: Import-module webadministration IIS: cd Sites cd “Default Web Site” cd owa PS IIS:\Sites\Default Web Site\owa> Get-WebConfigurationProperty -filter /system.webServer/security/access -name sslflags Review the result and verify only TLSv1.0 or higher is returned. If not, this is a finding.
Web email must use standard ports protocols.	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 connections is 443. Changing 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. Negative 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.	Configure web ports to be port 80 and 443, as specified by PPSM standards.	Open a Windows PowerShell Module and enter the following command: Get-WebBinding -Name <‘WebSiteName’>\| Format-List If the Web binding values are not on standard port 80 for HTTP connections or port 443 for HTTPS connections, this is a finding.
Email software must be monitored for change on INFOCON frequency schedule.	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). The 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. Note: 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.	Implement a process to compare software against a baseline (.exe, .bat, .com, .cmd, and *.dll) on a frequency required by the prevailing INFOCON level. Document the process and output artifacts in the EDSP.	Access the EDSP baseline section and determine the process and frequency for identifying software changes (.exe, .bat, .com, .cmd, and *.dll) on servers against a baseline. Examine artifacts identified as outputs of this process. If baseline comparisons are not done on the INFOCON-required schedule, this is a finding.
Forms-based Authentication must not be enabled.	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. Because 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. If 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.	Open the Exchange Management Shell and enter the following command: Set-OwaVirtualDirectory -Identity <‘IdentityName’> -FormsAuthentication $false	Open the Exchange Management Shell and enter the following command: Get-OwaVirtualDirectory \| Select Name, Identity, FormsAuthentication If the value of ‘FormsAuthentication’ is not set to ‘False’, this is a finding.
Services must be documented and unnecessary services must be removed or disabled.	Unneeded, but running, services offer attackers an enhanced attack profile, and attackers are constantly watching to discover open ports with running services. By analyzing and disabling unneeded services, the associated open ports become unresponsive to outside queries, and servers become more secure as a result. Exchange Server has role-based server deployment to enable protocol path control and logical separation of network traffic types. For example, a server implemented in the Client Access role (i.e., Outlook Web App [OWA]) is configured and tuned as a web server using web protocols. A client access server exposes only web protocols (HTTP/HTTPS) enabling system administrators to optimize the protocol path and disable all services unnecessary for Exchange web services. Similarly, servers created to host mailboxes are dedicated to that task, and must operate only the services needed for mailbox hosting. (Exchange servers must also operate some Web services, but only to the degree that Exchange requires the IIS engine in order to function). Because POP3, and IMAP4 clients are not included in the standard desktop offering, they must be disabled.	Document the services required for the system to operate. Remove or disable any services that are not required.	To view system services open a windows power shell and enter the following command: Get-Service \| Where-Object {$_.status -eq ‘running’} The command returns a list of installed services and the status of that service. Required services will vary between organizations, and will vary depending on the role of the individual system. Organizations will develop their own list of services which will be documented and justified with the ISSO. The Site’s list will be provided for any security review. Services that are common to multiple systems can be addressed in one document. Exceptions for individual systems should be identified separately by system. If the site has not documented the services required for their system(s), this is a finding. If any undocumented or unnecessary services are running, then this is a finding.
Email application must not share a partition with another application.	In the same way that added security layers can provide a cumulative positive effect on security posture, multiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit to one application can lead to an exploit of other applications sharing the same security context. For example, an exploit to a web server process that leads to unauthorized administrative access to the host system can most likely lead to a compromise of all applications hosted by the same system. Email services should be installed on a partition that does not host other applications. Email services should never be installed on a Domain Controller / Directory Services server.	Install Exchange on a dedicated application partition separate than that of the OS.	Access Windows Explorer and identify the OS partition. Navigate to configured partitions, and access the ‘Program Files’ directory. Note the installation partition for Microsoft Exchange. If Exchange resides on a partition other than that of the OS, and does not have other applications installed (without associated approval from the ISSO), this is not a finding.
Servers must use approved DoD certificates.	Server certificates are required for many security features in Exchange; without them the server cannot engage in many forms of secure communication. Failure to implement valid certificates makes it virtually impossible to secure Exchange’s communications.	Remove the non-DoD certificate and import the correct DoD certificates.	Open the Exchange Management Shell and enter the following command: Get-ExchangeCertificate \| Select CertificateDomains, issuer If the value of ‘CertificateDomains’ does not indicate it is issued by the DoD, this is a finding.
The Microsoft Exchange POP3 service must be disabled.	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.	Open the Windows Power Shell and enter the following command: services.msc Double click the ‘Microsoft Exchange POP3’ service and select the General tab. Set the ‘Startup Type’ to ‘Disabled’, click ok.	Open the Windows Power Shell and enter the following command: Get-ItemProperty ‘hklm:\system\currentcontrolset\services\MSExchangePOP3’ \| Select Start If the value of ‘Start’ is not set to ‘4’, this is a finding.
The Public Folder virtual directory must be removed if not in use by the site.	To reduce the vectors through which a server can be attacked, unneeded application components should be disabled or removed. By default, a virtual directory is installed for Public Folders. If an attacker were to intrude into an Exchange 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. Once removed, the Public functionality cannot be used without restoring the virtual directory.	Open the Exchange Management Shell and enter the following command: Remove-PublicFolder -Identity <‘Identity’> -Server <‘ServerName’> -Recurse: $true Note: This command removes both the root directory and any subdirectories.	If public folders are in use this check is NA. Open the Exchange Management Shell and enter the following command: Get-PublicFolder \| Select Name, Identity If public folders are not in use and directories exist, this is a finding.
Encryption must be used for RPC client access.	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. Failure to require secure connections to the client access server increases the potential for unintended eavesdropping or data loss.	Open the Exchange Management Shell and enter the following command: Set-RpcClientAccess -Server <‘ServerName’> -EncryptionRequired $true	Open the Exchange Management Shell and enter the following command: Get-RpcClientAccess \| Select Server, EncryptionRequired If the value of ‘EncryptionRequired’ is not set to ‘True’, this is a finding.
Audit record parameters must be set.	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. Audit records should include the following fields to supply useful event accounting: Object modified, Cmdlet name, Cmdlet parameters, Modified parameters, Caller, Succeeded, and Originating server.	Open the Exchange Management Shell and enter the following command: Set-AdminAuditLogConfig -AdminAuditLogParameters *	Open the Exchange Management Shell and enter the following command: Get-AdminAuditLogConfig \| Select AdminAuditLogParameters If the value of ‘AdminAuditLogParameters’ is not set to ‘{}’, this is a finding. Note: The value of {} indicates all parameters are being audited.
Exchange must not send Customer Experience reports to Microsoft.	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. While 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.	Open the Exchange Management Shell and enter the following command: Set-OrganizationConfig -CustomerFeedbackEnabled $false	Open the Exchange Management Shell and enter the following command: Get-OrganizationConfig If the value for CustomerFeedbackEnabled is not set to ‘False’, this is a finding.
Audit data must be protected against unauthorized access.	Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Audit log content must always be considered sensitive, and in need of protection. Audit data available for modification by a malicious user can be altered to conceal malicious activity. Audit data might also provide a means for the malicious user to plan unauthorized activities that exploit weaknesses. The contents of audit logs are protected against unauthorized access, modification, or deletion. Only authorized auditors and the audit functions should be granted Read and Write access to audit log data.	Restrict any unauthorized groups or users from accessing the audit logs.	Obtain the Email Domain Security Plan (EDSP) and locate the authorized groups or users that should have access to the audit data. If any group or user has access to the audit data that is not documented in the EDSP, this is a finding.
The Microsoft Active Sync directory must be removed.	To reduce the vectors through which a server can be attacked, unneeded application components should be disabled or removed. By default, a virtual directory is installed for Active Sync, and the Exchange application default has Active Sync disabled. If an attacker were to intrude into an Exchange CA server and reactivate Active Sync, this attack vector could once again be open, provided the virtual directory is present. Once removed, the Active Sync functionality cannot be used without restoring the virtual directory, not a trivial process.	Open an Exchange Command Shell and enter the following command: Remove-ActiveSyncVirtualDirectory ServerName\Microsoft-Server-Active-Sync -Confirm $true NOTE: The physical directory must also be deleted.	Open the Exchange Management Shell and enter the following command: Get-ActiveSyncVirtualDirectory \| Select Server, Name, Identity, Path If the value of ‘Path’ (actual directory) exists, this is a finding.
Exchange application directory must be protected from unauthorized access.	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.	Locate the Exchange application directory and Remove or modify the group or user access permissions. Note: The default installation directory is \Program Files\Microsoft\Exchange Server\V14.	Obtain the Email Domain Security Plan (EDSP) and locate the authorized groups and users that have access to the Exchange application directories. Verify the access permissions on the directory match the access permissions listed in the EDSP. If any group or user has different access permissions, this is a finding. Note: The default installation directory is \Program Files\Microsoft\Exchange Server\V14.
Queue monitoring must be configured with threshold and action.	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. The intent of this check is for system administrators to have awareness of performance changes on their network. Notification 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. Data elements configured to be monitored should be specific to the organization’s network. .	Open the Exchange Management Console In the left pane, navigate to and select Microsoft Exchange On-Premises <server.domain> –> Toolbox In the Right pane double click on Performance Monitor In the left pane, navigate to and select Performance Logs and Alerts –> Data Collector Sets –> User Defined Right click on User Defined and configure the system to use User Defined data collection for monitoring the queues.	Note: If a third-party application is performing monitoring functions, the reviewer should verify the application is monitoring correctly and mark the vulnerability NA. Open the Exchange Management Shell and enter the following command: perfmon In the left pane, expand and navigate Data Collector Sets >> User Defined. If no sets are defined or queues are not being monitored, this is a finding.
Audit data must be on separate partitions.	Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Audit log content must always be considered sensitive, and in need of protection. Successful exploit of an application server vulnerability may well be logged by monitoring or audit processes when it occurs. 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.	Configure the audit log location to be on a partition drive separate from the application. Document the location in the EDSP.	Obtain the Email Domain Security Plan (EDSP) and locate the audit logs assigned partition. By default the logs are located on the application partition in ‘\Program Files\Microsoft\Exchange Server\V14\Logging\’. If the log files are not on a separate partition from the application, this is a finding.
Local machine policy must require signed scripts.	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.	Open the Exchange Management Shell and enter the following command: Set-ExecutionPolicy RemoteSigned	Open the Exchange Management Shell and enter the following command: Get-ExecutionPolicy If the value of ‘LocalMachine’ does not return a value of ‘RemoteSigned’, this is a finding.
Exchange ActiveSync (EAS) must only use certificate-based authentication to access email.	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. The 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.	Open the Exchange Management Shell and enter the following command: Set-ActiveSyncVirtualDirectory -Identity “ClientAccessServerName\Microsoft-Server-ActiveSync (Default Web Site)” -ClientCertAuth “Required” -WindowsAuthEnabled:$False -InternalAuthenticationMethods “Certificate” –ExternalAuthenticationMethods “Certificate” –ExternalUrl “https://mail-site.easf.csd.disa.mil/Microsoft-Server-ActiveSync”	Open the Exchange Management Shell and enter the following commands: Get-ActiveSyncVirtualDirectory -Identity “<Identity Name>\Microsoft-Server-ActiveSync (Default Web Site)” \| fl Basic AuthEnabled,WindowsAuthEnabled,ClientCertAuth,WebSiteSSLEnabled,InternalAuthenticationMethods,ExternalAuthenticationMethods These should be the results returned: BasicAuthEnabled : False WindowsAuthEnabled : False ClientCertAuth : Required WebSiteSSLEnabled : True InternalAuthenticationMethods : {Certificate} ExternalAuthenticationMethods : {Certificate} If the values above are not returned, this is a finding.
IIS must map client certificates to an approved certificate server	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. The 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.	Open a command window and enter the following commands: cd C:\Windows\SysWOW64\InetSrv appcmd unlock config /section:clientCertificateMappingAuthentication appcmd set config “Default Web Site/Microsoft-Server-ActiveSync” -section:clientCertificateMappingAuthentication /enabled:true	Open a command window and enter the following commands: CD C:\Windows\SysWOW64\inetsrv Appcmd.exe list config “Default Web Site/Microsoft-Server-ActiveSync” -section:clientCertificateMappingAuthentication If clientCertificateMappingAuthentication enabled=”true” is not returned, this is a finding.
Exchange software baseline copy must exist.	Exchange software, as with other application software installed on a host system, must be included in a system baseline record and periodically reviewed; otherwise unauthorized changes to the software may not be discovered. This effort is a vital step to securing the host and the applications, as it is the only method that may provide the ability to detect and recover from otherwise undetected changes, such as those that result from worm or bot intrusions. The Exchange software and configuration baseline is created and maintained for comparison during scanning efforts. Operational procedures must include baseline updates as part of configuration management tasks that change the software and configuration.	Implement email software baseline process. Document the details in the EDSP.	Access the EDSP and locate the baseline documentation. Review the application software baseline procedures and implementation artifacts. Note the list of files and directories included in the baseline procedure for completeness. If an email software copy exists to serve as a baseline and is available for comparison during scanning efforts, this is not a finding.