8500.2 ia controls - umsl blogs · include the operators, management, and technical support...

8500.2 IA ControlsSelect a MAC/CL combination to view corresponding IA Controls:

Control Name Subject Area Description General Implementation Guidance System-specific Guidance Resource(s) Impact Code

COAS-2 Continuity High

COBR-1 Continuity High

CODB-3 Continuity Medium

Control Number

Threat/Vulnerability/Countermeasure

Alternate Site Designation

An alternate site is identified that permits the restoration of all mission or business essential functions.

Environmental disasters, organized disruptions, loss of utilities/services, equipment or system failures, and serious information security incidents are potential events that could disrupt mission or business essential functions. A recovery strategy should be developed to include an alternate site to mitigate the impact of disruptive events.

This general implementation guidance is provided for IAMs/IAOs involved in the creation of a system or organizational Continuity of Operations (COOP) plan:Identify an alternate site that has the capability to fully restore mission or business essential functions.Establish a program to ensure comprehensive and effective continuity of full functionality during a broad spectrum of emergencies or situations that may disrupt normal operations (e.g., power failures, damage to facilities caused by storms, fires, flooding, etc.)Ensure that the program includes a strategy to recover and perform full system operations at the alternate facility for an extended period of time.Full restoration of mission or business essential functions at an alternate site shall be based on a business impact analyses that identifies and ranks major information systems and mission-critical applications according to priority and the maximum permissible outage for each.A contingency plan shall be created that identifies mission-essential computing needs to include hardware, software, communication lines, applications, and data. The plan should also include the operators, management, and technical support personnel that will implement the contingency plan.

· NIST SP 800-12, An Introduction to Computer Security: The NIST Handbook, October 1995· NIST SP 800-34, Contingency Planning Guide for Information Technology Systems, June 2002· DoD Directive 3020.26, Defense Continuity Program, 08 September 2004· DoDI 3020.39, Integrated Continuity Planning for Defense Intelligence, 03 August 2001· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 25 March 2003, Enclosure D· CNSS Instruction 4009, May 2003, Reference B· NSTISSI 4013, National Training Standard for System Administrators in Information Systems Security, August 1997

Protection of Backup and Restoration Assets

Procedures are in place assure the appropriate physical and technical protection of the backup and restoration hardware, firmware, and software, such as router tables, compilers, and other security-related system software.

If backup and restoration assets do not have appropriate physical and technical protections in place, there is a risk of mission essential information being accidentally or deliberately modified or destroyed. A protection strategy for all backup and restoration hardware, firmware, and software, such as router tables, compilers, and other security-related system software mitigates the modification or destruction of information.

1. An inventory of all backup and restoration assets shall be documented in an organization or site backup plan.2. Physical security controls, such as building/room access controls and fire rated safes shall be employed to protect backup and restoration assets.3. Technical security controls, such as cryptographic key management and least-privilege access controls shall be implemented to protect backup and restoration assets.

· NIST SP 800-34, Contingency Planning Guide for Information Technology Systems, June 2002· DoDD 3020.36, Assignment of National Security Emergency Preparedness Responsibilities to DoD Components, 02 November 1988· DoD 8910.1-M, DoD Procedures for Management of Information Requirements, 30 June 1998· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 25 March 2003

Data Backup Procedures

Data backup is accomplished by maintaining a redundant secondary system, not co-located, that can be activated without loss of data or disruption to the operation.

Mission-critical data is at risk of corruption or loss if a redundant secondary system is not available for backup procedures. Maintaining a secondary system that is identical to the original is essential to ensuring the integrity and availability of data in the event of an incident. Practicing Data Backup Procedures annually or biannually ensures adherence to proper procedures, as well as an understanding of these procedures.

This guidance is written for System Administrators with backup privileges: 1. For site data backup, ensure that a redundant secondary system, identical in configuration and processing capacity to the original, and not collocated with the original is available.2. Ensure that access to the secondary system is available 24/7 and that resources are available to activate the secondary system without loss of data or disruption to the system operation.3. Ensure that an un-interrupted power supply (UPS) is available and operational for the redundant secondary system in order to ensure adequate activation and operation in the event of an incident.

· DoD Directive 3020.26, Defense Continuity Program, 08 September 2004

MAC I, Classified MAC II, ClassifiedMAC III, ClassifiedMAC I, Sensitive MAC II, SensitiveMAC III, SensitiveMAC I, Public MAC II, Public MAC III, Public

All 8500.2 IA Controls

CODP-3 Continuity Medium

COEB-2 Continuity High

COED-2 Continuity Medium

COEF-2 Continuity Medium

Disaster and Recovery Planning

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. (Disaster recovery procedures include business recovery plans, system contingency plans, facility disaster recovery plans, and plan acceptance.)

Mission and business essential functions are at risk to interruption from a disaster without a disaster recovery plan properly documented and executed within 24 hours of activation.

This guidance is provided for Information Assurance Managers to assist in setting up a disaster and recovery plan: 1. Ensure that the system disaster plan 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.2. Disaster recovery procedures shall include business recovery plans, system contingency plans, facility disaster recovery plans, and plan acceptance.

· DoD Directive 3020.26, Defense Continuity Program, 08 September 2004

Enclave Boundary Defense

Enclave boundary defense at the alternate site must be configured identically to that of the primary site.

A securely configured enclave boundary is essential to the maintaining the integrity of a site’s IT systems. Ensuring the identical configuration of an alternate site assures integrity of operations in the wake of an incident requiring the switch of mission operations to the alternate site.

Enclave boundary defense at the alternate site shall be configured identically to that of the primary site.

· DISA Enclave Security STIG, Version 2, Release 1, 01 July 2004· DISA Enterprise Security Management STIG, 29 October 2004

Scheduled Exercises and Drills

The continuity of operations or disaster recovery plans or significant portions are exercised semi-annually.

Disaster recovery plans are essential for mitigating the effects of emergencies, but without training, the threat of making mistakes during plan execution is high. Exercising disaster recovery plans semi-annually followed by corrections and enhancements improve an organization’s disaster response capabilities.

1. The continuity of operations or disaster recovery plans or significant portions shall be exercised semi-annually to ensure plans are complete and viable.2. The exercises shall be coordinated with management and other key personnel.3. The exercise, if possible, shall not interrupt normal operations.4. The results of the exercise shall be recorded and analyzed for improvements and enhancements.

· Presidential Decision Directive 67, Enduring Constitutional Government and Continuity of Government Operations, October 1998· NIST SP 500-170, Management Guide to Protection of Information Resources, October 1989· NIST SP 800-34, Contingency Planning Guide for Information Technology Systems, June 2002· FIPS Publication 87, Guidelines for ADP Contingency Planning, March 1981· DoDI 3020.39, Integrated Continuity Planning for Defense Intelligence, 03 August 2001· DoDD 3020.36, Assignment of National Security Emergency Preparedness Responsibilities to DoD Components, 02 November 1988· DoDD 3020.26, Defense Continuity Program, 08 September 2004· DoDD 5137.1, Assistant Secretary of Defense for Command, Control, Communications, and Intelligence, 12 February 1992· DoD 8910.1-M, DoD Procedures for Management of Information Requirements, 30 June 1998· CJCSM 6510.01 Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 25 March 2003

Identification of Essential Functions

Mission and business-essential functions are identified for priority restoration planning along with all assets supporting mission or business-essential functions (e.g., computer-based services, data and applications, communications, physical infrastructure).

Although many threats and vulnerabilities can be mitigated, some threats cannot be prevented. Therefore, it is important to be prepared and minimize the impact of an emergency by identifying and prioritizing mission and business essential functions along with all supporting assets (e.g., computer-based services, data and applications, communications, physical infrastructure).

1. Mission and business-essential functions shall be identified for priority restoration planning along with all assets supporting mission or business-essential functions (e.g., computer-based services, data and applications, communications, physical infrastructure), and the results shall be documented in a contingency plan.2. Business process managers and accountable executives shall be involved in the identification of essential functions for which disruption will result in significant financial and/or operational losses.3. The prioritized restoration plan shall be periodically reviewed and updated.

· OMB Circular A–130, Revised (Transmittal Memorandum No. 4), Appendix III, Security of Federal Automated Information Resources, November 2000· Presidential Decision Directive 67, Enduring Constitutional Government and Continuity of Government Operations, October 1998.· NIST SP 500-170, Management Guide to Protection of Information Resources, October 1989· CJCSM 6510.01 Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 25 March 2003· NIST SP 800-34, Contingency Planning Guide for Information Technology Systems, June 2002· FIPS Publication 87, Guidelines for ADP Contingency Planning, March 1981· DoDI 3020.39, Integrated Continuity Planning for Defense Intelligence, 03 August 2001· DoDD 3020.36, Assignment of National Security Emergency Preparedness Responsibilities to DoD Components, 02 November 1988· DoDD 3020.26, Defense Continuity Program, 08 September 2004· DoDD 5137.1, Assistant Secretary of Defense for Command, Control, Communications, and Intelligence, 12 February 1992· DoD 8910.1-M, DoD Procedures for Management of Information Requirements, 30 June 1998

COMS-2 Continuity N/A Medium

COPS-3 Power Supply Continuity N/A Medium

COSP-2 Spares and Parts Continuity N/A Medium

COSW-1 Continuity N/A High

COTR-1 Trusted Recovery Continuity N/A High

Maintenance Support

Maintenance support for key IT assets is available to respond 24 X 7 immediately upon failure.

Mission-critical systems require 24x7 maintenance support to ensure uninterrupted operations. Establishing a clear MOA or service contract with the responsible maintenance organization or vendor, as well as inventory control for critical items, is essential to maintaining continuous operations.

1. Ensure that maintenance support for key IT assets shall be available to respond 24 X 7 immediately upon failure by implementing a service agreement stipulating such availability.2. Verify that the maintenance support service agreement specifies 24 X 7 availability of maintenance support.

Electrical systems are configured to allow continuous or uninterrupted power to key IT assets and all users accessing the key IT assets to perform mission or business-essential functions. This may include an uninterrupted power supply coupled with emergency generators or other alternate power source.

Mission-critical systems, as well as terminals accessed by users of the critical applications, require continuous access to power in order to function. The installation of a functioning Uninterruptible Power Supply (UPS) or similar device ensures the uninterrupted processing power for the system.

1. Electrical systems shall be configured to allow continuous or uninterrupted power to key IT assets and all users accessing the key IT assets to perform mission or business-essential functions.2. This shall include an uninterrupted power supply coupled with emergency generators or other alternate power source.

Maintenance spares and spare parts for key IT assets are available 24 X 7 immediately upon failure.

Mission-critical systems require 24x7 maintenance spares and spare parts to ensure uninterrupted operations. Establishing a clear MOA or service contract with the responsible maintenance organization or vendor, as well as inventory control for critical items, is essential to maintaining continuous operations.

1. Review the maintenance support contracts, logs and documentation to verify that maintenance spares and spare parts support for key IT assets is available 24x7.2. Record the results.

Backup Copies of Critical SW

Back-up copies of the operating system and other critical software are stored in a fire rated container or otherwise not collocated with the operational software.

Operating systems and software are potentially vulnerable to corruption by malicious code or destruction, or through natural disaster or inadvertent operator or administrator error. Hardcopy SW should be available and maintained offsite in a protected environment with secure access.

1. Back-up copies of the operating system and other critical software shall be stored in a fire rated container or otherwise not collocated with the operational software.2. Refer to CODB-1.

Recovery procedures and technical system features exist to ensure that recovery is done in a secure and verifiable manner. Circumstances that can inhibit a trusted recovery are documented and appropriate mitigating procedures have been put in place.

The integrity of an information system is dependent in large part on the ability to recover system data and functionality in a manner that guarantees its integrity and availability. The absence of trusted recovery mechanisms put the system at risk for data compromise, system software failure, or inability to properly execute mission-essential tasking.

1. Recovery procedures and technical system features exist to ensure that recovery shall be done in a secure and verifiable manner.2. Circumstances that can inhibit a trusted recovery shall be documented and appropriate mitigating procedures have been put in place.3. Procedures and/or mechanisms shall be provided to assure that, after an ADP system failure or other discontinuity, recovery without a protection compromise is obtained.

DCAR-1 Medium

DCAS-1 High

DCBP-1 Medium

Procedural Review

Security Design and Configuration

An annual IA review is conducted that comprehensively evaluates existing policies and processes to ensure procedural consistency and to ensure that they fully support the goal of uninterrupted operations.

Complacency in regards to the periodic review of existing policies and processes opens the door to emerging security threats that can negatively impact mission success. The dynamic nature of information technology warrants at least an annual review of existing policies and processes to help achieve uninterrupted operations.

1. The DIACAP Team shall be an active participant in annual review process.2. An annual IA review shall be conducted that comprehensively evaluates existing policies and processes to ensure procedural consistency and to ensure that they fully support the goal of uninterrupted operations.3. The annual review process should account for the analysis of projected policy needs, and produce a plan for development or implementation of new policies or processes.

· DoDI 8500.2, Information Assurance (IA) Implementation, para E3.3.10, 06 February 2003· Section 2224 of title 10, United States Code,"Defense Information Assurance Program”, 05 October 1999

Acquisition Standards


The acquisition of all IA- and IA-enabled GOTS IT products is limited to products that have been evaluated by the NSA or in accordance with NSA-approved processes. The acquisition of all IA- and IA-enabled COTS IT products is limited to products that have been evaluated or validated through one of the following sources - the International Common Criteria (CC) for Information Security Technology Evaluation Mutual Recognition Arrangement, the NIAP Evaluation and Validation Program, or the FIPS validation program. Robustness requirements, the mission, and customer needs will enable an experienced information systems security engineer to recommend a Protection Profile, a particular evaluated product or a security target with the appropriate assurance requirements for a product to be submitted for evaluation (See also DCSR-1).

Procured IA- and IA- enabled GOTS and COTS IT products have the potential to introduce security vulnerabilities into information systems. Ensuring that products are successfully evaluated by the appropriate organization (e.g., NSA, NIST, etc.) to ensure that they have incorporated robust security features into their design and construction will mitigate the risk of inducing security vulnerabilities within a DoD information systems.

1. The acquisition of all IA- and IA-enabled GOTS IT products shall be limited to products that have been evaluated by the NSA or in accordance with NSA-approved processes.2. The acquisition of all IA- and IA-enabled COTS IT products shall be limited to products that have been evaluated or validated through one of the following sources: a. The International Common Criteria (CC) for Information Security Technology Evaluation Mutual Recognition Arrangement; b. The NIAP Evaluation and Validation Program; The NIAP program serves as the vehicle for evaluating IA and IA enabled COTS IT products. A complete list of products that have been evaluated under Common Criteria through NIAP can be found at the following website: http://niap.nist.gov/cc-scheme/vpl/vpl_type.html. Evaluated products can be located using a search by vendor, product name, technology type, and assurance level. c. The FIPS validation program.3. Robustness requirements, the mission, and customer needs will enable an experienced information systems security engineer to recommend a Protection Profile, a particular evaluated product or a security target with the appropriate assurance requirements for a product to be submitted for evaluation (See also DCSR-1).

· Common Criteria Version 2, Release 2, ISO International Standard 15408, or latest release, January 2004· National Security Telecommunications and Information Systems Security Policy (NSTISSP) No. 11,"National Policy Governing the Acquisition of Information Assurance (IA) and IA-enabled Information Technology Products."January 2000· DoD 5000.1, The Defense Acquisition System, 12 May 2003· DoD 5000.2, Operation of the Defense Acquisition System, 12 May 2003· DoDI 8580.1, Information Assurance (IA) in the Defense Acquisition System, 09 July 2004· FAQs for 8580.1, Frequently Asked Questions: DoDI 8580.1, 05 August 2004· IA in the Defense Acquisition Guidebook, IA Section of the Draft Defense Acquisition Guidebook, 09 July 2004· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)· DoDD 8000.1, Management of DoD Information Resources and Information Technology, 27 February 2002· DoDI 8500.2, Information Assurance (IA) Implementation, para. E3.2.5 – E3.2.5.6, 06 February 2003

Best Security Practices


The DoD information system security design incorporates best security practices such as single sign-on, PKE, smart card, and biometrics.

Organizations not leveraging best practices for security are not utilizing lessons learned from previous security efforts. These organizations run the risk of repeating historical errors and wasting money on duplication of efforts while needlessly introducing preventable vulnerabilities into the IS. Utilizing best security practices ensures information systems within the DoD are aligned with tested and validated practices.

1. The DoD information system security design shall incorporate best security practices such as single sign-on, PKE, smart card, and biometrics.2. Best Security Practices are compiled by government, industry, academia, (or collaborations between all three) to document those security practices that have a proven record of success when applied to appropriate technologies or situations. These Practices should be used in as many cases as practical.

· DISA Network Infrastructure STIG, Version 5, Release 2, 29 September 2003· DISA Network Infrastructure Security Checklist, Version 5, Release 2.2, 23 September 2004· DoD IA Strategic Plan, Version 1, Release 1, January 2004· Carnegie Mellon Software Engineering Institute, Capability Maturity Model® Integration (CMMISM),Version 1, Release 1, CMMISM for Systems Engineering, Software Engineering, and Integrated Product and Process Development (CMMI-SE/SW/IPPD, Version 1, Release 1) Continuous Representation CMU/SEI-2002-TR-003ESC-TR-2002-003, December 2001· DoDD 8000.1, Management of DoD Information Resources and Information Technology, 27 February 2002· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)

DCCB-2 Control Board Medium

DCCS-2 High

DCCT-1 Medium

DCDS-1 Medium


All information systems are under the control of a chartered Configuration Control Board that meets regularly according to DCPR-1. The IAM is a voting member of the CCB.

Without a Configuration Control Board, arbitrary, unapproved, and undocumented changes and updates to information system baselines have the potential to negatively impact system integrity and availability. A chartered Configuration Control Board provides a vetting process for technical review and formal approval of network changes to help prevent rogue system modifications.

1. Each Component shall formally charter a CCB for the purpose of monitoring and controlling configuration changes within all information systems under its purview.2. CCB members shall be appointed in writing for a specified period of time and their duties outlined by title, position, and system.3. The IAM shall be a regular, voting member of the CCB.*4. All decisions made by the CCB, including any changes to the system baseline, shall be documented and maintained in the appropriate configuration management system. * Note: This requirement is more stringent than DCCB-1

· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)· ANSI/EIA-649 “National Consensus Standard for Configuration Management”, July 1998

Configuration Specifications


A DoD reference document such as a security technical implementation guide or security recommendation guide constitutes the primary source for security configuration or implementation guidance for the deployment of newly acquired IA- and IA-enabled IT products that require use of the product's IA capabilities. If a DoD reference document is not available, the system owner works with DISA or NSA to draft configuration guidance for inclusion in a Departmental reference guide.

Default configuration settings and parameters are often times not the most secure. Security vulnerabilities can be exploited by malicious individuals causing severe damage to DoD computing environments. Adhering to the latest security technical implementation guide or security recommendation provides organizations a higher degree of assurance that products are secure.

1. Refer to the system security architecture document (or a similar document that outlines the various system components security configuration requirements) to identify each configurable system component .2. Identify the operating system or major software feature of each component that requires configuration.3. Using the DIACAP Knowledge Base or other repository, access the appropriate DISA STIG for the operating system, software application, or device.4. Follow the STIG’s manual or automated configuration guidance for the operating system, software application, or device.5. If a DISA STIG or other DoD-issued configuration guidance is not available, contact DISA or NSA for developmental guidance.* * Note: This requirement is more stringent than DCCS-1

