Email Services Policy STIG

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

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

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

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

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

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

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

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

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

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

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

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