Email Services Policy

U_Exchange_2003_Policy_V1R4_Manual-xccdf.xml

Email Services Policy
Details

Version / Release: V1R4

Published:

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

Download

Filter

Findings
Severity Open Not Reviewed Not Applicable Not a Finding
Overall 0 0 0 0
Low 0 0 0 0
Medium 0 0 0 0
High 0 0 0 0
Drop CKL or SCAP (XCCDF) results here.
    Vuln Rule Version CCI Severity Title Description Status Finding Details Comments
    SV-20630r1_rule EMG3-015 EMail MEDIUM Annual procedural reviews are not conducted at the site. A regular review of current E-mail security policies and procedures is necessary to maintain the desired security posture of E-mail 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. Information Assurance OfficerDCAR-1
    SV-20632r1_rule EMG3-020 Exch MEDIUM Exchange with Outlook Web Access is not deployed as Front-end/Back-end Architecture. Microsoft® Exchange supports a server architecture that distributes server tasks among front-end and back-end servers. Front-end/back-end architecture provides for logical separation of protocols, user traffic, and the subsequent ability to secure each of these aspects of E-Mail technology using discrete security techniques that are appropriate for each. In this architecture, a front-end server accepts requests from clients and proxies them to the appropriate back-end server for processing and offloads the SSL encryption The term "back-end server" refers to all servers in an organization that are not front-end servers after a front-end server is introduced into the organization. In a multi-server environment, one or more back-end servers may be cast in the role of ‘Bridgehead’ server. Bridgehead servers are used in large domains that deploy mailbox servers in multiple locations, sometimes spanning wide area network (WAN) (or other slow) connections, or require careful bandwidth management for other reasons. Bridgehead servers work in pairs, one at each side of a location, to manage replication and distribution tasks. The primary advantage of the front-end/back-end server architecture is the ability to expose a single, consistent namespace to end users, for example, https://mail.mycompany.com. Without a front-end server, users must know the name of the server that stores their mailbox. Information Assurance OfficerDCBP-1
    SV-20644r1_rule EMG3-045 EMail MEDIUM E-Mail Configuration Management (CM) procedures are not implemented. Uncontrolled, untested, or unmanaged changes can result in an unreliable security posture. All software libraries related to E-mail services must be reviewed, considered, and the responsibility for Configuration Management (CM) assigned to ensure that no libraries or configurations are left unaddressed. This is true even if CM responsibilities appear to cross organizational boundaries. Information Assurance OfficerDCPR-1
    SV-20646r1_rule EMG0-056 EMail LOW The E-mail Administrator role is not assigned and authorized by the IAO. Separation of roles supports operational security for application as well as human resources. Roles accompanied by elevated privileges, such as that of the E-Mail Administrator, must be carefully regulated and monitored. All appointments to Information Assurance (IA) roles, such as Designated Approving Authority (DAA), Information Assurance Manager (IAM), and Information Assurance Officer (IAO) are in writing, and include assigned duties and appointment criteria such as training, clearance and IT designation. The E-mail Administrator role is assigned and controlled by the IAM. The IAM role owns the responsibility to document responsibilities, privileges, training and scope for the E-mail Administrator role. It is with this definition that the IAO 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. Information Assurance OfficerDCSD-1
    SV-20650r1_rule EMG3-050 EMail MEDIUM E-mail Services are not documented in System Security Plan. A System Security Plan defines the security procedures and policies applicable to the Automated Information System (AIS). It includes definition of responsibilities and qualifications for those responsible for administering the security of the AIS. For E-mail services, this includes specifically the E-mail Administrator in addition to the standard System Administration (SA) and Information Assurance Officer (IAO) roles. Without a System Security Plan, unqualified personnel may be assigned responsibilities that they are incapable of meeting and E-mail security is prone to an inconsistent or incomplete implementation. Security controls applicable to E-mail services may not be documented, tracked, or followed if not identified in the System Security Plan. Any omission of security control consideration could lead to an exploit of E-mail services vulnerabilities. Information Assurance OfficerDCSD-1
    SV-20652r1_rule EMG3-028 EMail LOW E-mail software installation account usage is not logged. E-mail 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. Information Assurance OfficerECPA-1
    SV-20654r1_rule EMG3-037 EMail LOW E-mail audit trails are not reviewed daily. Access to E-mail services and software is 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 that prompt attention is given to any suspicious activities discovered therein. Information Assurance OfficerECAT-1
    SV-20667r1_rule EMG0-075 EMail MEDIUM E-mail Administrator Groups do not 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 is achieved. Roles, once defined, can then be used as “groups” with permissions granted, in the AD domain. Microsoft names three roles for E-mail administration as a starting point (appearing in diminishing order): E-mail Full Administrator, E-mail Administrator, and E-Mail View-Only Administrator. Because Exchange 2003 is an application, all three roles are subordinate to OS Administrator roles. E-mail Full Administrator has the ability to install the application and configure the access and operational parameters, perform user and configuration setup, and view all aspects of E-mail configuration and performance. The Exchange Installation account would be a good candidate for this group. E-mail Administrator is able to perform user and configuration setup, and view all aspects of e-mail configuration and performance. Operational tasks and administrators would be good candidates for this role. E-mail View-Only Administrator is able to view all aspects of E-mail configuration and performance. Persons or utilities that monitor throughput, connector, and queue performance would be a good candidate for this group. Further granularity is possible, and often makes sense to do, enabling each role to operate using the least possible permissions to perform the role. Information Assurance OfficerECPA-1
    SV-20669r1_rule EMG3-079 EMail MEDIUM Automated audit reporting tools are not 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 and summarized by such tools to provide choices for alert methods, reports, trend analyses, attack scenario solutions. Information Assurance OfficerECRG-1
    SV-20671r1_rule EMG3-071 EMail MEDIUM E-mail audit records are not 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. Information Assurance OfficerECRR-1
    SV-20673r1_rule EMG3-006 E-mail MEDIUM Audit logs are not 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 Exchange 2003 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. Information Assurance OfficerECTB-1
    SV-20675r1_rule EMG3-005 EMail LOW The E-mail backup and recovery strategy is not documented or is not tested on an INFOCON compliant frequency. A disaster 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. Information Assurance OfficerCODP-1
    SV-20677r1_rule EMG3-009 EMail MEDIUM E-mail backup and recovery data is not 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 E-mail system. Included in this category are physical media, online configuration file copies, and any user data that will need to be restored. Information Assurance OfficerCOBR-1
    SV-20679r1_rule EMG3-007 EMail MEDIUM E-mail backups do not meet schedule or storage requirements. Hardware failures or other (sometimes physical) disasters can cause data loss to active applications, and the need for expedient recovery. Ensuring that 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. Information Assurance OfficerCODB-2
    SV-20681r1_rule EMG3-010 EMail MEDIUM E-mail critical software copies are not stored offsite 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 E-mail 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 E-mail services recovery. Information Assurance OfficerCOSW-1
    SV-20683r1_rule EMG0-090 EMail LOW E-mail acceptable use policy is not documented in the System Security Plan or does not require annual user review. E-mail is only as secure as the recipient, which can be either a server or a human (client). Add to that, the surest way to prevent SPAM and other malware from entering the E-mail message transfer path by using secure IA measures at the point of origin. For inbound messages, that point is at the perimeter, where the Edge Transport Role server performs authentication and sanitization measures on the messages. For outbound messages, that point is the human user, who (with assistance from a client application such as Outlook) must use care with actions taken when reading or creating E-mail messages. An E-mail Acceptable Use Policy is a set of rules that describe IA operation and expected user behavior with regard to E-mail services. Formal creation and use of an E-mail Acceptable Use policy protects both organization and users by declaring boundaries, operational processes, and user training surrounding HelpDesk procedures, legal constraints and E-mail based threats that may be encountered. The Acceptable Use Policy should be distributed to each new E-mail user, as a requirement for obtaining an E-mail account. The policy must also be annually updated, then subject to repeat review by users. Requiring signed acknowledgement of the rules should be a condition of continued access to the E-mail system. Information Assurance OfficerPRRB-1
    SV-20685r1_rule EMG0-092 EMail LOW E-mail Acceptable Use Policy does not contain required elements. E-mail is only as secure as the recipient, which can be either a server or a human (client). Add to that, the surest way to prevent SPAM and other malware from entering the E-mail message transfer path by using secure IA measures at the point of origin. For inbound messages, that point is at the perimeter, where the Edge Transport Role server performs authentication and sanitization measures on the messages. For outbound messages, that point is the human user, who (with assistance from a client application such as Outlook) must use care with actions taken when reading or creating E-mail messages. E-mail Acceptable Use Policy statements must include, among other items, user education and expectations, as well as penalties and legal ramifications surrounding noncompliance. User education elements should include such elements as: Classification and Sensitivity Labeling; A user’s electronic signature is the stamp of authenticity that enables information to be trusted. SPAM and PHISHING recognition; The ability to recognize non-authentic messages is key to protecting the organization against user manipulation that results from false information. Acceptable and non-acceptable text content; Users should also be acquainted with legal responsibilities surrounding harassment, soliciting, or distribution of inappropriate content as outlined by the organization. Security Constraints; Forbidden attachment types and security reasons for each. “Personal business” usage policy; Message content guidelines, attention to CC: lists, information sensitivity, chain letters, and spillage prevention. Request help; how to report if you are a witnesses or victim of misuse, phone numbers for support, troubleshooting, how to request an account for a new user. User expectations elements should include such elements as: Acceptable Use Policy location; for ongoing reference if needed. E-mail types of services offered; for example, Outlook, OWA and Public Folders included, access from POP3 clients is not allowed, etc. E-mail tools, rules, and alerts; descriptions and official formats of E-mail based announcements that may originate from the E-mail Administration team (to prevent users being SPAMMED or compromised by social engineering exploits). Because there are known social engineering techniques that SPAM users in the form of ‘Administrator Requests’ to end users, it may be advantageous to have an ‘official’ method of communicating, enabling users to then recognize non-authentic requests and report them. Legal issues; what constitutes harassment, threats, or inappropriate language. E-mail Administration processes; how to add, remove, and manage the e-mail user population, report problems or abuse, compromise. Constraints; Mailbox, message, and attachment size limitations. Policies; Data retention, type of servers, server uptime and maintenance schedules Penalties for violating E-mail Acceptable Use Policy Schedule for Periodic review, format for signoff Information Assurance OfficerPRRB-1
    SV-21609r1_rule EMG3-106 Exch2K3 HIGH E-mail services and servers are not protected by routing all SMTP traffic through an Edge Transport Server. 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 E-mail services. The Edge Transport server role (also called the E-mail Secure Gateway) was created to focus authentication and sanitization tasks in one server, to provide Internet facing protection for internal E-mail servers. Microsoft Exchange 2003 does not offer the Edge Transport server role. In the E-mail 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 that an organization might locate, or perhaps intercept, messages with potential data spillage of sensitive or important information. The Edge Transport E-mail server role, which includes ‘appliances’ such as “Iron Port”, “Iron Mail” and the like, is designed to group 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 to its destination Inbound E-mail sanitization steps include (but are not limited to) the following: • Sender Authentication • Sender Reputation Evaluation (White-listing and Black-listing) • SPAM content scoring • Virus and Malware removal • Web Link URL evaluation • Absent sender information • SPOOFED domain sources (such as the local domain appearing as inbound mail) • 0-Day attack detection • Archiving or Quarantining trapped messages • Alerting and Reporting when configured items are identified. Failure to implement an E-mail Secure Gateway increases risk that raw messages will reach the internal servers and networks, thereby increasing risk of their compromise. Even though Exchange 2003 E-mail Services are able to perform many of these evaluations, their Windows domain membership requires that they be internal to the enclave rather than expose the domain interaction to the Public Internet. Attempting to sanitize E-mail after it arrives inside the domain is not longer an acceptable or effective security measure. By using an Edge Transport Server (E-mail Secure Gateway), any SMPT-specific attack vectors are more optimally secured. Information Assurance OfficerEBBD-1
    SV-21613r1_rule EMG3-108 Exch2K3 HIGH E-mail web services are not protected by having an application proxy server outside the enclave. Separation of 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. Web-based applications such as Exchange 2003 Outlook Web Access (OWA) reside on Windows domain Member Servers, and are classified as ‘internal’, or private web servers. In order for the DoD to grant web-based access to E-mail services, careful authentication, encryption, and other precautions are needed. Authentication, via Common Access Card, is not a feature of Exchange 2003. Add to that, it is risky to admit Internet-sourced web traffic, even with SSL or TLS encryption, into the enclave without some inspection, such as for suspicious URL formation. Also, ensuring that only the desired protocols are allowed reduces risk as well as excess traffic. An application proxy server, such as Microsoft Internet Security and Acceleration (ISA) server is an effective firewall and proxy that offers all of these features when properly equipped and configured. Failure to require CAC authentication of each user, a new security context for the transaction, and FIPS 140-2 compliant encryption for the Internet leg of the transaction, all increase risk of compromise to the OWA web server. Information Assurance OfficerEBBD-1