Free DISA STIG and SRG Library | Vaulted

Email Services Policy STIG

Version 2 Release 6
2015-10-23
U_Email_Services_Policy_V2R6_Manual-xccdf.xml
Email Services Policy STIG requirements must be evaluated on each system review, regardless of the email product or release level. These policies ensure conformance to DoD requirements that govern email services deployment and operations. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.

Vulnerabilities (21)

Annual procedural reviews must be conducted at the site.

Finding ID
EMG3-015 EMail
Rule ID
SV-20630r3_rule
Severity
Cat II
CCE
(None)
Group Title
EMG3-015 Procedural Review
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

A regular review of current email security policies and procedures is necessary to maintain the desired security posture of Email services. Policies and procedures should be measured against current Department of Defense (DoD) policy, Security Technical Implementation Guide (STIG) guidance, vendor-specific guidance and recommendations, and site-specific or other security policy.

Fix Text

Document review procedures in the EDSP. Include annual review schedules and plans to conduct them.

Check Content

Review the EDSP and implementation evidence showing that annual reviews of Email Services Information Assurance (IA) policy and procedures are done. If procedures are followed annually or more frequently, this is not a finding.

Responsibility

Other

IA Controls

DCAR-1

Email Configuration Management (CM) procedures must be implemented.

Finding ID
EMG3-045 EMail
Rule ID
SV-20644r3_rule
Severity
Cat II
CCE
(None)
Group Title
EMG3-045 Email Configuration Management
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

Uncontrolled, untested, or unmanaged changes can result in an unreliable security posture. All software libraries related to email services must be reviewed, considered, and the responsibility for CM assigned to ensure no libraries or configurations are left unaddressed. This is true even if CM responsibilities appear to cross organizational boundaries. Ensure patches, configurations, and upgrades are addressed. Process steps should have specific procedures and responsibilities assigned to individuals.

Fix Text

Document Configuration Management procedures in the EDSP. Implement the CM procedures as documented.

Check Content

Access the EDSP and confirm CM procedures and assignments are documented. Examine artifacts that show the processes have been implemented. If CM procedures are documented and implemented, this is not a finding.

Responsibility

Other

IA Controls

DCPR-1

Email Administrator role must be assigned and authorized by the ISSO.

Finding ID
EMG0-056 EMail
Rule ID
SV-20646r3_rule
Severity
Cat III
CCE
(None)
Group Title
EMG0-056 E-mail Administrator Role
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

Separation of roles supports operational security for application as well as human resources. Roles accompanied by elevated privileges, such as that of the Email Administrator, must be carefully regulated and monitored. All appointments to Information Assurance (IA) roles, such as Authorizing Officer (AO), System Security Manager (ISSM), and Information Systems Security Officer (ISSO) must be in writing, and include assigned duties and appointment criteria such as training, clearance and IT designation. The Email Administrator role is assigned and controlled by the ISSM. The ISSM role owns the responsibility to document responsibilities, privileges, training and scope for the Email Administrator role. It is with this definition that the ISSO is able to monitor assigned resources, ensuring that intended tasks are completed, and that elevated privileges are not used for purposes beyond their intended tasks.

Fix Text

Establish a procedure that ensures the Email Administrator role is defined and authorized (assigned) as documented by the ISSO.

Check Content

Review the documented procedures for approval of Email Administrator Privileges. Review implementation evidence for the procedures. If the Email Administrator role is documented and authorized by the ISSO, this is not a finding.

Responsibility

Other

IA Controls

DCSD-1

Email Services must be documented in the EDSP (Email Domain Security Plan).

Finding ID
EMG3-050 EMail
Rule ID
SV-20650r3_rule
Severity
Cat II
CCE
(None)
Group Title
EMG3-050 E-mail System Security Plan
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

