DCPDS DRAFT Atch 9 - Mandatory IA Procedures and Processes.doc

Attachment 9 Mandatory IA Procedures & Processes

Primary Information Assurance Policy Guidance

Addendum: Mandatory Information Assurance Procedures and Processes for Contractors Supporting DoD MAC II Sensitive Systems Section I. General

This addendum provides guidance to the Contractor regarding mandatory compliance with DoD Defense Information Assurance Certification and Accreditation Process (DIACAP) requirements and with the ongoing operational Information Assurance of computer systems processing and storing DoD information. The DIACAP for MAC II Sensitive systems consists of 105 specific controls applied within an clearly defined enclave. The intent of these controls is to ensure that confidentiality, availability, and integrity of the information. The contractor is strongly encourage to obtain copies of the DoD Information Assurance guidance and to read and understand its requirements in detail.

This addendum lists the specific responsibilities of the Contractor to meet the DIACAP requirements of the Department of Defense (DoD). Contractors should be aware that nothing in this addendum supersedes Federal law or DoD guidance. The Contractor is expected to comply with and support ongoing reporting requirements as defined by the Federal Information Security Management Act (FISMA) and with all DoD regulations/guidance not specifically covered by this section. Additionally, Congress, and the executive branch issue new guidance on an ongoing basis to deal with developing requirements and conditions in the Information Assurance (IA) field. The Contractor shall be expected to comply with all applicable Federal IA requirements.

This document presumes that the Contractor will be processing and storing DoD information in their security enclave. It is not possible in one document to cover specifics of every single possible situation. For each specific instantiation these requirements will vary depending on environmental factors. There will almost certainly be some controls that are not appropriate and they will be noted in the DIACAP scorecard for the system as “Not Applicable”. There may also be some controls that require additional protections based on environmental, data protection, or other unique requirements. The Contractor is expected to note and point out specific controls or issues with which it perceives there will be a problem with compliance. The government will make a reasonable effort to work with the Contractor to find solutions to issues. Contractors should note that final decisions on compliance, not applicability, or risk acceptance are the sole responsibility and determination of the government system’s Designated Approving Authority (DAA).

Section II: Contractor Responsibilities.

The Contractor shall comply with:

· Joint Task Force – Global Network Operations (USCYBERCOM) Communications Tasking Orders (CTOs) and Warning Orders.

· DoDI 8551.1, Ports, Protocols, and Services Management (PPSM), dated August 13, 2004. Ports, protocols, and services (PPS) that are visible to DoD-managed network components shall undergo a vulnerability assessment; be assigned to an assurance category; be appropriately registered; be regulated based on their potential to cause damage to DoD operations and interests if used maliciously; and be limited to only the PPS required to conduct official business or required to address Quality of Life issues authorized by competent authority.

· DoDI 8552.01, Use of Mobile Code Technologies in DoD Information Systems, dated October 23, 2006. Each mobile code technology to be used in DoD information systems shall undergo a risk assessment, be assigned to a risk category, and have its use regulated based on its potential to cause damage to DoD operations and interests if used maliciously.

· Assistant Secretary of Defense for Networks and Information Integration (ASD (NII)) Memorandum, Use of Peer-to-Peer File-Sharing Applications across DoD, dated November 23, 2004. Peer-to-Peer (P2P) file-sharing applications require approval by the Civilian Personnel Management Service (CPMS) DAA. The requirements, security architecture, configuration management process, and training program will be part of the DAA review.

Source: https://powhatan.iiie.disa.mil//policy-guidance/novp2p-memo.pdf

· Memorandum, Open Source Software (OSS) in the Department of Defense, dated May 28, 2003, by notifying CPMS of all open source software used to provide services connected to the NIPRNET. The contractor shall provide clear documentation of its necessity and sufficient market research to demonstrate that no viable alternative exists. The government will make the final determination whether, or when, to allow the use of Open Source Software on this contract.

· Office of the Secretary of Defense (OSD) Memorandum, Safeguarding Against and Responding to the Breach of Personally Identifiable Information, dated September 25, 2006.

· DoD Memorandum, Privacy Impact Assessment Guidance, dated October 28, 2005. This will be conducted before developing or procuring IT systems or projects that collect, maintain, or disseminate information in identifiable form from or about members of the public Source: http://www.dla.mil/public_info/efoia/DODPIAGuidance.pdf

· OMB memorandum M-08-21, « FY 2008 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management” requires that, where appropriate to the environment the use of common security configurations (Federal Desktop Core Configurations) is required. Security configurations are available from the National Institute of Standards and Technology’s website at http://checklists.nist.gov.