· Refer to application-specific DoD, DISA, & NSA STIG· DoDI 8551.1, Ports, Protocols, and Services Management (PPSM), 13 August 2004· DoDI 8500.2, Information Assurance (IA) Implementation, para. E3.2.4, E3.2.6, 06 February 2003

Compliance Testing


A comprehensive set of procedures is implemented that tests all patches, upgrades, and new AIS applications prior to deployment.

Most information systems throughout an organization are unique. Patches, upgrades, and new applications can behave quite differently when applied across disparate systems. It is paramount that steps be taken to maintain the stability of the production IS. Proper compliance testing provides a reasonable level of assurance that system changes will achieve expected results.

1. Each component shall implement a comprehensive set of test procedures that verify modifications to fielded systems will not be negatively impacted by the introduction of patches, upgrades, or modification.2. Identify need for upgrade by monitoring appropriate channels such as vendor sites, mailing lists, third party sources, vulnerability scans or other means of detection.3. Patches shall come from an approved trusted source and be tested and deployed in a timely manner.4. Follow all prescribed installation procedures associated with the upgrade.

· NIST SP 800-40, Procedures for Handling Security Patches. August 2002· DoDI 8500.2, Information Assurance (IA) Implementation, para E3.2.4, E3.2.5.7, 06 February 2003

Dedicated IA Services


Acquisition or outsourcing of dedicated IA services such as incident monitoring, analysis and response; operation of IA devices such as firewalls; or key management services are supported by a formal risk analysis and approved by the DoD Component CIO.

Many dedicated IA services introduce ancillary security and financial risks which may not be readily apparent to organizations. Formal risk management techniques must be employed to fully understand the scope of implementing IA services.

1. Each Component shall adopt or develop a documented formal risk analysis process in which to evaluate the acquisition or outsourcing of dedicated IA services such as incident monitoring, analysis and response; operation of IA devices such as firewalls; or key management services.2. Minimum factors to consider when evaluating dedicated IA shall include potential cost, schedule and technical risk. Ideally, consideration would be given in terms of the Mission Assurance Categories, provided in DoDI 8500.2 Enclosure 2.3. The risk analysis findings shall be presented to the DoD Component CIO for action.

· DoDD 8000.1, Management of DoD Information Resources and Information Technology, 27 February 2002· DoDI 8500.2, Information Assurance (IA) Implementation, para E2.1.38, 06 February 2003

DCFA-1 Medium

DCHW-1 HW Baseline High

DCID-1 High

DCII-1 Medium

Functional Architecture for AIS Applications


For AIS applications, a functional architecture that identifies the following has been developed and is maintained: - all external interfaces, the information being exchanged, and the protection mechanisms associated with each interface - user roles required for access control and the access privileges assigned to each role (See ECAN) - unique security requirements (e.g., encryption of key data elements at rest) - categories of sensitive information processed or stored by the AIS application, and their specific protection plans (e.g., Privacy Act, HIPAA) - restoration priority of subsystems, processes, or information (See COEF).

Information systems without proper architectural documentation may be difficult to troubleshoot in a timely manner. Additionally, continuity of operations is seriously degraded when system architecture is undocumented. Having complete and accurate functional documentation for an AIS application architecture ensures all unique aspects are captured.

1. Each Component shall identify standard and unique characteristics of their AIS applications to develop a functional architecture that identifies the following: a. All external interfaces, the information being exchanged, and the protection mechanisms associated with each interface; b. User roles required for access control and the access privileges assigned to each role (See ECAN); c. Unique security requirements (e.g., encryption of key data elements at rest); d. Categories of sensitive information processed or stored by the AIS application, and their specific protection plans (e.g., Privacy Act, HIPAA); and e. Restoration priority of subsystems, processes, or information (See COEF).2. Components shall maintain and keep current their functional architecture documentation through disposal.

· DoDI 8500.2, Information Assurance (IA) Implementation, 06 February 2003


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 SSAA. A backup copy of the inventory is stored in a fire-rated container or otherwise not collocated with the original.

Organizations without a valid hardware baseline inventory are vulnerable to the introduction of unauthorized hardware to their IS. Additional concerns include not knowing what HW to use to rebuild a system after catastrophic loss. A current hardware baseline enables consistency within the environment and the rebuilding of information systems.

1. Each Component shall develop a current and comprehensive baseline inventory of all hardware (HW).2. At a minimum the baseline shall include manufacturer, type, model, physical location and network topology or architecture required to support enclave operations.3. Physical and logical location of hardware shall be recorded.4. The baseline shall be maintained by the Configuration Control Board (CCB) and as part of the system security documentation.5. A current and comprehensive backup copy of the inventory shall be stored in a fire-rated container or otherwise not collocated with the original.6. Regular updates to the HW baseline shall be managed through the CCB.7. The HW baseline shall be validated during turnover of duties to include but not limited to: management and operations.8. The HW baseline shall be validated not less then annually.

· ANSI/EIA-649 Configuration Management, “National Consensus Standard for Configuration Management”, July 1998

Interconnection Documentation


For AIS applications, a list of all (potential) hosting enclaves is developed and maintained along with evidence of deployment planning and coordination and the exchange of connection rules and requirements. For enclaves, a list of all hosted AIS applications, interconnected outsourced IT-based processes, and interconnected IT platforms is developed and maintained along with evidence of deployment planning and coordination and the exchange of connection rules and requirements.

Interconnected information systems create the risk of introducing security risks to linked systems if proper safeguards and considerations are not employed. To provide a reasonable level of assurance among interconnected information systems, appropriate documentation of the connecting system must be developed maintained.

1. Each Component with an existing or potential connection to another system shall identify and establish an agreement of operating parameters.2. Items such as data handling methods, personnel clearances requirements, and operating procedures must be approved by both DAA’s.3. Agreements shall be maintained and followed by each system.4. All potential changes to either system must be analyzed for IA and accreditation impact.

· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DoDI 8500.2, Information Assurance (IA) Implementation, para. E3.2.7, 06 February 2003

IA Impact Assessment


Changes to the DoD information system are assessed for IA and accreditation impact prior to implementation.

Arbitrary changes to DoD information systems have the potential to affect not only the primary system but any interconnected system as well. All changes must be analyzed for IA and accreditation impact prior to implementation to maintain system stability and accreditation.

1. A formal process that identifies changes that will affect IA and accreditation impact shall be developed.2. The CCB and the DIACAP Team shall work together to assess system changes for IA and accreditation impact prior to implementation.

· DoDI 8500.2, Information Assurance (IA) Implementation, para. E3.3.8, 06 February 2003· ANSI/EIA-649 Configuration Management, “National Consensus Standard for Configuration Management”, July 1998

DCIT-1 IA for IT Services High

DCMC-1 Mobile Code Medium


Acquisition or outsourcing of IT services explicitly addresses Government, service provider, and end user IA roles and responsibilities.

IA roles that are not clearly defined and expressed during the acquisition or outsourcing of IT services create a confusing environment where IA responsibility can be easily passed and accountability is nonexistent. By clearly defining and expressing IA roles, organizations ensure IA ownership, accountability, and IA consideration throughout the entire systems lifecycle.

During acquisition or outsourcing of IT services, contracts and other documentation identifying roles shall include Government, service provider, and end user IA roles and responsibilities for example: PM, IAM, User Representative, CA, DAA, SIAO, and CIO.

· DoDI 8500.2, Information Assurance (IA) Implementation, para. E3.3.5 - E3.3.6, 06 February 2003· NIST SP 800-35, Guide to Information Technology Security Services. October 2003· NIST SP 800-64, Security Considerations in the Information System Development Lifecycle. June 2004


The acquisition, development, and/or use of mobile code to be deployed in DoD systems meets the following requirements:1. Emerging mobile code technologies that have not undergone a risk assessment by NSA and been assigned to a Risk Category by the DoD CIO is not used.2. Category 1 mobile code is signed with a DoD-approved PKI code signing certificate; use of unsigned Category 1 mobile code is prohibited; use of Category 1 mobile code technologies that cannot block or disable unsigned mobile code (e.g., Windows Scripting Host) is prohibited.3. Category 2 mobile code, which executes in a constrained environment without access to system resources (e.g., Windows registry, file system, system parameters, network connections to other than the originating host) may be used.4. Category 2 mobile code that does not execute in a constrained environment may be used when obtained from a trusted source over an assured channel (e.g., SIPRNET, SSL connection, S/MIME, code is signed with a DoD-approved code signing certificate).5. Category 3 mobile code may be used.6. All DoD workstation and host software are configured, to the extent possible, to prevent the download and execution of mobile code that is prohibited.7. The automatic execution of all mobile code in email is prohibited; email software is configured to prompt the user prior to executing mobile code in attachments.

Without proper safeguards, the acquisition, development, and/or use of mobile code has the potential to introduce unexpected behavior to DoD information systems. Such behavior may include denial of service, destruction, masquerading, harassment, and theft of resources. Approved measures must be implemented to mitigate the inherent risks associated with mobile code.

The acquisition, development, and/or use of mobile code to be deployed in DoD systems shall meet the following minimum requirements: 1. Emerging mobile code technologies that have not undergone a risk assessment by NSA and been assigned to a Risk Category by the DoD CIO shall not used.2. Category 1 mobile code shall be signed with a DoD-approved PKI code signing certificate; use of unsigned Category 1 mobile code is prohibited; use of Category 1 mobile code technologies that cannot block or disable unsigned mobile code (e.g., Windows Scripting Host) is prohibited.3. Category 2 mobile code, which executes in a constrained environment without access to system resources (e.g., Windows registry, file system, system parameters, network connections to other than the originating host) may be used.4. Category 2 mobile code that does not execute in a constrained environment may be used when obtained from a trusted source over an assured channel (e.g., SIPRNET, SSL connection, S/MIME, code is signed with a DoD-approved code signing certificate).5. Category 3 mobile code may be used.6. All DoD workstation and host software shall be configured, to the extent possible, to prevent the download and execution of mobile code that is prohibited.7. The automatic execution of all mobile code in email is prohibited; email software shall be configured to prompt the user prior to executing mobile code in attachments.

· DoD Policy Guidance for use of Mobile Code Technologies in Department of Defense (DoD) Information Systems Memorandum, 07 November 2000· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), Appendix J to Enclosure C, 10 August 2004

DCNR-1 Non-repudiation Medium

DCPA-1 · DISA Web Server STIG, Version 5, 26 July 2004 Low

DCPB-1 High

DCPD-1 Medium


NIST FIPS 140-2 validated cryptography (e.g., DoD PKI class 3 or 4 token) is used to implement encryption (e.g., AES, 3DES, DES, Skipjack), key exchange (e.g., FIPS 171), digital signature (e.g., DSA, RSA, ECDSA), and hash (e.g., SHA-1, SHA-256, SHA-384, SHA-512). Newer standards should be applied as they become available.

Without the ability to ensure proof of sender identity as well as proof of delivery, organizations foster an environment of lawlessness where individuals can deny having processed data. NIST FIPS 140-2 validated cryptography provides a means to provide for non-repudiation.

1. Non-repudiation is accomplished by employing various mechanisms or techniques (e.g., digital signatures, digital message receipts, and time stamps).2. Each Component shall ensure proper non-repudiation implementation on all systems.3. Follow system specific and FIPS guidance for latest approved non-repudiation methods.4. NIST FIPS 140-2 validated cryptography (e.g., DoD PKI class 3 or 4 token) shall be used to implement encryption (e.g., AES, 3DES, DES, Skipjack), key exchange (e.g., FIPS 171), digital signature (e.g., DSA, RSA, ECDSA), and hash (e.g., SHA-1, SHA-256, SHA-384, SHA-512).5. Newer standards shall be applied as they become available.

· FIPS 140-2, Security Requirements for Cryptographic Modules, 25 May 2001

Partitioning the Application


User interface services (e.g., web services) are physically or logically separated from data storage and management services (e.g., database management systems). Separation may be accomplished through the use of different computers, different CPUs, different instances of the operating system, different network addresses, combinations of these methods, or other methods, as appropriate.

Unauthorized users as well as malicious insiders who gain access to a particular service will find it relatively easy to gain access and exploit another service on the same hard drive. As part of the defense in depth methodology, services must be separated to provide an additional layer of protection between them.

1. User interface services (e.g., web pages) are physically or logically separated from data storage and management services (e.g., database management systems).2. Separation may be accomplished through the use of different computers, different CPUs, different instances of the operating system, different network addresses, combinations of these methods, or other methods, as appropriate.

IA Program and Budget


A discrete line item for Information Assurance is established in programming and budget documentation.

Not having the ability to discern dollars associated with IA instances makes it near impossible to underscore its magnitude, thus hindering future appropriation of resources. A discrete line item for IA ensures proper tracking and forecasting of IA funding.

Component programming and budget documentation shall include a discrete line item for Information Assurance activities within their purview.

· DoDI 8500.2, Information Assurance (IA) Implementation, para. E3.3.4, 06 February 2003· Section 2224 of title 10, United States Code,"Defense Information Assurance Program”, 05 October 1999

Public Domain Software Controls


Binary or machine executable public domain software products and other software products with limited or no warranty such as those commonly known as freeware or shareware are not used in DoD information systems unless they are necessary for mission accomplishment and there are no alternative IT solutions available. Such products are assessed for information assurance impacts, and approved for use by the DAA. The assessment addresses the fact that such software products are difficult or impossible to review, repair, or extend, given that the Government does not have access to the original source code and there is no owner who could make such repairs on behalf of the Government.

Public domain software products introduce an element of uncertainty to DoD information systems due to their public and unsupported nature. Organizations should not use public domain software products unless required for a mission critical purpose and as approved by the DAA.

1. Components shall establish local policy governing freeware or shareware.2. The CCB shall ensure freeware or shareware applications are distributed and used as directed.3. Such products shall be assessed for information assurance impacts, and approved for use by the DAA.4. The assessment addresses the fact that such software products are difficult or impossible to review, repair, or extend.5. If such software products are determined to be warranted, the organization shall limit the distribution of software to those that have a legitimate business need.6. Periodic audits shall be conducted to ensure such software is being used for its intended business purpose.

· Open Source Software (OSS) in the Department of Defense (DoD) Memorandum., 28 May 2003· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)

DCPP-1 Medium

DCPR-1 CM Process High

DCSD-1 IA Documentation High

DCSL-1 Medium

Ports, Protocols, and Services


DoD information systems comply with DoD ports, protocols, and services guidance. AIS applications, outsourced IT-based processes and platform IT identify the network ports, protocols, and services they plan to use as early in the life cycle as possible and notify hosting enclaves. Enclaves register all active ports, protocols, and services in accordance with DoD and DoD Component guidance.

Open, undocumented, and unnecessary ports, protocols, and services increase the risk of data compromise and system unavailability. Adhering to DoD guidance minimizes the inherent risk associated with ports, protocols, and services.

1. DoD information systems shall comply with DoD ports, protocols, and services guidance.2. A port, protocol, or service that does not explicitly support a business function shall be disabled or removed.3. A list of ports, protocols, and services shall be documented and regularly updated and maintained through the CCB.4. Organizations shall identify the network ports, protocols, and services they plan to use within AIS applications, outsourced IT-based processes and platform IT as early in the life cycle as possible and notify hosting enclaves.5. Enclaves shall register all active ports, protocols, and services in accordance with DoD and DoD Component guidance.6. Components shall monitor emerging threats and vulnerabilities to the ports, protocols, and services they use.

· JTF-GNO PNP Update Message, 14 March 2003· ASD/C3I Memorandum DoD Ports, Protocols and Services, 28 January 2003· DoD Ports, Protocols and Services Security Technical Guidance, 05 November 2005· Firewall Guidance Message. September 2002· DoDI 8551.1, Ports, Protocols, and Services Management (PPSM), 13 August 2004·http://iase.disa.mil/ports/index.html· DoDD O-8530.1, Computer Network Defense (CND), 08 January 2001


A configuration management (CM) process is implemented that includes requirements for:1. Formally documented CM roles, responsibilities, and procedures to include the management of IA information and documentation;2. A configuration control board that implements procedures to ensure a security review and approval of all proposed DoD information system changes, to include interconnections to other DoD information systems;3. A testing process to verify proposed configuration changes prior to implementation in the operational environment; and4. A verification process to provide additional assurance that the CM process is working effectively and that changes outside the CM process are technically or procedurally not permitted.

Numerous security threats have the potential to be introduced to an information system when a proper CM process is not employed. A well designed and implemented configuration management process will provide a sound framework for an organization to manage and maintain DoD IA compliance.

Components shall establish a local configuration management (CM) process that includes consideration for the following: 1. Formally documented CM roles, responsibilities, and procedures to include the management of IA information and documentation;2. A configuration control board that implements procedures to ensure a security review and approval of all proposed DoD information system changes, whether scheduled or emergency, to include interconnections to other DoD information systems;3. A formal testing process to verify proposed configuration changes prior to implementation in the operational environment; and4. A verification process to provide additional assurance that the CM process is working effectively and that changes outside the CM process are technically or procedurally not permitted. Techniques such as auditing and verification testing can enable this.

· Carnegie Mellon Software Engineering Institute, Capability Maturity Model® Integration (CMMISM), Version 1, Release 1. CMMISM for Systems Engineering, Software Engineering, and Integrated Product and Process Development (CMMI-SE/SW/IPPD, Version 1, Release 1) Continuous Representation CMU/SEI-2002-TR-003 ESC-TR-2002-003. December 2001· DoD Systems Management College, Defense Acquisition University Press, Systems Engineering Fundamentals. December 2000· ANSI/EIA-649 Configuration Management, “National Consensus Standard for Configuration Management”, July 1998· IEEE 12207.0, Industry Implementation of International Standard ISO/IEC 12207: 1995 (ISO/IEC 12207)) Standard for Information Technology - Software Life Cycle Processes, 01 March 1998


All appointments to required IA roles (e.g., DAA and IAM/IAO) are established in writing, to include assigned duties and appointment criteria such as training, security clearance, and IT-designation. A System Security Plan is established that describes the technical, administrative, and procedural IA program and policies that govern the DoD information system, and identifies all IA personnel and specific IA requirements and objectives (e.g., requirements for data handling or dissemination, system redundancy and backup, or emergency response).

When local IA policies that govern DoD information systems are nonexistent, it is impossible for these systems to be accredited. Appropriate IA documentation is necessary to effectively communicate local IA instruction throughout the local enterprise.

1. All appointments to required IA roles (e.g., DAA and IAM/IAO) shall be qualified and at a minimum meet the eligibility requirements.2. Appointees shall acknowledge duties and criteria by reading and signing a designation document.3. A System Security Plan shall be developed that describes the technical, administrative, and procedural IA program and policies that govern the DoD information system, and identifies all IA personnel and specific IA requirements and objectives (e.g., requirements for data handling or dissemination, system redundancy and backup, or emergency response).

· DoDI 8500.2, Information Assurance Implementation, para. E3.3.5 - 6, 06 February 2003

System Library Management Controls


System libraries are managed and maintained to protect privileged programs and to prevent or minimize the introduction of unauthorized code.

Without appropriate library management controls, unauthorized code can intentionally or inadvertently be added to information systems. Software versioning, access rights, etc. all work towards maintaining a known configuration.

1. Libraries shall be controlled by the CCB.2. Access to libraries shall be restricted to a minimum number of individuals.3. A library access log shall be maintained, preferably automated.

