Email Services Policy STIG

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: [email protected]
Details

Version / Release: V2R6

Published: 2015-08-07

Updated At: 2018-09-23 02:27:33

Actions

Download

Filter

Vuln Rule Version CCI Severity Title Description
SV-20630r3_rule EMG3-015 EMail MEDIUM Annual procedural reviews must be conducted at the site. 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.OtherDCAR-1
SV-20644r3_rule EMG3-045 EMail MEDIUM Email Configuration Management (CM) procedures must be implemented. 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.OtherDCPR-1
SV-20646r3_rule EMG0-056 EMail LOW Email Administrator role must be assigned and authorized by the ISSO. 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. OtherDCSD-1
SV-20650r3_rule EMG3-050 EMail MEDIUM Email Services must be documented in the EDSP (Email Domain Security Plan). 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.OtherDCSD-1
SV-20652r3_rule EMG3-028 EMail LOW Email software installation account usage must be logged. 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. OtherECPA-1
SV-20654r3_rule EMG3-037 EMail LOW Email audit trails must be reviewed daily. 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. OtherECAT-1
SV-20667r3_rule EMG0-075 EMail MEDIUM Email Administrator Groups must ensure least privilege. 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. OtherECPA-1
SV-20669r3_rule EMG3-079 EMail MEDIUM Automated audit reporting tools must be available. 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. OtherECRG-1
SV-20671r3_rule EMG3-071 EMail MEDIUM Email audit records must be retained for 1 year. 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. OtherECRR-1
SV-20673r3_rule EMG3-006 Email MEDIUM Audit logs must be documented and included in backups. 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. OtherECTB-1
SV-20675r3_rule EMG3-005 EMail LOW The email backup and recovery strategy must be documented and tested on an INFOCON compliant frequency. 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. OtherCODP-1
SV-20677r3_rule EMG3-009 EMail MEDIUM Email backup and recovery data must be protected. 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. OtherCOBR-1
SV-20679r3_rule EMG3-007 EMail MEDIUM Email backups must meet schedule and storage requirements. 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. OtherCODB-2
SV-20681r3_rule EMG3-010 EMail MEDIUM Email critical software copies must be stored off-site in a fire-rated container. 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. OtherCOSW-1
SV-20683r3_rule EMG0-090 EMail LOW Email acceptable use policy must be documented in the Email Domain Security Plan (EDSP). 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. OtherPRRB-1
SV-20685r3_rule EMG0-092 EMail LOW Email Acceptable Use Policy must contain required elements. 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.OtherPRRB-1
SV-21609r3_rule EMG3-106 Email HIGH Email domains must be protected by an Edge Server at the email transport path. 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.OtherEBBD-1
SV-21613r3_rule EMG3-108 EMail HIGH Email domains must be protected by transaction proxy at the client access path. 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.OtherEBBD-1
SV-43808r2_rule EMG0-093 EMail LOW Email acceptable use policy must be renewed annually. 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.Other
SV-46514r2_rule EMG3-110 Email MEDIUM Transaction proxies protecting email domains must interrupt and inspect web traffic on the client access path prior to its entry to the enclave. 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.OtherEBBD-1
SV-50955r4_rule EMG3-055 EMail MEDIUM Email client services for Commercial Mobile Devices must be documented in the Email Domain Security Plan (EDSP). 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.OtherDCFA-1