Contractors will provide information to support FISMA privacy reporting requirements on a quarterly basis as scheduled by the Information Assurance Manager (IAM).

Contractors must complete Privacy Act training as a prerequisite before being permitted to access DoD systems.

Contractors will report Personal Identifying Information (PII) breaches based on the level of risk as determined in the five factors in the policy. The five risk determining factor are: the nature of the data elements breached, the number of individuals affected, the likelihood the information is accessible and useable, the likelihood the breach may lead to harm, and the ability of the government to mitigate the risk of harm. The current guidance can be found at:

Source: http://www.defenselink.mil/privacy/pdfdocs/Safeguarding_PII.pdf http://www.defenselink.mil/privacy/DoD_Guidance_on_%20Protecting_Personally_Identifiable_Information_Aug_26_2006.pdf Section III. Specific IA Control Requirements

Department of Defense Instruction 8510.01, Section 6.9.2.4 states: “Security responsibilities of the service provider down to the control level are made explicit in the contract, along with any other performance and service-level parameters by which the Department of Defense shall measure the IA profile of the outsourced IT-based process for the purpose of C&A.” Accordingly, the remainder of this addendum lists specific IA actions the contractor is expected to perform. Contractors are strongly encouraged to obtain a copy of DoDI 8510.01 “DoD Information Assurance Certification and Accreditation Program” and DoDI 8500.02 “Information Assurance Implementation” to cross-reference and better understand specifically what the government will be expecting in terms of compliance with this addendum.

For Software as a Service (SaaS) environments, where providers do not own the facility hosting the DoD data, a copy of the most recent Statement of Auditing Standard 70 Type II report may be acceptable if the specific IA Control equivalents were evaluated. To use this alternative, the Contractor shall provide a copy of the SAS 70 report to the CPMS IAM. The Contractor must also arrange for a site security visit for verification of implementation by the IAM. Additionally, the government acknowledges that for SaaS environments some IA controls may not be possible to achieve and will require an acceptance of risk. The decision to accept a risk is a government decision.

Several of the DIACAP IA controls require a physical verification or inspection by the IAM and Certifying Authority (CA). The Contractor shall allow access to facilities to support this requirement.

COAS: The Contractor shall develop a Business Impact Analysis (BIA) or similar document that describes the impact of an incident on system resources and customers. The BIA shall identify and rank major information systems and mission-critical applications according to priority.

Additionally, the Contractor shall develop a Continuity Of Operations Plan (COOP) that is exercised at least annually, and at a minimum:

1) Designates an alternate site that has the capability to fully restore mission or business essential functions.

2) Identifies and prioritizes system functions by data type, criticality, or other operational criteria.

3) Identifies system resources required for duplication of operations, including hardware, software, applications, boundary defense devices, physical and environmental infrastructure, and personnel support.

4) Clearly identifies all mission or business-essential functions requiring restoration

5) Ensures that a program has been established that provides comprehensive and effective continuity of all system functions during a broad spectrum of emergencies or situations that may disrupt normal operations

6) A plan to fully restore full system functions at an alternate site are based on a business impact analysis or similar document. This plan shall include a strategy to perform full system operations at the alternate facility for an extended period of time.

7) Provides detailed plans for system maintenance of full mission operations under, at a minimum, the following incident-related conditions: · Power Failure · Natural Disaster (e.g., flooding, storms, tornadoes, etc.) · Fire · Outages due to facilities maintenance or relocation · Outages due to cyber-security incidents, such as network intrusion, worms, viruses, etc.

8) Contains a service agreement between the primary and alternate sites that is signed by the owner or operator of both sites.

9) Specifies a generic recovery plan to restore operations at the primary site. The government understands that specific details will vary depending on the nature of the incident that caused the activation of the alternate site and cannot all be determined in advance.

10) Specifies resources with which and the length of time for which the alternate site can support full operations of the primary site in the event of an incident.

11) Documents system continuity and mission impact that clearly prioritizes mission or business functions.

12) Documents system continuity and mission impact that lists the maximum allowable outage times for system resources.

13) Identifies mission-essential computing needs to include hardware, software, communication lines, applications, and data.

14) Identified all IT assets supporting mission and business essential functions (e.g., computer-based services, data and applications, communications, physical infrastructure) for priority restoration planning.

15) Includes the operators, management, and technical support personnel that will implement the plan.

16) Includes a listing of key personnel associated with the system administration and operations.

17) Clearly identifies resources needed to support mission-essential computing needs in the form of hardware, software, facilities, network infrastructure, and personnel.

18) Provides for the resumption of mission or business essential functions within 12 hours of activation.