A System Security Plan defines the security procedures and policies applicable to the Automated Information System (AIS). The Email Domain Security Plan (EDSP) defines the security settings and other protections for email systems. It may be implemented as a stand-alone document, or as a section within an umbrella System Security document, provided it contains the unique values engineered for that domain. Without a System Security Plan, unqualified personnel may be assigned responsibilities that they are incapable of meeting and email security may become prone to an inconsistent or incomplete implementation. Because email systems are sufficiently unique, an EDSP is recommended. For some email data categories, the product specific STIG provides required security settings. For other categories, values can vary among domains, depending on the implementation and system sizing requirements. For example, tuning variables such as log sizes, mailbox quota limits, and partner domain security are engineered for optimal security and performance, and should therefore be documented so reviews can assess whether they are set as intended. Assigned administrator names by role enable assessment of roles separation and least privilege permissions, as well as the ability to identify unauthorized access of processes or data. Back-up and recovery artifacts, SPAM reputation providers, and anti-virus vendors may differ by domain, and will require operational support information to be recorded, for example, license agreements, product copy locations, and storage requirements. NIST publication SP800-18, which is publicly available, is entitled “Guide for Developing Security Plans for Federal Information Systems”. It gives both guidelines and a template for security plan creation, and can serve as a base for development if one is needed. At this writing, the document can be found at the following link: http://csrc.nist.gov/publications/PubsSPs.html. Security controls applicable to email systems may not be tracked and followed if they are not identified in the EDSP. Omission of security control consideration could lead to an exploit of email system vulnerabilities or compromise of email information.

Fix Text

Establish an Email Domain Security Plan (EDSP) to document STIG identification, tuning values, administrator, and procedural IA programs and policies that govern email product servers.

Check Content

Access the Email Domain Security Plan (EDSP) for email systems. Review for current STIG identification, tuning values, administrator assignments, and procedural IA programs and policies that govern email product servers. If email services are not documented in an EDSP, this is a finding.

Responsibility

Other

IA Controls

DCSD-1

Email software installation account usage must be logged.

Finding ID
EMG3-028 EMail
Rule ID
SV-20652r3_rule
Severity
Cat III
CCE
(None)
Group Title
EMG3-028 Installation Account Usage Logged
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

Email Administrator or application owner accounts are granted more enhanced privileges than non-privileged users. It is especially important to grant access to privileged accounts to only those persons who are qualified and authorized to use them. Each use of the account should be logged to demonstrate this accountability.

Fix Text

Implement a logging procedure for use of the email software installation account. Document it in the EDSP.

Check Content

Access the EDSP to verify logging procedure for software installation account usage. Examine evidence that logging is done for use of the correct account for email software installations and upgrades. If email software installation account usage is logged, this is not a finding.

Responsibility

Other

IA Controls

ECPA-1

Email audit trails must be reviewed daily.

Finding ID
EMG3-037 EMail
Rule ID
SV-20654r3_rule
Severity
Cat III
CCE
(None)
Group Title
EMG3-037 Audit Trail Reviews
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

Access to email servers and software are logged to establish a history of actions taken in the system. Unauthorized access or use of the system could indicate an attempt to bypass established permissions. Reviewing the log history can lead to discovery of unauthorized access attempts. Reviewing the logs daily helps to ensure prompt attention is given to any suspicious activities discovered therein.

Fix Text

Document audit record review procedures in the EDSP. Implement audit record daily reviews as documented.

Check Content

Review the audit trail review procedures in the EDSP. Examine artifacts of log reviews (results) and review frequency. If Audit trail review procedures and evidence of review results exist, this is not a finding.

Responsibility

Other

IA Controls

ECAT-1

Email Administrator Groups must ensure least privilege.

Finding ID
EMG0-075 EMail
Rule ID
SV-20667r3_rule
Severity
Cat II
CCE
(None)
Group Title
EMG0-075 Email Admin Privileges Granted by Role
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

When an oversight responsibility is assigned to the same person performing the actions being overseen, the function of oversight is compromised. When the responsibility to manage or control one application or activity is assigned to one party yet another party is also assigned the privilege to the same actions, then neither party can logically be held responsible for those action. By separating responsibility and permissions by role, accountability can be as granular as needed. Role Based Access Control (RBAC) strategies for email administration include server role administration, permissions within server roles, and task based assignments. Further granularity is possible, and often makes sense to do, enabling each role to operate using the least possible permissions to perform the role.

