acceptedMicrosoft Exchange 2013 Client Access Server Security Technical Implementation GuideThis Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.DISASTIG.DOD.MILRelease: 1 Benchmark Date: 15 Dec 20213.2.2.360791.10.02I - Mission Critical Classified<ProfileDescription></ProfileDescription>I - Mission Critical Public<ProfileDescription></ProfileDescription>I - Mission Critical Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>SRG-APP-000014<GroupDescription></GroupDescription>EX13-CA-000005Exchange must use Encryption for RPC client access.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84337V-69715CCI-000068Open the Exchange Management Shell and enter the following command:
Set-RpcClientAccess -Server <ServerName> -EncryptionRequired $trueOpen the Exchange Management Shell and enter the following command:
Get-RpcClientAccess | Select Server, Name, EncryptionRequired
If the value of EncryptionRequired is not set to True, this is a finding.SRG-APP-000014<GroupDescription></GroupDescription>EX13-CA-000010Exchange must use Encryption for OWA access.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84339V-69717CCI-000068Configure the OWA site to require SSL port 443.Open a Windows PowerShell and enter the following command:
Import-module webadministration
Enter cd “IIS:”
At the IIS: prompt, enter cd Sites
At the Sites: prompt, enter cd “Default Web Site”
At the “Default Web Site”: prompt, enter cd owa
At the IIS:\Sites\Default Web Site\owa>: prompt, enter Get-WebConfigurationProperty -filter /system.webServer/security/access -name sslflags
If the value returned is not Ssl,Ssl128, this is a finding.
SRG-APP-000014<GroupDescription></GroupDescription>EX13-CA-000015Exchange must have Forms-based Authentication disabled.<VulnDiscussion>Identification and Authentication provide the foundation for access control. Access to email services applications in the DoD requires authentication using DoD Public Key Infrastructure (PKI) certificates. Authentication for Outlook Web App (OWA) is used to enable web access to user email mailboxes and should assume that certificate-based authentication has been configured. This setting controls whether forms-based logon should be used by the OWA website.
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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84341V-69719CCI-000068Open the Exchange Management Shell and enter the following command:
Set-OwaVirtualDirectory -Identity <'IdentityName'> -FormsAuthentication $false
Note <IdentityName> must be in quotes.
Example for the Identity Name: <ServerName>\owa (Default Web site)
Restart the ISS service.Open the Exchange Management Shell and enter the following command:
Get-OwaVirtualDirectory | Select ServerName, Name, Identity, FormsAuthentication
If the value of FormsAuthentication is not set to False, this is a finding.SRG-APP-000033<GroupDescription></GroupDescription>EX13-CA-000020Exchange must have authenticated access set to Integrated Windows Authentication only.<VulnDiscussion>To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems (e.g., networks, web servers, and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement.
Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system.
This requirement is applicable to access control enforcement applications (e.g., authentication servers) and other applications that perform information and system access control functions.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84343V-69721CCI-000213Open the Exchange Management Shell and enter the following command:
Set-OwaVirtualDirectory -Identity '<IdentityName>' -WindowsAuthentication $true
Note: The <IdentityName> value must be in quotes.
Example for the Identity Name: <ServerName>\owa (Default Web site)Open the Exchange Management Shell and enter the following command:
Get-OwaVirtualDirectory | Select ServerName, Name,Identity,*Authentication
If the value of WindowsAuthentication is not set to True, this is a finding.SRG-APP-000027<GroupDescription></GroupDescription>EX13-CA-000025Exchange must have Administrator audit logging enabled.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84345V-69723CCI-001403Open the Exchange Management Shell and enter the following command:
Set-AdminAuditLogConfig -AdminAuditLogEnabled $trueOpen the Exchange Management Shell and enter the following command:
Get-AdminAuditLogConfig | Select Name, Identity, AdminAuditLogEnabled
If the value of AdminAuditLogEnabled is not set to True, this is a finding.SRG-APP-000033<GroupDescription></GroupDescription>EX13-CA-000030Exchange Servers must use approved DoD certificates.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84347V-69725CCI-000213Remove 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.SRG-APP-000033<GroupDescription></GroupDescription>EX13-CA-000035Exchange ActiveSync (EAS) must only use certificate-based authentication to access email.<VulnDiscussion>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 06 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84349V-69727CCI-000213Open the Exchange Management Shell and enter the following command:
Set-ActiveSyncVirtualDirectory -Identity ‘<ServerName>\Microsoft-Server-ActiveSync (Default Web Site)’ -BasicAuthEnabled $False -WindowsAuthEnabled $False -ClientCertAuth ‘Required’ -WebSites-InternalAuthenticationMethods ‘Certificate’ -ExternalAuthenticationMethods ‘Certificate’
Note: The <ServerName>Microsoft-Server-ActiveSync (Default Web Site) value must be in quotes.Open the Exchange Management Shell and enter the following commands:
Get-ActiveSyncVirtualDirectory | Select Name, Identity
Get-ActiveSyncVirtualDirectory -Identity '<ServerName>Microsoft-Server-ActiveSync (Default Web Site)' | fl BasicAuthEnabled, WindowsAuthEnabled, ClientCertAuth, WebSiteSSLEnabled, InternalAuthenticationMethods, ExternalAuthenticationMethods
Note: The <ServerName>Microsoft-Server-ActiveSync (Default Web Site) value must be in quotes.
The command should return the following:
BasicAuthEnabled : False
WindowsAuthEnabled : False
ClientCertAuth : Required
WebSiteSSLEnabled : True
InternalAuthenticationMethods : {Certificate}
ExternalAuthenticationMethods : {Certificate}
If the values above are not returned, this is a finding.SRG-APP-000033<GroupDescription></GroupDescription>EX13-CA-000040Exchange must have IIS map client certificates to an approved certificate server.<VulnDiscussion>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 synchronization with CMD should be mitigated by the introduction of MEM products and is specified in the DoD CIO memo dated 06 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84351V-69729CCI-000213Open 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:trueOpen 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 is not set to True, this is a finding.SRG-APP-000089<GroupDescription></GroupDescription>EX13-CA-000045Exchange Email Diagnostic log level must be set to lowest level.<VulnDiscussion>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 large very quickly. Diagnostic log levels may be raised for limited periods of time when attempting to debug relevant pieces of Exchange functionality. Once debugging has finished, diagnostic log levels should be reduced again.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84353V-69731CCI-000169Open the Exchange Management Shell and enter the following command:
Set-EventLogLevel -Identity <'IdentityName\EventlogName'> -Level Lowest
Note: The <IdentityName\EventlogName> value must be in quotes.Open the Exchange Management Shell and enter the following command:
Get-EventLogLevel
If any Diagnostic EventLogLevel is not set to Lowest, this is a finding.SRG-APP-000089<GroupDescription></GroupDescription>EX13-CA-000050Exchange must have Audit record parameters set.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84355V-69733CCI-000169Open 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 Name, Identity, AdminAuditLogParameters
If the value of AdminAuditLogParameters is not set to {*}, this is a finding.
Note: The value of {*} indicates all parameters are being audited.SRG-APP-000111<GroupDescription></GroupDescription>EX13-CA-000055Exchange must have Queue monitoring configured with threshold and action.<VulnDiscussion>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.
This field offers choices of alerts when a "warning" or "critical" threshold is reached on the SMTP queue. A good rule of thumb (default) is to issue warnings when SMTP queue growth exceeds 10 minutes and critical messages when it exceeds 20 minutes, which should only exist occasionally. Frequent alerts against this counter may indicate a network or other issue (such as inbound SPAMMER traffic) that directly impacts email delivery.
Notification choices include email alert to an email-enabled account, for example, an email Administrator, or invoke a script to take other action, for example, to add an Event to the Microsoft Application Event Log, where external monitors might detect it.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84357V-69735CCI-000154Open the Exchange Management Shell and enter the following command:
perfmon
In the left pane, navigate to and select Performance >> Data Collector Sets >> User Defined.
Right-click, navigate to, and configure User Defined >> New >> Data Collector Set 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 not applicable.
Open the Exchange Management Shell and enter the following command:
perfmon
In the left pane, expand and navigate Performance >> Data Collector Sets >> User Defined.
If no sets are defined or queues are not being monitored, this is a finding.SRG-APP-000141<GroupDescription></GroupDescription>EX13-CA-000060Exchange must have Send Fatal Errors to Microsoft disabled.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84359V-69737CCI-000381Open the Exchange Management Shell and enter the following command:
Set-ExchangeServer -Identity <IdentityName> -ErrorReportingEnabled $false
Note: The <IdentityName> value must be in quotes.
Repeat the procedure for each Identity.Open the Exchange Management Shell and enter the following command:
Get-ExchangeServer –status | Select Name, Identity, ErrorReportingEnabled
For each Identity, if the value of ErrorReportingEnabled is not set to False, this is a finding.SRG-APP-000118<GroupDescription></GroupDescription>EX13-CA-000065Exchange must have Audit data protected against unauthorized read access.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84361V-69739CCI-000162Update the EDSP.
Navigate to the location of the audit data.
By default, the logs are located on the application partition in \Program Files\Microsoft\Exchange Server\V15\Logging
Restrict any unauthorized groups' or users' read access to the audit logs.Review the Email Domain Security Plan (EDSP).
Determine the authorized groups or users that should have read access to the audit data.
If any group or user has read access to the audit data that is not documented in the EDSP, this is a finding.SRG-APP-000141<GroupDescription></GroupDescription>EX13-CA-000070Exchange must not send Customer Experience reports to Microsoft.<VulnDiscussion>It is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.
Applications are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions).
Examples of non-essential capabilities include, but are not limited to, advertising software or browser plug-ins not related to requirements or providing a wide array of functionality not required for every mission, but cannot be disabled.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84363V-69741CCI-000381Open the Exchange Management Shell and enter the following command:
Set-OrganizationConfig -CustomerFeedbackEnabled $falseOpen the Exchange Management Shell and enter the following command:
Get-OrganizationConfig | Select Name, Identity, CustomerFeedbackEnabled
If the value for CustomerFeedbackEnabled is not set to False, this is a finding.SRG-APP-000119<GroupDescription></GroupDescription>EX13-CA-000075Exchange must have Audit data protected against unauthorized modification.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84365V-69743CCI-000163Update the EDSP.
Navigate to the location of the audit data.
By default, the logs are located on the application partition in \Program Files\Microsoft\Exchange Server\V15\Logging
Restrict any unauthorized groups' or users' modify permissions for the audit logs.Review the Email Domain Security Plan (EDSP).
Determine the authorized groups or users that should have access to the audit data.
If any group or user has modify privileges for the audit data that is not documented in the EDSP, this is a finding.SRG-APP-000120<GroupDescription></GroupDescription>EX13-CA-000080Exchange must have audit data protected against unauthorized deletion.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84367V-69745CCI-000164Update the EDSP.
Navigate to the location of the audit data.
By default, the logs are located on the application partition in \Program Files\Microsoft\Exchange Server\V15\Logging
Restrict any unauthorized groups' or users' delete permissions for the audit logs.Review the Email Domain Security Plan (EDSP).
Determine the authorized groups or users that should have delete permissions for the audit data.
If any group or user has delete permissions for the audit data that is not documented in the EDSP, this is a finding.SRG-APP-000125<GroupDescription></GroupDescription>EX13-CA-000085Exchange must have Audit data on separate partitions.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84369V-69747CCI-001348Update the EDSP.
Configure the audit log location to be on a partition drive separate from the application.Review the Email Domain Security Plan (EDSP).
Determine the audit logs' assigned partition.
Note: By default, the logs are located on the application partition in \Program Files\Microsoft\Exchange Server\V15\Logging.
If the log files are not on a separate partition from the application, this is a finding.SRG-APP-000131<GroupDescription></GroupDescription>EX13-CA-000090Exchange Local machine policy must require signed scripts.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84373V-69751CCI-001749Open the Exchange Management Shell and enter the following command:
Set-ExecutionPolicy RemoteSignedOpen the Exchange Management Shell and enter the following command:
Get-ExecutionPolicy
If the value returned is not RemoteSigned, this is a finding.SRG-APP-000141<GroupDescription></GroupDescription>EX13-CA-000095Exchange IMAP4 service must be disabled.<VulnDiscussion>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 users to access other system features. Uninstalling or disabling the service will prevent the use of the IMAP4 protocol.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84375V-69753CCI-000381Open the Windows PowerShell and enter the following command:
services.msc
Navigate to and double-click on Microsoft Exchange IMAP4 Backend.
Click on the General tab.
In the Startup Type: dropdown, select Disabled.
Click the OK button.Open the Windows PowerShell and enter the following command:
Get-ItemProperty 'hklm:\system\currentcontrolset\services\MSExchangeIMAP4' | Select Start
Note: The hklm:\system\currentcontrolset\services\MSExchangeIMAP4 value must be in quotes.
If the value of Start is not set to 4, this is a finding.SRG-APP-000141<GroupDescription></GroupDescription>EX13-CA-000100Exchange POP3 service must be disabled.<VulnDiscussion>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 users to access other system features. Uninstalling or disabling the service will prevent the use of the POP3 protocol.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84377V-69755CCI-000381Open the Windows PowerShell and enter the following command:
services.msc
Navigate to and double-click on Microsoft Exchange POP3 Backend.
Click on the General tab.
In the Startup Type: dropdown, select Disabled.
Click the OK button.Open the Windows PowerShell and enter the following command:
Get-ItemProperty 'hklm:\system\currentcontrolset\services\MSExchangePOP3' | Select Start
Note: The hklm:\system\currentcontrolset\services\MSExchangePOP3 value must be in quotes.
If the value of Start is not set to 4, this is a finding.SRG-APP-000141<GroupDescription></GroupDescription>EX13-CA-000105Exchange must have the Public Folder virtual directory removed if not in use by the site.<VulnDiscussion>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 website, 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84379V-69757CCI-000381Open the Exchange Management Shell and enter the following command:
Remove-PublicFolder -Identity 'IdentityName' -Recurse:$True
Note: This command deletes the public folder Directory Folder and all its child public folders.Review the Email Domain Security Plan (EDSP).
Determine if public folders are being used.
Open the Exchange Management Shell and enter the following command:
Get-PublicFolder | Select Name, Identity
Note: The value returns a root directory and subdirectories.
If public folders are not in use and directories exist or are being used and are not documented in the EDSP, this is a finding.SRG-APP-000141<GroupDescription></GroupDescription>EX13-CA-000110Exchange must have the Microsoft Active Sync directory removed.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84381V-69759CCI-000381Open an Exchange Command Shell and enter the following command:
Remove-ActiveSyncVirtualDirectory <ServerName>\Microsoft-Server-ActiveSync -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 (the actual directory path) exists, this is a finding.SRG-APP-000378<GroupDescription></GroupDescription>EX13-CA-000115Exchange application directory must be protected from unauthorized access.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84383V-69761CCI-001812Update the EDSP.
Remove or modify the group or user access permissions.Review the Email Domain Security Plan (EDSP).
Determine 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 than those listed in the EDSP, this is a finding.
Note: The default installation directory is \Program Files\Microsoft\Exchange Server\V15.SRG-APP-000380<GroupDescription></GroupDescription>EX13-CA-000120Exchange software baseline copy must exist.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84385V-69763CCI-001813Update the EDSP.
Implement the email software baseline process.Review the Email Domain Security Plan (EDSP).
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.SRG-APP-000381<GroupDescription></GroupDescription>EX13-CA-000125Exchange software must be monitored for unauthorized changes.<VulnDiscussion>Monitoring software files for changes against a baseline on a regular basis may help detect the possible introduction of malicious code on a system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84387V-69765CCI-001814Update the EDSP.
Monitor the software files (e.g., *.exe, *.bat, *.com, *.cmd, and *.dll) on Exchange servers for unauthorized changes against a baseline on a weekly basis.
Use an approved DoD monitoring tool.Review the Email Domain Security Plan (EDSP).
Determine whether the site monitors system files (e.g., *.exe, *.bat, *.com, *.cmd, and *.dll) on servers for unauthorized changes against a baseline on a weekly basis.
If software files are not monitored for unauthorized changes on a weekly basis, this is a finding.
Note: A properly configured HBSS Policy Auditor File Integrity Monitor (FIM) module will meet the requirement for file integrity checking. The Asset module within HBSS does not meet this requirement.SRG-APP-000383<GroupDescription></GroupDescription>EX13-CA-000130Exchange services must be documented and unnecessary services must be removed or disabled.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84389V-69767CCI-001762Update the EDSP with the services required for the system to function.
Remove or disable any services that are not required.Review the Email Domain Security Plan (EDSP).
Note: 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.
Open a Windows PowerShell 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.
If the site has not documented the services required for its system(s), this is a finding.
If any undocumented or unnecessary services are running, this is a finding.SRG-APP-000391<GroupDescription></GroupDescription>EX13-CA-000135Exchange Outlook Anywhere (OA) clients must use NTLM authentication to access email.<VulnDiscussion>Identification and authentication provide the foundation for access control. Access to email services applications requires 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84391V-69769CCI-001953Open the Exchange Management Shell and enter the following commands:
For InternalClientAuthenticationMethod:
Set-OutlookAnywhere -Identity '<IdentityName'> -InternalClientAuthenticationMethod NTLM
For ExternalClientAuthenticationMethod:
Set-OutlookAnywhere -Identity '<IdentityName'> -ExternalClientAuthenticationMethod NTLMOpen the Exchange Management Shell and enter the following command:
Get-OutlookAnywhere | Select Name, Identity, InternalClientAuthenticationMethod, ExternalClientAuthenticationMethod
If the value of InternalClientAuthenticationMethod and the value of ExternalClientAuthenticationMethod is not set to NTLM, this is a finding.SRG-APP-000431<GroupDescription></GroupDescription>EX13-CA-000140Exchange software must be installed on a separate partition from the OS.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84393V-69771CCI-002530Update the EDSP.
Install Exchange on a dedicated application directory or partition separate than that of the OS.Review the Email Domain Security Plan (EDSP).
Determine where the directory Exchange is installed.
Open Windows Explorer.
Navigate to the directory or partition where Exchange is installed.
If Exchange resides on a directory or partition other than that of the OS and does not have other applications installed (unless approved by the ISSO), this is not a finding.SRG-APP-000435<GroupDescription></GroupDescription>EX13-CA-000145Exchange must provide redundancy.<VulnDiscussion>Load balancing is a way to manage which Exchange servers receive traffic. Load balancing helps distribute incoming client connections over a variety of endpoints. This ensures that no one endpoint takes on a disproportional share of the load. Load balancing provides failover redundancy in case one or more endpoints fails. By using load balancing, users continue to receive Exchange service in case of a computer failure. Load balancing also enables Exchange to handle more traffic than one server can process while offering a single host name for your clients.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84395V-69773CCI-002385Update the EDSP.
Configure two or more CAS servers for load balancing.Review the Email Domain Security Plan (EDSP).
Determine if the Exchange Servers are using redundancy.
Get-ClientAccessServer | Select Name, Site
If the value returned is not at least two CAS servers, this is a finding.SRG-APP-000439<GroupDescription></GroupDescription>EX13-CA-000150Exchange OWA must use https.<VulnDiscussion>Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84397V-69775CCI-002418Open the Exchange Management Shell and enter the following command:
Set-OWAVirtualDirectory -Identity '<IdentityName>\owa (Default Web Site)' -ExternalUrl 'https://URL' -InternalUrl 'https://URL'
Note: The <IdentityName>\owa (default web site) value must be in quotes.If the exchange server does not provide OWA services, this check is Not Applicable.
If the exchange server does not provide external OWA services, https does not need to be assigned to external URL, it may be blank.
Open the Exchange Management Shell and enter the following command:
Get-OWAVirtualDirectory | Select Name, Identity, ExternalUrl, InternalUrl
If the value returned is not both ExternalUrl and InternalUrl and these are not set to https://, this is a finding.
SRG-APP-000440<GroupDescription></GroupDescription>EX13-CA-000155Exchange OWA must have S/MIME Certificates enabled.<VulnDiscussion>Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered.
This requirement applies only to those applications that are either distributed or can allow access to data non-locally. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, applications need to leverage transmission protection mechanisms, such as TLS, SSL VPNs, or IPsec.
Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84399V-69777CCI-002421Open the Exchange Management Shell and enter the following command:
Set-OWAVirtualDirectory -Identity '<IdentityName>\owa (Default Web Site)' -SmimeEnabled $true
Note: The <ServerName>\owa (Default Web Site) value must be in quotes.Open the Exchange Management Shell and enter the following command:
Get-OWAVirtualDirectory | Select Name, Identity, SmimeEnabled
If the value returned is not set to True, this is a finding.SRG-APP-000456<GroupDescription></GroupDescription>EX13-CA-000160Exchange must have the most current, approved service pack installed.<VulnDiscussion>Failure to install the most current Exchange service pack leaves a system vulnerable to exploitation. Current service packs correct known security and system vulnerabilities.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84401V-69779CCI-002605Install the most current, approved service pack.Determine the most current, approved service pack.
Open the Exchange Management Shell and enter the following command:
Get-ExchangeServer | fl Name, AdminDisplayVersion
For each Name from the previous command, enter the following command:
Invoke-Command -ComputerName [Name] -ScriptBlock {Get-Command Exsetup.exe | ForEach-Object {$_.FileversionInfo}}
If the version displayed does not reflect the most current, approved service pack, this is a finding.SRG-APP-000516<GroupDescription></GroupDescription>EX13-CA-000165Exchange must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs.<VulnDiscussion>Configuring the application to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoD that reflects the most restrictive security posture consistent with operational requirements.
Configuration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the application, including the parameters required to satisfy other security control requirements.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Exchange 2013 Client Access ServerDISADPMS TargetMicrosoft Exchange 2013 Client Access Server5273SV-84403V-69781CCI-000366Configure web ports to be 80, 81 and 443, 444, as specified by PPSM standards.Open a Windows PowerShell Module and enter the following commands:
Get-Website | Select Name
Get-WebBinding -Name <'WebSiteName'> | Format-List
If the Web binding values returned are not on standard port 80 and 81 for HTTP connections or port 443 and 444 for HTTPS connections, this is a finding.
Repeat the process for each website.