19) Includes an enclave boundary defense at the alternate site provides security measures equivalent to the primary site

COBR. COSW, COTR, DCSW, CODB: The Contractor shall have procedures in place to assure the appropriate physical and technical protection of the backup and restoration hardware, firmware, and software are in place. Additionally, the hardware, software, or firmware used for back up of data or other system assets shall be clearly identified. The Contractor shall ensure that appropriate physical and technical measures are in place for the protection of backup and restoration hardware, firmware, and software. The Contractor shall maintain a detailed inventory of all backup and restoration assets as part of the organization or site backup plan. The Contractor shall maintain physical security controls, such as building/room access controls (e.g., visitor logs, manned visitor control points, etc.) in place and functioning; technical security controls, such as a cryptographic key management system, and least privilege access controls in place to protect archived data assets (e.g., lockable storage lockers for backup tapes); and fire-rated containers to maintain media containing backed up data, whether for short-term on-site storage or in preparation for transportation to an approved remote storage facility. The Contractor shall also ensure that appropriate physical security controls are employed for protection of backup and restoration assets and that the organization’s system security documentation identifies the type and location of physical assets (e.g., locked metal containers, rooms or spaces with lockable restricted-access doors, etc.) protecting of backup and restoration assets. The Contractor shall ensure that appropriate technical security controls are employed for protection of backup and restoration assets. The Contractor organization’s system security documentation shall identify the technical security controls (e.g., cryptographic key management, role-based access controls, etc.) used to protect backup and restoration assets. It shall also identify the system’s backup and restoration assets And that the technical controls are in place to protect these assets through testing. Most importantly, the Contractor shall ensure that data backup is performed daily and that the storage of the backups is located offsite from the primary processing location. A backup copy of the software inventory is stored in a fire-rated container or otherwise not collocated with the original. Additionally, at least one back-up copy of each operating system and each critical software application used by the system is stored in a fire rated container or otherwise not collocated with the operational software.. The Contractor shall also develop, document, and maintain, recovery procedures and technical system features to ensure a recovery is done in a secure and verifiable manner are documented. In the event that circumstances that could inhibit a trusted recovery are documented and appropriate mitigating procedures have been put in place.

COMS, COPS, COSP: The Contractor shall ensure that maintenance support is available to respond 24 X 7 immediately upon failure. An uninterruptible power supply shall be installed on all emergency generators capable of restoring sufficient power to continue partial operations. Additionally, maintenance spares and spare parts for key IT assets can be obtained within 24 hours of failure.

DCAS: The system has implemented only those IA- and IA-enabled GOTS products that have been evaluated by NSA or in accordance with NSA-approved processes.

DCSD, DCBP. DCCB, DCCT, DCAR: The Contractor shall prepare a System Security Design document that addresses all required best security practices based on the system's MAC and Confidentiality levels. For each best practice, the document either: provides the rationale for not incorporating the identified practice or, explains how the practice was incorporated into the system design. The system security documentation describes the technical, administrative, and procedural IA program and policies that govern the system, and identifies its IA personnel and specific IA requirements and objectives. The document shall address specific IA requirements for data handling, dissemination, system redundancy, backup, and emergency response. The document shall address technical, administrative, and procedural IA program and policies that govern the DoD information system. All appointments to required IA roles (e.g., DAA and IAM/IAO) are documented in writing, to include assigned duties and appointment requirements criteria such as training, security clearance, and IT-designation. A current and comprehensive baseline inventory of all software (SW) (to include manufacturer, type, and version) of the information system operations is maintained by the CCB and as part of the system security documentation.

The system security documentation addresses potential identity management products that will be implemented to prevent unauthorized access to the system. The Contractor shall provide test results of a randomly selected sample of system components or nodes in which best security practices had been incorporated and demonstrates positive results for implementation of the best practices. A comprehensive annual evaluation of policies and processes shall be conducted that ensures that policies consistently and adequately support system operations. The contracted information system shall be under the control of a chartered CCB that meets regularly (e.g., quarterly), and the AM is identified as a member of the CCB and attends scheduled CCB meetings. The procedures for testing of patches, upgrades and new AIS applications prior to deployment are documented. These procedures are being followed and testing results are documented in CCB documentation.

DCCS: All system IA and IA-enabled products are configured and implemented securely in accordance with the governing security guidance documents or DISA and NSA guidance.

DCDS-1: The Contractor shall perform a formal risk analysis report for all the IA services of the system and provide it to the IAM to have it approved by the DoD Component CIO.