· IEEE 12207.0, Industry Implementation of International Standard ISO/IEC 12207: 1995 (ISO/IEC 12207)) Standard for Information Technology - Software Life Cycle Processes, 01 March 1998

DCSP-1 Medium

DCSQ-1 Software Quality Medium

DCSR-3 High

DCSS-2 High

Security Support Structure Partitioning


The security support structure is isolated by means of partitions, domains, etc., including control of access to, and integrity of, hardware, software, and firmware that perform security functions. The security support structure maintains separate execution domains (e.g., address spaces) for each executing process.

The security support infrastructure of an information system, particularly in the form of an enclave or application suit isolated from the rest of the system, performs essential functions in guarding the confidentiality, integrity, and availability of the system. For this reason, the system is subject to compromise if the security support infrastructure is not appropriately isolated from the rest of the system and access granted only to appropriately authorized administrator personnel.

1. Review the system architecture documentation or other relevant functional architecture.2. Ensure that the security support structure is isolated by means of partitions, domains, etc., including control of access to, and integrity of, hardware, software, and firmware that perform security functions.3. Verify that the security support structure is maintaining a separate execution domain (e.g., address space) for each process that it is executing.

· DISA Network Infrastructure STIG, Version 5, Release 2, 29 September 2003· DISA Web Server STIG, Version 5, 26 July 2004


Software quality requirements and validation methods that are focused on the minimization of flawed or malformed software that can negatively impact integrity or availability (e.g., buffer overruns) are specified for all software development initiatives.

Poor software quality can introduce problematic behavior to DoD systems. Degradation to integrity or availability can negatively impact mission success. To promote software quality, strict requirements and validation methods must be established and followed.

1. Components engaged in software development initiatives shall develop local procedures and checklists to insure software quality.2. Formal software test methodologies shall be adhered to during all phases of product lifecycle.

· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)· IEEE 12207.0, Industry Implementation of International Standard ISO/IEC 12207: 1995 (ISO/IEC 12207)) Standard for Information Technology - Software Life Cycle Processes, 01 March 1998

Specified Robustness – High


Only high-robustness GOTS or COTS IA and IA-enabled IT products are used to protect classified information when the information transits networks that are at a lower classification level than the information being transported. High-robustness products have been evaluated by NSA or in accordance with NSA-approved processes. COTS IA and IA-enabled IT products used for access control, data separation or privacy on classified systems already protected by approved high-robustness products at a minimum, satisfy the requirements for basic robustness. If these COTS IA and IA-enabled IT products are used to protect National Security Information by cryptographic means, NSA-approved key management may be required.

Utilizing GOTS or COTS IA and IA-enabled IT products that are designated at a lower robustness then is required will increase network vulnerability by not adequately protecting DoD data and information systems. By adhering to robustness requirements, organizations can be confident that they are applying the appropriate level of protection to their network.

1. Use high-robustness GOTS or COTS IA and IA-enabled IT products to protect classified information when the information transits networks at a lower classification level than the information being transported. *2. Ensure all High-robustness designated products have been evaluated by NSA in accordance with NSA-approved processes. *3. COTS IA and IA-enabled IT products used for access control, data separation or privacy on classified systems already protected by approved high-robustness products at a minimum, satisfy the requirements for basic robustness. If these COTS IA and IA-enabled IT products are used to protect National Security Information by cryptographic means, NSA-approved key management may be required. * * Note: These requirement are more stringent than DCSR-2

· DoD CIO Guidance and Policy Memorandum No. 6-8510, DoD GIG IA, 16 June 2000· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DoDI 8500.2, Information Assurance Implementation, para. E3.2.4.3, .1, .2, 06 February 2003· Information Assurance Technical Framework, Appendix E IATF Release 3.1. September 2002

System State Changes


System initialization, shutdown, and aborts are configured to ensure that the system remains in a secure state. Tests are provided and periodically run to ensure the integrity of the system state.

When systems are in a state of transition they may be susceptible to unauthorized access or to attack. Means shall be employed to ensure unauthorized changes to the system state are not allowed during transition.

1. Identify system transition states and refer to appropriate DISA, NSA, or other approved security technical implementation guide for specific configuration guidance.

· Refer to application-specific DoD, DISA, & NSA STIG· DoDI 8551.1, Ports, Protocols, and Services Management (PPSM), 13 August 2004· DoDI 8500.2, Information Assurance (IA) Implementation, para. E3.2.4, E3.2.6, 06 February 2003

DCSW-1 SW Baseline High

EBBD-3 High


A current and comprehensive baseline inventory of all software (SW) (to include manufacturer, type, and version and installation manuals and procedures) required to support DoD information system operations is maintained by the CCB and as part of the C&A documentation. A backup copy of the inventory is stored in a fire-rated container or otherwise not collocated with the original.

Without a comprehensive software baseline, it may not be possible to identify unauthorized changes to system software or to successfully rebuild network equipment after facility loss. Maintaining a SW baseline allows for periodic software consistency checks and dependable system rebuilds.

1. Each Component shall develop a current and comprehensive baseline inventory of all software (SW).2. At a minimum the baseline shall include manufacturer, type, model, physical location and network topology or architecture required to support enclave operations.3. Physical and logical location of software shall be recorded.4. The baseline shall be maintained by the Configuration Control Board (CCB) and as part of the system security documentation.5. A current and comprehensive backup copy of the inventory shall be stored in a fire-rated container or otherwise not collocated with the original.6. Regular updates to the SW baseline shall be managed through the CCB.7. The SW baseline shall be validated during turnover of duties to include but not limited to: management and operations.8. The SW baseline shall be validated not less then annually.

· ANSI/EIA-649 Configuration Management, “National Consensus Standard for Configuration Management”, July 1998

Boundary Defense


Boundary defense mechanisms to include firewalls and network intrusion detection systems (IDS) are deployed at the enclave boundary to the wide area network, and at layered or internal enclave boundaries and key points in the network as required. All Internet access is prohibited.

Systems processing classified information require layered defensive mechanisms to control access to the information from outside the enclave, as well as prevent inadvertent disclosure by allowing connections to the public Internet. This protection is achieved by implementing boundary defense mechanisms such as firewalls and Intrusion Detection Systems (IDS), as well as securely configuring enclave routers, to ensure that access to classified information is restricted to authorized users and trusted sources. Access to the public Internet from a classified system enclave would result in almost certain compromise of classified data. For this reason access to external (Internet) systems is prohibited by the boundary defense mechanisms.

This guidance is designed for IAMs, PMs, SMEs, System Administrators, and all personnel involved in the design and implementation of boundary defense: 1. As part of the system design process, identify the specific boundary defense mechanisms to be incorporated into the system security architecture. When making the decision to select specific hardware and software applications for these devices (e.g., firewalls, IDS), refer to the list of devices that have been evaluated by the NIAP program under Common Criteria and meet the fundamental requirements outlined in NSTISSP 1. This list is available online at: http://niap.nist.gov/cc-scheme/vpl/vpl_type.html.2. Review the NIAP evaluation summary for each product, focusing on the Evaluation Assurance Level (EAL) for each product. For information systems processing classified information as national security systems, a minimum evaluation level of EAL-3 is required.3. Once boundary defense mechanisms for the system have been identified, ensure that each mechanism is incorporated into a system security architecture documentation that details physical and logical placement of the mechanism within the system, data flows, ports, protocols, and services used; and interconnections between related systems or network segments.4. Ensure that all boundary defense devices for classified systems (i.e., firewalls, IDS, and boundary routers) are configured in accordance with approved DoD secure configuration standards, preferably the most current DISA STIGs for each specific mechanism. If STIGs are unavailable for specific mechanisms, refer to other approved DoD guidance such as NSA configuration guidelines, DoD guidelines created by or adopted from other organizations, or the vendor’s own configuration guidance.5. Ensure that access lists and rule bases for boundary routers and firewalls for the classified system are configured to prohibit access to or from any network segment enabling access to the public Internet.6. Ensure that boundary defense mechanisms adhere to the DoD ports, protocols, and services implementation process.7. Ensure that enclave boundary defenses include the following: · Capability to monitor higher layer protocols (commonly called “deep-content scans”). · Active monitoring of event logs on a continual basis and prompt response to threats.

· DISA Network Infrastructure STIG, Version 6, 29 October 2003· DISA Enclave Security STIG, Version 2, Release 1, 01 July 2004· DISA Enterprise Security Management STIG, Version 1, Section 3, paragraph 3.5, 29 October 2004· Cisco IOS Router Checklist Procedure Guide (Supp. to Network Infrastructure Checklist Version 5, Release 2.1, 01 June 2004)· Juniper JUNOS Router Checklist Procedure Guide (Supp. to Network Infrastructure ChecklistVersion 5, Release 2.1, 17 June 2004)· DISA Secure Remote Computing STIG, Version 1, Release 1, Sections 5 and 6, 04 February 2003· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)· DoDI 8551.1 “Ports, Protocols, and Services Management”, Enclosure 3, 13 August 2004

EBCR-1 Connection Rules Medium

EBRP-1 High

EBRU-1 High

EBVC-1 VPN Controls Medium


The DoD information system is compliant with established DoD connection rules and approval processes.

A connection between any type of, or agency owned, information system increases the risk of exploiting existing vulnerabilities with new threats. Great care has been taken in the development of DoD connection rules. It is paramount they be adopted to ensure proper risk management and documentation processes are employed when connecting to disparate systems.

1. To start the connection process, Components shall begin by identifying the following in relation to their network as well as the network they wish to connect to: · Information system owner; · DAA of system; · Classification levels processed; and · Ports, protocols and services used.2. Interconnection risks and agreements shall be reviewed and approved by each DIACAP Team prior to DAA submission.3. Refer to DoD or other applicable guidance for proper connection requirements and procedures.4. Connections shall be audited not less then annually to ensure proper configuration and compliance with regulations.

· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DISA Network Infrastructure STIG, Version 6 Draft, 29 October 2004· DoDI 8500.2, Information Assurance Implementation, 06 February 2003· DISA Enclave Security STIG, Version 2, Release 1, 01 July 2004

Remote Access for Privileged Functions


Remote access for privileged functions is discouraged, is permitted only for compelling operational needs, and is strictly controlled. In addition to EBRU-1, sessions employ security measures such as a VPN with blocking mode enabled. A complete audit trail of each remote session is recorded, and the IAM/IAO reviews the log for every remote session.

Remote access for privileged functions is especially dangerous due to the transmission of administer usernames and passwords over non-DoD media and devices. Compromised privileged credentials can cause network denial of service and of unauthorized use of sensitive DoD information. Proper security precautions such as correct use of VPN and auditing minimize the risk of network compromise and attack.

1. If needed for a compelling operational need, remote access for privileged functions shall be used only with VPN.2. Auditing of each remote VPN session shall be enabled.3. The IAM/IAO shall review the audit log for every remote session.4. Refer to DoD or other applicable guidance for proper connection requirements and procedures.

· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DISA Network Infrastructure STIG, Version 6 Draft, 29 October 2004· DISA Secure Remote Computing STIG, Version 1, Release 1, 14 February 2003· DISA Enclave Security STIG, Version 2, Release 1, 01 July 2004

Remote Access for User Functions


All remote access to DoD information systems, to include telework access, is mediated through a managed access control point, such as a remote access server in a DMZ. Remote access always uses encryption to protect the confidentiality of the session. The session-level encryption equals or exceeds the robustness established in ECCT. Authenticators are restricted to those that offer strong protection against spoofing. Information regarding remote access mechanisms (e.g., Internet address, dial-up connection telephone number) is protected.

Remote access allows users to interact with enclave resources from afar. This convenience introduces inherent risks such as spoofing and brute force attacks. Proper security precautions such as a properly configured remote access server in a DMZ along with approved encryption techniques minimize the chance of network compromise and attack.

1. All remote access connections shall authentic network users and encrypt transmitted data by using approved access controls and cryptographic means.2. Components shall establish a process for managing remote access user accounts to include prompt account removal or disablement as warranted.3. Components shall take steps to ensure remote access numbers or Internet addresses are secure.4. Refer to DoD or other applicable guidance for proper connection requirements and procedures.

· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DISA Network Infrastructure STIG, Version 6 Draft, 29 October 2004· DISA Secure Remote Computing STIG, Version 1, Release 1, 14 February 2003· Public Law 106-346, Section 359, Attachment 1, Memorandum to Executive Departments and Agencies, Congressional Federal Telework Mandate 2001, 23 October 2000· DISA Enclave Security STIG, Version 2, Release 1, 01 July 2004· UNIX STIG, Version 4, Release 4, 15 September 2003


All VPN traffic is visible to network intrusion detection systems (IDS).

The use of VPN creates an environment where network traffic travels in and out of physical network boundaries. Albeit relatively secure, allowing VPN connections introduces a point of entry into a network. This tunnel into a system creates the potential for unauthorized and unwanted traffic entering or leaving the core network. Ensuring all VPN traffic is visible to network IDS enables components to monitor this connection for anomalies.

1. Components shall ensure network intrusion detection systems (IDS) are positioned to monitor all VPN Traffic.2. Refer to DoD or other applicable guidance for proper connection requirements and procedures.

· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DISA Network Infrastructure STIG, Version 6 Draft, 29 October 2004· DISA Secure Remote Computing STIG, Version 1, Release 1, 14 February 2003· DISA Enclave Security STIG, Version 2, Release 1, 01 July 2004

ECAD-1 Affiliation Display MediumEnclave Computing Environment

To help prevent inadvertent disclosure of controlled information, all contractors are identified by the inclusion of the abbreviation "ctr" and all foreign nationals are identified by the inclusion of their two character country code in: - DoD user e-mail addresses (e.g., [email protected] [email protected]); - DoD user e-mail display names (e.g., John Smith, Contractor <[email protected]> or John Smith, United Kingdom <[email protected]>); and - automated signature blocks (e.g., John Smith, Contractor, J-6K, Joint Staff or John Doe, Australia, LNO, Combatant Command). Contractors who are also foreign nationals are identified as both (e.g.,[email protected]). Country codes and guidance regarding their use are in FIPS 10-4.

Classified and sensitive information could be disclosed to unauthorized users who do not have proper security clearances and need to know. Proper assignment of user accounts and email addresses will protect classified and sensitive information from unauthorized disclosure, modification, or destruction. This implementation guide is aimed to help system and network managers/administrators implement consistent assignment and maintenance of user profile.

1. Once a user submits a DOD standard or agency’s Access Request Form upon approval of the user’s manager/supervisor, the system/network administrator shall review the user information and determine if the user is a contractor or a foreign national.2. If the user is a contractor, the system/network administrator, when creating the new user account, shall assign the abbreviation “CTR” to his/her email address (e.g.,[email protected]). Configure the email server to display the email address on the screen, such as John Smith, Contractor [email protected]. If the user is a foreign national, review the country code identified in FIPS 10-4 and include their two character country code in (e.g.,[email protected]) and configure the email server to display the email address on the screen as John Smith, United Kingdom [email protected]. If the user is both contractor and foreign national, include both information (e.g.,[email protected]).5. The network administrator shall assign names for the automated signature block to include contractor or country name as follows: John Smith, Contractor, J-6K, Joint Staff or John Doe, Australia, LNO, Combatant Command.6. The network administrator shall test the proper display of the email addresses by sending an initial email to the new user and verify if the email address is shown as described above.

· DoDD 5200-2, DoD Personnel Security Program, 09 April 1999

ECAN-1 HighAccess for Need-to-Know

Enclave Computing Environment

Access to all DoD information (classified, sensitive, and public) is determined by both its classification and user need-to-know. Need-to-know is established by the Information Owner and enforced by discretionary or role-based access controls. Access controls are established and enforced for all shared or networked file systems and internal websites, whether classified, sensitive, or unclassified. All internal classified, sensitive, and unclassified websites are organized to provide at least three distinct levels of access:1. Open access to general information that is made available to all DoD authorized users with network access. Access does not require an audit transaction.2. Controlled access to information that is made available to all DoD authorized users upon the presentation of an individual authenticator. Access is recorded in an audit transaction.

Unauthorized access could be made to classified and sensitive information that must be protected from unauthorized disclosure, modification, or destruction. This implementation guide is aimed to help web administrators/network administrators implement proper discretionary or role based access controls, as well as user authenticators and audit trails to prevent and detect unauthorized access to system data effectively.

1. For the system that provides public information without restrictions, the web administrator shall implement the following for the external web server: a. Implement an external router between the external web server and the Internet to filter the traffic to the external web server. b. Configure the web server in accordance with the DISA Web Server STIG c. Configure the web server operating system in accordance with proper DISA STIGs (e.g., Windows, Unix) d. Provide only Read access to Public e. Disable the public access auditing feature to prevent system crash f. Restrict access to a limited number of people for web content management2. For the system that provides classified and/or sensitive information to all DOD authorized users with network access, the web administrator shall implement the following for the internal web server: a. Implement internal firewalls, routers, and switches in accordance with DOD SIPRNET and NIPRNET Connection Approval Process b. Configure the internal web server in accordance with DISA Web Server STIG c. Configure the web server operating system (e.g., Windows, Unix) in accordance with proper DISA STIGs, which require DOD approved user ID and authenticators (e.g., password, token) prior to system access d. Configure the database containing classified and sensitive information made available to all DOD users in accordance with DISA Database STIG for role based access controls in the areas of table and column privileges and file permissions e. Configure the web application properly to prevent any direct access of users to the database f. Configure the audit features of the system components (e.g., operating system, database, and application) to capture security related activities (e.g., logon/logoff) g. Maintain and update a list of user accounts regularly to prevent unauthorized access3. For the system that is available only to an authorized community of interest, the system/network administrator shall implement the following: a. Configure the system server operating system in accordance with proper DISA STIGs (e.g., Windows, Unix) or NSA security guides b. Assign user accounts and authenticators based on need to know in accordance with DOD and organization’s security policies c. Configure the system to request user ID and authenticator prior to system access d. Maintain and update a list of user accounts regularly in accordance with DOD personnel security program and organization’s guidance e. Configure the databases containing classified and/or sensitive information in accordance with the DISA Database STIGs, NSA database security guides, and vendor’s security administration guide to provide role based access controls in the areas of table and column privileges and file permissions f. Configure the auditing features of the operating system, database, and application to record security related events, to include logon/logoff and all failed access attempts)

· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DISA Web Server STIG, 26 July 2004· DISA Windows NT Security Checklist, 10 December 2004· DISA Windows 2003 Security Checklist (draft), 10 December 2004· DISA Unix STIG, 15 September 2003· DISA UNISYS STIG, 22 July 2003· DISA Solaris Security Checklist, 20 January 2004· DOD Database STIG, 24 July 2004· DOD Web Site Administration Policy and Procedures, 11 January 2002· DOD OC/390 RACF Checklist October 2004· DOD OC/390 ACF2 Checklist October 2004· DOD OC/390 TSS Checklist October 2004· NSA Microsoft SQL Server Guides, 02 October 2003· NSA Oracle Database Server Guides, 02 October 2003· NSA Secure Configuration of the Apache Web Server, Apache Server Version 1.3.3 on Red Hat Linux 5.1, 10 November 2003· NSA Guide to the Secure Configuration and Administration of the iPlanet Web Server, Enterprise Edition 4.1, 10 November 2003· NSA Guide to the Secure Configuration and Administration of Microsoft Internet Information Server 4.0, 10 November 2003· NIST SP 800-44, Guidelines on Securing Public Web Servers, September 2002· NIST SP 800-47, Security Guide for Interconnecting Information Technology Systems, August 2002· Service/agency specific references/guidelines/manuals