Fix Text

Assign administrators to roles with appropriate permissions for Email Administrators. Configure each role so it is commensurate with least possible permission to perform the associated tasks.

Check Content

Review EDSP documentation that describes division of duties by role in the email domain administration assignments. If Email Administrator tasks are assigned to a defined role in the organization, and the role is operating at least privilege for the tasks, this is not a finding.

Responsibility

Other

IA Controls

ECPA-1

Automated audit reporting tools must be available.

Finding ID
EMG3-079 EMail
Rule ID
SV-20669r3_rule
Severity
Cat II
CCE
(None)
Group Title
EMG3-079 Automated Audit Reporting Tool
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

Monitors are automated “process watchers” that respond to performance changes, and can be useful in detecting outages and alerting administrators where attention is needed. Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. However, audit record collection may quickly overwhelm storage resources and an auditor’s ability to review it in a productive manner. Add to that, an audit trail that is not monitored for detection of suspicious activities provides little value. Regular or daily review of audit logs not only leads to the earliest possible notice of a compromise, but can also minimize the extent of the compromise. Automated Log Monitoring gives the additional boost to the monitoring process, in that noteworthy events are more immediately detected, provided they have been defined to the automated monitoring process. Log data can be mined for specific events, and upon detection, they can be analyzed to provide choices for alert methods, reports, trend analyses, attack scenario solutions.

Fix Text

Implement automated reporting tools for Email Server audit records. Document the specifics in the EDSP.

Check Content

Access the EDSP for description of automated audit trail review tool. Review automated tool usage artifacts or reports with audit trail result data. If automated tools are available for review and reporting on email server audit records, this is not a finding.

Responsibility

Other

IA Controls

ECRG-1

Email audit records must be retained for 1 year.

Finding ID
EMG3-071 EMail
Rule ID
SV-20671r3_rule
Severity
Cat II
CCE
(None)
Group Title
EMG3-071 Audit Data Retention
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

Audit data retention serves as a history that can aid in determining actions executed by users and administrators. Reasons for such research include both malicious actions that may have been perpetrated, as well as legal evidence that might be needed for proof of activity. Audit data records are required to be retained for a period of 1 year.

Fix Text

Create a process that details email audit record retention for required time period of 1 year. Document the process in the EDSP.

Check Content

Access EDSP documentation that describes data retention for audit records. Examine artifacts that demonstrate audit data retention for a period of 1 year. If email audit records are retained for required time period (1 year), this is not a finding.

Responsibility

Other

IA Controls

ECRR-1

Audit logs must be documented and included in backups.

Finding ID
EMG3-006 Email
Rule ID
SV-20673r3_rule
Severity
Cat II
CCE
(None)
Group Title
EMG3-006 Audit Logs Included in Backups
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Audit logs are essential to the investigation and prosecution of unauthorized access to email services software and data. Unless audit logs are available for review, the extent of data compromise may not be determined and the vulnerability exploited may not be discovered. Undiscovered vulnerabilities could lead to additional or prolonged compromise of the data. Audit records should be backed up not less than weekly on to a different system or media than the system being audited, to ensure preservation of audit history.

Fix Text

Include email audit records in backups and document the backup strategy in the EDSP.

Check Content

Access the EDSP documentation that describes inclusion of Exchange audit data with the weekly backups. Verify these directories are included in the backup strategy to preserve log history. If email audit records are included in backups, this is not a finding.

Responsibility

Other

IA Controls

ECTB-1

The email backup and recovery strategy must be documented and tested on an INFOCON compliant frequency.

Finding ID
EMG3-005 EMail
Rule ID
SV-20675r3_rule
Severity
Cat III
CCE
(None)
Group Title
EMG3-005 Backup and Recovery Strategy
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

A disaster recovery plan exists that provides for the smooth transfer of all mission or business essential functions to an alternate site for the duration of an event with little or no loss of operational continuity. The backup and recovery plan should include business recovery, system contingency, facility disaster recovery plans and plan acceptance.

Fix Text

Document the Email Backup and Recovery Strategy site Disaster Recovery Plan, with components, locations and directions, and test according to INFOCON frequency requirements.