For Software As a Service environments, if the most Statement of Auditing Standard 70 Type II report does not include an equivalent for IA control DCDS-1 IA, the Contractor is required to complete and submit a Computer Network Defense Service Designation Checklist to the IAM. This can be downloaded from the IASE site at https://powhatan.iiie.disa.mil/cnd/Component_CNDS_Designation_Checklist.doc.

In completing the Checklist, the Contractor is expected to provide all official documentation which reflects formal arrangements in the establishment or provisioning of CND services. Due diligence must be observed when compiling the artifacts for this checklist and all exceptions must be explained in the comments section.

DCFA: The Contractor shall develop, maintain, and document a system functional architecture describes all external interfaces, the information being exchanged, and the protection mechanisms associated with each interface are identified. The system functional architecture describes all unique security requirements, including where they have been implemented within the system, their purpose, and technical details of their implementation (e.g., encryption key strength/algorithm for data at rest). The system functional architecture describes all categories of sensitive information processed or stored by the system application and their specific protection plans (e.g., Privacy Act, HIPAA). The system functional architecture shall describe, in detail, the restoration priority of each subsystem, process, or information source.

DCHW: The Contractor shall ensure that a current and comprehensive baseline inventory of all hardware (HW) (to include manufacturer, type, model, physical location and network topology or architecture) required to support enclave operations is maintained by the Configuration Control Board (CCB) and as part of the appropriate system security document. Any changes to the baseline have been, and routinely are approved by the CCB. A backup copy of the current HW baseline inventory shall be stored in a fire-rated container and not geographically collocated with the original

DCID: The Contractor shall ensure that for all enclaves used in support of this contract, a list of all current or planned hosted AIS applications, interconnected outsourced IT-based processes, and interconnected IT platforms are developed and maintained along with evidence of deployment planning and coordination and the exchange of connection rules and requirements. This interconnection documentation shall be used to ensure that: planned and current hosted system applications are identified and methods are defined for security planning and coordinating with the enclave as early in the development cycle of the software release as possible based on the connection rules and requirements.

DCII: The Contractor shall ensure that proposed changes to the DoD information system are assessed for IA and accreditation impact prior to implementation. For each change, the change is identified; the change was reviewed by the CCB and assessed for IA and accreditation impact; and the implementation was approved by the CCB.

DCIT: The Contractor shall ensure that the acquisition or outsourcing of IT services explicitly addresses Government, service provider and end user IA roles and responsibilities and that they are clearly defined.

DCMC: The Contractor shall ensure that a mobile code registration and approval process that is in compliance with CJDSM 6510.01 is implemented and prevents the development or acquisition of unacceptable mobile code for deployment within the system or enclave. The Contractor shall ensure that system workstations and host software are configured to prevent the download and execution of mobile code that is prohibited.

DCNR: The Contractor shall ensure that in order to support non-repudiation, the current NIST FIPS validated cryptography standard is used for encryption, key exchange, digital signature, and hash. The Contractor shall ensure that NIST FIPS 140-2 validated cryptography is used to implement encryption, key exchange, digital signature, and hash.

DCPA: The Contractor shall ensure that user interface services (e.g., web servers) are separated from data storage and management services (e.g., database servers) using appropriate methods. User interface services shall be identified in the system architecture.

DCPB: The Contractor shall work with the government to ensure that a discrete line item for Information Assurance is established in the program and budget documentation. The government understands that this information may be proprietary and will work with the Contractor to maintain privacy of the information. to the maximum extent possible and still support the requirement of this IA control.

DCPD: The Contractor shall ensure that public domain software (e.g., freeware, shareware) is not used in the system unless compelling reasons are established, the product is assessed by the DAA for information assurance impact, and the product is approved for use by the DAA. Any public domain software used shall be listed in the CCB approved software list.

DCPP: The Contractor shall ensure that the system complies with the DoD ports, protocols, and services guidance for enclave connections and for registration. Contractors are required to comply with DoD Instruction 8551.1, Ports, Protocols, and Services Management, dated August 13, 2004. This includes following the Category Assurance List for designing interconnections to DoD systems. All ports, protocols and services that the system requires shall be listed in the security documentation for the system and in any relevant MOAs.

DCPR: The Contractor shall assist the government in the development, maintenance, and documentation of a Configuration Management plan, and a Configuration Control Board. The Contractor shall support the government to ensure that a configuration management (CM) plan has been developed to include detailed CM roles, test processes for the changes requested and processes to verify and validate the effectiveness of the CM process.