ECAR-3 High

ECAT-2 Medium

Audit Record Content – Classified Systems


Audit records include: · User ID. · Successful and unsuccessful attempts to access security files. · Date and time of the event. · Type of event. · Success or failure of event. · Successful and unsuccessful logons. · Denial of access resulting from excessive number of logon attempts. · Blocking or blacklisting a user ID, terminal or access port, and the reason for the action. · Activities that might modify, bypass, or negate safeguards controlled by the system. · Data required auditing the possible use of covert channel mechanisms. · Privileged activities and other system-level access. · Starting and ending time for access to the system. · Security relevant actions associated with periods processing or the changing of security labels or categories of information.

Insufficient security related information recorded in the audit trails could not support system forensics effectively and efficiently. This implementation guide is aimed to help system administrators configure system audit mechanisms properly to provide effective monitoring and detection of security problems. As a result, security fixes can be implemented in a timely manner.

1. The system administrator shall select audit events against security files of individual system components in accordance with DISA STIGs related to operating system, database, and application, such as excessive number of logon attempt; blocking or blacklisting a user ID; and bypassing or negating safeguards controlled by the system.2. The system administrator shall configure the system audit features to record system access-level auditing regarding root/administrator logons; access level change; security policy change; creation, deletion, or modification of security label change; and use of covert channel mechanisms.3. The system administrator shall configure each audit event to record sufficient information in the audit trails such as date/time of the event, user ID, source, target, type of event, and success/failure.4. If the system does not provide the capability of recording DOD required security events, the system administrator shall identify and install a DOD approved 3rd party product and configure it in accordance with DISA STIGs and vendor documentation for auditing.5. The system administrator shall test the auditing capability to ensure that the audit trails record required security events; each event contains sufficient information to support system forensics; and the auditing functions do not affect system operations.

· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DISA Windows NT Security Checklist, 10 December 2004· DISA Windows 2003 Security Checklist (draft), 10 December 2004· DISA Unix STIG, 15 September 2003· DISA UNISYS STIG, 22 July 2003· DISA Solaris Security Checklist, 20 January 2004· DISA Database STIG, 24 July 2004· DOD OC/390 RACF Checklist October 2004· DOD OC/390 ACF2 Checklist October 2004· DOD OC/390 TSS Checklist October 2004· NSA Microsoft SQL Server Guides, 02 October 2003· NSA Oracle Database Server Guides, 02 October 2003

Audit Trail, Monitoring, Analysis and Reporting


An automated, continuous on-line monitoring and audit trail creation capability is deployed with the capability to immediately alert personnel of any 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.

Lack of automated, continuous on-line monitoring and audit capability would cause the delay of detection of security violations, and further damage to the system would not be prevented in a timely manner. This implementation guide is aimed to help network administrators implement an automated auditing tool that can provide continuous on-line monitoring and audit report generation to provide effective and efficient detection of minor and/or major security violations that affect critical system operations.

1. The system engineering team (consisting of project manager, system engineer, network administrator, security engineer, IA personnel) shall identify a list of DOD approved automated, continuous on-line monitoring tools (e.g. intrusion detection system).2. The system project management team shall perform an analysis of advantages and disadvantages of individual monitoring tools based on tool functions, system environment, and fund.3. The system project management team shall select an automated, continuous on-line monitoring tool that is the best suitable to the system environment.4. The network administrator shall install the selected automated, continuous on-line monitoring tool in a lab environment and configure the tool properly in accordance with vendor security checklists and/or industry best practices.5. The network administrator shall test the tool, at a minimum, the following capabilities: · Recording and monitoring security events on real-time · Alerting personnel immediately of any unusual or inappropriate security activity · Disabling the system if serious IA violations are detected based on detection signatures.6. The network administrator shall determine the options of alerting via pager, email, or cell phone and configure it so that is alerts operators immediately when a security violation is detected.7. If the tool works as planned, the network administrator shall implement the tool into the system in the operational environment.

· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DISA Network Infrastructure STIG, 29 September 2003·NIST - Guide to Intrusion Detection and Prevention Systems (IDPS)· NIST SP 800-36, Guide to Selecting Information Security Products, October 2003

ECCD-2 Changes to Data High

ECCM-1 COMSEC High

ECCR-2 Medium


Access control mechanisms exist to ensure that data is accessed and changed only by authorized personnel. Access and changes to the data are recorded in transaction logs that are reviewed periodically or immediately upon system security events. Users are notified of time and date of the last change in data content.

Lack of proper access controls would allow unauthorized users to gain access to the system. This would impact the integrity, confidentiality, and availability of the system and its data. This implementation guide is aimed to help system administrators implement proper access controls through user privileges, file permissions, auditing, and user notification.

1. The system, database, and/or application administrators shall create user accounts only upon approval of System Access Request by authorized personnel (e.g., user manager/supervisor/IAM/IAO).2. The system, database, and/or application administrators shall determine user privileges required to perform their job functions.3. The system, database, and/or application administrators shall configure the system software (e.g., operating system, database, and application) to which users have access to read or modify data to perform job functions in accordance with DISA STIGs applicable to the software based on the least privileges and need to know.4. The administrators shall configure the audit trails and transaction logs to capture user access to the software/application.5. The administrators shall configure the system to display and generate audit reports for regular reviews or immediate reviews upon system security events.6. The system administrator shall research and determine if the system software provides the capability of notifying users of time and date of the last change in data content and perform the following: a. If the system provides the capability, the system administrator shall enable the capability. b. If the system does not provide the capability, the administrators shall implement other means (e.g., scripts) into the system to notify users of time and date of the last change in data content.7. The system administrator shall generate and review the audit trails and the transaction logs on a regular basis or immediately upon system security events.

· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DISA Windows NT Security Checklist, 10 December 2004· DISA Windows 2003 Security Checklist (draft), 10 December 2004· DISA Unix STIG, 15 September 2003· DISA UNISYS STIG, 22 July 2003· DISA Solaris Security Checklist, 20 January 2004· DISA Database STIG, Version 7, Release 1, 29 October 2004· DOD OC/390 RACF Checklist October 2004· DOD OC/390 ACF2 Checklist October 2004· DOD OC/390 TSS Checklist October 2004· NSA Microsoft SQL Server Guides, 02 October 2003· NSA Oracle Database Server Guides, 02 October 2003


COMSEC activities comply with DoD Directive C-5200.5.

Improper handling of COMSEC devices and encryption keys will affect the confidentiality, integrity, and availability of classified and sensitive information. This implementation guide is aimed to help COMSEC personnel implement controls regarding proper safeguard, operation and maintenance of COMSEC devices and encryption keys.

1. The Communications Security Officer (CSO) shall ensure the development of a COMSEC Material Control Guide in accordance with DOD and NSA guidelines and organization specific COMSEC guide. This guide shall include the following information at a minimum: · COMSEC material identification and accountability · COMSEC material control (e.g., forms, accounting reports, hand receipts) · Accounting forms · Receipt and transfer of COMSEC material · Packaging and shipment of COMSEC material · Inventory of accountable COMSEC material · Storage and destruction of COMSEC material · Reporting of COMSEC incidents · Creating and closing a COMSEC account2. The CSO shall establish a COMSEC account.3. The CSO shall designate COMSEC custodian and alternate custodian in writing.4. COMSEC custodians shall take security trainings relevant to COMSEC material controls and be familiar with COMSEC procedures.

· DoDD C-5200.5, Communications Security (COMSEC), 21 April 1990· NSA/CSS CSCM-1, NSA COMSEC Material Control Manual, February 1985· National COMSEC Instruction (NACSI) No. 4005, Safeguarding and Controls of Communications Security Material, 12 October 1979· NSTTSST No. 4000, Communications Security Equipment Maintenance and Maintenance, Training, 01 February 1991· NTISSI No. 4001, Controlled Cryptographic Items, March 1985· NTTSSI No. 4002, Classification Guide for COMSEC Information, 05 June 1985· NSTISSI No. 4003, Reporting and Evaluating COMSEC Incidents, 02 December 1991· NTISSI No. 4004, Routine Destruction and Emergency Protection of COMSEC Material, 11 March 1987· NTISSI No. 4005, Control of Top Secret Keying Material, 02 May 1989· NTISSI No. 4006, Controlling Authorities for COMSEC Material, 02 December 1991

Encryption for Confidentiality (Data at Rest)


If required by the information owner, NIST-certified cryptography is used to encrypt stored classified non-SAMI information.

Without proper cryptography methods being used, it would affect the confidentiality, integrity, and availability of classified non-SAMI information. This implementation guide is aimed to help information owners implement proper cryptography to protect all classified non-SAMI information stored within the enclave.

1. The information owner shall determine whether non-SAMI in the classified enclave requires encryption-at-rest to protect privacy and need-to-know.2. If the classified enclave contains non-SAMI, the system engineering team (e.g., project manager, system engineers, and IA personnel) shall perform the following: a. Identify a list of NIST-certified cryptography algorithms and keys (e.g., 3DES, AES) that can encrypt stored classified non-SAMI information b. Research vendors products that have been certified based on NIST-certified cryptography c. Perform an analysis of advantages and disadvantages of individual cryptography products based on system’s operational requirements and available fund d. Select a product that is the most suitable to the system’s environment to encrypt classified non-SAMI information e. Test the encryption capability in a lab environment f. Implement the NIST-approved cryptography into the system in the operational environment

· FIPS 197, Advanced Encryption Standard. 26 November 2001· FIPS 140-2, Security Requirements for Cryptographic Modules, 25 May 2001· NIST SP 800-21, Guideline for Implementing Cryptography in the Federal Government, November 1999· NIST SP 800-67, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, May 1004· NIST SP 800-36, Guide to Selecting Information Security Products, October 2003

ECCR-3 High

ECCT-2 High

ECDC-1 Medium

Encryption for Confidentiality (Data at Rest)


If a classified enclave contains SAMI and is accessed by individuals lacking an appropriate clearance for SAMI, then NSA-approved cryptography is used to encrypt all SAMI stored within the enclave.

Without proper cryptography methods being used, it would affect the confidentiality, integrity, and availability of Sources and Methods Intelligence (SAMI). This implementation guide is aimed to help information owners implement proper cryptography to protect all SAMI information stored within the enclave.

1. The information owner shall determine if the classified enclave contains SAMI and is accessed by individuals lacking an appropriate clearance for SAMI.2. If the classified enclave is affected, the system engineering team (e.g., project manager, system engineers, and IA personnel) shall perform the following: a. Obtain a list of NSA-approved cryptography algorithms and keys (e.g., AES, private and public keys) b. Research and obtain a list of NSA-approved encryption products (e.g., HAIPE devices) c. Perform an analysis of advantages and disadvantages of individual cryptography methods based on system’s operational requirements and available fund d. Select a cryptography method that is the most suitable to the system environment to encrypt SAMI information stored within the enclave e. Test the encryption capability in a lab environment f. Implement the NSA-approved cryptography into the system in the operational environment

· High Assurance Internet Protocol Interoperability Specification (HAIPIS)· FIPS 197, Advanced Encryption Standard. 26 November 2001· FIPS 140-2, Security Requirements for Cryptographic Modules, 25 May 2001· NIST SP 800-21, Guideline for Implementing Cryptography in the Federal Government, November 1999· NIST SP 800-36, Guide to Selecting Information Security Products, October 2003

Encryption for Confidentiality (Data at Transmit)


Classified data transmitted through a network that is cleared to a lower level than the data being transmitted are separately encrypted using NSA-approved cryptography (See also DCSR-3).

Without separation of different classification levels of data, classified data transmitted would be disclosed, modified, or destroyed by unauthorized users. This implementation guide is aimed to help system engineering teams implement proper cryptography to protect classified information transmitted.

1. The system engineering team (e.g., project manager, system engineers, security engineer, and IA personnel) shall perform the following: a. Identify a list of NSA-approved encryption methods (e.g., NSA-certified Type-1 HAIPE devices) that can encrypt classified information transmitted through a network that is cleared to a lower level than the data being transmitted b. Research NSA-certified HAIPE devices (e.g., KG-250, KG-240) c. Perform an analysis of advantages and disadvantages of individual encryption devices based on system’s operational requirements and available fund d. Select an encryption device that is the most suitable to the system’s environment to encrypt classified data transmitted e. Install and test the encryption capability in a lab environment to ensure classified data is transmitted in encrypted form through a separate tunnel f. Implement the devices into the system in the operational environment

· High Assurance Internet Protocol Interoperability Specification (HAIPIS)· FIPS 197, Advanced Encryption Standard. 26 November 2001· FIPS 140-2, Security Requirements for Cryptographic Modules, 25 May 2001· NIST SP 800-21, Guideline for Implementing Cryptography in the Federal Government, November 1999· NIST SP 800-36, Guide to Selecting Information Security Products, October 2003

Data Change Controls


Transaction-based systems (e.g., database management systems, transaction processing systems) implement transaction roll-back and transaction journaling, or technical equivalents.

Without implementing transaction roll-back and journaling, unauthorized or unintentional modification or destruction of data stored in the database would cause the loss of critical data. This implementation guide is aimed to help database administrators ensure the recovery of database data that was modified or deleted unintentionally or by unauthorized users.

1. The database administrator shall identify and determine if the database systems (e.g., Oracle, Microsoft SQL Server) implemented into the system provide transaction capabilities (e.g., transaction roll back and transaction journaling).2. If the database systems provide the capability of transaction roll back and journaling, the database administrator shall enable the capability in order to log database updates to either files or disk partition according to DISA Database STIG and organization specific database guides.3. If the database systems do not provide the transaction roll back and journaling or technical equivalent, the database administrator shall: · Identify a DoD approved 3rd party product that provides transaction roll back and journaling or technical equivalent · Configure the product and test it in a lab environment to ensure it functions properly · Install the product on the database system in the operational environment

· DISA Database STIG, Version 7, Release 1, 29 October 2004· NSA Microsoft SQL Server Guides, 02 October 2003· NSA Oracle Database Server Guides, 02 October 2003· Center for Internet Security Database Security Checklist, 06 April 2005· Vendor Security Administration Guide, (Refer to if no DSSA/NSA/NIST/USG guidance is available)

ECIC-1 Medium

ECID-1 Host Based IDS Medium

Interconnections among DoD Systems and Enclaves


Discretionary access controls are a sufficient IA mechanism for connecting DoD information systems operating at the same classification, but with different need-to-know access rules. A controlled interface is required for interconnections among DoD information systems operating at different classifications levels or between DoD and non-DoD systems or networks. Controlled interfaces are addressed in separate guidance.

Lack of proper protection mechanisms (e.g., discretionary access controls) for information sharing would allow unauthorized access, resulting in unauthorized disclosure, modification, or destruction of classified and/or sensitive information. This implementation guide is aimed to help system/network administrators implement proper access controls for the controlled connectivity.

1. When connecting the information systems operating at the same classification level (e.g., classified system to classified system, sensitive system to sensitive system), the network/system administrator shall perform the following: a. The network administrator shall configure the router properly using the access control list in accordance with DISA router STIGs, NSA router security configuration guide, and organization’s specific router guide so that only authorized services/applications can be transferred from the source to the destination. b. The system administrator shall configure the system software (e.g., operating system, database, application) securely to restrict access to system information only to authorized personnel in accordance with DISA STIGs, NSA security guides, and organization’s specific guides.2. When connecting the information systems operating at different classification levels (e.g., Top Secret to Secret, Secret to Unclassified), or when connecting DoD and non-DoD systems/networks, the network/system administrator shall perform the following: a. Research the type of methods that can be used for cross domain solutions (e.g., gateways, guards) in the system environment b. Perform an analysis of advantages and disadvantages of individual cross domain solutions based on functions and security features c. Select the best suitable method and install it in the lab environment d. Configure the gateway and/or guard securely based on DISA STIGs and vendors security administration guides e. Test the component for its adequacy and implement it into the system in the operational environment3. If the system is a part of the Global Information Grid (GIG), the network administrator shall install the NSA-developed Cross Domain Solution package, if available, and configure it properly.

· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· CJCSI - Defense Information System Network (DISN): Policy and Responsibilities· DISA Cisco IOS Router Checklist, Version 5, Release 2.1, 01 June 2004· DISA Jupiter Router Checklist, Version 5, Release 2.1, 17 June 2004· DISA Network STIG, 29 October 2004· DISA Network Infrastructure STIG, 29 September 2003· DODI 8540.aa, Interconnection and Data Transfer between Security Domains· NIST SP 800-36, Guide to Selecting Information Security Products, October 2003


Host-based intrusion detection systems are deployed for major applications and for network management assets, such as routers, switches, and domain name servers (DNS).

Without proper installation of IDS, intrusions to and hacker attacks against system’s major applications or network assets could not be detected in a timely manner. This implementation guide is aimed to help network administrators implement host- and network-based IDSs for the system to monitor and detect security violations and intrusions.

1. The network administrator shall identify a list of DOD approved host-based and network-based IDSs (e.g., ISS Real Secure, ISS Proventia, Symantec Intruder Alert).2. The network administrator shall perform an analysis to determine advantages and disadvantages of individual IDSs identified.3. The network administrator shall select host-based and network-based IDSs that satisfy the IA requirement and that are suitable to the system and network environment.4. The network administrator shall install the IDSs in a lab environment, configure the IDSs in accordance with vendor’s security administration guide, and test the installed IDSs for their functionality.5. The network administrator shall install the IDSs in the operational environment.6. The project management shall determine who will operate and review the IDSs and the method of managing the IDS (e.g., remote management via VPN in band/out of band, local management)

· DISA Network Infrastructure STIG, Section 3.8, Network Intrusion Detection, 29 September 2003·NIST - Guide to Intrusion Detection and Prevention Systems (IDPS)· NIST SP 800-36, Guide to Selecting Information Security Products, October 2003· Vendor Security Administration Guide, (Refer to if no DSSA/NSA/NIST/USG guidance is available)

ECIM-1 Medium

ECLC-1 Low

Instant Messaging


Instant messaging traffic to and from instant messaging clients that are independently configured by end users and that interact with a public service provider is prohibited within DoD information systems. 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.

Uncontrolled instant messaging traffic could allow unauthorized users to gain access to the protected services. This would result in unauthorized disclosure, modification, or destruction of critical system data. This implementation guide is aimed to help network administrators implement controlled instant messaging traffic within DoD information systems.

1. The network administrator shall install DOD authorized instant messaging services on the system servers and workstations in support of authorized and official functions (e.g., collaboration, file transfer).2. The network administrator shall configure the instant messaging client on user workstations not to allow users to change baseline client configuration.3. The network administrator/telecommunications specialist shall configure the enclave boundary protection mechanisms (e.g., firewall, router) to block both inbound and outbound public service instant messaging traffic (e.g., the rule set for this service should have “DENY”) except for the instant message services that are configured by a DOD AIS application or enclave to perform authorized and official functions.4. The project management shall ensure that system users (government employees and contractors) take regular security trainings related to the use of instant message services and privacy issues and that users follow the Rules of Behavior.