Check Content

Access the disaster recovery documentation that describes the backup and recovery strategy for the email servers. The documentation should detail specifically what files and data stores are saved, including the frequency and schedules of the saves (as required by INFOCON levels), and recovery plans (should they become necessary). The recovery plan should also state a periodic recovery rehearsal to ensure the backup strategy is sound. If Email Backup and Recovery strategy is documented and periodically tested, this is not a finding.

Responsibility

Other

IA Controls

CODP-1

Email backup and recovery data must be protected.

Finding ID
EMG3-009 EMail
Rule ID
SV-20677r3_rule
Severity
Cat II
CCE
(None)
Group Title
EMG3-009 Restrict Access to Backup/ Recovery Data
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

All automated information systems are at risk of data loss due to disaster or compromise. Failure to provide adequate protection to the backup and recovery data exposes it to risk of potential theft or damage that may ultimately prevent a successful restoration, should the need become necessary. Adequate protection ensures that backup components can be used to provide transparent or easy recovery from losses or operations outages. Backup files need the same protections against unauthorized access when stored on backup media as when online and actively in use by the email system. Included in this category are physical media, online configuration file copies, and any user data that may need to be restored.

Fix Text

Document the authorized backup and recovery users and groups in the EDSP. Create access restrictions to the authorized staff for email services backup and restore data.

Check Content

Access EDSP documentation that describes protections for the Backup and Recovery data. If email backup and recovery data and processes are restricted to authorized users and groups, this is not a finding.

Responsibility

Other

IA Controls

COBR-1

Email backups must meet schedule and storage requirements.

Finding ID
EMG3-007 EMail
Rule ID
SV-20679r3_rule
Severity
Cat II
CCE
(None)
Group Title
EMG3-007 Backups Interval and Storage Location
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

Hardware failures or other (sometimes physical) disasters can cause data loss to active applications, and precipitate the need for expedient recovery. Ensuring backups are conducted on an agreed schedule creates a timely copy from which to recover active systems. Storing backup contents at a separate physical location protects the backup data from site-specific physical disasters. Backup schedule and storage location are determined in accordance with the MAC category and confidentiality level of the system.

Fix Text

Document the email backup strategy in the EDSP and perform backups on the schedule that is documented. Store the data as required.

Check Content

Access the EDSP for intended backup schedule and storage provisions. Review artifacts, such as job logs, file locations, access protections and procedures for offline files, and storage methods that demonstrate compliance to the intended schedule and log storage requirements. If email backups are conducted according to the EDSP, on schedule and are stored appropriately, this is not a finding.

Responsibility

Other

IA Controls

CODB-2

Email critical software copies must be stored off-site in a fire-rated container.

Finding ID
EMG3-010 EMail
Rule ID
SV-20681r3_rule
Severity
Cat II
CCE
(None)
Group Title
EMG3-010 Software Critical Copies
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

There is always potential that accidental loss can cause system loss and that restoration will be needed. In the event that the installation site is compromised, damaged or destroyed copies of critical software media may be needed to recover the systems and become operational. Copies of the operating system (OS) and other critical software, such as email services applications must be created and stored off-site in a fire-rated container. If a site experiences loss or compromise of the installed software libraries, available copies can reduce the risk and shorten the time period for a successful email services recovery.

Fix Text

Create email software copies for use in recovering systems, and store them off-site and in fire-rated containers. Document the off-site storage details in the EDSP.

Check Content

Access the EDSP and review the email application software offline storage plan. Examine artifacts showing that copies exist and are stored off-site in fire-rated containers. If an email software copy exists and is stored off-site in a fire-rated container, this is not a finding.

Responsibility

Other

IA Controls

COSW-1

Email acceptable use policy must be documented in the Email Domain Security Plan (EDSP).

Finding ID
EMG0-090 EMail
Rule ID
SV-20683r3_rule
Severity
Cat III
CCE
(None)
Group Title
EMG0-090 Email Acceptable Use Policy
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