DCSL: The Contractor shall ensure that all source code libraries for the system are maintained and managed under Configuration Management Control, that CCB procedures and processes explicitly forbid implementation of changes to system programs without prior authorization, that codes that permit changes to system software are CCB approved prior to implementation. And that access to the system containing source code libraries is restricted only to authorized personnel. The Contractor shall ensure that all access to source code libraries is controlled to protect privileged programs that require prior CCB approval and prevent the introduction of unauthorized code. The Contractor shall ensure that there are procedures that explicitly disallow introduction of unauthorized code.

DCSP: The Contractor shall ensure that IA products and the security services of IA-enabled IT products are physically or logically isolated and protected. Additionally, the system security architecture and other documentation depicts a security support structure that is isolated physically, using domains and partitions, and the security support products are configured securely to provide access controls and the integrity of the products.

DCSQ: The Contractor shall ensure that all required system software life cycle documentation exists, is current, and approved, and that it reflects the implementation of regular code reviews and accepted software quality assurance practices during the system software lifecycle. The Contractor shall ensure that its software development initiative complies with all requirements listed in the latest versions of the following DISA documents: Recommended Standard Application Security Requirements, and companion documents Application Security Developer's Guide and Host Security Guide. Additionally, all identified application test plans shall be approved by the CA or DAA, and incorporate the testing specified in Recommended Standard Application Security Requirements. The Contractor shall ensure that web applications comply with all requirements of the DoD Web group and specifically with the latest version of the DISA Applications Security checklist.

DCSR: The Contractor shall ensure that IA and IA-enabled products evaluated through either the NIAP or the Common Criteria process, which protect publicly released information conform, at a minimum, to the Protection Profile Consistency Guidance for Basic Robustness published under IATF. Note that this Control Objective applies in conjunction with DCAS-1, and, alternatively, IA and IA-enabled products may be evaluated or validated through 1 of 2 additional sources: FIPS or NSA-approved processes. All IA and IA-enabled products incorporated into the DoD information system that are evaluated by the NIAP or the CC satisfy the requirements for the Basic Robustness as stated in the Protection Profile Consistency Guidance for Basic Robustness.

DCSS: The Contractor shall ensure that the system initialization, shutdown, and aborts are configured to ensure that the system remains in a secure state and in accordance with the NSA and/or DISA STIGs and SRGs related to the system operating systems, which specify directions to ensure that system initialization, shutdown and aborts are securely configured. Further, tests shall be provided and periodically run to ensure the integrity of the system state.

EBBD: The Contractor shall ensure that firewalls and network IDSs are deployed at the enclave boundary to the WAN and configured properly. Internet access shall be proxied through Internet access points that are under the management and control of the enclave and are isolated from other DoD information systems by physical or technical means. The Contractor shall also ensure that the boundary defense mechanisms to include firewalls and network IDSs, are deployed at layered or internal enclave boundaries as required and configured properly.

EBCR: The Contractor shall support the government to ensure that the DoD information system is compliant with established DoD connection rules and approval processes. All connections with external DoD information systems shall be established in accordance with approved DoD connection rules and processes. Contractor should specifically note that they must be prepared to support Defense Security Accreditation Working Group and Global Information Grid IA technical meetings upon request.

EBPW: The Contractor will ensure that any connections between the system enclave and the Internet or other public or commercial wide area networks occur only through a DMZ.

EBRP: The Contractor shall ensure that remote access for privileged functions is controlled and allowed only for compelling operational needs that are clearly documented and defined. Remote access session is protected by a security measure (e.g., VPN) that enables blocking mode. All remote access sessions shall be recorded in detail. Remote access for privileged functions is permitted only for compelling operational needs. Security measures such as a VPN with blocking mode enabled are employed to secure sessions in addition to EBRU. The Contractor shall make regularly available to the IAM the audit logs for a thorough review of every remote session EBRU: The Contractor shall ensure that the system has a remote access architecture within the enclave DMZ that positively authenticates all users through strong authentication methods, and encrypts remote access sessions with the appropriate level of encryption. The remote access architecture shall comply with all specified requirements and information transmitted via remote access is protected through appropriate encryption methods. The system documentation containing User Rules of Behavior shall specify the protection requirements for remote access information.

EBVC: The Contractor shall ensure that network intrusion detection systems (IDSs) are able to capture all VPN traffic. The network IDSs capture security-related events associated with VPNs.

ECAD: The Contractor shall ensure the prevention of inadvertent disclosure of controlled information by making sure that all Contractors are identified by the inclusion of the abbreviation “CTR” and all foreign nationals are identified by the inclusion of their 2-character country code in DoD user e-mail addresses, DoD user e-mail display names, and automated signature blocks. Contractors who are also foreign nationals shall be identified as both. Country codes and guidance regarding their use are in FIPS 10-4.