· DISA CISCO IOS Router Checklist, Version 5, Release 2.1, 01 June 2004· DISA Jupiter Router Checklist, Version 5, Release 2.1, 17 June 2004· DISA Network STIG, 29 October 2004· DISA Network Infrastructure STIG, Section 3.0, 29 September 2003· NSA Guide to Securing Netscape 7.02, 24 June 2003· NSA Guide to Secure Configuration and Administration of Microsoft Exchange 2000, 15 December 2004· NIST SP 800-45, Guidelines on Electronic Mail Security, September 2002· Vendors’ security administration for network devices (e.g., firewall, router) (Refer to if no DSSA/NSA/NIST/USG guidance is available)

Audit of Security Label Changes


The system automatically records the creation, deletion, or modification of confidentiality or integrity labels, if required by the information owner.

Insufficient security related information recorded in the audit trails could not support system forensics effectively and efficiently. This implementation guide is aimed to help system administrators configure system audit mechanisms properly to provide effective monitoring and detection of security problems. As a result, security fixes can be implemented in a timely manner.

1. The system administrator shall select audit events against security files of individual system components in accordance with DISA STIGs related to operating system, database, and application, such as excessive number of logon attempt; blocking or blacklisting a user ID; and bypassing or negating safeguards controlled by the system.2. The system administrator shall configure the system audit features to record system access-level auditing regarding root/administrator logons; access level change; security policy change; creation, deletion, or modification of security label change; and use of covert channel mechanisms.3. The system administrator shall configure each audit event to record sufficient information in the audit trails such as date/time of the event, user ID, source, target, type of event, and success/failure.4. If the system does not provide the capability of recording DOD required security events, the system administrator shall identify and install a DOD approved 3rd party product and configure it in accordance with DISA STIGs and vendor documentation for auditing.5. The system administrator shall test the auditing capability to ensure that the audit trails record required security events; each event contains sufficient information to support system forensics; and the auditing functions do not affect system operations.

· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DISA Windows NT Security Checklist, 10 December 2004· DISA Windows 2003 Security Checklist (draft), 10 December 2004· DISA Unix STIG, 15 September 2003· DISA UNISYS STIG, 22 July 2003· DISA Solaris Security Checklist, 20 January 2004· DISA Database STIG, Version 7, Release 1, 29 October 2004· DOD OC/390 RACF Checklist October 2004· DOD OC/390 ACF2 Checklist October 2004· DOD OC/390 TSS Checklist October 2004· NSA Microsoft SQL Server Guides, 02 October 2003· NSA Oracle Database Server Guides, 02 October 2003

ECLO-2 Logon Medium

ECLP-1 Least Privilege High


Successive logon attempts are controlled using one or more of the following: · Access is denied after multiple unsuccessful logon attempts. · The number of access attempts in a given period is limited. · A time-delay control system is employed. If the system allows for multiple logon sessions for each user ID, the system provides a capability to control the number of logon sessions. Upon successful logon, the user is notified of the date and time of the user's last logon, the location of the user at last logon, and the number of unsuccessful logon attempts using this user ID since the last successful logon.

Without proper user account lockout policies in place, unauthorized users could continually attempt to gain system access and not be noticed by the system administrator. Allowing a number of logon sessions for each user ID would result in unauthorized access to the system. In addition, without proper notification displayed on the monitor upon successful logon, users would not detect unauthorized access to system files and data. This implementation guide is aimed to help system administrators implement the account lock policy, a limited number of logon sessions for each user ID, and the notification of the last successful logon.

1. The system administrator shall configure the account policy of the operating system, database, and/or application that authenticate users prior to system access. For example, for the Windows operating system, the User Account Lockout Policy in the User Manager can be set as follows: · Account lockout duration: 0 · Account lockout threshold: 3 bad login attempts · Reset account lockout counter after: 60 minutes2. For the number of logon sessions for the same user ID, a. If the system software (e.g., Novell Netware) provides the capability of restricting a number of logon sessions, the system administrator shall configure the feature to the limited number (e.g., one or two). b. If the system software does not provide the capability of restricting a number of logon sessions, the system administrator shall identify an approve method (e.g., scripts) that restricts simultaneous login sessions for the same user ID. Otherwise, the system administrator shall review the audit trails regularly to monitor and detect simultaneous logons with the same user ID.3. For displaying information on the last logon, a. If the application provides the capability, the system/application administrator shall enable the capability so that the information on the last logon is displayed upon successful logon. b. If the application does not provide a capability of displaying information on the last logon, the system administrator shall use an approved script to notify users of the following upon successful logon: · Date and time of the user's last logon · Location of the user at last logon · Number of unsuccessful logon attempts using this user ID since the last successful logon.

· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DISA Windows NT Security Checklist, 10 December 2004· DISA Windows 2003 Security Checklist (draft), 10 December 2004· DISA Unix STIG, 15 September 2003· DISA Unisys STIG, 22 July 2003· DOD Database STIG, 24 July 2004· NSA Microsoft SQL Server Guides, 2 October 2003· NSA Oracle Database Server Guides, 2 October 2003· NSA Guide to Securing Windows 2000 – Policy Toolsets, Chapter 3, 05 March 2003· NSA Guide to Securing Windows XP, Chapters 2 and 4, 22 October 2004


Access procedures enforce the principles of separation of duties and "least privilege." Access to privileged accounts is limited to privileged users. Use of privileged accounts is limited to privileged functions; that is, privileged users use non-privileged accounts for all non-privileged functions. This control is in addition to an appropriate security clearance and need-to-know authorization.

Unauthorized users could gain access to critical classified and/or sensitive data through the improperly granted privileges. This could result in unauthorized disclosure, modification, and destruction of classified and sensitive information. This implementation guide is aimed to help system administrators implement proper access privileges based on user job functions and need to know and maintain privileged accounts securely.

1. The Information Assurance Manager (IAM) shall determine the number of roles/groups that are associated with specific functions required for the system.2. The IAM shall determine the names of the specific roles/groups (e.g., Engineering, IA, Configuration Management) and assign users to specific groups based on user’s job functions.3. The system administrator shall grant least privileges to individual users within the group (e.g., read, write, execute) only based on user job functions and need to know and upon the completion of background investigation.4. The system administrator shall grant access to privileged accounts (e.g., root, administrator) only to a limited number of privileged users (e.g., system administrator, database administrator, application administrator).5. The system administrator shall assign individual unique user accounts (e.g., johndoe1) to users with privileged functions, which must be used only to perform non-privileged functions.6. The system administrator shall review audit trails regularly to ensure that privileged users use the non-privileged accounts to perform non-privileged functions.7. The system administrator shall create non-privileged accounts for privileged users to perform non-privileged functions.

· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DISA Windows NT Security Checklist, 10 December 2004· DISA Unix STIG, Version 4, Release 4, 15 September 2003· DISA Application Security Checklist, Version 2, Release 1.5. 28 January 2005· NSA Guide to Securing Windows XP, Chapters 2 and 4, 22 October 2004· NSA Microsoft SQL Server Guides, 02 October 2003· NSA Oracle Database Server Guides, 02 October 2003· NSA Guide to Securing Windows 2000 – Policy Toolsets, 05 March 2003· NSA Guide to Securing Netscape 7.02, 24 June 2003

ECML-1 High

ECMT-2 Medium

Marking and Labeling


Information and DoD information systems that store, process, transit, or display data in any form or format that is not approved for public release 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 any special dissemination, handling, or distribution instructions.

Without proper markings and labels, classified and/or sensitive information could not be handled properly. This could result in unauthorized disclosure, modification, or destruction of data. This implementation guide is aimed to help information owners implement proper markings and labels that reflect the classification or sensitivity level of information.

1. The information owner shall identify and determine if the system stores, processes, transits, or displays data in any form or format, which is not approved for public release.2. If the system has data not approved for public release, the information owner shall perform the following prior to marking classification levels in accordance with DoD 5200.1R: a. Determine the overall classification of the document. b. Identify specific classified information and its level of classification within the document c. Identify information that should be included in the marking and labeling process d. Determine the type of standard markings and labeling format that is specified in DoD 5200.1R and/or organization’s classification labeling guide. e. Determine the specific pages where markings are displayed (e.g., front page, outside of back cover) f. Apply the labels and markings on the classified and sensitive documents as determined.

· DoD 5200.1R, Information Security Program, Chapter 5, Marking, January 1997· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· Organizations’ labeling and marking policies and/or guidelines

Conformance Monitoring and Testing


Conformance testing that includes periodic, unannounced in-depth monitoring and provides for specific penetration testing to ensure compliance with all vulnerability mitigation procedures such as the DoD IAVA or other DoD IA practices is planned, scheduled, conducted, and independently validated. Testing is intended to ensure that the system's IA capabilities continue to provide adequate assurance against constantly evolving threats and vulnerabilities.

Without regular conformance testing being performed, system vulnerabilities could not be identified and fixed in a timely manner. This implementation guide is aimed to help project management schedule and perform regular conformance testing to identify threats to and vulnerabilities of the system and implement countermeasures to mitigate or eliminate potential risks.

1. The project management shall develop a conformance testing plan that includes the following information: · Type of conformance testing (e.g., vulnerability assessment, security test and evaluation [ST&E], internal and/or external penetration testing) · Schedule of the testing either periodic (e.g., quarterly) or unannounced · Resources required to perform individual testing · Tools to be used for conformance testing (e.g., Internet Security Systems (ISS) Vulnerability Scanner, FSO Gold Disk, nmap, nessus, Retina) · Current Information Assurance Vulnerability Alerts (IAVA), IAV Bulletins (IAVB), and IAV Technical Advisories (IAV-TA) · Other vulnerability and patch information from vendors, Common Vulnerabilities& Exposures (CVE), etc.2. The project management shall determine if the conformance testing will be performed using in-house resources or outsourced.3. The project management shall establish a conformance test team (e.g., Test Engineer, Test Reviewer) with an adequate degree of independent review and validation.4. The project management shall review and approve the Rules of Engagement developed by the test team.5. The project management shall coordinate with personnel involved in the conformance testing for all activities associated with the periodic or unannounced conformance testing.6. For penetration testing, the project management shall ensure to establish a “White Cell” to coordinate the penetration testing.7. The test team shall install required testing resources on the workstations/laptops to be used for the testing and configure them properly.8. The test teams shall perform the testing based on the approved rules (e.g., ST&E Plan, Rules of Engagement) and document the test results.9. The project management shall review the results of the conformance testing and countermeasures to mitigate the identified potential risks.10. The project management shall develop a Plan of Actions and Milestones (POAM).11. The project management shall implement the recommended countermeasures based on the POAM to ensure that the system’s IA capabilities provide adequate assurance against constantly evolving threats and vulnerabilities.12. The project management shall protect the Conformance Testing Reports at the level of information contained in the reports (e.g., Classified, For Official Use Only).

· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DISA Windows NT Security Checklist, 10 December 2004· DISA Windows 2003 Checklist, 10 December 2004· DISA Unix STIG, Version 4, Release 4, 15 September 2003· DISA Solaris Security Checklist, 20 January 2004· DISA Unisys STIG, 22 July 2003· DISA Application Security Checklist, Version 2, Release 1.5. 28 January 2005· DISA FSO Security Readiness Scripts· Center for Internet Security Router Audit Tool (RAT), September 2004· Field Security Operations (FSO) Operating Systems Gold Disks· NIST - Technical Guide to Information Security Testing and Assessment

ECND-2 Medium

ECNK-1 Medium

ECNK-2 Medium

Network Device Controls


An effective network device control program (e.g., routers, switches, firewalls) is implemented and includes: 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). Audit or other technical measures are in place to ensure that the network device controls are not compromised. Change controls are periodically tested.

Without an adequate network device control program, perimeter protection devices could not be protected from unauthorized access, resulting in denial of service, malicious code attacks, and unauthorized modification of network device data. This implementation guide is aimed to help network administrators implement proper access controls, maintain network control devices effectively, and monitor unauthorized compromise of the network devices.

1 The project management shall ensure that an effective network device program shall be developed for the network control devices (e.g., firewalls, routers, switches) in accordance with DOD policy and organization specific guidelines. The program must include, but are not limited to, the following information: · Roles and responsibilities for personnel involved in installing, operating, and managing the network control devices · Instructions for restart and recovery procedures in accordance with DISA STIGs and vendor system administration guides related to firewalls, routers, and switches · Restrictions on source code access, system utility access, and system documentation in accordance with DISA STIGs and vendor security administration guides · Protection from deletion of system and application file through proper file permissions in accordance with DISA STIGs and vendor security administration guides; · A structured process for the implementation of directed solutions (e.g., IAVA).2. The network administrator shall configure the network control devices in accordance with DISA STIGs and NSA security guides to prevent unauthorized access to the network control devices.3. The network administrator shall enable the auditing capabilities of individual network control devices so that access to the devices is monitored and recorded in audit trails.4. If feasible, the project management shall ensure that network-based IDSs are implemented to detect security events occurred to the network control devices. (refer to ECID-1)5. The network administrator shall test changes and updates made to the network control devices periodically to ensure their integrity in accordance with the system Configuration Management Plan.

· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DOD Information Security Program, 13 December 1993· DISA Network STIG, 29 October 2004· DISA Network Infrastructure STIG, 29 September 2003· DISA Cisco IOS Router Checklist, Version 5, Release 2.1, 01 June 2004· DISA Jupiter Router Checklist, Version 5, Release 2.1, 17 June 2004· NSA Router Security Configuration Guide, 08 April 2004· NIST SP 800-41, Guidelines on Firewalls and Firewall Policy, January 2002· Individual System Configuration Management Plans

Encryption for Need-To-Know


Information in transit through a network at the same classification level, but which must be separated for need-to-know reasons, is encrypted, at a minimum, with NIST-certified cryptography. This is in addition to ECCT (encryption for confidentiality – data in transit).

Confidentiality of need-to-know information can be compromised easily when transmitted through a network in an unencrypted state. Certified cryptography methods provide important functionality to protect against intentional and accidental compromise and alteration of data.

1. Identify system components processing sensitive and unclassified information (classified and sensitive national security systems are covered by the ECNK-2 control).2. NIST issues standards and guidelines used to protect sensitive information as Federal Information Processing Standards (FIPS) publications. Federal agencies must comply with all mandatory standards.3. A system manager shall select an encryption method to protect need-to-know information in transit by using, at a minimum, a NIST certified cryptographic method. By using FIPS, the manager knows that the standard has been developed and the algorithm has been tested against this standard and the results validated by NIST. NIST validation means the algorithm has been found to be adequate for the protection of sensitive government data.

· NIST SP 800-32, Introduction to Public Key Technology and the Federal PKI Infrastructure, February 2001· NIST SP 800-29, A Comparison of the Security Requirements for Cryptographic Modules in FIPS 140-1 and FIPS 140-2, June 2001· NIST SP 800-25, Federal Agency Use of Public Key Technology for Digital Signatures and Authentication, October 2000· NIST SP 800-21, Guideline for Implementing Cryptography in the Federal Government, November 1999· FIPS 140-2, Security Requirements for Cryptographic Modules, 25 May 2001· FIPS 196, Entity Authentication Using Public Key Cryptography, 18 February 1997· FIPS 197, Advanced Encryption Standard (AES), 26 November 2001

Encryption for Need-To-Know


SAMI information in transit through a network at the same classification level is encrypted using NSA-approved cryptography. This is to separate it for need-to-know reasons. This is in addition to ECCT (encryption for confidentiality – data in transit).

Confidentiality of need-to-know information can be compromised easily when transmitted through a network in an unencrypted state. Certified cryptography methods provide important functionality to protect against intentional and accidental compromise and alteration of data.

1. NSA-approved cryptography shall be used to separate compartments or protect “need-to-know” information among cleared users on classified systems. For such uses the DAA may select the cryptographic mechanisms (including commercially available products) to be used after consulting with the Data Owner on requirements. The DAA shall also consult with NSA for assistance and advice regarding the security of the proposed implementation. They should pay particular attention to key management, since appropriate secure key management is an important factor in overall system security.2. NSA approved cryptography consists of an approved algorithm; an implementation that has been approved for the protection of classified information in a particular environment; and a supporting key management infrastructure.3. The NSA Director shall review and approve all cryptographic implementations intended to protect national security systems and/or national security information and provide advice and assistance to U.S. Government Departments and Agencies in identifying protection requirements and selecting the encryption algorithms and product implementations most appropriate to their needs.

· DCID 6/3, Protecting Sensitive Compartmented Information Within Information Systems, 12 April 2002· CNSSP-15, Fact Sheet No. 1 for the National Policy on the Use of the Advanced Encryption Standard (AES) to Protect National Security Systems and National Security Information, June 2003· FIPS 140-2, Security Requirements for Cryptographic Modules, 25 May 2001· FIPS 196, Entity Authentication Using Public Key Cryptography, 18 February 1997· FIPS 197, Advanced Encryption Standard (AES), 26 November 2001

ECPA-1 High

ECPC-2 Medium

ECRC-1 Resource Control Medium

Privileged Account Control


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, system administration, database administration, web-administration). The IAM tracks privileged role assignments.

An organization’s network and the integrity of stored information are at risk if the control of actions, functions, applications and operations of legitimate users are not managed with a role-based access scheme. The unnecessary allocation and use of system privileges significantly increases the vulnerability of systems. Role-based systems are designed to minimize the potential for inside security violations by providing greater control over users' access to information and resources. Also, by assigning individuals to predefined roles, the administrative process of establishing privileges is streamlined and management time for reviewing privilege assignments is reduced.

1. An analysis of how an organization operates shall be accomplished for the basis of defining user roles and privileges.2. Systems shall employ a role-based access scheme that enforces separation of duties and network privileges.3. Privileged user accounts (administrators, root/super users on UNIX, routers and LAN servers, SANs, etc) shall be limited to the absolute minimum number needed to manage the system, and the IAM shall document all privileged role assignments.4. Privileged user accounts shall be limited to the minimum number of privileges needed to perform their assigned duties.5. Where technically possible, privileged users should initially log on with a personal user ID and only be granted privileged access by way of group assignment.6. Privileged and guest accounts shall be renamed from any default.

· CJCSM 6510. 01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 25 March 2003· NSA Guide to Securing Windows 2000 – Policy Toolsets, 05 March 2003· NSA Guide to Securing Windows XP, 22 October 2004· DISA Unix STIG, Version 4, Release 4, 15 September 2003· DISA UNISYS STIG, 22 July 2003· NSA Windows 2000 Security Recommendations Guide 16 January 2004· NSA Windows NT Security Recommendations Guide 18 September 2001· DISA Database STIG, Version 7, Release 1, 29 October 2004· http://csrc.nist.gov/rbac/

Production Code Change Controls


Application programmer privileges to change production code and data are limited and reviewed every 3 months.

The reliability, availability, and integrity of applications are at risk if there are too many programmers making production code and data changes. An effective configuration management plan should address managing and monitoring the personnel allowed to make code changes with a review accomplished every 3 months.

1. The Configuration Control Board (CCB), consisting of, at minimum, a Program Manager, Information Assurance Manager, or the Information Assurance Officer shall identify the files/data sets that contain production code or production data and then authorize and document who is allowed to make changes to the production code or data.2. The System Administrator shall limit the application programmer accounts to the minimum number of privileges needed to perform their assigned duties.3. The CCB shall limit and periodically review the total number of application programmers authorized to make production code changes.

· NIST SP 800-12, An Introduction to Computer Security: The NIST Handbook, October 1995· DISA, Recommended Standard Application Security Requirements Version 2, March 2003· DISA, Application Security Checklist, Version 2.0, Release 1.5, 28 January 2005