Email is only as secure as the recipient, which is ultimately person who is receiving messages. Also to consider, the surest way to prevent SPAM and other malware from entering the email message transport path is by using secure IA measures at the point of origin. Here again, this is ultimately a person, who is sending messages. An Email Acceptable Use Policy is a set of rules that describe expected user behavior with regard to email messages. Formal creation and use of an Email Acceptable Use policy protects both organization and users by declaring boundaries, operational processes, and user training for such tasks as Help Desk procedures, legal considerations and email based threats that may be encountered. The Email Acceptable Use Policy should be distributed to and signed by each email user, as a requirement for obtaining an email account.

Fix Text

Implement an Email Acceptable Use Policy that is documented in the EDSP and that requires a signature by each user.

Check Content

Access the EDSP documentation that describes the Email Acceptable Use Policy that is followed at the site. If the Email Acceptable Use Policy is documented in the EDSP, this is not a finding.

Responsibility

Other

IA Controls

PRRB-1

Email Acceptable Use Policy must contain required elements.

Finding ID
EMG0-092 EMail
Rule ID
SV-20685r3_rule
Severity
Cat III
CCE
(None)
Group Title
EMG0-092 Acceptable Use Policy Required Elements
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

Email is only as secure as the recipient, which is ultimately the person who is receiving messages. Also to consider, the surest way to prevent SPAM and other malware from entering the email message transport path is by using secure IA measures at the point of origin. Here again, this is ultimately a person, who is sending messages. Email Acceptable Use Policy statements must include user education and expectations, as well as penalties and legal ramifications surrounding noncompliance. Examples of elements may include such items as classification and sensitivity labeling, undesirable message recognition such as for SPAM, Phishing, or bogus certificates. There should also be process information, such as the Email Acceptable Use Policy location, review frequency, email services offered (Outlook, web based email), and email services forbidden (such as access via alternate email products). Users may also need to know other useful information, such as mailbox size quotas, attachment limitations, and procedural steps for making help desk requests. Email tools, rules, and alerts descriptions plus official formats of email based announcements that may originate from the Email Administration team should be documented to prevent users being fooled or compromised by social engineering exploits. It may also be advantageous to have an ‘official’ method of communicating, enabling users to then recognize non-authentic requests and report them.

Fix Text

Revise or supplement the Email Acceptable Use Policy so it contains the required elements. Document the email acceptable use policy elements in the EDSP.

Check Content

Access the EDSP documentation that describes the Email Acceptable Use Policy elements. Included should be elements such as the following: User education User expectations Penalties for non-conformance Legal ramifications Classification labeling SPAM and Phishing recognition Bogus certificates Review frequency Services offered or not offered Message and attachment size quotas Help desk and other support information If the Email Acceptable Use Policy contains required elements, this is not a finding.

Responsibility

Other

IA Controls

PRRB-1

Email domains must be protected by an Edge Server at the email transport path.

Finding ID
EMG3-106 Email
Rule ID
SV-21609r3_rule
Severity
Cat I
CCE
(None)
Group Title
EMG3-106 Edge Transport Server Required
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

Separation of roles supports operational security for application and protocol services. Since 2006, Microsoft best practices had taken the direction of creating operational “roles” for servers within email services. The Edge Transport server role (also called an Email Secure Gateway) was created to focus authentication and sanitization tasks in one server, to provide Internet facing protection for internal email servers. In the email services infrastructure, it has become imperative that inbound messages be examined prior to their being forwarded into the enclave, primarily due to the amount of SPAM and malware contained in the message stream. Similarly, outbound messages must be examined, so an organization might locate, or perhaps intercept, messages with potential data spillage of sensitive or important information. The Edge Transport email server role, which could be implemented using a number of comparable products, is designed to perform protective measures for both inbound and outbound messages. Its charter is to face the Internet, and to scrutinize all SMTP traffic, to determine whether to grant continued passage for messages to their destination. Inbound email sanitization steps include (but are not limited to) processes, such as sender authentication and evaluation, content scoring (SPAM, spoofing, and phishing detection), antivirus sanitization and quarantine services, and results reporting. Outbound messages are typically examined for SPAM and malware origination. Failure to implement an Email Edge Transport server role may increase risk of compromise by allowing undesirable inbound messages could to reach the internal servers and networks. Failure to examine outbound traffic may increase risk of domain blacklisting if SPAM or malware is traced back to the source domain. Attempting to sanitize email after it arrives inside the domain is not an acceptable or effective security measure. By using an Edge Transport Server (Email Secure Gateway), any SMTP-specific attack vectors are more optimally secured.