ECAN, ECAT, ECAR: The Contractor shall ensure that discretionary access controls are established and enforced for all shared or networked file systems. Access to all shared file systems is limited to the personnel identified as authorized by the organization. All internal classified, sensitive, and unclassified web sites are organized to provide at least 3 distinct levels of access.

1. Open access to general information made available to all DoD authorized users with network access. Access does not require an audit transaction.

2. Controlled access to information that made available to all DoD authorized users upon the presentation of an individual authenticator. Access is recorded in an audit transaction.

3. Restricted access to need-to-know information made available only to an authorized community of interest. Authorized users must present an individual authenticator and have either a demonstrated or validated need-to-know. All access to need-to-know information and all failed access attempts are recorded in audit transactions.

The Contractor shall ensure that discretionary access requirements are complete and sufficient for all reviewed web sites. Further all audit controls are operational, complete and effective for controlled access information. .Audit controls shall be put in place and operational, complete and effective for controlled access information. The Contractor shall ensure that audit records include: User ID, Successful and unsuccessful attempts to access security files, Date and Time of the Event, Type of event, and Success or failure of event. . The Contractor shall ensure that an automated, continuous on-line monitoring and audit trail creation capability is deployed with the capability to immediately alert personnel of unusual or inappropriate activity with potential IA implications, and with a user configurable capability to automatically disable the system if serious IA violations are detected. .

ECCD: The Contractor shall establish that access control mechanisms exist to ensure data is accessed and changed only by authorized personnel. Users, if required by the Information Owner, shall be notified of time and date of the last change in identified data elements. Access and changes to identified data are recorded in transaction logs that are reviewed periodically and immediately upon system security events1. The system will record changes in identified data in the transaction log and notify designated users of changes in data. System documentation will identify what data has notification requirements, how users are designated for notification, and how they are notified of changes. The documentation shall also assigns responsibility for review of transaction logs and indicates how such reviews are to be conducted and documented.

ECCR: The Contractor shall, if required by the information owner, ensure that NIST-certified cryptography is used to encrypt stored sensitive information. Contractors must provide proof of FIPS 140-2 certified cryptography implementation for Data at Rest. Contractors should note that all PII data must be encrypted.

ECCT: The Contractor shall ensure that unclassified, sensitive data transmitted through a commercial (e.g., Internet) network must be encrypted using NIST-certified cryptography Contractors must provide proof of FIPS 140-2 certified cryptography implementation for Data in Transit. Note for purpose of this addendum that all personnel data records are considered sensitive data.

ECDC: The Contractor shall ensure that transaction-based systems (e.g., database management systems, transaction processing systems) have implemented transaction rollback and transaction journaling, or technical equivalents

ECIC: The Contractor shall employ discretionary access controls when connecting DoD information systems operating at the same classification but with different need-to-know access rules.. Contractors are required to comply with DoD Instruction 8551.1, Ports, Protocols, and Services Management, dated August 13, 2004. This includes following the Category Assurance List for designing interconnections to DoD systems. Cross-domain solutions or other controlled interfaces are to be employed when connecting DoD information systems operating at different classification levels, or between DoD systems and non-DoD systems. The controlled interface required for interconnections among DoD information systems operating at different classifications levels or between DoD and non-DoD systems or networks shall conform to DoD cross-domain technical requirements.

ECID: The Contractor shall ensure that host-based intrusion detection systems are deployed for major applications. All listed site-critical servers must have IDS properly installed. .Further, the Contractor shall ensure that network-based intrusion detection systems are deployed for network management assets such as routers, firewalls, and domain name servers (DNS).

ECIM: The Contractor shall ensure that both inbound and outbound public service instant messaging traffic is blocked at the enclave boundary. (Note: this does not include IM services that are configured by a DoD AIS application or enclave to perform an authorized and official function.). The firewall rules must block both incoming and outgoing instant messaging traffic managed by public service providers.

ECLO: The Contractor shall ensure that successive logon attempts are controlled using 1 or more of the following:

1 Access is denied after 3 invalid attempts to log onto the system.

2. The number of access attempts in a given period is limited.

3. A time-delay control system is employed.

Additionally, if the system allows for multiple logon sessions for each user ID, the system shall provide a capability to control the number of logon sessions. .

ECLP: The Contractor shall ensure that access to procedures enforce the principles of separation of duties and “least privilege.” Access to privileged accounts shall be limited to privileged users. The Contractor shall ensure that the use of privileged accounts is limited to privileged functions; that is, privileged users use non-privileged accounts for all non-privileged functions.

