<?xml version="1.0" encoding="utf-8"?>
<IMPORT_FILE xmlns="urn:FindingImport">
<IACONTROL>
<CONTROL_NUMBER title="Alternate Site Designation">COAS-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Alternate Site Designation</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>An alternate site is identified that permits the partial restoration of mission or business essential functions.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>This general implementation guidance is provided for IAMs/IAOs involved in the creation of a system or organizational Continuity of Operations (COOP) plan:
1. Identify an alternate site that has the capability to at least partially restore mission or business essential functions.
2. Establish a program to ensure comprehensive and effective continuity of essential functions 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.)
3. Ensure that the program includes a strategy to recover and perform partial system operations at the alternate facility for an extended period of time.
4. Partial restoration of mission or business essential functions at an alternate site shall be based on the results of a business impact analyses that identifies and ranks major information systems and mission-critical applications according to their operational priority and the maximum permissible outage for each.
5. Review the system contingency plan to ensure that the alternate site is able to support partial system operations as defined in the plan.
6. The contingency plan shall provide detailed procedures and capabilities to facilitate recovery and sustain functions at the alternate site.
7. The contingency plan shall define a strategy for 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.
8. The alternate site shall include HVAC capabilities and any specialized security equipment to sustain partial operations</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Alternate Site Designation">COAS-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Alternate Site Designation</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>An alternate site is identified that permits the restoration of all mission or business essential functions.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Protection of Backup and Restoration Assets">COBR-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Protection of Backup and Restoration Assets</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Data Backup Procedures">CODB-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Data Backup Procedures</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>Data backup is performed at least weekly.</DESCRIPTION>
<THREAT>Data is at risk of corruption and loss if not backed up on the housing system on a weekly basis. Backups should be incremental during the week and whole on weekends or during non-peak operational hours to ensure completeness of backup with minimal disruption to system operations.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. Data backup shall be performed on a weekly basis.
2. Backup media shall be labeled with the appropriate information, including a Date/Time stamp.
3. Data backups shall be logged and verified by the appropriate personnel in accordance with agency policy and standard operating procedures.
4. Backup media shall not be stored in the same office space as the information system that was backed up.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD Directive 3020.26, Defense Continuity Program, 08 September 2004</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Data Backup Procedures">CODB-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Data Backup Procedures</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Data backup is performed daily, and recovery media are stored off-site at a location that affords protection of the data in accordance with its mission assurance category and confidentiality level.</DESCRIPTION>
<THREAT>Classified or sensitive data is at risk of loss or corruption if not backed up on media that and stored at an off-site location, should an incident occur at the primary site, such as fire, water, natural disaster, and tampering.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>This guidance is written for System Administrators with backup privileges:
1. Perform data backups on a daily basis at times specified by local operations policy.
2. Ensure that site(s) is/are designated for storage of Backup/Recovery media at a location that affords protection of the data in accordance with its mission assurance category and confidentiality level.
3. Backup media shall be labeled with the appropriate information, including system identifier, classification or sensitivity labeling, and a Date/Time stamp.
4. Ensure that data backups are logged and verified by the appropriate administrative personnel in accordance with system security policy.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD Directive 3020.26, Defense Continuity Program, 08 September 2004</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Data Backup Procedures">CODB-3</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
</MACCONF>
<CONTROL_NAME>Data Backup Procedures</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD Directive 3020.26, Defense Continuity Program, 08 September 2004</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Disaster and Recovery Planning">CODP-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Disaster and Recovery Planning</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>A disaster plan exists that provides for the partial resumption of mission or business essential functions within 5 days of activation. (Disaster recovery procedures include business recovery plans, system contingency plans, facility disaster recovery plans, and plan acceptance.)</DESCRIPTION>
<THREAT>Mission and business essential functions are at risk to interruption from a disaster without a disaster recovery plan properly documented and executed within 5 days of activation. Categorizing the level of impact of the data, training proper personnel, building in proper process can ensure success in the planning.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. A disaster plan shall exist that provides for the partial resumption of mission or business essential functions within 5 days of activation.
2. Disaster recovery procedures shall include business recovery plans, system contingency plans, facility disaster recovery plans, and plan acceptance.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD Directive 3020.26, Defense Continuity Program, 08 September 2004</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Disaster and Recovery Planning">CODP-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Disaster and Recovery Planning</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>A disaster plan exists that provides for the resumption of mission or business essential functions within 24 hours of activation. (Disaster recovery procedures include business recovery plans, system contingency plans, facility disaster recovery plans, and plan acceptance.)</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. A disaster plan shall exist that provides for all resumption of mission or business essential functions within 24 hours of activation.
2. Disaster recovery procedures shall include business recovery plans, system contingency plans, facility disaster recovery plans, and plan acceptance.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD Directive 3020.26, Defense Continuity Program, 08 September 2004</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Disaster and Recovery Planning">CODP-3</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
</MACCONF>
<CONTROL_NAME>Disaster and Recovery Planning</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.)</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD Directive 3020.26, Defense Continuity Program, 08 September 2004</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Enclave Boundary Defense">COEB-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Enclave Boundary Defense</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Enclave boundary defense at the alternate site provides security measures equivalent to the primary site.</DESCRIPTION>
<THREAT>A securely configured enclave boundary is essential to the maintaining the integrity of a site’s IT systems. Ensuring that an alternate site provides boundary security equivalent to the primary site assures integrity of operations in the wake of an incident requiring the switch of mission operations to the alternate site.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>Enclave boundary defense at the alternate site shall provide security measures equivalent to the primary site.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DISA Enclave Security STIG, Version 2, Release 1, 01 July 2004
· DISA Enterprise Security Management STIG, 29 October 2004</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Enclave Boundary Defense">COEB-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
</MACCONF>
<CONTROL_NAME>Enclave Boundary Defense</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>Enclave boundary defense at the alternate site must be configured identically to that of the primary site.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>Enclave boundary defense at the alternate site shall be configured identically to that of the primary site.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DISA Enclave Security STIG, Version 2, Release 1, 01 July 2004
· DISA Enterprise Security Management STIG, 29 October 2004</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Scheduled Exercises and Drills">COED-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Scheduled Exercises and Drills</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>The continuity of operations or disaster recovery plans are exercised annually.</DESCRIPTION>
<THREAT>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 annually followed by corrections and enhancements improve an organization’s disaster
response capabilities.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. The continuity of operations or disaster recovery plans shall be exercised annually to ensure plans are complete and viable.
2. The exercise 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Scheduled Exercises and Drills">COED-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
</MACCONF>
<CONTROL_NAME>Scheduled Exercises and Drills</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>The continuity of operations or disaster recovery plans or significant portions are exercised semi-annually.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Identification of Essential Functions">COEF-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Identification of Essential Functions</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>Mission and business essential functions are identified for priority restoration planning.</DESCRIPTION>
<THREAT>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 for restoration planning.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. Mission and business essential functions shall be identified for priority restoration planning and 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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
· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Identification of Essential Functions">COEF-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Identification of Essential Functions</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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).</DESCRIPTION>
<THREAT>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).</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Maintenance Support">COMS-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Maintenance Support</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>Maintenance support for key IT assets is available to respond within 24 hours of failure.</DESCRIPTION>
<THREAT>Mission-essential systems require maintenance support to be available within 24 hours of a system failure to ensure minimal disruption of 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 operations.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. Ensure that maintenance support for key IT assets shall be available to respond within 24 hours of system failure by implementing a service agreement stipulating such availability
2. Verify that the maintenance support service agreement specifies availability of maintenance support within 24 hours after a system failure.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Maintenance Support">COMS-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Maintenance Support</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Maintenance support for key IT assets is available to respond 24 X 7 immediately upon failure.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Power Supply">COPS-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Power Supply</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>Electrical power is restored to key IT assets by manually activated power generators upon loss of electrical power from the primary source.</DESCRIPTION>
<THREAT>Mission and business essential functions are at risk to interruption and loss of data if primary electrical power is not restored in a timely manner.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. Electrical power shall be restored to key IT assets by manually activated power generators upon loss of electrical power from the primary source.
2. Full enterprise electrical back up system with an alert system indicator for power influx.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Power Supply">COPS-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Power Supply</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Electrical systems are configured to allow continuous or uninterrupted power to key IT assets. This may include an uninterrupted power supply coupled with emergency generators.</DESCRIPTION>
<THREAT>Mission-critical systems 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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. Electrical systems shall be configured to allow continuous or uninterrupted power to key IT assets.
2. This shall include an uninterrupted power supply coupled with emergency generators.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Power Supply">COPS-3</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
</MACCONF>
<CONTROL_NAME>Power Supply</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Spares and Parts">COSP-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Spares and Parts</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>Maintenance spares and spare parts for key IT assets can be obtained within 24 hours of failure.</DESCRIPTION>
<THREAT>Mission-essential systems require access to maintenance spares and spare parts twithin 24 hours of a system failure to ensure minimal disruption of 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 operations.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. Review the maintenance support contracts, logs and documentation to verify that maintenance spares and spares parts support for key IT assets is available within 24 hours of failure.
2. Record the results.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Spares and Parts">COSP-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
</MACCONF>
<CONTROL_NAME>Spares and Parts</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Maintenance spares and spare parts for key IT assets are available 24 X 7 immediately upon failure.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Backup Copies of Critical SW">COSW-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Backup Copies of Critical SW</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Trusted Recovery">COTR-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Trusted Recovery</CONTROL_NAME>
<SUBJECT_AREA>Continuity</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Procedural Review">DCAR-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Procedural Review</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Acquisition Standards">DCAS-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
<CONF>PUBLIC</CONF>
</MACCONF>
<CONTROL_NAME>Acquisition Standards</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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).</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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).</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Best Security Practices">DCBP-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Best Security Practices</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>The DoD information system security design incorporates best security practices such as single sign-on, PKE, smart card, and biometrics.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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)</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Control Board">DCCB-1</CONTROL_NUMBER>
<MACCONF />
<CONTROL_NAME>Control Board</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>All DoD information systems are under the control of a chartered configuration control board that meets regularly according to DCPR-1.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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. All decisions made by the CCB, including any changes to the system baseline, shall be documented and maintained in the appropriate configuration management system.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)
· ANSI/EIA-649 “National Consensus Standard for Configuration Management”, July 1998</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Control Board">DCCB-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Control Board</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)
· ANSI/EIA-649 “National Consensus Standard for Configuration Management”, July 1998</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Configuration Specifications">DCCS-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Configuration Specifications</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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 following are acceptable in descending order as available: (1) Commercially accepted practices (e.g., SANS); (2) Independent testing results (e.g., ICSA); or (3) Vendor literature.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004
· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Configuration Specifications">DCCS-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Configuration Specifications</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Compliance Testing">DCCT-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Compliance Testing</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>A comprehensive set of procedures is implemented that tests all patches, upgrades, and new AIS applications prior to deployment.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Dedicated IA Services">DCDS-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Dedicated IA Services</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Functional Architecture for AIS Applications">DCFA-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Functional Architecture for AIS Applications</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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).</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoDI 8500.2, Information Assurance (IA) Implementation, 06 February 2003</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="HW Baseline">DCHW-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>HW Baseline</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· ANSI/EIA-649 Configuration Management, “National Consensus Standard for Configuration Management”, July 1998</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Interconnection Documentation">DCID-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Interconnection Documentation</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="IA Impact Assessment">DCII-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>IA Impact Assessment</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Changes to the DoD information system are assessed for IA and accreditation impact prior to implementation.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="IA for IT Services">DCIT-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>IA for IT Services</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>Acquisition or outsourcing of IT services explicitly addresses Government, service provider, and end user IA roles and responsibilities.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Mobile Code">DCMC-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Mobile Code</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Non-repudiation">DCNR-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Non-repudiation</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· FIPS 140-2, Security Requirements for Cryptographic Modules, 25 May 2001</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Partitioning the Application">DCPA-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Partitioning the Application</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DISA Web Server STIG, Version 5, 26 July 2004</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="IA Program and Budget">DCPB-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>IA Program and Budget</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>A discrete line item for Information Assurance is established in programming and budget documentation.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>Component programming and budget documentation shall include a discrete line item for Information Assurance activities within their purview.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Public Domain Software Controls">DCPD-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Public Domain Software Controls</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· Open Source Software (OSS) in the Department of Defense (DoD) Memorandum., 28 May 2003
· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Ports, Protocols, and Services">DCPP-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Ports, Protocols, and Services</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="CM Process">DCPR-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>CM Process</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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; and
4. 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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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; and
4. 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="IA Documentation">DCSD-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>IA Documentation</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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).</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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).</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoDI 8500.2, Information Assurance Implementation, para. E3.3.5 - 6, 06 February 2003</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="System Library Management Controls">DCSL-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>System Library Management Controls</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>System libraries are managed and maintained to protect privileged programs and to prevent or minimize the introduction of unauthorized code.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Security Support Structure Partitioning">DCSP-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Security Support Structure Partitioning</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DISA Network Infrastructure STIG, Version 5, Release 2, 29 September 2003
· DISA Web Server STIG, Version 5, 26 July 2004</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Software Quality">DCSQ-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Software Quality</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Specified Robustness - Basic">DCSR-1</CONTROL_NUMBER>
<MACCONF>
<CONF>PUBLIC</CONF>
</MACCONF>
<CONTROL_NAME>Specified Robustness - Basic</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>At a minimum, basic-robustness COTS IA and IA-enabled products are used to protect publicly released information from malicious tampering or destruction and ensure its availability. The basic-robustness requirements for products are defined in the Protection Profile Consistency Guidance for Basic Robustness published under the IATF.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. At a minimum, basic-robustness COTS IA and IA-enabled products shall be used to protect publicly released information from malicious tampering or destruction and ensure its availability.
2. The basic-robustness requirements for products are defined in the Protection Profile Consistency Guidance for Basic Robustness published under the IATF.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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, .4, 06 February 2003
· Information Assurance Technical Framework, Appendix E IATF Release 3.1. September 2002</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Specified Robustness - Medium">DCSR-2</CONTROL_NUMBER>
<MACCONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Specified Robustness - Medium</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>At a minimum, medium-robustness COTS IA and IA-enabled products are used to protect sensitive information when the information transits public networks or the system handling the information is accessible by individuals who are not authorized to access the information on the system. The medium-robustness requirements for products are defined in the Protection Profile Consistency Guidance for Medium Robustness published under the IATF. COTS IA and IA-enabled IT products used for access control, data separation, or privacy on sensitive systems already protected by approved medium-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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. At a minimum, medium-robustness COTS IA and IA-enabled products shall be used to protect sensitive information when the information transits public networks or the system handling the information is accessible by individuals who are not authorized to access the information on the system. *
2. The medium-robustness requirements for products are defined in the Protection Profile Consistency Guidance for Medium Robustness published under the IATF. *
3. COTS IA and IA-enabled IT products used for access control, data separation, or privacy on sensitive systems already protected by approved medium-robustness products, at a minimum, shall 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-1</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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, .3, 06 February 2003
· Information Assurance Technical Framework, Appendix E IATF Release 3.1. September 2002</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Specified Robustness – High">DCSR-3</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Specified Robustness – High</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="System State Changes">DCSS-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>System State Changes</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>System initialization, shutdown, and aborts are configured to ensure that the system remains in a secure state.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. Identify system transition states and refer to appropriate DISA, NSA, or other approved security technical implementation guide for specific configuration guidance.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="System State Changes">DCSS-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>System State Changes</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. Identify system transition states and refer to appropriate DISA, NSA, or other approved security technical implementation guide for specific configuration guidance.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="SW Baseline">DCSW-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>SW Baseline</CONTROL_NAME>
<SUBJECT_AREA>Security Design and Configuration</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· ANSI/EIA-649 Configuration Management, “National Consensus Standard for Configuration Management”, July 1998</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Boundary Defense">EBBD-1</CONTROL_NUMBER>
<MACCONF>
<CONF>PUBLIC</CONF>
</MACCONF>
<CONTROL_NAME>Boundary Defense</CONTROL_NAME>
<SUBJECT_AREA>Enclave Boundary Defense</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>Boundary defense mechanisms to include firewalls and network intrusion detection systems (IDS) are deployed at the enclave boundary to the wide area network, and Internet access is permitted from a demilitarized zone (DMZ) that meets the DoD requirement that such contacts are isolated from other DoD systems by physical or technical means. All Internet access points are under the management and control of the enclave. Internet access is permitted from a demilitarized zone (DMZ) that meets the DoD requirement that such contacts are isolated from other DoD systems by physical or technical means. All Internet access points are under the management and control of the enclave.</DESCRIPTION>
<THREAT>DoD systems processing public information, while not bound by stringent classification or sensitivity concerns, nonetheless require layered defensive mechanisms to prevent malicious actions against system resources. This protection is achieved by implementing boundary defense mechanisms such as firewalls and IDSes, as well as securely configuring enclave routers, to ensure that access to system resources is confined to authorized users. While access to public (Internet) resources is permitted, such access must be set up through a demilitarized zone (DMZ), the purpose of which is to isolate network segments with access to public resources.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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 public information, 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 public 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 and 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 such that access to or from any network segment or node to the public Internet must is done only from a DMZ.
6. Ensure that boundary defense mechanisms adhere to the DoD ports, protocols, and services implementation process.
7. Ensure that wireless networks terminate in DMZs and are segregated from back office LAN traffic unless they pass through a secure gateway or VLAN.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DISA Network Infrastructure STIG, Version 6, 29 October 2004
· 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 Checklist Version 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Boundary Defense">EBBD-2</CONTROL_NUMBER>
<MACCONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Boundary Defense</CONTROL_NAME>
<SUBJECT_AREA>Enclave Boundary Defense</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Boundary defense mechanisms, to include firewalls and network intrusion detection systems (IDS) are deployed at the enclave boundary to the wide area network, at layered or internal enclave boundaries, or at key points in the network, as required. All Internet access is proxied through Internet access points that are under the management and control of the enclave and are isolated from other DoD information systems by physical or technical means.</DESCRIPTION>
<THREAT>Systems processing sensitive 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 untrusted public (Internet) resources. This protection is achieved by implementing boundary defense mechanisms such as firewalls and IDSes, as well as securely configuring enclave routers, to ensure that access to sensitive information is restricted to authorized users and trusted sources. Additionally, uncontrolled access to public (Internet) resources by a system processing sensitive information elevates the risk of inadvertent disclosure through unauthorized access. For this reason access to external (Internet) systems is proxied to ensure that connections are made to trusted sources only.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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 sensitive information, 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 sensitive 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 and 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 such that access to or from any network segment or node to the public Internet must be proxied through a dedicated node, such as a remote access server, set up at the enclave level and that is under the strict administration of the enclave. For additional details on proxy configurations for Internet access, refer to the DISA Network Infrastructure STIG.
6. Ensure that boundary defense mechanisms adhere to the DoD ports, protocols, and services implementation process.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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 Checklist Version 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Boundary Defense">EBBD-3</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Boundary Defense</CONTROL_NAME>
<SUBJECT_AREA>Enclave Boundary Defense</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Connection Rules">EBCR-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Connection Rules</CONTROL_NAME>
<SUBJECT_AREA>Enclave Boundary Defense</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>The DoD information system is compliant with established DoD connection rules and approval processes.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Public WAN Connection">EBPW-1</CONTROL_NUMBER>
<MACCONF>
<CONF>SENSITIVE</CONF>
<CONF>PUBLIC</CONF>
</MACCONF>
<CONTROL_NAME>Public WAN Connection</CONTROL_NAME>
<SUBJECT_AREA>Enclave Boundary Defense</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>Connections between DoD enclaves and the Internet or other public or commercial wide area networks require a demilitarized zone (DMZ).</DESCRIPTION>
<THREAT>When DoD systems are connected to public networks without the proper DMZ configuration unscrupulous individuals or groups can access sensitive information within an enclave and launch denial of service attacks. The use of a DMZ adds a reasonable layer of protection against external untrusted networks and DoD systems.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. Components shall identify the need for utilitzing a DMZ.
2. A Firewall device and routing schema shall be employed , i.e.: use of a dual-honed with screened subnet firewall architecture.
3. Refer to DoD or other applicable guidance for proper connection requirements and procedures.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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 Enclave Security STIG, Version 2, Release 1, 01 July 2004
· DISA Web Server STIG, Version 5 Draft, 26 July 2004</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Remote Access for Privileged Functions">EBRP-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Remote Access for Privileged Functions</CONTROL_NAME>
<SUBJECT_AREA>Enclave Boundary Defense</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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 sensitiv
e DoD information. Proper security precautions such as correct use of VPN and auditing minimize the risk of network compromise and attack.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Remote Access for User Functions">EBRU-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Remote Access for User Functions</CONTROL_NAME>
<SUBJECT_AREA>Enclave Boundary Defense</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="VPN Controls">EBVC-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>VPN Controls</CONTROL_NAME>
<SUBJECT_AREA>Enclave Boundary Defense</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>All VPN traffic is visible to network intrusion detection systems (IDS).</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Affiliation Display">ECAD-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Affiliation Display</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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., john.smith.ctr@army.mil orjohn.smith.uk@army.mil); - DoD user e-mail display names (e.g., John Smith, Contractor <john.smith.ctr@army.mil> or John Smith, United Kingdom <john.smith.uk@army.mil>); 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.,john.smith.ctr.uk@army.mil). Country codes and guidance regarding their use are in FIPS 10-4.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.,john.smith.CTR@army.mil). Configure the email server to display the email address on the screen, such as John Smith, Contractor john.smith.ctr@army.mil
3. 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.,john.smith.uk@army.mil) and configure the email server to display the email address on the screen as John Smith, United Kingdom john.smith.uk@army.mil
4. If the user is both contractor and foreign national, include both information (e.g.,john.smith.ctr.uk@army.mil).
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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoDD 5200-2, DoD Personnel Security Program, 09 April 1999</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Access for Need-to-Know">ECAN-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Access for Need-to-Know</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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 management
2. 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 access
3. 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)</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Audit Record Content – Public Systems">ECAR-1</CONTROL_NUMBER>
<MACCONF>
<CONF>PUBLIC</CONF>
</MACCONF>
<CONTROL_NAME>Audit Record Content – Public Systems</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>Audit records include:
· User ID.
· Successful and unsuccessful attempts to access security files.
· Date and time of the event.
· Type of event.</DESCRIPTION>
<THREAT>Insufficient security related information recorded in the audit trails cannot support effective and efficient detection of security violations. This implementation guide is aimed to help system administrators implement proper audit configuration to provide effective detection of security problems.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. The system administrator shall select security events within the auditing capability that can be provided by the system components in accordance with DISA STIGs for auditing related to operating system, database, and application.
2. 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.
3. 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 security investigation; and the auditing capability does not affect system operations.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DISA Web Server STIG, 26 July 2004
· DISA Windows 2003 Security Checklist (draft), 10 December 2004
· DISA Windows 4.0 Security Checklist, 10 December 2004
· DISA Unix STIG, 15 September 2003
· DISA Solaris Security Checklist, 20 January 2004
· DISA Database STIG, 24 July 2004</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Audit Record Content – Sensitive Systems">ECAR-2</CONTROL_NUMBER>
<MACCONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Audit Record Content – Sensitive Systems</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>Insufficient security related information recorded in the audit trails cannot support system forensics effectively and efficiently. This implementation guide is aimed to help system administrators implement the system audit mechanisms properly to provide effective monitoring and detection of the security problems, and security fixes can be implemented in a timely manner.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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 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.
3. 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.
4. 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Audit Record Content – Classified Systems">ECAR-3</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Audit Record Content – Classified Systems</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Audit Trail, Monitoring, Analysis and Reporting">ECAT-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
<CONF>SENSITIVE</CONF>
<CONF>PUBLIC</CONF>
</MACCONF>
<CONTROL_NAME>Audit Trail, Monitoring, Analysis and Reporting</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>Audit trail records from all available sources are regularly reviewed for indications of inappropriate or unusual activity. Suspected violations of IA policies are analyzed and reported in accordance with DoD information system IA procedures.</DESCRIPTION>
<THREAT>If audit trails that record security events are not reviewed regularly, security violations of the system cannot be detected and prevented in a timely manner. This implementation guide is aimed to help system administrators detect security violations in a timely manner.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. The project manager shall designate authorized personnel (IAM/IAO) in writing who can review audit trails regularly (e.g., daily, weekly) to monitor and detect any anomalies and unusual user activities.
2. The system administrator shall generate audit trails and distribute them as planned to the ISSO for review.
3. The system administrator also shall review the online audit trails and analyze the security violations and report minor and/or major security incident to ISSO in accordance with the system’s Incident Response Plan and the Standard Operating Procedures.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND), 10 August 2004
· System or Organization-specific Standard Operating Procedures and Incident Response Plan</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Audit Trail, Monitoring, Analysis and Reporting">ECAT-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Audit Trail, Monitoring, Analysis and Reporting</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Changes to Data">ECCD-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Changes to Data</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Access control mechanisms exist to ensure that data is accessed and changed only by authorized personnel.</DESCRIPTION>
<THREAT>Lack of proper access controls would allow unauthorized users to gain access to the system. This implementation guide is aimed to help system administrator to implement proper access controls based on user privileges.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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 Database STIG, Version 7, Release 1, 29 October 2004</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Changes to Data">ECCD-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Changes to Data</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="COMSEC">ECCM-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>COMSEC</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>COMSEC activities comply with DoD Directive C-5200.5.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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 account
2. 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Encryption for Confidentiality (Data at Rest)">ECCR-1</CONTROL_NUMBER>
<MACCONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Encryption for Confidentiality (Data at Rest)</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>If required by the information owner, NIST-certified cryptography is used to encrypt stored sensitive information.</DESCRIPTION>
<THREAT>Without proper cryptography being used, it would affect the confidentiality, integrity, and availability of sensitive information. This implementation guide is aimed to help information owners implement proper cryptography to protect sensitive information stored within the enclave.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. The information owner shall determine whether sensitive information stored needs to be protected using encryption.
2. 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 sensitive information
b. Research vendors products that have been certified based on NIST-certified cryptography
c. Perform an analysis of advantages and disadvantages of individual 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 sensitive information
e. Install and test the encryption capability in a lab environment
f. Implement the product into the system in the operational environment</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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 Tripe Data Encryption Algorithm (TDEA) Block Cipher, May 1004
· NIST SP 800-36, Guide to Selecting Information Security Products, October 2003</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Encryption for Confidentiality (Data at Rest)">ECCR-2</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Encryption for Confidentiality (Data at Rest)</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>If required by the information owner, NIST-certified cryptography is used to encrypt stored classified non-SAMI information.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Encryption for Confidentiality (Data at Rest)">ECCR-3</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Encryption for Confidentiality (Data at Rest)</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Encryption for Confidentiality (Data at Transmit)">ECCT-1</CONTROL_NUMBER>
<MACCONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Encryption for Confidentiality (Data at Transmit)</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Unclassified, sensitive data transmitted through a commercial or wireless network are encrypted using NIST-certified cryptography (See also DCSR-2).</DESCRIPTION>
<THREAT>Without protecting unclassified, sensitive information using encryption methods, sensitive data transmitted through unprotected network could be disclosed, modified, or destroyed by unauthorized users. This implementation guide is aimed to help system engineering teams implement proper cryptography to protect sensitive information transmitted through a commercial or wireless network.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>The system engineering team (e.g., project manager, system engineers, security engineer, and IA personnel) shall perform the following:
1. Identify a list of NIST-certified cryptography (3DES, AES) to encrypt unclassified, sensitive information transmitted through a commercial or wireless network
2. Research vendor products (e.g., virtual private network [VPN], secure sockets layer [SSL], secure shell [SSH]) using NIST-certified cryptography
3. Perform an analysis of advantages and disadvantages of individual encryption products based on system’s operational requirements and available fund
4. Select an encryption product (with the latest version) that is the most suitable to the system’s environment to encrypt sensitive data transmitted
5. Install and test the encryption capability in a lab environment to ensure that sensitive data transmitted in encryption through a commercial or wireless network
6. Implement the device into the system in the operational environment</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DISA Wireless STIG, 15 April 2004
· 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 Tripe Data Encryption Algorithm (TDEA) Block Cipher, May 2004
· NIST SP 800-36, Guide to Selecting Information Security Products, October 2003</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Encryption for Confidentiality (Data at Transmit)">ECCT-2</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Encryption for Confidentiality (Data at Transmit)</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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).</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Data Change Controls">ECDC-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Data Change Controls</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Transaction-based systems (e.g., database management systems, transaction processing systems) implement transaction roll-back and transaction journaling, or technical equivalents.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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)</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Interconnections among DoD Systems and Enclaves">ECIC-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Interconnections among DoD Systems and Enclaves</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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 environment
3. 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Host Based IDS">ECID-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Host Based IDS</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Host-based intrusion detection systems are deployed for major applications and for network management assets, such as routers, switches, and domain name servers (DNS).</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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)</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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)</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Instant Messaging">ECIM-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Instant Messaging</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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)</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Audit of Security Label Changes">ECLC-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Audit of Security Label Changes</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>The system automatically records the creation, deletion, or modification of confidentiality or integrity labels, if required by the information owner.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Logon">ECLO-1</CONTROL_NUMBER>
<MACCONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Logon</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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. This implementation guide is aimed to help system administrators implement the account lock policy and a limited number of logon sessions for each user ID.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. The system administrator shall configure the account policy of the operating system, database, and/or application that authenticates users to access the system. For example, for 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 minutes
2. For the implementation of a 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 use an approved 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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, 02 October 2003
· NSA Oracle Database Server Guides, 02 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Logon">ECLO-2</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Logon</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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 minutes
2. 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Least Privilege">ECLP-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
<CONF>PUBLIC</CONF>
</MACCONF>
<CONTROL_NAME>Least Privilege</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Marking and Labeling">ECML-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Marking and Labeling</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Conformance Monitoring and Testing">ECMT-1</CONTROL_NUMBER>
<MACCONF>
<CONF>SENSITIVE</CONF>
<CONF>PUBLIC</CONF>
</MACCONF>
<CONTROL_NAME>Conformance Monitoring and Testing</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>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, and conducted. Testing is intended to ensure that the system's IA capabilities continue to provide adequate assurance against constantly evolving threats and vulnerabilities.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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)
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).</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Conformance Monitoring and Testing">ECMT-2</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Conformance Monitoring and Testing</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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).</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Network Device Controls">ECND-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Network Device Controls</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>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).</DESCRIPTION>
<THREAT>Without an adequate network device control program, effective 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 and maintain network control devices effectively.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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 the following information, but are not limited to:
· 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 protect the network control devices from unauthorized access.
3. 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)
4. 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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
· DISA IAVA Process Handbook Version 2.1, 11 June 2002
· NIST SP 800-41, Guidelines on Firewalls and Firewall Policy, January 2002</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Network Device Controls">ECND-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Network Device Controls</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Encryption for Need-To-Know">ECNK-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Encryption for Need-To-Know</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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).</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Encryption for Need-To-Know">ECNK-2</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Encryption for Need-To-Know</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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).</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Privileged Account Control">ECPA-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Privileged Account Control</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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/</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Production Code Change Controls">ECPC-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Production Code Change Controls</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Application programmer privileges to change production code and data are limited and are periodically reviewed.</DESCRIPTION>
<THREAT>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 periodically.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. The CCB 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Production Code Change Controls">ECPC-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Production Code Change Controls</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Application programmer privileges to change production code and data are limited and reviewed every 3 months.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Resource Control">ECRC-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Resource Control</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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://www.niap-ccevs.org/ website along with procedures to get a product through the validation process.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Audit Reduction and Report Generation">ECRG-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Audit Reduction and Report Generation</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>Tools are available for the review of audit records and for report generation from audit records.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Audit Record Retention">ECRR-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
<CONF>PUBLIC</CONF>
</MACCONF>
<CONTROL_NAME>Audit Record Retention</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Security Configuration Compliance">ECSC-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Security Configuration Compliance</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>For Enclaves and AIS applications, all DoD security configuration or implementation guides have been applied.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Software Development Change Controls">ECSD-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Software Development Change Controls</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Change controls for software development are in place to prevent unauthorized programs or modifications to programs from being implemented.</DESCRIPTION>
<THREAT>The integrity of computer systems is at risk if software development change controls are not established and implemented. A Configuration Management (CM) plan greatly reduces the risk of unauthorized program modification.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. A CM plan shall be established and implemented, and the CM plan shall include how software change requests (SCRs) 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. The System Administrator shall institute access controls limiting the software developer accounts to the minimum number of privileges needed to perform their assigned duties.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Software Development Change Controls">ECSD-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Software Development Change Controls</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Audit Trail Backup">ECTB-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Audit Trail Backup</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>The audit records are backed up not less than weekly onto a different system or media than the system being audited.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Tempest Controls">ECTC-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Tempest Controls</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>Measures to protect against compromising emanations have been implemented according to DoD Directive S-5200.19.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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 systems
3. A Certified TEMPEST Technical Authority shall conduct or validate a TEMPEST countermeasure review.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Transmission Integrity Controls">ECTM-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Transmission Integrity Controls</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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).</DESCRIPTION>
<THREAT>Integrity of transmitted information is at risk if good engineering practices are not implemented. Error detection methods like parity checks, checksums, and CRCs mitigate the integrity risk of incoming and outgoing files during transmission.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Transmission Integrity Controls">ECTM-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Transmission Integrity Controls</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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).</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Audit Trail Protection">ECTP-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Audit Trail Protection</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>The contents of audit trails are protected against unauthorized access, modification or deletion.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Voice-over-IP (VoIP) Protection">ECVI-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Voice-over-IP (VoIP) Protection</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Virus Protection">ECVP-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Virus Protection</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>All Servers, workstations and mobile computing devices (i.e. laptop, PDAs) implement virus protection that includes a capability for automatic updates.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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).</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Warning Message">ECWM-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
<CONF>PUBLIC</CONF>
</MACCONF>
<CONTROL_NAME>Warning Message</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Wireless Computing and Network">ECWN-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Wireless Computing and Network</CONTROL_NAME>
<SUBJECT_AREA>Enclave Computing Environment</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Account Control">IAAC-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Account Control</CONTROL_NAME>
<SUBJECT_AREA>Identification and Authentication</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Group Authentication">IAGA-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Group Authentication</CONTROL_NAME>
<SUBJECT_AREA>Identification and Authentication</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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).</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Individual Identification and Authentication">IAIA-1</CONTROL_NUMBER>
<MACCONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Individual Identification and Authentication</CONTROL_NAME>
<SUBJECT_AREA>Identification and Authentication</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>DoD information system access is gained through the presentation of an individual identifier (e.g., a unique token or user login 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 the password 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. Additionally, to the extent system capabilities permit, system mechanisms are implemented to enforce automatic expiration of passwords and to prevent password reuse. 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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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
· DISA Database STIG, Version 7, Release 1, Section 3.1, 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.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 2002
· Windows XP STIG Version 1, Release 8, Section 6.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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Individual Identification and Authentication">IAIA-2</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Individual Identification and Authentication</CONTROL_NAME>
<SUBJECT_AREA>Identification and Authentication</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Key Management">IAKM-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Key Management</CONTROL_NAME>
<SUBJECT_AREA>Identification and Authentication</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Symmetric Keys are produced, controlled, and distributed using NIST-approved key management technology and processes. Asymmetric Keys are produced, controlled, and distributed using DoD PKI Class 3 certificates or pre-placed keying material.</DESCRIPTION>
<THREAT>Sensitive 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 DoD Public Key Infrastructure can be utilized to encrypt sensitive data on Unclassified networks to transmit data over untrusted networks. 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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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. 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.
5. 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Key Management">IAKM-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Key Management</CONTROL_NAME>
<SUBJECT_AREA>Identification and Authentication</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Symmetric Keys are produced, controlled and distributed using NSA-approved key management technology and processes. Asymmetric Keys are produced, controlled, and distributed using DoD PKI Medium Assurance or High Assurance certificates and hardware security tokens that protect the user's private key.</DESCRIPTION>
<THREAT>Sensitive 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 DoD Public Key Infrastructure can be utilized to encrypt sensitive data on Unclassified networks to transmit data over untrusted networks. 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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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. 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.
5. 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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
· CJSCI 6510.01D, Change 1, Enclosure C, Appendix O, 10 August 2004
· FIPS 140-2 Level 2, FIPS 140-2 Level 3</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Key Management">IAKM-3</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Key Management</CONTROL_NAME>
<SUBJECT_AREA>Identification and Authentication</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Symmetric and asymmetric keys are produced, controlled and distributed using NSA-approved key management technology and processes.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Token and Certificate Standards">IATS-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Token and Certificate Standards</CONTROL_NAME>
<SUBJECT_AREA>Identification and Authentication</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Identification and authentication is accomplished using the DoD PKI Class 3 certificate and hardware security token (when available).</DESCRIPTION>
<THREAT>DoD PKI and KMI software Tokens are required to counter the following threats:
· Logical attack
· Control of access
· Unanticipated interactions
· Cryptographic functions
· Miscellaneous threats</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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 protection
3. 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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
· DISA IAVA Process Handbook, Version 2, Relase 1, 11 June 2002
· FIPS 140-2 Level 2, FIPS 140-2 Level 3</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Token and Certificate Standards">IATS-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Token and Certificate Standards</CONTROL_NAME>
<SUBJECT_AREA>Identification and Authentication</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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 protection
3. 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Access to Computing Facilities">PECF-1</CONTROL_NUMBER>
<MACCONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Access to Computing Facilities</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>Only authorized personnel with a need-to-know are granted physical access to computing facilities that process sensitive information or unclassified information that has not been cleared for release.</DESCRIPTION>
<THREAT>Servers, workstations and documentation located in secure facilities are at risk of attack, copying, destruction, and illegal distribution by unauthorized access.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. All locations where servers, workstations and documentation containing sensitive 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, granted approval for access and need-to-know permissions to sensitive information or unclassified information that has not been cleared for release.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD 5200.2-R, (Personnel Security Program), January 1987</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Access to Computing Facilities">PECF-2</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Access to Computing Facilities</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>Only authorized personnel with appropriate clearances are granted physical access to computing facilities that process classified information.</DESCRIPTION>
<THREAT>Servers, workstations and documentation located in secure facilities are at risk of attack, copying, destruction, and illegal distribution by unauthorized access.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD 5200.2-R, (Personnel Security Program), January 1987</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Clearing and Sanitizing">PECS-1</CONTROL_NUMBER>
<MACCONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Clearing and Sanitizing</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>All documents, equipment, and machine-readable media containing sensitive data are cleared and sanitized before being released outside of the Department of Defense according to DoD 5200.1-R and ASD(C3I) Memorandum, dated June 4, 2001, subject: "Disposition of Unclassified DoD Computer Hard Drives."</DESCRIPTION>
<THREAT>Ensure that all documents, equipment, and machine-readable media containing sensitive data are at risk from unauthorized copying and illegal distribution if not properly cleared and sanitized before distribution outside of DoD.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. All documents, equipment, and machine-readable media containing sensitive data shall be properly cleared and sanitized in accordance with DoD 5200.1-R and ASD(C3I) Memorandum, dated June 4, 2001, subject: "Disposition of Unclassified DoD Computer Hard Drives."
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 sensitive 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD 5200.1-R, (Personnel Security Program), January 1997
· ASD(C3I) Memorandum"Disposition of Unclassified DoD Computer Hard Drives", 04 June 2004</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Clearing and Sanitizing">PECS-2</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Clearing and Sanitizing</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD 5200.1-R, (Personnel Security Program), January 1997</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Destruction">PEDD-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Destruction</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>All documents, machine-readable media, and equipment are destroyed using procedures that comply with DoD policy (e.g., DoD 5200.1-R).</DESCRIPTION>
<THREAT>All documents, machine-readable media and equipment not properly destroyed are at risk to unauthorized copying and illegal distribution.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD 5200.1-R, (Personnel Security Program), January 1997</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Data Interception">PEDI-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Data Interception</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>Devices that display or output classified or sensitive information in human-readable form are positioned to deter unauthorized individuals from reading the information.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD 5200.1-R, (Personnel Security Program), January 1997</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Emergency Lighting">PEEL-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Emergency Lighting</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>An automatic emergency lighting system is installed that covers emergency exits and evacuation routes.</DESCRIPTION>
<THREAT>Personnel are at risk of injury and equipment at risk of damage in emergency situations if adequate lighting is not automatic and provided that covers all emergency exits and evacuation routes.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Emergency Lighting">PEEL-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Emergency Lighting</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Fire Detection">PEFD-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Fire Detection</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>Battery-operated or electric stand-alone smoke detectors are installed in the facility.</DESCRIPTION>
<THREAT>Personnel are at risk of injury and equipment at risk of damage in emergency situations if battery-operated or electric stand-alone smoke detectors are not installed and in working order.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. Battery-operated or electric stand-alone smoke detectors shall be installed in the facility.
2. All battery-operated smoke detectors shall have their batteries checked and changed if necessary every time there is a universal time change, such as moving to Day-Light Savings Time.
3. Electric stand-alone smoke detectors shall have adequate emergency power in the case of the facility losing power.
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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Fire Detection">PEFD-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Fire Detection</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>A servicing fire department receives an automatic notification of any activation of the smoke detection or fire suppression system.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Fire Inspection">PEFI-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Fire Inspection</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Computing facilities undergo a periodic fire marshal inspection. Deficiencies are promptly resolved.</DESCRIPTION>
<THREAT>Personnel, equipment, media, and documentation are at risk to fire if facilities are not inspected by a fire marshal on a periodic basis.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Fire Suppression">PEFS-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Fire Suppression</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Handheld fire extinguishers or fixed fire hoses are available should an alarm be sounded or a fire be detected.</DESCRIPTION>
<THREAT>Personnel, equipment, media, and documentation are at risk to fire if handheld fire extinguishers or fixed fire hoses are not available.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. Handheld fire extinguishers or fixed fire hoses shall be available should an alarm be sounded or a fire be detected.
2. Handheld fire extinguishers or fixed fire hoses 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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Fire Suppression">PEFS-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Fire Suppression</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>A fully automatic fire suppression system is installed that automatically activates when it detects heat, smoke, or particles.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Humidity Controls">PEHC-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Humidity Controls</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Humidity controls are installed that provide an alarm of fluctuations potentially harmful to personnel or equipment operation; adjustments to humidifier/de-humidifier systems may be made manually.</DESCRIPTION>
<THREAT>Refer to PEHC-2.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. Refer to PEHC-2.
2. Install a humidity control mechanism that contains an alarm feature that activates when humidity levels reach those that are harmful to proper operation of equipment or personnel.
3. Ensure that humidifier/de-humidifier systems are capable of manual operation to enable immediate adjustment of humidity levels required for personnel safety and equipment maintenance.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Humidity Controls">PEHC-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Humidity Controls</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Automatic humidity controls are installed to prevent humidity fluctuations potentially harmful to personnel or equipment operation.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Master Power Switch">PEMS-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Master Power Switch</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>IT assets are at risk to electrical damage if a master power switch is not available or operational at a critical moment.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Physical Protection of Facilities">PEPF-1</CONTROL_NUMBER>
<MACCONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Physical Protection of Facilities</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>Every physical access point to facilities housing workstations that process or display sensitive information or unclassified information that has not been cleared for release is controlled during working hours and guarded or locked during non-work hours.</DESCRIPTION>
<THREAT>All documents, equipment, and machine-readable media containing sensitive data are at risk from unauthorized personnel, access, copying and illegal distribution, if every physical access point is not guarded and locked during non-working hours.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. Every physical access point to facilities housing workstations that process or display sensitive information or unclassified information that has not been cleared for release shall be controlled during working hours and guarded or locked during non-work hours.
2. Authorization to physical access points to facilities shall follow the same guidelines as authorization to the sensitive information or unclassified information that has not been cleared for release on the workstations within those facilities.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Physical Protection of Facilities">PEPF-2</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Physical Protection of Facilities</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Physical Security Testing">PEPS-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Physical Security Testing</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>A facility penetration testing process is in place that includes periodic, unannounced attempts to penetrate key computing facilities.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Screen Lock">PESL-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Screen Lock</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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).</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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).</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Workplace Security Procedures">PESP-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Workplace Security Procedures</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>Information not handled and stored properly is at risk of unauthorized access, copying, and distribution.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Storage">PESS-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Storage</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>Documents and equipment are stored in approved containers or facilities with maintenance and accountability procedures that comply with DoD 5200.1-R.</DESCRIPTION>
<THREAT>Documents and equipment not stored in approved containers are at risk to damage, unauthorized access, copying, and distribution.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD 5200.1-R, (Information Security Program), January 1997</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Temperature Controls">PETC-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Temperature Controls</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>Temperature controls are installed that provide an alarm when temperature fluctuations potentially harmful to personnel or equipment operation are detected; adjustments to heating or cooling systems may be made manually.</DESCRIPTION>
<THREAT>Refer to PETC-2.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>1. Ensure that temperature controls (i.e., thermostats) are equipped with an alarm that alerts system or facilities administrators when temperature fluctuations potentially harmful to personnel or equipment operation are detected.
2. Adjustments to heating or cooling systems may be made manually, but shall be documented in accordance with building, fire, and facility codes and system and organizational standard operating procedures.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Temperature Controls">PETC-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Temperature Controls</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>Automatic temperature controls are installed to prevent temperature fluctuations potentially harmful to personnel or equipment operation.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Environmental Control Training">PETN-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Environmental Control Training</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>Low</IMPACT_CODE>
<DESCRIPTION>Employees receive initial and periodic training in the operation of environmental controls.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Visitor Control to Computing Facilities">PEVC-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Visitor Control to Computing Facilities</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>Current signed procedures exist for controlling visitor access and maintaining a detailed log of all visitors to the computing facility.</DESCRIPTION>
<THREAT>Facility is at risk of unauthorized access if controlled visitor access is not maintained.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Voltage Regulators">PEVR-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Voltage Regulators</CONTROL_NAME>
<SUBJECT_AREA>Physical and Environmental</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>Automatic voltage control is implemented for key IT assets.</DESCRIPTION>
<THREAT>Workstations, servers, equipment, and media is at risk to damage if voltage is not automatically controlled for key IT assets.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>N/A</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Access to Information">PRAS-1</CONTROL_NUMBER>
<MACCONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Access to Information</CONTROL_NAME>
<SUBJECT_AREA>Personnel</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>Individuals requiring access to sensitive information are processed for access authorization in accordance with DoD personnel security policies.</DESCRIPTION>
<THREAT>Sensitive 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 sensitive information by unauthorized persons, a proper personnel screening and authorization process must be implemented in accordance with DoD Personnel Security policy.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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 sensitive (i.e., non-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 sensitive information, is cleared accordingly, and has been authorized access to the information on a need-to-know basis.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>DoD 5200.1R (Personnel Security Program), Appendix 3 (Controlled Unclassified Information), January 1997</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Access to Information">PRAS-2</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Access to Information</CONTROL_NAME>
<SUBJECT_AREA>Personnel</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>Individuals requiring access to classified information are processed for access authorization in accordance with DoD personnel security policies.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD 5200.2-R (Personnel Security Program), January 1987</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Maintenance Personnel">PRMP-1</CONTROL_NUMBER>
<MACCONF>
<CONF>SENSITIVE</CONF>
<CONF>PUBLIC</CONF>
</MACCONF>
<CONTROL_NAME>Maintenance Personnel</CONTROL_NAME>
<SUBJECT_AREA>Personnel</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>Maintenance is performed only by authorized personnel. The processes for determining authorization and the list of authorized maintenance personnel is documented.</DESCRIPTION>
<THREAT>Refer to PRAS-1.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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. Review the system security documentation to ensure that personnel security is adequately addressed. Only authorized personnel shall perform maintenance on building utilities.
2. Only authorized personnel shall perform maintenance on sensitive agency equipment.
3. Only authorized personnel shall perform maintenance on facility access points.
4. The processes for determining authorization and the lst of authorized maintenance personnel shall be documented.
5. A list of all authorized maintenance personnel shall be documented.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD 5200.1R (Personnel Security Program), January 1997, Appendix 3 (Controlled Unclassified Information)</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Maintenance Personnel">PRMP-2</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
</MACCONF>
<CONTROL_NAME>Maintenance Personnel</CONTROL_NAME>
<SUBJECT_AREA>Personnel</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>Refer to PECF-2, PEDI-1, PEPF-2, and PRAS-2.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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 performed
5. 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-2
2. PEDI-1
3. PEPF-2
4. PRAS-2</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD 5200.2-R (Personnel Security Program), January 1987</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Access to Need-to-Know Information">PRNK-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
<CONF>PUBLIC</CONF>
</MACCONF>
<CONTROL_NAME>Access to Need-to-Know Information</CONTROL_NAME>
<SUBJECT_AREA>Personnel</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>Refer to PRAS-1 and PRAS-2.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>Refer to implementation guidance for PRAS-1 and PRAS-2 for details.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· DoD 5200.2-R, (Personnel Security Program), January 1987</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Security Rules of Behavior or Acceptable Use Policy">PRRB-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Security Rules of Behavior or Acceptable Use Policy</CONTROL_NAME>
<SUBJECT_AREA>Personnel</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Information Assurance Training">PRTN-1</CONTROL_NUMBER>
<MACCONF>
<CONF>CLASSIFIED</CONF>
<CONF>SENSITIVE</CONF>
</MACCONF>
<CONTROL_NAME>Information Assurance Training</CONTROL_NAME>
<SUBJECT_AREA>Personnel</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· CJCSI - Information Assurance (IA) and Computer Network Defense (CND)</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Incident Response Planning">VIIR-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Incident Response Planning</CONTROL_NAME>
<SUBJECT_AREA>Vulnerability and Incident Management</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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 annually.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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 annually.
14. Command critiques exercises, develops Lessons Learned, identifies and implements corrective actions derived from exercises.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Incident Response Planning">VIIR-2</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
</MACCONF>
<CONTROL_NAME>Incident Response Planning</CONTROL_NAME>
<SUBJECT_AREA>Vulnerability and Incident Management</SUBJECT_AREA>
<IMPACT_CODE>High</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
<IACONTROL>
<CONTROL_NUMBER title="Vulnerability Management">VIVM-1</CONTROL_NUMBER>
<MACCONF>
<MAC>MACI</MAC>
<MAC>MACII</MAC>
<MAC>MACIII</MAC>
</MACCONF>
<CONTROL_NAME>Vulnerability Management</CONTROL_NAME>
<SUBJECT_AREA>Vulnerability and Incident Management</SUBJECT_AREA>
<IMPACT_CODE>Medium</IMPACT_CODE>
<DESCRIPTION>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.</DESCRIPTION>
<THREAT>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.</THREAT>
<GENERAL_IMPLEMENTATION_GUIDANCE>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.</GENERAL_IMPLEMENTATION_GUIDANCE>
<SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>· 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</SYSTEM_SPECIFIC_GUIDANCE_RESOURCES>
</IACONTROL>
</IMPORT_FILE>