Fix Text

Install and configure an Edge Transport Server role in the email infrastructure, configured to perform specified sanitization processes. Ensure all inbound and outbound SMTP traffic passes through this server role. Document the Edge Transport Server specifics in the EDSP.

Check Content

Access EDSP documentation that describes the infrastructure for email services. Verify an Edge Transport Server (or Email Secure Gateway) is installed and active on the network. Ensure all inbound and outbound email messages pass through and are examined as required. If the email domain employs an Edge Transport Server Role that performs the required protection, this is not a finding.

Responsibility

Other

IA Controls

EBBD-1

Email domains must be protected by transaction proxy at the client access path.

Finding ID
EMG3-108 EMail
Rule ID
SV-21613r3_rule
Severity
Cat I
CCE
(None)
Group Title
EMG3-108 Web Application Client Access
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

Separation of email server roles supports operational security for application and protocol services. The HTTP path to web sites is a proven convenience in requiring only a browser to access them, but is simultaneously a well known attack vector for people and applications that would attempt to gain unwelcome admittance to internal networks. Web-based email applications, such as Exchange Outlook Web App (OWA), are classified as 'internal' or 'private' web servers. As with all web servers in the DoD, Internet-sourced email requests must be encrypted, authenticated, and proxied prior to permitting the transaction to access internally hosted email data. For email domains using Microsoft Exchange Client Access (CA) servers, Microsoft recommends and supports that all email CA servers reside inside enclaves (rather than a DMZ location) where firewalls would separate them from the other email servers. DoD PKI approved mechanisms for authentication are required for email access in the DoD. Multiple products exist that could meet the intent of this requirement, such as combination firewall and proxy servers, multi-tasking load balancers or shared authentication services for Internet-sourced traffic.

Fix Text

Install a web security solution requiring DoD approved multi-factor authentication tokens, with architecture placing the CA server inside the enclave, and the transaction proxy residing in the DMZ. Document the solution in the EDSP.

Check Content

For sites not using Internet-sourced email web services, this check is N/A. Access the EDSP documentation that describes web email infrastructure. Confirm the architecture places the CA server inside the enclave and a transaction proxy residing in the DMZ. Verify DoD approved multi-factor authentication tokens (e.g., Common Access Card (CAC) for unclassified systems) are required at the transaction proxy. If the email domain employs the required architecture, this is not a finding.

Responsibility

Other

IA Controls

EBBD-1

Email acceptable use policy must be renewed annually.

Finding ID
EMG0-093 EMail
Rule ID
SV-43808r2_rule
Severity
Cat III
CCE
(None)
Group Title
EMG0-093 Email Acceptable Use Policy
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

An Email Acceptable Use Policy is a set of rules that describe IA operation and expected user behavior with regard to email services. Formal creation and use of an Email Acceptable Use policy protects both organization and users by declaring boundaries, operational processes, and user training surrounding helpdesk procedures, legal constraints and email based threats that may be encountered. The Email Acceptable Use Policy must be annually updated, then subject to renewal by users. Requiring signed acknowledgement of the policy would constitute continued access to the email system.

Fix Text

Implement a review and renewal process for the Email Acceptable Use Policy that requires annual renewal and signature acknowledgement. Document the process in the EDSP.

Check Content

Access the EDSP documentation that describes the Email Acceptable Use Policy. Verify there is a stated requirement for users to renew annually. If the Email Acceptable Use Policy requires annual user renewal with signature acknowledgement, this is not a finding.

Responsibility

Other

Transaction proxies protecting email domains must interrupt and inspect web traffic on the client access path prior to its entry to the enclave.