ECML: The Contractor shall ensure that systems that store, process, transit, or display classified or sensitive data comply with all requirements for marking and labeling contained in policy and guidance documents such as DoD 5200.1R. Markings and Labels clearly reflect the classification or sensitivity level, if applicable, and special dissemination, handling, or distribution instructions.

ECMT: The Contractor shall consent to unannounced in-depth monitoring and penetration testing by the DoD CERT or a DoD CERT-designated entity A current, approved consent to IA monitoring and penetration testing exists. The scope of the testing is to ensure adequate system’s IA capabilities against constantly evolving threats and vulnerabilities. For Software As a Service environments where providers do not own the facility hosting the DoD data, Contractors have the option of conducting an independent penetration test assessment. This assessment must conform to the requirement in DOD or SAS70 standards.

ECND: The Contractor shall implement an effective network device control program (e.g., routers, switches, firewalls). It shall include instructions for restart and recovery procedures; restrictions on source code access, system utility access, and system documentation; protection from deletion of system and application files, and a structured process for implementation of directed solutions, e.g., IAVA. The Contractor shall ensure that audit or other technical measures are in place to ensure that the network device controls are not compromised. All devices must have auditing enabled to record security-related events.

ECNK: The Contractor shall verify that sensitive (FOUO, Privacy Act, etc) or classified information requiring separation for need-to-know reasons within the DoD network (e.g., NIPRNet, SIPRNet) is encrypted using NIST-certified cryptography (e.g., SSL, PKI, VPN). Contractors must ensure implementation of FIPS 140-2 certified cryptography for Data in Transit and Data at Rest. The Contractor shall provide a copy of the FIPS 140-2 certificate to the IAM.