All authorizations to the information contained within an object are revoked prior to initial assignment, allocation, or reallocation to a subject from the system's pool of unused objects. No information, including encrypted representations of information, produced by a prior subject's actions is available to any subject that obtains access to an object that has been released back to the system. There is absolutely no residual data from the former object.

The constant reallocation of objects is a security risk because residual data may remain when the object is reassigned to a new process after a previous process is finished with it. Clearing residual data from an object before reuse assures that system resources, in particular storage media, are allocated and reassigned among system users in a manner which prevents the disclosure of sensitive information.

1. If a system component is required to make policy enforcement decisions or implement a security feature, it is considered to be an Information Assurance (IA) enabled IT component, and it must be validated to ensure that residual data is cleared before any object reuse. Operating systems and firewalls are examples of IA enabled components.2. COTS or GOTS IA and IA enabled products shall be evaluated and validated in accordance with: The International Common Criteria for Information Security Technology Evaluation Mutual Recognition Arrangement; The National Security Agency (NSA) /National Institute of Standards and Technology (NIST) National Information Assurance Partnership (NIAP) Evaluation and Validation Program; or The NIST Federal Information Processing Standard (FIPS) validation program.3. A validated products list can be found at the http://niap.nist.gov website along with procedures to get a product through the validation process.

· CCIMB-99-031, Common Criteria for Information Technology Security Evaluation, August 1999· DOD 8500.2, Information Assurance Implementation, 06 February 2003· NSTISSP No. 11, National Information Assurance Acquisition Policy - Revised Fact Sheet, July 2003· NIST SP 800-23, Guidelines to Federal Organizations on Security Assurance and Acquisition/Use of Tested/Evaluated Products, August 2000

ECRG-1 Low

ECRR-1 Medium

ECSC-1 High

ECSD-2 High

Audit Reduction and Report Generation


Tools are available for the review of audit records and for report generation from audit records.

The amount of information in audit logs can be very large and extremely difficult to analyze manually; important security related events could be overlooked. Audit review tools are available that can query the audit records by user ID, date/time, or some other set of parameters to run reports of selected information.

1. Determine if an audit reduction capability exists. This capability can be either OS provided or an add-on product.2. Operating systems and applications shall have the capability to review audit records and generate reports from the audit records. Most operating systems and applications have built-in auditing capabilities, but if they don’t, a DOD approved auditing utility shall be acquired. Selection of the individual approved software should be determined by auditing capabilities, ease of use, administrative overhead, and system overhead, as well as enterprise or organizational policy on auditing requirements.3. Operating systems typically provide at least the minimum tools and utilities to review audit records and generate reports. Microsoft Windows event viewer tracks all security events and can selectively review audit records, and the Solaris operating system uses the ‘praudit’ utility for audit reviews.

· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 25 March 2003· NIST SP 800-12, An Introduction to Computer Security: The NIST Handbook, October 1995· CNSS 4013, National Training Standard for System Administrators in Information Security, March 2004

Audit Record Retention


If the DoD information system contains sources and methods intelligence (SAMI), then audit records are retained for 5 years. Otherwise, audit records are retained for at least 1 year.

Audit trail data, though voluminous, must be retained for a sufficient time to permit retrospective examination for specific incidents and for trend analysis. Operating system parameters must be set so that growing logs are not inadvertently overwritten. Procedures must be in place for migrating audit trail data to archival storage and to prevent inadvertent or unauthorized deletion of log data. An intruder might attempt to delete audit trails in an attempt to conceal unauthorized activity.

1. Activate audit logging for security-significant components and systems.2. Limit access to audit data to authorized system administrators.3. Set system controls to ensure that audit logs that have reached maximum length are not overwritten. If possible, the system should issue a warning that log data length is approaching the maximum value and then should fail gracefully.4. Ensure that procedures exist for moving audit trails from on-line to archival media.5. Inspection and modification of audit data are, themselves, security significant events that should generate log entries.

· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 25 March 2003· NIST SP 800-12, An Introduction to Computer Security: The NIST Handbook, October 1995· CNSS 4013, National Training Standard for System Administrators in Information Security, March 2004

Security Configuration Compliance


For Enclaves and AIS applications, all DoD security configuration or implementation guides have been applied.

The computer hardware and software systems used within the DOD have varying amounts of risks. Security configuration or implementation guides are created to minimize the security risks associated with the hardware or software products.

1. All IA and IA-enabled applications deployed within the enclave (C&A boundary) shall be configured or implemented according to the information within applicable security guides (e.g., STIGs, SNAC Guides).2. If security guides are not available for deployed IA products, waivers shall be obtained and commercial best practices shall be applied.

· http://www.nsa.gov/snac/ National Security Agency, Systems and Network Attack Center - Security and Configuration Guides· http://csrc.nist.gov/pcig/ Defense Information Systems Agency, STIGs· http://csrc.nist.gov/pcig/ppsp.html Public and Private Security Practices

Software Development Change Controls


Change controls for software development are in place to prevent unauthorized programs or modifications to programs from being implemented. Change controls include review and approval of application change requests and technical system features to assure that changes are executed by authorized personnel and are properly implemented.

The integrity of computer systems is at risk if software development change controls are not established and implemented. A Configuration Management (CM) plan, and an access control policy greatly reduce the risk of unauthorized program modification.

1. A CM plan shall be established and implemented, and the CM plan shall include how software change requests are prepared, submitted, processed, and tracked.2. The IAM/IAO and the site’s lead developer/programmer shall authorize and document the roles, responsibilities, and privileges for all personnel allowed to make software development changes.3. Systems shall include technical features that implement a role-based access scheme to assure program modifications are made by authorized personnel.4. The software developer’s user accounts shall be limited to the minimum number of permissions needed to perform their assigned duties.

· NIST SP 800-12, An Introduction to Computer Security: The NIST Handbook, October 1995· DISA, Recommended Standard Application Security Requirements Version 2, March 2003· DISA, Application Security Checklist, Version 2.0, Release 1.5, 28 January 2005

ECTB-1 Medium

ECTC-1 Tempest Controls High

ECTM-2 Medium

Audit Trail Backup


The audit records are backed up not less than weekly onto a different system or media than the system being audited.

Loss of important information/work is a risk if back-ups are not performed regularly. Performing back-ups daily or at least weekly enhances the integrity and availability of information.

1. A back-up plan shall be established, documented, and implemented for all systems recording audit records within your C&A boundary.2. The audit records shall be backed-up not less than weekly, and if possible, the back-up process should be automated.3. The back-ups shall be saved to a different system or saved on a different media (e.g., disk, CD, tape) than the system being audited.

· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 25 March 2003· NIST SP 800-12, An Introduction to Computer Security: The NIST Handbook, October 1995· NSA Guide to Securing Windows 2000 – Policy Toolsets, 05 March 2003· NSA Guide to Securing Windows XP, 22 October 2004· DISA Unix STIG, Version 4, Release 4, 15 September 2003· DISA Solaris Security Checklist, 20 January 2004· DISA UNISYS STIG, 22 July 2003· NSA Windows 2000 Security Recommendations Guide 16 January 2004· NSA Windows NT Security Recommendations Guide 18 September 2001· DISA Database STIG, Version 7, Release 1, 29 October 2004


Measures to protect against compromising emanations have been implemented according to DoD Directive S-5200.19.

All electronic and electromechanical information processing equipment can produce unintentional data-related or intelligence-bearing emanations, which if intercepted and analyzed, disclose the information transmitted, received, handled, or otherwise processed. Properly implementing TEMPEST controls mitigates the risk of compromising emanations.

1. DoD Directive S-5200.19 establishes guidelines and procedures that shall be used by departments and agencies to determine the applicable countermeasures to protect against compromising emanations.2. Some of the factors that shall be evaluated to determine TEMPEST countermeasures are: a. Location of systems and proximity of threat b. Volume of information processed c. Sensitivity of information processed d. Physical control of facility and systems3. A Certified TEMPEST Technical Authority shall conduct or validate a TEMPEST countermeasure review.

· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 25 March 2003· DoDD S-5200.19, Control of Compromising Emanations,· NSTISSI No. 7000, TEMPEST Countermeasures for Facilities, 29 November 1993· NSTISSAM TEMPEST/2-95, RED/BLACK Installation Guidance, 12 December 1993

Transmission Integrity Controls


Good engineering practices with regards to the integrity mechanisms of COTS, GOTS, and custom developed solutions are implemented for incoming and outgoing files, such as parity checks and cyclic redundancy checks (CRCs). Mechanisms are in place to assure the integrity of all transmitted information (including labels and security parameters) and to detect or prevent the hijacking of a communication session (e.g., encrypted or covert communication channels).

Integrity of transmitted information is at risk if good engineering practices are not implemented. Error detection methods like parity checks, checksums, and CRCs along with mechanisms to detect and prevent the hijacking of communication sessions mitigate the integrity risk of incoming and outgoing files during transmission.

1. COTS, GOTS, and custom developed solutions shall implement some form of error detection to enhance data integrity during transmission.2. Schematics, diagrams, or some other form of documentation shall show system data flows, the communication mediums, and the associated protection mechanisms.3. Integrity checkers such as Tripwire can be utilized to detect suspicious activity by searching a program or file to determine if it has been altered or changed. Integrity checkers are usually checksum based with cryptographic checksums providing the highest level of security.4. COTS or GOTS IA and IA enabled products shall be searched and evaluated for covert channels and if applicable, potential cryptographic key leakage from the cryptographic module. The following programs are used to evaluate and validate IA products: The International Common Criteria for Information Security Technology Evaluation Mutual Recognition Arrangement; The National Security Agency (NSA) /National Institute of Standards and Technology (NIST) National Information Assurance Partnership (NIAP) Evaluation and Validation Program; or The NIST Federal Information Processing Standard (FIPS) validation program.5. A validated products list can be found at the http://niap.nist.gov website along with procedures to get a product through the validation process.

· NIST SP 800-23, Guideline to Federal Organizations on Security Assurance and Acquisition/Use of Tested/Evaluated Products, August 2000· NIST SP 800-27, Engineering Principles for Information Technology Security (A Baseline for Achieving Security), Revision A, June 2004· NIST SP 800-36, Guide to Selecting Information Security Products, October 2003· NCSC TG-030, A Guide To Understanding Covert Channel Analysis of Trusted Systems, Version 1, November 1993· NSA, U.S. Government Protection Profile for Single-level Operating Systems in Environments Requiring Medium Robustness, Version 1.67, 30 October 2003· CCIMB-99-031, Common Criteria for Information Technology Security Evaluation, August 1999· DOD 8500.2, Information Assurance Implementation, 06 February 2003· NSTISSP No. 11, National Information Assurance Acquisition Policy - Revised Fact Sheet, July 2003

ECTP-1 Medium

ECVI-1 Medium

ECVP-1 Virus Protection High

Audit Trail Protection


The contents of audit trails are protected against unauthorized access, modification or deletion.

Audit trails help accomplish individual accountability, event reconstruction, intrusion detection, and problem analysis. Strong access controls and encryption are effective security mechanisms that help prevent unauthorized access, modification or deletion.

1. Applications shall ensure its role-based access control implementation enforces separation of duties and least privilege. Two examples of duty separation are: a. Personnel that review and clear audit logs and personnel that perform non-audit administration, and b. Personnel that create, modify and delete access control rules and personnel that perform either data entry or application programming.2. For Windows systems, the NTFS file permissions should be System – Full control, Administrators and Application Administrators - Read, and Auditors - Full Control.3. For Unix systems, use the ls –la (or equivalent) command to check the permissions of the audit log files. Excessive permissions shall not exist.4. Digital signatures and encryption shall be used for ensuring integrity and preserving confidentiality of audit trail data.

· DISA, Recommended Standard Application Security Requirements Version 2, March 2003· DISA, Application Security Checklist, Version 2.0, Release 1.5, 28 January 2005· NIST SP 800-12, An Introduction to Computer Security: The NIST Handbook, October 1995

Voice-over-IP (VoIP) Protection