Finding ID
EMG3-110 Email
Rule ID
SV-46514r2_rule
Severity
Cat II
CCE
(None)
Group Title
EMG3-110 Web Application Client Access
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

Separation of email server roles supports operational security for application and protocol services. The HTTP path to web sites is a proven convenience in requiring only a browser to access them, but is simultaneously a well known attack vector for people and applications that would attempt to gain unwelcome admittance to internal networks. Web-based email applications, such as Exchange Outlook Web App (OWA), are classified as 'internal' or 'private' web servers. As with all web servers in the DoD, Internet-sourced email requests must be encrypted, authenticated, and proxied prior to permitting the transaction to access internally hosted email data. DoD PKI approved mechanisms for authentication are required for email access in the DoD. Internet-sourced web traffic using TLS encryption is also required, however must have the encryption offloaded, and the transaction interrupted before allowing it into the enclave without some inspection. Multiple products exist that could meet the intent of this requirement, such as combination firewall and proxy servers, multi-tasking load balancers or shared authentication services for Internet-sourced traffic.

Fix Text

Install a web security solution using a transaction proxy that offloads and inspects the TLS encryption and continues the transaction in a new security context on behalf of the user for Internet-sourced web mail transactions. Document the solution in the EDSP.

Check Content

For sites not using Internet-sourced email web services, this check is N/A. Access the EDSP documentation that describes web email infrastructure. Verify transaction proxies offload and inspect the encryption, and initiate a new security context for the transaction. If the transaction servers perform the required security steps before allowing the transaction to proceed into the enclave, this is not a finding.

Responsibility

Other

IA Controls

EBBD-1

Email client services for Commercial Mobile Devices must be documented in the Email Domain Security Plan (EDSP).

Finding ID
EMG3-055 EMail
Rule ID
SV-50955r4_rule
Severity
Cat II
CCE
(None)
Group Title
EMG3-055 EMail Security for CMD
CCI
(None)
Target Key
(None)
Documentable
No
Discussion

Commercial Mobile Devices (CMDs) introduce additional IA concerns to email systems because of the additional guidance pertaining specifically to CMDs. The Department of Defense (DoD) Chief Information Officer (CIO) put forth specific guidance concerning CMD implementation on 6 Apr 2011. The memo states, "Email redirection from the email server (e.g., Exchange Server) to the device shall be controlled via centrally managed server." Therefore the native clients used on CMD cannot access the email system directly but instead must be managed by mobile email management (MEM) services. The Exchange configuration relies on Exchange ActiveSync (EAS) as the client communication protocol. Natively, EAS is an inbound initiated, bidirectional protocol, which is problematic for DoD networks. Acceptable implementations avoid inbound initiated connections and use external secure network operation centers (NOC) in secure tunnels from the management servers residing in the DoD to the NOC and from the NOC to the CMD. For email systems that do not deliver email directly to the device but rather use browser access to DoD email systems, this requirement would not apply but client-access path guidance does (EMG3-108 Email). The EDSP must include the functional architecture of the integration of the email system, required MEM, NOC if used, and CMDs. Protocols communicating with the CMD or NOC must be secured to protect sensitive DoD data from being compromised using accepted FIPS 140-2 approved modules.

Fix Text

Email client services to Commercial Mobile Devices, including the required components of the architecture, must be documented in the Email Domain Security Plan (EDSP).

Check Content

For systems not providing Internet-sourced email client services to CMDs, this check is N/A. Access the Email Domain Security Plan (EDSP) for email systems. Review for functional architecture of the email system for all required components, including the MEM, NOC, CMDs, etc., when providing service to CMDs. Confirm the design requires secure communication from the email system to the MEM. Verify the MEM, NOC, and CMDs are approved for use in DoD. If the email domain employs the required architecture and is documented in the EDSP, this is not a finding. If the architecture uses the EAS protocol to Commercial Mobile Devices (CMD) without connecting through external secure NOCs and encapsulating in a secure tunnel from the management servers residing in the DoD to the NOC and from the NOC to the CMD, this is a finding. If the use of EAS is not documented in the EDSP, this is a finding.

Responsibility

Other

IA Controls

DCFA-1