.ECPA: The Contractor shall ensure that all privileged user accounts are established and administered in accordance with a role-based access scheme that organizes all system and network privileges into roles (e.g., key management, network administration, system administration, database administration, web administration.

ECPC: The Contractor shall ensure that application programmer privileges to change production code and data are limited and reviewed every 3 months.

ECRC: The operating systems on all systems' critical servers have been approved for use on the basis of an evaluation that addresses object reuse.

ECRG, ECTB, ECTP, ECRR: The Contractor shall ensure that tools are available for the review of audit records and for report generation from audit records. (Note: This control should not be limited to IDSs, but should be applied to other IT platforms and critical AIS applications to facilitate audit review and reporting Audit records are to be retained for at one year for systems that do not contain SAMI, or for at least five years for systems that do contain SAMI. Operating systems are configured not to overwrite (or otherwise lose) audit trails when log lengths reach specified maximums. Logs record attempts to view and to delete. Audit trails stored off-line are readily available for analysis. The Contractor shall verify that the audit records are backed up not less than weekly onto a different system or media than the system being certified .The contents of audit trails shall be protected against unauthorized access, modification or deletion ECSC: The Contractor shall ensure that all IA and IA-enabled IT products deployed within the system are periodically reviewed for compliance with governing security implementation guidance documents (e.g. DISA STIGs or SRGs, NSA guidelines. Contractors must provide the IAM raw results of scans and a detailed documented analysis of each of the findings. Microsoft Windows Gold Disks will be run at Platinum level. Alternately a completed DISA-provided checklist with signatures or security test and evaluation report/mitigation plan within the last compliance review cycle is acceptable.

ECSD: The Contractor shall ensure that change controls for software development are in place to prevent unauthorized programs or modifications to programs from being implemented. Ensure change requests are subject to a review and approval process. Specifically, the CM plan addresses how SCRs/ECRs are to be prepared, submitted and processed. SCRs are filled out according to the guidelines and procedures in the CM plan. Processing of SCRs reflected in the CCB minutes is consistent with the procedures in the CM plan.. The system implements separation of duties and different environment types (i.e., development, testing, and production). Their corresponding personnel are kept separate, and the associated functionality and operations do not overlap. Change controls for software development also include technical system features to assure that changes are executed by authorized personnel and are properly implemented. All active accounts on the development servers correspond to designated software developers.

ECTC: The contactor shall ensure that measures to protect against compromising emanations have been implemented in accordance with DoD Directive S-5200.19. .

ECTM: The Contractor shall ensure that good engineering practices with regards to the integrity mechanisms of COTS, GOTS and custom developed solutions are implemented for incoming and outgoing files. Integrity mechanisms, such as parity checks and/or CRCs, shall be used to check the integrity of incoming and outgoing files.

Mechanisms shall be in place to assure the integrity of all transmitted information, including labels and security parameters. Proper integrity mechanisms, such as security labels and strong encryption are to be used to provide the integrity of transmitted information. Mechanisms shall be put in place to detect or prevent the hijacking of a communication session (e.g., encryption or covert communication channel checks). Proper integrity mechanisms, such as covert communication analysis tools (e.g., tcpdump), are to be used to detect or prevent the hijacking of a communication session.

ECVI: The Contractor shall ensure that VoIP traffic to and from workstation IP telephony clients that are independently configured by end users for personal use is prohibited within DoD information systems. Rules of Behavior, or other relevant system architecture or security documentation, shall specify that VoIP traffic to and from workstation IP telephony clients that are independently configured by end users for personal use is prohibited within DoD information systems. Both inbound and outbound individually configured Voice Over IP traffic is blocked at the enclave boundary, except for those VoIP services that are configured by a DoD AIS application or enclave to perform an authorized and official function. The firewall rules shall accept only authorized VoIP services and block both incoming and outgoing VoIP traffic not specifically designated for an authorized and official function.

ECVP: The Contractor shall verify that all system components have implemented a virus protection system which includes a capability for automatic updates All virus protection software installed have signatures that are current as of the test date. Contractors are required to use the DoD-approved anti-virus software which currently includes McAfee and Norton.

ECWM: The Contractor shall ensure that an approved warning banner is displayed prior to logging into a Government information system, and that the warning provides appropriate privacy and security notices, to include statements informing users that they are subject to monitoring, recording and auditing ECWN: The Contractor shall ensure that all wireless capabilities comply with DoDD policy 8100.2, April 14, 2004..All factory default settings or configurations of wireless computing capabilities internally embedded in interconnected DoD IT assets shall be disabled prior to issue to end users.

IAAC: The Contractor shall ensure that a comprehensive account management process is implemented to ensure that only authorized users can gain access to workstations, applications and networks. User accounts shall not be duplicated.

User IDs and passwords that have not been used in a 30-day period shall be suspended.

User IDs shall be removed and passwords disabled within 72 hours of notification that a user no longer requires system/network access IAGA, IAIA: The Contractor shall verify that the use of group accounts is either based on the DoD PKI or approved by the DAA. Individual authenticator is assigned to each group. The system shall require each user to provide a unique user ID and password before accessing the system either initially or after a screen lock program is interrupted. Passwords shall be shadowed when entered at terminal or printer The system shall enforce stringent password constraints in the areas of minimum password length and password age and history. The system shall enforce strong passwords to resist password cracking. At least four characters must be changed when a new password is created. The system shall prevent creation of weak or improperly configured passwords. Passwords shall be stored in encrypted form. Passwords shall be protected commensurate with the classification of the information accessed. Passwords shall not transmitted in clear text over the network. Vendor-provided user accounts and passwords shall be removed or changed. Passwords shall not be shared. Proper procedures shall be implemented to create and distribute user IDs and passwords. The Contractor should be aware that password stringency requirements change periodically. Contractors are responsible for implementing the most current password policy guidance per the JTF-GNO CTO. At this time, USCYBERCOM CTO 07-015 Revision 1, Public Key Infrastructure Implementation specifies these requirements.

IAKM, IATS: The Contractor shall verify that symmetric keys are produced, controlled and distributed using NSA-approved key management technology and asymmetric keys are produced, controlled and distributed using DoD PKI Class 3 or Class 4 certificate and hardware security tokens. Identification and Authentication shall be accomplished using the DoD PKI Class 3 or Class 4 certificate and hardware security token or NSA-certified product. Be aware that external Contractors and other organizations that communicate with the DoD will not be issued DoD PKI certificates. The ECA PKI program was implemented by the DoD to provide a mechanism for these external entities to obtain certificates and thereby be able to communicate securely with the DoD. In addition, DoD has mandated that most DoD private websites must be Public Key-Enabled; websites that have users who are not eligible to obtain DoD PKI certificates must allow other DoD approved PKIs such as ECA for authentication. Contractors must follow the program details at http://iase.disa.mil/pki/eca/index.html.

PECF, PEEL, PEFD, PEFL, PEFS, PEHC, PEMS, PEPF, PEPS, PETC, PETN, PEVC, PEVR, PRMP, PEDI: The Contractor shall ensure that only authorized personnel with appropriate clearances are granted physical access to computing facilities that process sensitive information. Devices that display or output classified or sensitive information in human-readable form are positioned to deter unauthorized individuals from reading the information. An automatic emergency lighting system shall be installed that covers all areas necessary to maintain mission or business essential functions, to include emergency exits and evacuation routes. A servicing fire department must receive an automatic notification of any activation of the smoke detection or fire suppression system. Smoke detectors shall be configured to automatically alert a servicing fire department to any activity involving smoke detection or fire suppression are installed in the facility. Smoke detectors and alert systems shall be in working condition.