Voice over Internet Protocol (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. Note: This does not include VoIP services that are configured by a DoD AIS application or enclave to perform an authorized and official function.

VoIP technology improves productivity through enhanced voice services for the DOD, but these services increase the risk in exposing government information systems to security vulnerabilities especially if configured independently by end users. VoIP vulnerabilities are mitigated when authorized personnel configure the services.

1. The VoIP supported network must be designed, implemented, and operated in a secure manner, providing end-to-end security from the VoIP terminal device to the VoIP applications required for operation, including applicable host platforms and associated support software.2. The IAO shall ensure that VoIP systems are approved by the DAA before they are installed and/or used to store, process, or transmit DOD information.3. The IAO shall ensure that VoIP systems are compliant with overall network security architecture and appropriate enclave security requirements.4. The IAO shall ensure that VoIP devices are added to site System Security Authorization Agreements.

· CJCSM 6510.10, Defense-In-Depth: Information Assurance (IA) and Computer Network Defense (CND), 15 March 2002· CJCSI - Policy for Department of Defense (DOD) Voice Networks With Real Time Services· DISA Instruction 630-230-19, Security Requirements for Automated Information Systems, 09 July 1996· DISA Computer Services Security Handbook, Version 3. 1 December 2000· DISA, Voice Over Internet Protocol (VOIP), STIG, Version 1, Release 1, 13 January 2004· DISA Defense Switched Network STIG, Version 1, Release 1, 12 March 2003· DISA Network Infrastructure STIG, Version 5, Release 2, 29 September 2003· Addendum to the NSA Guide to Securing Microsoft Windows NT Networks and NSA Guides to Securing Windows 2000, Version 43 (to match NSA Guide), Release 1, 26 November 2002· DISA Unix STIG, Version 4, Release 4, 15 September 2003· DISA Enclave Security STIG, Version 1, Release 1, 30 March 2001· Army Regulation 380-19, Information Systems Security, 27 February 1998· Air Force Instruction 33-111, Telephone Systems Management, 01 June 2001· Secretary of the Navy Instruction 5239.3, Department of the Navy Automated Information Systems Security Program, 14 July 1995· Navy Staff Office Publication 5239-15, Controlled Access Protection Guidebook, August 1992· NIST Security Considerations for Voice Over IP Systems, January 2003. NSTISSP 101, National Policy on Securing Voice Communications, 14 September 1999


All Servers, workstations and mobile computing devices (i.e. laptop, PDAs) implement virus protection that includes a capability for automatic updates.

Servers, workstations and mobile computing devices are at risk of attack by computer viruses, unauthorized users, and related threats (Trojan horse, worms, overwriting viruses, malicious code, Denial of Service, etc). Virus protection software is installed on servers, workstations, and mobile computing devices in an effort to reduce the risk of attack. This implementation guide is aimed to help technical managers, system administrators, and individual users implement the tools to prevent, detect, identify and contain/remove viruses.

1. All servers, workstations and mobile computing devices shall be installed with DoD approved virus protection software. Selection of the individual DoD approved software should be determined by software accuracy, ease of use, administrative overhead, and system overhead, as well as enterprise or organizational policy on antivirus software acquisition.2. All servers, workstations and mobile computing devices shall be configured to run automatic updates. The scheduling of automatic updates for specific frequency or time periods shall be set in accordance with DoD, organizational, or and other related requirements.3. Regular automatic updates may be implemented through either a “push” method (administrators sending current definitions to the workforce from an enterprise server) or a “pull” through the commercial Internet from a vendor’s update server. Implementation method should be selected in accordance with system security requirements (e.g., systems behind a classified boundary will require a “push” implementation).

· CJCSM 8510.101, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 25 March 2003· NSA Guide to Securing Windows 2000 – Policy Toolsets, Chapter 3, 05 March 2003· NSA Guide to Securing Windows XP, Chapters 2 and 4, 22 October 2004· DISA Unix STIG, Version 4, Release 4, 15 September 2003· DISA UNISYS STIG, 22 July 2003· NSA Windows 2000 Security Recommendations Guide 16 January 2004· NSA Windows NT Security Recommendations Guide 18 September 2001· DISA Database STIG, Version 7, Release 1, 29 October 2004

ECWM-1 Low

ECWN-1 High

Warning Message


All users are warned that they are entering a Government information system, and are provided with appropriate privacy and security notices to include statements informing them that they are subject to monitoring, recording and auditing.

The use of warning banners on computers and networks provides legal notice to anyone accessing them that they are using a U.S. Government system that is subject to monitoring, recording, and auditing. Users also being notified of possible sanctions, such as loss of privileges or even prosecution, if they misuse or access the network without authorization help mitigate malicious activity.

1. A warning banner shall be displayed after a successful log-on and this includes banners for internal and local logins as well as external logins.2. The following elements shall be included in the warning message: a. use of the application constitutes the user’s consent to monitoring, b. use of the application is limited to official US Government business only, c. unauthorized use is subject to criminal prosecution, and d. notice that this is a DOD system.

· CJCSM 6510.10, Defense-In-Depth: Information Assurance (IA) and Computer Network Defense (CND), 15 March 2002· NIST SP 800-18, Guide for Developing Security Plans for Information Technology Systems, December 1998· DISA Instruction 630-230-19, Security Requirements for Automated Information Systems, 09 July 1996· DISA Computer Services Security Handbook, Version 3, 01 December 2000· DISA Defense Switched Network STIG, Version 1, Release 1, 12 March 2003· DISA Network Infrastructure STIG, Version 5, Release 2, 29 September 2003

Wireless Computing and Network


Wireless computing and networking capabilities from workstations, laptops, personal digital assistants (PDAs), handheld computers, cellular phones, or other portable electronic devices are implemented in accordance with DoD wireless policy, as issued. (See also ECCT). Unused wireless computing capabilities internally embedded in interconnected DoD IT assets are normally disabled by changing factory defaults, settings or configurations prior to issue to end users. Wireless computing and networking capabilities are not independently configured by end users.

Wireless computing and networking provide many benefits such as portability and flexibility, increased productivity, and lower installation costs. However, wireless networks present similar security risks to those of a wired network, and since the open airwaves are the communications medium for wireless technology, an entirely new set of risks are introduced. Implementing wireless computing and networking capabilities in accordance with DoD wireless policy and allowing only authorized and qualified personnel to configure wireless services greatly reduces vulnerabilities.

1. All wireless systems shall be approved by the DAA prior to installation and use for processing DoD information.2. Personally owned wireless devices shall not be used for processing DoD information.3. A list of all DAA approved WLAN devices shall be maintained.4. All individual functions of multi-functional devices shall be secured.5. Wireless devices shall be documented in the system security documentation.6. All wireless devices, particularly laptops, shall comply with applicable operating system STIGs.7. DoD approved anti-virus software shall be installed and configured in accordance with the Desktop Application STIG on all wireless devices, particularly laptops and PDAs, and kept up-to-date with the most recent virus definition tables.

· CJCSM 6510.10, Defense-In-Depth: Information Assurance (IA) and Computer Network Defense (CND), 15 March 2002· CJCSI - Policy for Department of Defense (DOD) Voice Networks With Real Time Services· NIST SP 800-48, Wireless Network Security: 802.11, Bluetooth, and Handheld Devices, November 2002· DISA, Wireless Security Checklist, Version 3, Release 1.1, 01 November 2004· DoDD 8100.2, Use of Commercial Wireless Devices, Services, and Technologies in the Department of Defense Global Information Grid (GIG), 14 April 2004· DoDD 4650.1, Management and Use of the Radio Frequency Spectrum, 24 June 1987· DoD 5200.1-R, Information Security Program, January 1997· DoDD 4630.5, Interoperability and Supportability of Information Technology and National Security Systems, 11 January 2002· DoDI 4630.8, Procedures for Interoperability and Supportability of Information Technology and National Security Systems, 02 May 2002

IAAC-1 Account Control High

IAGA-1 Medium

Identification and Authentication

A comprehensive account management process is implemented to ensure that only authorized users can gain access to workstations, applications, and networks and that individual accounts designated as inactive, suspended, or terminated are promptly deactivated.

Information within the organization is potentially vulnerable to access and exploitation by individuals using active accounts that should have been deactivated. This includes individuals who have transferred from the organization, had their employment terminated, lost appropriate security clearance/need-to-know, or who otherwise are no longer authorized access to the system or its information resources. In order to prevent unauthorized access and potential loss/compromise/destruction of information, it is essential that accounts be properly controlled and restricted only to authorized users.

This implementation guidance is designed for use by Information Assurance Managers and/or System Administrators. The following general implementation guidelines apply: 1. During the operating system installation process on servers and workstations, ensure that default accounts and associated passwords are disabled and/or removed IAW procedures applicable to the specific system (see the appropriate DISA STIG or vendor documentation).2. During the application installation process on servers and workstations, ensure that any default accounts and associated passwords associated with the applications are disabled and/or removed IAW procedures applicable to the specific system (see the appropriate DISA STIG or vendor documentation).3. When creating a new account for a system user, the registration process should collect at a minimum the following user information: · Name · Title and Position · IT Category · Organization · Phone Number · Official email address · Supervisor’s Name and Contact Information · Security Clearance Level/Special Access information · Projected Transfer Date (for military or TDY personnel)4. Ensure that users and/or supervisors are aware of the requirement to notify System Administrators and IAMs/IAOs immediately when users no longer require or are authorized system access.5. Disable and remove user IDs and passwords within two days of notification that a user no longer requires or is authorized system access.6. System Administrators shall suspend user accounts that have been inactive for 30 days or more.7. System Administrators shall immediately disable any account through which unauthorized user activity has been detected.

· CJSCM 6510.01, Change 1, Enclosure C, Appendix A, 10 August 2004· Windows XP STIG, Section 12.2, 03 December 2002· Windows NT/XP/2000 Addendum Version 4, Release 1, Section 5, 26 February 2004· DISA Unix STIG, Version 4, Release 4, 15 September 2003· DISA Supplement to Network Infrastructure Checklist Version 5, Release 2.1, Cisco Router Checklist NET 0465, 01 June 2004· DISA Database STIG, Version 7, Release 1, Section 3.1, 29 October 2004

Group Authentication


Group authenticators for application or network access may be used only in conjunction with an individual authenticator. Any use of group authenticators not based on the DoD PKI has been explicitly approved by the Designated Approving Authority (DAA).

Group authenticators allow users within a single domain, user group, or role and permissions set to access specific applications or network resources without having to repeat an individual authentication instance. Permitting group authentication to system resources without first requiring individual authentication opens the risk of enabling unauthorized users to access system resources.

1. The system administrator and project manager shall determine if it is necessary to assign group accounts to support system operations and mission.2. Once it is determined that group accounts are required to support system maintenance and operations and/or network access, the system administrator and the project manager shall determine if group authenticators can be used based on the DOD PKI.3. If the DOD PKI can be used, the system administrator shall coordinate with the DOD PKI Program Office for use of group accounts.4. If the DOD PKI cannot be used, the project manager submits a request for an approval to DAA and obtains an approval from DAA.5. For the group accounts to support application maintenance and functions or network access, the system and network administrators shall perform the following: · Identify individual groups that require group accounts · Identify users for each group, maintain the list of users, and update the list · Determine the group accounts depending on group functions · Assign individual group accounts and a unique password for individual groups · Distribute the passwords to the users securely

· DODD 5200-2, DOD Personnel Security Program, 09 April 1999· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004· DISA Network Infrastructure STIG, Version 5, Release 2.29, September 2003· DISA Network Infrastructure Security Checklist, Version 5, Release 2.2, 23 September 2004· NIST SP 800-12, An Introduction to Computer Security: The NIST Handbook, October 1995

IAIA-2 HighIndividual Identification and Authentication


DoD information system access is gained through the presentation of an individual identifier (e.g., a unique token or user logon ID) and password. For systems utilizing a logon ID as the individual identifier, passwords are, at a minimum, a case sensitive, 8-character mix of upper case letters, lower case letters, numbers, and special characters, including at least one of each (e.g., emPagd2!). At least four characters must be changed when a new password is created. Deployed/tactical systems with limited data input capabilities implement these measures to the extent possible. Registration to receive a user ID and password includes authorization by a supervisor, and is done in person before a designated registration authority. Multiple forms of certification of individual identification such as a documentary evidence or a combination of documents and biometrics are presented to the registration authority. Additionally, to the extent capabilities permit, system mechanisms are implemented to enforce automatic expiration of passwords and to prevent password reuse, and processes are in place to validate that passwords are sufficiently strong to resist cracking and other attacks intended to discover a user's password). All factory set, default or standard-user IDs and passwords are removed or changed. Authenticators are protected commensurate with the classification or sensitivity of the information accessed; they are not shared; and they are not embedded in access scripts or stored on function keys. Passwords are encrypted both for storage and for transmission.

Access to DoD information sytems must be protected commensurate with the sensitivity of the information the systems process. For this reason it is mandatory that each individual who is authorized access to DoD information systems be provided with a unique individual identifier in the form of either a DoD PKI certificate, CAC card, or username and password. Failure to require an individual I&A mechanism leaves DoD information resources vulnerable to theft, exploitation, unauthorized modification, or destruction.

This implementation guidance is designed for use by Information Assurance Managers, System Administrators, or individual Subject Matter Experts (SMEs) tasked with implementation of I&A mechanisms. The following general implementation guidelines apply: 1. To ensure compliance with (DoD PKI policy), DoD PKI is to be the primary mechanism of individual identification and authentication for all DoD systems wherever possible. For DoD PKI infrastructure implementation guidance, refer to DoDI 8520.2, Enclosure 3 (01 Apr 04).2. For systems that have not yet implemented, or are unable to implement DoD PKI, ensure that individual user accounts are set up in accordance with guidance provided in implementation guidance for IAAC-1 and ECLP-1.3. When setting up user accounts on workstations, servers, databases, or individual applications, system administrators shall set password configuration parameters to ensure that password structure conforms to the following standards: · Passwords must be a minimum of eight (8) characters in length. · Passwords must contain a case-sensitive mixture of letters, digits, and special characters (e.g., punctuation marks, etc.) such as the example (emPagd2!). · Whenever a password is changed (by the user or system administrator), at least four characters must be changed from the previous password (e.g., [emPagd2!] becomes [0LP&gd2?]). · Password aging must be enabled to ensure that passwords must be changed at least every ninety (90) days for classified and SBU systems and no more frequently than every seven (7) days for both types of system. · System administrators shall configure system accounts to maintain a password history for a period of at least one (1) year. Additionally, users shall not be allowed to use any of their ten (10) previously used passwords.4. Ensure that the process for registering new users on the system and providing user ID and password conform to practices outlined in IAAC-1.5. System Administrators (or other SMEs involved in Independent Verification and Validation of password features) shall test the robustness of user passwords on systems processing classified or SBU information by employing a DoD-approved password policy enforcement tool (e.g., Anixis PPE).6. System Administrators are to ensure that all default, factory-set, or standard-user accounts and associated default passwords are disabled and, to the extent that the OS or application permits, removed completely. Refer to OS, system, or application-specific STIGs, configuration standards, or vendor’s configuration guidance for specific steps on how do disable and/or remove default user accounts, IDs, and passwords.7. Authenticators/user IDs/passwords shall be protected in the following manner: · Access to system files containing user account information and passwords shall be restricted to system administrators · Files containing authenticator information shall be classified at the level of information for which the accounts and passwords are assigned to protect. · Passwords shall be shadowed. If password characters display in clear text while being entered into the password acceptance field, check the configuration of the application to ensure that the shadowing feature is enabled. · System security policy, rules of behavior, or other applicable system user policy shall be written in a manner that specifically prohibits the sharing of passwords among users. · Review any and all scripts used for automated boot processes or application access shall be reviewed to ensure that they contain no password automation or access features.8. User passwords shall be encrypted, both at rest and in transit through the network using robust (i.e., 128-bit or stronger) encryption through a DoD-approved algorithm (e.g., RC4, RC5, IDEA, Blowfish) and through such robust means of secure transit as SSH and SSL-3.

· DoDI 8520.2 “Public Key Infrastructure (PKI) and Public Key (PK) Enabling”, Enclosure 3, 01 April 2004· CJCSI 6510.01”Defense in Depth: Information Assurance (IA) and Computer Network Defense (CND)” Change 1, Enclosure C, Appendix A; and Appendix H, Enclosure C, August 2004· DISA Enterprise System Management STIG, Version 1, Release 0, Section 3.3, 29 October 2004· DISA Network STIG, Version 5, Release 2, Sections 3.4.1, 3.5.4, and 3.13, 29 September 2003· Database STIG, Version 7, Release 1, Section 3, Paragraphs 3.1, 3.2, 29 October 2004· Secure Remote Computing STIG, Version 1, Release 1, Section 5.5 and 5.6, 14 February 2003· Department of Transportation Solaris Secure Baseline Configuration Standards, Section 2.0 20 January 2004· UNIX STIG, Version 4, Release 4, Section 3, paragraphs 3.1 and 3.1.1, 3.2, 3.2.1, and 9.4, 15 September 2003· Windows NT STIG, Version 4, Release 2, Chapter 13, 18 September 2001· Addendum to Windows NT STIG, Version 3, Release 1, paragraph 4.5.3; Section 5; Appendix E, 24 November 2004· Windows XP STIG Version 1, Release 8, Section 6.1.1, 03 December 2002· Windows NT/XP/2000 Addendum Version 4, Release 1 – STIG, Section 4.5.3, 26 February 2004· Department of Transportation Windows 2000 Secure Baseline Configuration Standards, Section 1, 20 January 2004

IAKM-3 Key Management MediumIdentification and Authentication

Symmetric and asymmetric keys are produced, controlled and distributed using NSA-approved key management technology and processes.

Classified DoD information requires protection from unauthorized access, modification, or destruction. All symmetric keys used to encrypted data must be protected commensurate with the classification level of the information being protected. For Asymmetric keys the user or custodian must protect the private key commensurate with the classification level of the information being protected. The processes for creating and distributing keys used to encrypt transmit classified information and to authenticate users who are authorized access to classified information must be carried out using highly secure processes. The DoD Public Key Infrastructure can be utilized to encrypt data on Classified networks, Classified data transmitted across untrusted networks must be encrypted using. The security requirements for cryptographic key management encompass the entire lifecycle of cryptographic keys, cryptographic key components, and Cryptographic Service Providers employed by the cryptographic module. Key management includes random number and key generation, key establishment, key distribution, key entry/output, key storage, and key zeroization.

1. The PKI manages the registration, issuance and control of X.509 certificates for use by DoD personnel in the conduct of official business. An X.509 certificate binds an end entity (such as a subscriber, router, or automated message guard) to a key pair, certifying that the entity identified in the certificate has the private key associated with the public key incorporated into the certificate.2. The key pairs are used by end entities to perform cryptographic operations: to digitally sign information, to ensure the identity of the signer and the integrity of the information, and to encrypt information to ensure confidentiality. The DoD PKI issues separate certificates and key pairs for identity authentication and integrity, and for confidentiality.3. Secret keys, private keys, and Cryptographic Service Providers shall be protected within the cryptographic module from unauthorized disclosure, modification, and substitution. Public keys shall be protected within the cryptographic module against unauthorized modification and substitution. 4. SAs shall document and specify all cryptographic keys, cryptographic key components, and Cryptographic Service Providers employed by a cryptographic module.5. All private key pairs that are used to assert non-repudiation and are tightly bound to an entities identity must be protected in accordance with classification level of the information being processed.6. All users and custodians are responsible to protect and store all private keys. For the hardware token, users must promptly report lost or stolen tokens. For software private keys, users must store them in a tamper evident package locked in a safe.

· DoDI 8520.2 “DoD Public Key Infrastructure (PKI) and Public Key (PK) Enabling, 01 April 2004)· X.509 Certificate Policy for the United States Department of Defense, Version 8, 11 December 2003)· CJSCM 6510.01, Change 1, Enclosure C, Appendix O, 10 August 2004· FIPS 140-2 Level 2, FIPS 140-2 Level 3

IATS-2 Medium

PECF-2 High

PECS-2 High

PEDD-1 Destruction High

Token and Certificate Standards


Identification and authentication is accomplished using the DoD PKI Class 3 or 4 certificate and hardware security token (when available) or an NSA-certified product.

DoD PKI hardware tokens will be used to support automation and enhance security without jeopardizing user mobility. DoD PKI hardware tokens will provide a “medium” level of robustness and security strength applicable to “unclassified mission critical” operations. There are a number of potential threats and vulnerabilities on the Token, to include the following: · Physical attacks · Logical attacks · Attacks associated with control of access to the Token · Attacks associated with unanticipated interactions with the Token · Attacks associated with the Token’s Cryptographic Functions · Attacks associated with monitoring information of the Token · Attacks associated with miscellaneous threats to the Token; and · Attacks associate with the operating environment of the Token The DoD PKI hardware token should be an enhanced COTS product, based on token standards, and interoperable with any commercial and DoD PKI applications.

1. The DoD will provide for a certificate management infrastructure yielding a capability to verify the identity, authority and integrity involved in each transaction.2. The system administrators shall protect the workstations and the cryptographic module from unauthorized access or modification via the following at a minimum: · Access control list · Configuration management · Physical protection3. The system administrators shall ensure that all applications should be Common Criteria evaluated and Joint Interoperability Testing Command certified.4. The system administrators shall configure workstations with the appropriate security technical implementation guidance and implement the IAVA process into configuration management practices in accordance with the security policy.

· Department of Defense (DoD) Public Key Infrastructure (PKI) Token Protection Profile (Medium Robustness), Version 2, Release 1 of the “Common Criteria” International Standard 15408· Smart Card Security User Group Smart Card Protection Profile (SCSUG-SCPP) Draft Version 2.0· DISA IAVA Process Handbook, Version 2, Release 1, 11 June 2002· FIPS 140-2 Level 2, FIPS 140-2 Level 3

Access to Computing Facilities

Physical and Environmental

Only authorized personnel with appropriate clearances are granted physical access to computing facilities that process classified information.

Servers, workstations and documentation located in secure facilities are at risk of attack, copying, destruction, and illegal distribution by unauthorized access.

1. All locations where servers, workstations and documentation containing classified information shall be prohibited to those who do not have adequate permissions to enter such facilities.2. Access to these facilities shall be granted to those personnel only after receiving a background investigation and granted approval for access to classified information.

· DoD 5200.2-R, (Personnel Security Program), January 1987

Clearing and Sanitizing


All documents, equipment, and machine-readable media containing classified data are cleared and sanitized before being released outside its security domain according to DoD 5200.1-R.

Ensure that all documents, equipment, and machine-readable media containing classified data are at risk from copying and illegal distribution if not properly cleared and sanitized before distribution outside the security domain of DoD.

1. All documents, equipment, and machine-readable media containing classified data shall be properly cleared and sanitized in accordance with DoD 5200.1-R.2. A release catalog shall be created, logged, and stored for at least five (5) years on all documents, equipment, and machine-readable media that has been cleared and sanitized of classified data before being released outside of DoD.3. The release catalog shall be updated and verified every time sanitized documents, equipment, and machine-readable media are released outside of DoD.4. Audit and version controls shall be in place to ensure the most recent version of the release catalog is updated and stored.



All documents, machine-readable media, and equipment are destroyed using procedures that comply with DoD policy (e.g., DoD 5200.1-R).

All documents, machine-readable media and equipment not properly destroyed are at risk to unauthorized copying and illegal distribution.

1. All documents, machine-readable media, and equipment shall be destroyed in accordance with the procedures outlined in DoD policy (DoD 5200.1-R).2. A destruction catalog shall be created, logged, and stored for at least five (5) years on all documents, machine-readable media and equipment that has been destroyed.


PEDI-1 Data Interception High

PEEL-2 N/A Medium

PEFD-2 Fire Detection N/A High

PEFI-1 Fire Inspection N/A Medium

PEFS-2 Fire Suppression N/A High

PEHC-2 Humidity Controls N/A Medium


Devices that display or output classified or sensitive information in human-readable form are positioned to deter unauthorized individuals from reading the information.

Devices that display or output classified or sensitive information in human-readable form are at risk to unauthorized viewing, memorizing, copying, and illegal data distribution if not properly positioned to prevent such display units from being seen by unauthorized individuals.

1. Devices that display or output classified or sensitive information in human-readable form shall be positioned to deter unauthorized individuals from reading the information.


Emergency Lighting


An automatic emergency lighting system is installed that covers all areas necessary to maintain mission or business essential functions, to include emergency exits and evacuation routes.

Personnel are at risk of injury, equipment is at risk of damage, and maintaining mission and business essential functionality is at risk of interruption in emergency situations if adequate lighting is not automatic and provided that covers all emergency exits and evacuation routes.

1. An automatic emergency lighting system shall be installed that covers all emergency exits and evacuation routes.2. The automatic emergency lighting system shall be tested on a yearly basis to ensure proper functionality.3. The automatic emergency lighting system shall be in accordance with building fire and safety codes.4. Documentation of all testing procedures shall be stored at the facility.5. Documentation of all tests performed shall be logged and verified through internal audit verification in accordance with standard operating procedures.


A servicing fire department receives an automatic notification of any activation of the smoke detection or fire suppression system.

Personnel are at risk of injury and equipment at risk of damage in emergency situations if a servicing fire department is not automatically notified of smoke detection or fire suppression system.

1. A servicing fire department shall receive an automatic notification of any activation of the smoke detection or fire suppression system.2. Testing of the automatic notification of any activation of smoke detection by the servicing fire department shall be tested every time there is a universal time change, such as moving to Day-Light Savings Time.3. Testing of the automatic notification of any activation of the fire suppression system by the servicing fire department shall be tested on an annual basis.4. Documentation of all testing procedures shall be stored at the facility.5. Documentation of all tests performed shall be logged and verified through internal audit verification in accordance with standard operating procedures.


Computing facilities undergo a periodic fire marshal inspection. Deficiencies are promptly resolved.

Personnel, equipment, media, and documentation are at risk to fire if facilities are not inspected by a fire marshal on a periodic basis.

1. Computing facilities shall undergo a periodic fire marshal inspection in accordance with building fire codes and standard operating procedures.2. All deficiencies detected shall be documented and updated on an annual basis.3. All deficiencies shall be promptly resolved in accordance with building fire codes and standard operating procedures.


A fully automatic fire suppression system is installed that automatically activates when it detects heat, smoke, or particles.

Personnel, equipment, media, and documentation are at risk to fire if a fully automatic fire suppression system is not installed that automatically activates when it detects heat, smoke, or particles.

1. A fully automatic fire suppression system shall be installed that automatically activates when it detects heat, smoke, or particles.2. A fully automatic fire suppression system shall be tested on a regular basis in accordance with equipment and manufacturer guidelines.3. Documentation of all testing procedures shall be stored at the facility.4. Documentation of all tests performed shall be logged and verified through internal audit verification in accordance with standard operating procedures.


Automatic humidity controls are installed to prevent humidity fluctuations potentially harmful to personnel or equipment operation.

Equipment and media are at risk to damage by heat, condensation, and humidity if humidity controls are not installed that provide an alarm of humidity fluctuations.

1. Humidity controls shall be installed that provide an alarm of fluctuations potentially harmful to personnel or equipment operation.2. Humidity controls shall be tested on a regular basis in accordance with equipment and manufacturer guidelines.3. Documentation of all testing procedures shall be stored at the facility.4. Documentation of all tests performed shall be logged and verified through internal audit verification in accordance with standard operating procedures.

PEMS-1 N/A High

PEPF-2 N/A High

PEPS-1 N/A Low

PESL-1 Screen Lock Medium

Master Power Switch


A master power switch or emergency cut-off switch to IT equipment is present. It is located near the main entrance of the IT area and it is labeled and protected by a cover to prevent accidental shut-off.

IT assets are at risk to electrical damage if a master power switch is not available or operational at a critical moment.

1. A master power switch or emergency cut-off switch to IT equipment shall be present in the facility.2. A master power switch or emergency cut-off switch to IT equipment shall be located near the main entrance of the IT area.3. A master power switch or emergency cut-off switch to IT equipment shall be protected by a cover to prevent accidental shut-off.4. Testing of the master power switch or emergency cut-off switch shall be tested in accordance with building code regulations.

Physical Protection of Facilities


Every physical access point to facilities housing workstations that process or display classified information is guarded or alarmed 24 X 7. Intrusion alarms are monitored. Two (2) forms of identification are required to gain access to the facility (e.g., ID badge, key card, cipher PIN, biometrics). A visitor log is maintained.

All documents, equipment, and machine-readable media containing classified information are at risk from unauthorized personnel, access, copying and illegal distribution, if every physical access point is not guarded or alarmed 24 X 7. The same risk applies if intrusion alarms are not monitored and two forms of identification are not required and verified to gain access to the facility.

1. Every physical access point to facilities housing workstations that process or display classified information shall be guarded or alarmed 24 X 7.2. Intrusion alarms to identified physical access points shall be monitored.3. Two (2) forms of identification shall be required to gain access to the facility.4. A visitor log shall be maintained for all entry through identified physical access points.

Physical Security Testing


A facility penetration testing process is in place that includes periodic, unannounced attempts to penetrate key computing facilities.

All documents, equipment, and machine-readable media are at risk from unauthorized personnel, access, copying and illegal distribution, if penetration testing to computing facilities are not performed.

1. A facility penetration testing process shall be in place.2. Periodic, unannounced attempts to penetrate key computing facilities shall take place.3. Results to periodic, unannounced attempts to penetrate key computing facilities shall be documented and shared with authorized security management and personnel.4. Review of the results to the periodic, unannounced attempts to penetrate key computing facilities shall take place within one week of each test to determine if any changes are required to correct deficiencies in facility security.


Unless there is an overriding technical or operational problem, workstation screen-lock functionality is associated with each workstation. When activated, the screen-lock function places an unclassified pattern onto the entire screen of the workstation, totally hiding what was previously visible on the screen. Such a capability is enabled either by explicit user action or a specified period of workstation inactivity (e.g., 15 minutes). Once the workstation screen-lock software is activated, access to the workstation requires knowledge of a unique authenticator. A screen lock function is not considered a substitute for logging out (unless a mechanism actually logs out the user when the user idle time is exceeded).

Unattended workstations and servers are at risk to unauthorized access to sensitive and classified information if there is not a screen-lock function in place.

1. Unless there is an overriding technical or operational problem, workstation screen-lock functionality shall be associated with each workstation.2. When activated, the screen-lock function shall place an unclassified pattern onto the entire screen of the workstation. This functionality shall totally hide what was previously visible on the screen.3. Such a capability shall be enabled either by explicit user action or a specified period of workstation inactivity (e.g., 15 minutes) in accordance with agency standard operating procedures.4. Once the workstation screen-lock software is activated, access to the workstation shall require knowledge of a unique authenticator.5. A screen lock function shall not be considered a substitute for logging out (unless a mechanism actually logs out the user when the user idle time is exceeded).

· Database STIG, Version 7, Release 1, 29 October 2004· Secure Remote Computing STIG, Version 1, Release 1, 14 February 2003· Department of Transportation Solaris Secure Baseline Configuration Standards, 20 January 2004)· UNIX STIG, Version 4, Release 4, 15 September 2003· Windows NT STIG, Version 4, Release 2, 18 September 2001· Addendum to Windows NT STIG, Version 3, Release 1, 24 November 2002· Windows XP STIG Version 1, Release 8, 03 December 2002· Windows NT/XP/2000 Addendum Version 4, Release 1 – STIG, 26 February 2004· Department of Transportation Windows 2000 Secure Baseline Configuration Standards, Section 1, 20 January 2004

PESP-1 N/A Medium

PESS-1 Storage High

PETC-2 N/A Medium

PETN-1 N/A Low

PEVC-1 N/A High

PEVR-1 N/A High

Workplace Security Procedures


Procedures are implemented to ensure the proper handling and storage of information, such as end-of-day security checks, unannounced security checks, and, where appropriate, the imposition of a two-person rule within the computing facility.

Information not handled and stored properly is at risk of unauthorized access, copying, and distribution.

1. Procedures shall be implemented to ensure the proper handling and storage of information.2. End-of-day (EOD) security checks shall take place to verify the handling and storage of information deemed necessary in accordance with agency and facility standard operating procedures.3. Unannounced security checks shall take place to verify the handling and storage of information deemed necessary in accordance with agency and facility standard operating procedures.4. Two-person rule shall take place when appropriate to verify the handling and storage of information deemed necessary in accordance with agency and facility standard operating procedures.


Documents and equipment are stored in approved containers or facilities with maintenance and accountability procedures that comply with DoD 5200.1-R.

Documents and equipment not stored in approved containers are at risk to damage, unauthorized access, copying, and distribution.

1. Documents and equipment shall be stored in approved containers.2. Approved containers shall be fireproof and waterproof where applicable.3. Facilities with maintenance and accountability procedures shall be in compliance with DoD 5200.1-R.

· DoD 5200.1-R, (Information Security Program), January 1997

Temperature Controls


Automatic temperature controls are installed to prevent temperature fluctuations potentially harmful to personnel or equipment operation.

Personnel, equipment and media are at risk to damage by heat, condensation, and humidity if temperature controls are not installed that provide an alarm of humidity fluctuations that are potentially harmful.

1. Ensure that temperature controls (i.e., thermostats) that are installed in system operational spaces that capable of automatically adjusting temperature to ensure it is kept at that which is prescribed for safe operation of system hardware.2. Temperature controls shall be equipped with an alarm that alerts system or facilities administrators when temperature fluctuations potentially harmful to personnel or equipment operation are detected.

Environmental Control Training


Employees receive initial and periodic training in the operation of environmental controls.

Damage to equipment, documents and media is at risk if environmental controls are not operated properly. Potentially harmful environmental conditions to personnel are at risk if environmental controls are not operated properly.

1. Employees shall receive initial training in the operation of environmental controls.2. Employees shall receive periodic training in the operation of environmental controls.3. Documentation of those employees who attended and received initial and periodic training shall be maintained.

Visitor Control to Computing Facilities


Current signed procedures exist for controlling visitor access and maintaining a detailed log of all visitors to the computing facility.

Facility is at risk of unauthorized access if controlled visitor access is not maintained.

1. Current signed procedures shall be in place for controlling visitor access.2. Current signed procedures shall be in place for maintaining a detailed log of all visitors to the computing facility.3. Visitor log shall be archived in a secure area for a set amount of time as established by security operating procedures.

Voltage Regulators


Automatic voltage control is implemented for key IT assets.

Workstations, servers, equipment, and media is at risk to damage if voltage is not automatically controlled for key IT assets.

1. Automatic voltage control shall be implemented and tested for key IT assets in accordance with vendor guidelines.2. Automatic voltage control shall be implemented and tested for key IT assets in accordance with facility guidelines.3. The automatic voltage control system shall be checked on a regular basis to ensure optimum efficiency and functionality.

PRAS-2 Personnel High

PRMP-2 Personnel High

Access to Information

Individuals requiring access to classified information are processed for access authorization in accordance with DoD personnel security policies.

Classified information stored on servers, workstations, media and documentation are at risk of copying, destruction, and illegal distribution by unauthorized access. In order to prevent access to classified information by unauthorized persons, a proper personnel screening and authorization process must be implemented in accordance with DoD Personnel Security policy.

This guidance is intended for Information Assurance Managers/Officers or System Administrators tasked with insuring that only those personnel cleared for the level of information processed by the system, and the requisite need to know, are granted access to the system for processing purposes: 1. Identify types of classified information processed by the system.2. For each person assigned to the organization and requiring processing privileges on the system, ensure that access authorization is provided by the organizational Security Officer in the form of a document clearly stating that the user has undergone the required background investigation for access to classified information at specific security classification levels, is cleared accordingly, and has been authorized access to the information on a need-to-know basis.3. Ensure that for systems processing sensitive compartmented information (SCI) or any other compartmented classified information that users have been received the proper briefings and signed the appropriate authorization paperwork.

· DoD 5200.2-R (Personnel Security Program), January 1987

Maintenance Personnel

Maintenance is performed only by authorized personnel. The processes for determining authorization and the list of authorized maintenance personnel is documented. Except as authorized by the DAA, personnel who perform maintenance on classified DoD information systems are cleared to the highest level of information on the system. Cleared personnel who perform maintenance on a classified DoD information systems require an escort unless they have authorized access to the computing facility and the DoD information system. If uncleared or lower-cleared personnel are employed, a fully cleared and technically qualified escort monitors and records all activities in a maintenance log. The level of detail required in the maintenance log is determined by the IAM. All maintenance personnel comply with DAA requirements for U.S. citizenship, which are explicit for all classified systems.

Refer to PECF-2, PEDI-1, PEPF-2, and PRAS-2.

This guidance is intended for Information Assurance Managers/Officers or System Administrators tasked with insuring that only those personnel cleared for the level of information processed by the system, and the requisite need to know, are granted access to the system for maintenance purposes: 1. Refer to guidance for IA control PRMP-1.2. Except as specifically waivered on a case-by-case basis by the DAA or organizational Security Officer, ensure that all personnel who perform maintenance on classified DoD information systems are cleared to the highest level of information on the system in accordance with DoD personnel security policies by verifying individual clearances and accesses through the organizational security officer.3. Ensure that system security documentation contains a clearly-stated policy that all cleared personnel who perform maintenance on classified DoD information systems shall require an escort unless they have been authorized access to the computing facility and the DoD information system.4. Ensure that system security policy states clearly that if uncleared personnel, or personnel with a lower clearance level than that of the system are employed for maintenance purposes, a fully cleared and technically qualified escort shall monitor and record all activities in a maintenance log. The level of detail required in the maintenance log shall be determined by the IAM in accordance with DoD personnel security policies, but should contain, at a minimum, the following information: a. Name, SSN, position, and company/organization of escorted individual b. System, node, or network segment on which individual is performing maintenance c. Security clearance level of the escorted individual d. Name of escort e. Start and stop date and times of maintenance work f. Summary description of maintenance performed5. Ensure that system security policy mandates that the information system environment is sanitized of all classified material or information prior to entrance of the escorted individual into the workspace.6. Verify that system security policy mandates that all maintenance personnel comply with DAA requirements for U.S. citizenship, which are explicit for all classified systems. For further supporting/amplifying information, see:1. PECF-22. PEDI-13. PEPF-24. PRAS-2

· DoD 5200.2-R (Personnel Security Program), January 1987

PRNK-1 Personnel High

PRRB-1 Personnel High

PRTN-1 Personnel High

Access to Need-to-Know Information

Only individuals who have a valid need-to-know that is demonstrated by assigned official Government duties and who satisfy all personnel security criteria (e.g., IT position sensitivity background investigation requirements outlined in DoD 5200.2-R) are granted access to information with special protection measures or restricted distribution as established by the information owner.

Refer to PRAS-1 and PRAS-2.

Refer to implementation guidance for PRAS-1 and PRAS-2 for details.


Security Rules of Behavior or Acceptable Use Policy

A set of rules that describe the IA operations of the DoD information system and clearly delineate IA responsibilities and expected behavior of all personnel is in place. The rules include the consequences of inconsistent behavior or non-compliance. Signed acknowledgement of the rules is a condition of access.

Sensitive and classified information stored on servers, workstations, media and documentation are at risk of access, monitoring, copying, destruction, and illegal distribution if rules are not in place to prevent such actions. Access to sensitive and classified facility access points is a risk from unauthorized personnel. Personnel performance in the work place is at risk of being non-productive due to unethical and irresponsible behavior if consequences for those actions are not defined and acknowledged by employees.

1. A set of rules that describe the IA operations of the DoD information system and clearly delineate IA responsibilities and expected behavior of all personnel shall be in place.2. The rules shall include the consequences of inconsistent behavior or non-compliance.3. Signed acknowledgement of the rules shall be a condition of access.4. Training or reminder of the IA operations rules and code of conduct shall be performed on an annual basis, or as frequently as in accordance with DoD policy.

· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)

Information Assurance Training

A program is implemented to ensure that upon arrival and periodically thereafter, all personnel receive training and familiarization to perform their assigned IA responsibilities, to include familiarization with their prescribed roles in all IA- related plans such as incident response, configuration management and COOP or disaster recovery.

Sensitive and classified information stored on servers, workstations, media and documentation are at risk of access, monitoring, copying, destruction, and illegal distribution if rules are not in place to prevent such actions. Access to sensitive and classified facility access points is a risk from unauthorized personnel. Personnel performance in the work place is at risk of being non-productive due to unethical and irresponsible behavior if consequences for those actions are not defined and acknowledged by employees.

1. A set of rules that describe the IA operations of the DoD information system and clearly delineate IA responsibilities and expected behavior of all personnel shall be in place.2. The rules shall include the consequences of inconsistent behavior or non-compliance.3. Signed acknowledgement of the rules shall be a condition of access.4. Training or reminder of the IA operations rules and code of conduct shall be performed on an annual basis, or as frequently as in accordance with DoD policy.

· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)

VIIR-2 High

VIVM-1 Medium

Incident Response Planning

Vulnerability and Incident Management

An incident response plan exists that identifies the responsible CND Service Provider in accordance with DoD Instruction O-8530.2 and CJCS Instruction 6510.01D, defines reportable incidents, outlines a standard operating procedure for incident response to include INFOCON, provides for user training, and establishes an incident response team. The plan is exercised at least every 6 months.

1. Computer network attack.2. Denial/degradation of service, including distributed denial of service.3. Unauthorized disclosure of non-public information (compromise of confidentiality).4. Unauthorized modification to and/or destruction of data (compromise of integrity, availability).5. Malicious code (viruses, worms, Trojan horses, unauthorized mobile code).6. Insider threats (privilege escalation; unauthorized viewing, copying, printing, e-mailing, modification).7. Plan must be exercised to ensure appropriateness and completeness of actions; training and readiness of personnel to recognize, respond to, contain/limit damage from, recover from and report incident.

1. An Incident Response Plan exists that covers foreseeable categories of incidents.2. The general Incident Response Plan is supplemented by specific Tactics, Techniques and Procedures (TTPs), as needed.3. Plan, TTPs and reporting procedures are in accordance with CJCSM 6510.01 CH-1 Enclosure B Appendix B and NSTISSD No. 503.4. Plan, TTPs are reporting procedures include evaluation of and recommended change to INFOCON if the specific situation warrants.5. An Incident Response Team is identified by billet and/or by name.6. Personnel are assigned in writing to the Incident Response Team.7. Assigned personnel have received necessary training and/or certifications.8. Command has established or subscribes to a certified Computer Network Defense Service Provider (CNDSP).9. Procedures include keeping Incident Response Team personnel aware of DOD Computer Network Defense situation including INFOCON, recent IAV Alerts&Bulletins, and Attack Sensing & Warning in accordance with DODI O-8530.2 Enclosures (3) and (4).10. The Plan includes internal and external notification requirements, including public affairs and law enforcement notification where appropriate. 11. User and system administrator training includes recognition of possible incidents and actions to notify the Incident Response Team.12. Incident Response Plan procedures preserve forensic evidence and chain-of-custody.13. The Plan is exercised at least every six months.14. Command critiques exercises, develops Lessons Learned, identifies and implements corrective actions derived from exercises.

· DoDI O-8530.2, Support to Computer Network Defense, 09 March 2001· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)· CJCSM 6510.01 (Change 1, 10 Aug 2004), Enclosure B, Appendix B

Vulnerability Management

Vulnerability and Incident Management

A comprehensive vulnerability management process that includes the systematic identification and mitigation of software and hardware vulnerabilities is in place. Wherever system capabilities permit, mitigation is independently validated through inspection and automated vulnerability assessment or state management tools. Vulnerability assessment tools have been acquired, personnel have been appropriately trained, procedures have been developed, and regular internal and external assessments are conducted. For improved interoperability, preference is given to tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention and use the Open Vulnerability Assessment Language (OVAL) to test for the presence of vulnerabilities.

1. Newly identified vulnerabilities in operating system and application software.2. Software received from vendor and installed without service packs and patches (new and re-built systems).3. Software no longer supported by vendor.4. Loss of configuration and change management (CCM) discipline.5. Loss of Certification and Accreditation integrity.

1. Command has an IAVM policy.2. Command has detailed IAVM implementation procedures and processes, timelines, organizational and individual responsibilities, actions in response to vulnerability exploitation.3. Command has designated in writing"Critical Servers& Infrastructure Components," "Servers & Infrastructure Components," and "Workstations" for IAVM prioritization?4."Critical Servers and Infrastructure Components"designations are consistent with assigned Mission Assurance Categories?5. There is a process for complying with and internally reporting IAV Bulletins and Technical Advisories, as well as Alerts.6. Command uses DOD-provided, enterprise-wide or interoperable Combatant Commander/Service/Agency (CC/S/A)-procured tools and solutions to support IAVM program.7. Primary and secondary IAVM representatives are designated in writing.8. Receipts of IAV Alerts and Bulletins are timely acknowledged.9. Vulnerability notifications and remediation procedures&resources are promulgated to all subordinate organizations.10. All subordinate organizations comply with IAVAs or develop and implement mitigation plans.11. Compliance by assets is reported using the Vulnerability Management System (VMS) web application.12. Positive configuration control of all IT assets is maintained.13. All contracts for IT assets and services reflect requirements of the IAVM program.14. Monitor implementation or mitigation plans for all centrally-managed programs.15. Conduct IAVM program compliance checks of subordinate organizations.

· DoDI O-8530.2, Enclosure (6), Support to Computer Network Defense, 09 March 2001· CJCSM 6510.01 (Change 1, 10 Aug 04) , Enclosure B, Appendix A

Validation ProceduresSelect a MAC/CL combination to view corresponding Validation Procedures:

IA Control # Procedure Name Procedure ObjectiveValidation Procedure

Number

MAC I, Classified

MAC I, Sensitive

MAC I, Public

All Validation Procedures

Validation ProceduresSelect a MAC/CL combination to view corresponding Validation Procedures:

Procedure Preparation Procedure Script

MAC I, Classified MAC II, Classified MAC III, Classified

MAC I, Sensitive MAC II, Sensitive MAC III, Sensitive

MAC I, Public MAC II, Public MAC III, Public

Validation Procedures Last Update: 8/13/2007

Select a MAC/CL combination to view corresponding Validation Procedures:

Expected Results