Attachment_3_-_SSP_OD_68392-Revision_A.pdf

SSP OD 68392

Revision A

APPENDIX C: VALIDATION REPORT FOR MAC III SENSITIVE SYSTEMS

Validation Procedure

Procedure Name Procedure Objective Procedure Preparation Procedure Script Expected Results Actual Results

COAS-1-1 Alternate Site Identification – Partial Mission Restoration

Verify that an alternate site has been identified that has the capability to partially restore mission or business essential functions.

1. Obtain system description documentation that identifies and prioritizes system functions by data type, criticality, or other operational criteria.

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

3. Obtain a copy of the service agreement is signed with the alternate site.

1. Review the primary site’s system description documentation to identify mission or business-essential services and functions.

2. Compare the primary site’s system description documentation with the service agreement for the alternate site.

3. Verify that the service agreement with the alternate site contains a detailed description of the restoration services to be provided to the primary site in the event of an incident or outage and that all mission or business-essential functions requiring restoration are clearly identified.

4. Report the results.

An alternate site has been identified that has the capability to partially restore mission or business essential functions.

COAS-1-2 Continuity of Operations Plan (COOP) for Partial Restoration

Ensure that a program has been established that ensures comprehensive and effective continuity of mission or business-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.).

Obtain a copy of the system COOP 1. Review the COOP to ensure that it provides detailed plans for system maintenance of mission or business-essential operations under, at a minimum, the following incident-related conditions:

· Power Failure

· Natural Disaster (e.g., flooding, storms, tornadoes, etc.)

· Fire

· Outages due to facilities maintenance or relocation

· Outages due to cyber-security incidents such as network intrusion, worms, viruses, etc.

2. Report the results

A comprehensive and effective COOP is in place to ensure implementation of continuity of mission or business-essential functions over a broad spectrum of emergency situations.

COAS-1-3 Alternate Site Operations – Mission or Business-Essential Capabilities

Ensure that the COOP program includes a strategy to recover and perform mission or business-essential system operations at the alternate facility for an extended period of time.

1. Obtain a copy of the system COOP

2. Obtain a copy of the service agreement between the primary and alternate site

1. Review the system COOP to identify mission and business-essential functions.

2. Review the service agreement between the primary and alternate sites.

3. Verify that the service agreement between the primary and alternate sites specifies a recovery plan.

4. Verify that the service agreement specifies resources and the length of time the alternate site can support those operations of the primary site identified as mission or business-essential in the event of an incident.

5. Record the results.

The COOP program includes a strategy for recovery and mission or business-essential operations system operations at the alternate site for an extended period of time.

VALIDATION REPORT FOR MAC III SENSITIVE SYSTEMS

The Validation Report for MAC III Sensitive Systems has been modified to assist FBM Partners with implementation at their sites. IACs that are not required based on the overall SWSNET operating environment have been annotated not applicable (N/A) with a justification.

C-1 17 MAY 2012

Validation Procedure

Procedure Name Procedure Objective Procedure Preparation Procedure Script Expected Results Actual Results

VALIDATION REPORT FOR MAC III SENSITIVE SYSTEMS

COAS-1-4 Priority of Operations – Mission or Business-essential Functions

Verify that restoration of mission or business essential functions at an alternate site are 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.

1. Obtain a copy of the system COOP

2. Obtain a copy of the most recent business impact analysis, or similar document that describes the impact of an incident on system resources and customers

1. Verify that system continuity and mission impact documentation clearly prioritize mission or business functions.

2. Verify that the system continuity and mission impact documentation list the maximum allowable outage times for system resources.

3. Record the results.

Restoration of mission or business-essential system functions have been based on business impact analyses that describe and rank mission-critical applications and resources. System documentation lists maximum allowable outage times for these resources.

COAS-1-5 Contingency Plan Verify that a contingency plan exists that identifies mission-essential computing needs to include hardware, software, communication lines, applications, and data. Verify that the plan includes the operators, management, and technical support personnel that will implement the plan.

1. Obtain a copy of the system contingency plan

2. Obtain a current listing of key personnel associated with the system administration and operations

1. Review the system contingency plan.

2. Ensure that the plan clearly identifies resources needed to support mission-essential computing needs in the form of hardware, software, facilities, network infrastructure, and personnel.

3. Verify that the contingency plan is current in terms of key personnel listed in support of system operations.

4. Record the results.

A contingency plan exists that identifies mission-essential computing needs to include hardware, software, communication lines, applications, and data. Verify that the plan includes the operators, management, and technical support personnel that will implement the plan.

COBR-1-1 Protection of Backup and Restoration Assets

Ensure that procedures are in place to assure the appropriate physical and technical protection of the backup and restoration hardware, firmware, and software.

1. Obtain copies of policies, procedures and other documentation relating to the physical and technical protection of restoration assets.

2. Identify the hardware, software, or firmware used for back up of data or other system assets.

3. Schedule an inspection with the IAM/IAO or system administrator.

1. Review the documentation to ensure that appropriate physical and technical measures are in place for the protection of backup and restoration hardware, firmware, and software.

2. Inspect the system facilities to confirm the following:

a. A detailed inventory exists of all backup and restoration assets as part of the organization or site backup plan.

b. Physical security controls, such as building/room access controls (e.g., visitor logs, manned visitor control points, etc.) are in place and functioning.

c. Technical security controls, such as a cryptographic key management system, and least privilege access controls are in place to protect archived data assets (e.g., lockable storage lockers for backup tapes).

d. Fire-rated containers are in place to maintain media containing backed up data, whether for short-term on-site storage or in preparation for transportation to an approved remote storage facility.

Procedures are in place that assure the appropriate physical and technical protection of the backup and restoration hardware, firmware and software.

COBR-1-2 Physical Security Controls

Ensure that appropriate physical security controls are employed for protection of backup and restoration assets.

Obtain a copy of the portion of the organization’s system security documentation that identifies the type and location of physical assets (e.g., locked metal containers, rooms or spaces with lockable restricted-access doors, etc.) protecting of backup and restoration assets.

1. Ensure that the system security documentation contains descriptions and locations of the physical protection features of the backup and restoration systems (e.g., locked metal containers, rooms or spaces with lockable restricted-access doors, etc.).

2. Conduct a visit of the facilities where the physical protection assets are located to verify that they are in fact protecting backup and restoration assets (hardware and software).

3. Record the results.

Appropriate physical security controls have been identified, located, and implemented for the protection of backup and restoration assets.

C-2 17 MAY 2012

Validation Procedure

Procedure Name Procedure Objective Procedure Preparation Procedure Script Expected Results Actual Results

VALIDATION REPORT FOR MAC III SENSITIVE SYSTEMS

COBR-1-3 Technical Security Controls

Ensure that appropriate technical security controls are employed for protection of backup and restoration assets.

Obtain a copy of the portion of the organization’s system security documentation that identifies the technical security controls (e.g., cryptographic key management, role-based access controls, etc.)

used to protect backup and restoration assets.

1. Identify the system’s backup and restoration assets.

2. Verify that technical controls are in place to protect these assets through such tests as the following:

- Attempting to access the backup/restoration application(s) without use of a cryptographic key or certificate

- Attempt to access the backup/restoration application(s) through a user account lacking the proper roles or privileges for said access.

3. Record the results

Appropriate technical security controls have been identified and implemented for the protection of backup and restoration assets.

CODB-1-1 Data Backup - Weekly

Ensure that data backup is performed at least weekly.

1. Obtain activity logs; audit records, other documentation, or a representative sample (for example a minimum of 3-5 documents) for the past month that show data is backed up weekly.

2. Obtain copies of CCB-approved waivers governing the storage of recovery media.

Review activity logs, audit records, waivers or other documentation to confirm that data backup is performed at least on a weekly basis.

"Data backup is performed at least weekly."

CODP-1-1 Disaster Recovery

– 5 Days

Verify that a disaster plan exists to provide 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 acceptancance).

1. Obtain copies of documents detailing business continuity plans and arrangements (e.g., SOPs, COOP, Emergency Plans, Incident Response Plans, Disaster Recovery Plans, etc.).

2. Obtain copies of CCB-approved waivers or exceptions to policy governing Disaster Planning.

3. Review the continuity plans and other documentation to verify that the partial resumption of mission or business essential functions within 5 days of activation is addressed.

4. Record the results.

1. Review the continuity plans and other documentation to verify that the partial resumption of mission or business essential functions within 5 days of activation is addressed.

2. Record the results.

A disaster plan exists that provides for the partial resumption of mission or business essential functions within 5 days of activation.

COEB-1-1 Enclave Boundary Defense – Equivalent Security Configuration

Ensure that the enclave boundary defense at the alternate site provides security measures equivalent to the primary site.

1. Obtain a list of alternate sites.

2. Obtain copies of the security architecture of the primary and alternate sites and applicable waivers.

1. Compare security architecture of the alternate sites with those of the primary site.

2. Verify that the security architecture indicates that security measures at the alternate sites are equivalent or waivers are documented.

3. Record the results.

Security architecture indicates that enclave boundary defense security measures at alternate sites are equivalent.

COED-1-1 Scheduled Exercises and Drills

The ensure that the system COOP or Disaster Recovery Plan is exercised annually (for control COED-1) or semi-annually (for COED-2).

1. Obtain copies of the Continuity of Operations Plan or Disaster Recovery Plan and the yearly exercise schedule.

2. Obtain documentation addressing previous COOP/DRP tests and drills, as well as associated after-action reports.

1. Review plans, exercise schedules and exercise After Action Reports.

2. Verify periodicity of COOP/DRP exercises/drills:

a. For control COED-2 verify that exercise schedules and after-action reports show that exercises/drills are being conducted on at least a semi-annual basis.

b. For control COED-1, verify that exercise schedules and after-action reports show that exercises/drills are being conducted on an annual basis.

3. Ensure that results of the tests are maintained and that any discrepancies are duly noted and POA&M established to address these discrepancies.

4. Record the results and note any discrepancies.

· For systems operating under COED-2, plans are exercised at least semi-annually.

· For systems operating under COED-1, plans are exercised annually.

C-3 17 MAY 2012

Validation Procedure

Procedure Name Procedure Objective Procedure Preparation Procedure Script Expected Results Actual Results

VALIDATION REPORT FOR MAC III SENSITIVE SYSTEMS

COEF-1-1 Restoration of Essential Functions

All IT assets supporting mission and business essential functions (e.g., computer-based services, data and applications, communications, physical infrastructure) have been identified for priority restoration planning.

1. Obtain copies of documents detailing business continuity plans and arrangements (e.g. SOPs, COOP, emergency plans, incident response plans, disaster recovery plans, etc.) and waivers.

2. Identify the IT assets that support mission and business essential functions.

1. Review the COOP plan, disaster recovery plan, and other appropriate documentation and verify that mission and business essential functions and their supporting IT assets have been identified for priority restoration.

2. Record the results.

IT assets supporting mission and business essential functions have been identified for priority restoration planning.

COMS-1-1 Maintenance Support – Next Day

Ensure that maintenance support for key IT assets is available to respond within 24 hours of failure.

Obtain copies of maintenance support contracts, logs and documentation.

1. Review the maintenance support contracts, logs and documentation to verify that maintenance support for key IT assets is available to respond within 24 hours of a failure.

2. Record the results.

Maintenance support is available to respond within 24 hours of a failure..

COPS-1-1 Power Supply – Manual Activation of Emergency Power

Electrical power is restored to key IT assets by manually activated emergency power generators upon loss of electrical power from the primary source.

1. Obtain listing of key computing facilities that house key IT assets.

2. Obtain emergency power backup plans and documentation for the key computing facilities.

1. Review the emergency power backup plans and documentation and verify that, at minimum, manually activated emergency power generators can supply emergency power to key computing facilities on demand.

2. Record the results.

Manually activated emergency power generators can restore electrical power.

COSP-1-1 Maintenance and Spare Parts – Next-day Availability

Maintenance spares and spare parts for key IT assets can be obtained within 24 hours of failure.

Obtain copies of maintenance support contracts, logs and spare parts inventories and other documentation.

1. Review the documentation to verify that maintenance spares and spare parts for key IT assets are available within 24 hours of failure.

2. Record the results.

Maintenance spares and spare parts for key IT assets can be obtained within 24 hours of failure.

COSW-1-1 Software Backup Ensure that backup copies of the operating system and other critical software are stored in a fire rated container or otherwise not collocated with the operational software.

1. Obtain a copy of the current software inventory.

2. Identify the operating system(s) and other critical software.

Verify that at least one licensed copy of each operating system and each critical software application used by system components is stored in a fire rated container or a physically separate site.

At least one back-up copy of each operating system and each critical software application used by the system is stored in a fire rated container or otherwise not collocated with the operational software.

COTR-1-1 Trusted Recovery Verify that recovery procedures and technical system features exist to ensure that recovery is done in a secure and verifiable manner, and that circumstances than can inhibit a trusted recovery are documented and appropriate mitigating procedures have been put in place.

1. Obtain a copy of the IT COOP and disaster recovery plans.

2. Obtain SOP documentation that addresses recovery procedures and the associated technical system documentation.

3. Obtain documentation that addresses circumstances that could inhibit a trusted recovery and mitigating procedures.

1. Review IT COOP, disaster recovery plans and other appropriate documentation to verify that recovery procedures and technical system features are in place to ensure that recovery is performed in a secure and verifiable manner.

2. Verify that circumstances that could inhibit a trusted recovery are documented and confirm that mitigating procedures are identified.

3. Record the results.

1. Recovery procedures and technical system features to ensure a recovery is done in a secure and verifiable manner are documented.

2. Circumstances that could inhibit a trusted recovery are documented and appropriate mitigating procedures have been put in place.

DCAR-1-1 Comprehensive Annual Review

Ensure that a comprehensive annual IA review is performed to evaluate existing policies and that procedures are consistent to support uninterrupted operations.

1. Obtain policies, SOPs, plans, and other documentation addressing the conduct of scheduled procedural reviews.

2. Obtain After-Action Reports or review results of procedural reviews performed within the last year.

3. Obtain a schedule of procedural reviews to be conducted within the next year.

1. Review policy, SOP, plans, and other documentation to confirm that annual procedural reviews are scheduled.

2. Review After Action Reports or review results and schedules to confirm that annual procedural reviews are conducted.

3. Record the results.

A comprehensive annual evaluation of policies and processes is conducted that ensures that policies consistently and adequately support system operations.

C-4 17 MAY 2012

Validation Procedure

Procedure Name Procedure Objective Procedure Preparation Procedure Script Expected Results Actual Results

VALIDATION REPORT FOR MAC III SENSITIVE SYSTEMS

DCAS-1-1 GOTS Products Evaluation

All IA- and IA-enabled GOTS IT products implemented in the system have been evaluated by the NSA or in accordance with NSA-approved processes.

1. Obtain a system documentation or a system inventory list and identify all IA- and IA-enabled GOTS products implemented in the system.

2. Obtain a list of IA or IA-enabled products evaluated by the NSA or in the NSA-approved processes or visit the NIAP website at http://www.niap-ccevs.org/cc-scheme/vpl/ for an updated product listing.

1. Compare the list of IA and IA-enabled products GOTS incorporated into the system with the list of NSA-approved GOTS products.

2. Verify that all of the products are on the list of the NSA-approved GOTS products list.

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

Most likely this will be N/A. GOTS IA and IA enabled products are very uncommon.

(NOTE: IA enabled products are: routers, switches, firewalls, IDS's, log collection devices and servers.)

DCAS-1-2 COTS Products Evaluation

All IA- and IA-enabled COTS IT products implemented in the system 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.

1. Obtain a system documentation or a system inventory list and identify all IA- and IA-enabled COTS products implemented in the system.

2. Obtain a list of IT products evaluated by the following approved sources:

· International Common Criteria (CC) for Information Security Technology Evaluation Mutual Recognition,Arrangement

· NIAP Evaluation and Validation Program (For Common Criteria) FIPS validation program

1. Compare the list of IA and IA-enabled products COTS incorporated into the system with the list of products evaluated through Common Criteria, NIAP, or FIPS.

2. Verify that all of the products are on the list of approved COTS products validated by one of these three sources.

The system has implemented only those IA- and IA-enabled COTS products that have been evaluated through one of the following processes:

· International Common Criteria (CC) for Information Security Technology Evaluation Mutual Recognition Arrangement

· NIAP Evaluation and Validation Program (For Common Criteria)

· FIPS validation program

(NOTE: IA enabled products are: routers, switches, firewalls, IDS's, log collection devices and servers.)

DCBP-1-1 System Security Design Best Practices

To ensure that the system security design incorporates best security practices such as single sign on, PKE, smart card, and biometrics.

1. Obtain a copy of the system security design documentation.

2. Obtain a copy of the section of the system security documentation that addresses best security practices within the design for secure identification management.

3. Obtain a specific list of best security practices required for the specific MAC levels based on DoD, NSA, and NIST recommendations and guidance, and commercial best practices. (Note:

Current DoD practices and guidance for various systems may be found at the NIAP web page, www.niap.nist.gov, as well as at http://iase.disa.mil for those with DoD PKI inside of the .mil domain.)

1. Review the system security design documentation.

2. Verify that the specified best security practices for identity management are incorporated in the system design.

3. Selecting a sampling of system components in which the security design best practices are incorporated, test the features to see if they are functioning as described by the system security architecture. Examples include attempting to log onto a system node or terminal without the required PKI certificate, CAC/smart card, or token.

· The System Security Design document addresses all required best security practices based on the system's MAC and Confidentiality levels.For each best practice, the document either:

1. Provides the rationale for not incorporating the identified practice or,

2. Explains how the practice was incorporated into the system design. The system security documentation addresses potential identity management products that will be implemented to prevent unauthorized access to the system.

· Feature tests of the randomly selected sample of system components or nodes in which best security practices had been incorporated return positive results for implementation of the best practices.

C-5 17 MAY 2012

Validation Procedure

Procedure Name Procedure Objective Procedure Preparation Procedure Script Expected Results Actual Results

VALIDATION REPORT FOR MAC III SENSITIVE SYSTEMS

DCCB-1-1 Configuration Control Board

To ensure that the DoD system is under the control of a chartered Configuration Control Board that meets regularly IAW DCPR-1.

Obtain a copy of the CM Plan, the CCB charter and the most recent CCB minutes from the previous quarters.

1. Review the CM plan and CCB charter to ensure the DoD information system is under the control of a CCB.

2. Review the previous CCB minutes to ensure that the CCB meets regularly (e.g., quarterly) IAW DCPR-1.

The DoD information system is under the control of a chartered CCB that meets regularly (e.g., quarterly) IAW DCPR-1.

DCCB-1-2 IAM Membership on the CCB (applicable to DCCB-2 only)

To ensure that the IAM is a member of the system’s

CCB.

1. Identify the IAM for the system.

2. Obtain a copy of the CCB charter or other documentation specifying CCB membership.

1. Review the charter of the CCB to ensure that the IAM is identified as a member.

2. Review the previous CCB minutes to verify the IAM attended the meetings.

3. Record the results.

The IAM is identified as a member of the CCB and attends scheduled CCB meetings.

N/A - DCCB-2 is not a MAC III Sensitive control. SWSNet is a MAC III Sensitive Network.

DCCS-1-1 Configuration of newly acquired IA and IA-enabled products is carried out in accordance with non-DoD standards (e.g., SANS, ICSA, Vendors) where DoD standards are not available.

Ensure that newly-acquired IA and IA-enabled products for which configuration and implementation security guidance is not available have been configured according to the following standards, in descending order of preference:

1. Commercially accepted practices (e.g., SANS);

2. Independent testing results (e.g., ICSA); or

3. Vendor literature.

1. Obtain a list of all IA and IA-enabled products deployed within the enclave.

2. Obtain a copy of STIGs and SRGs for individual IA and IA-enabled products implemented.

3. Develop test procedures or identify security tools to verify the security configuration of the products deployed or implemented.

4. Schedule inspection of the products with IAM/IAO and administrator.

1. Consult the IAM or system administrator on procedures and methods for configuring of security features of the IA and IA enabled products. 2. Verify that governing security reference documents are readily available to the administrators.

3. Inspect the IA and IA-enabled products based on the test procedures developed or using the test tools to verify they are configured securely according to the security guidance documents.

4. Record the results.

5. If no governing security reference documents are used and not available for the security configuration, identify guidance documents for configuring the products.

6. Record the results.

All system IA and IA-enabled products for which DoD security governance is not available are configured and implemented securely in accordance with industry best practices (e.g., SANS, vendor security checklists).

DCCT-1-1 Compliance Testing

To ensure that a comprehensive set of procedures are developed and used to test all patches, upgrades, and new AIS applications prior to deployment.

1. Obtain a copy of the CM plan and/or SOPs that describe procedures for testing and implementing patches, updates, and new AIS applications.

2. Obtain sample copies of system change requests and approvals.

1. Review the CM plan/SOPs for the required procedures for testing of patches, changes or upgrades prior to deployment.

2. Review the selected system change requests to verify that changes have been in compliance with the required testing procedures.

3. Record the results.

1. The procedures for testing of patches, upgrades and new AIS applications prior to deployment are documented.

2. The procedures are being followed and testing results are documented in CCB documentation.

DCDS-1-1 Dedicated IA Services

Ensure that acquisition or outsourcing of dedicated IA services (e.g., 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.

1. Obtain a listing of all acquired or outsourced dedicated IA services associated with the system, such as IDS, firewall, and key management.

2. Obtain copies of the final risk analysis reports for the identified IA services, if any.

1. Review the risk analysis reports.

2. Verify that the DoD Component CIO has approved them with signature (digital or otherwise).

3. Record the results.

Formal risk analysis reports were performed for all the IA services of the system and approved by the DoD Component CIO.

Most likely this will be N/A. Most organizations do not oursource dedicated IA services.

DCFA-1-1 Functional Architecture for AIS Applications – External Interfaces

For all external interfaces, the functional architecture identifies all external interfaces, the information being exchanged, and the protection mechanisms associated with each interface.

Obtain the appropriate system documentation that addresses the system architecture and detailed security-related information.

1. Review the system security documents for descriptions of the system external interfaces.

2. Verify that within the functional architecture all external interfaces, the information being exchanged, and the protection mechanisms associated with each interface are identified

3. Record the results.

The system functional architecture describes all external interfaces, the information being exchanged, and the protection mechanisms associated with each interface are identified.

C-6 17 MAY 2012

Validation Procedure

Procedure Name Procedure Objective Procedure Preparation Procedure Script Expected Results Actual Results

VALIDATION REPORT FOR MAC III SENSITIVE SYSTEMS

DCFA-1-2 Functional Architecture for AIS Applications – User Roles

Ensure that the system functional architecture describes all system user roles required for access control and the access privileges assigned to each role.

Obtain the appropriate system documentation that addresses the system architecture and detailed security-related information.

1. Review the system security documents for descriptions of the system user roles.

2. Verify that within the functional architecture describes all user roles required for access control and the access privileges assigned to each role.

3. Record the results.

The system functional architecture describes all user roles required for access control and the access privileges assigned to each role.

DCFA-1-3 Functional Architecture for AIS Applications – Unique security requirements

Ensure that the system functional architecture describes all unique system security requirements (e.g., encryption of data at rest).

Obtain the appropriate system documentation that addresses the system architecture and detailed security-related information.

1. Review the system security documents for descriptions of unique system security requirements.

2. Verify that the functional architecture describes each unique security requirement, including where it has been implemented within the system, its purpose, and technical details of its implementation (e.g., encryption key strength/algorithm for data at rest).

3. Record the results.

The system functional architecture describes all unique security requirements, including where they have been implemented within the system, their purpose, and technical details of their implementation (e.g., encryption key strength/algorithm for data at rest).

DCFA-1-4 Functional Architecture for AIS Applications – Categories of sensitive information and their specific protection plans

Ensure that the system functional architecture describes each category of sensitive information processed or stored by the system application, and its specific protection plan (e.g., Privacy Act, HIPAA).

Obtain the appropriate system documentation that addresses the system architecture and detailed security-related information.

1. Review the system security documents for descriptions of unique system security requirements.

2. Verify that the system security document describes, in detail, each of the categories of sensitive information processed or stored by the system application, and their specific protection plans (e.g., Privacy Act, HIPAA).

3. Record the results.

The system functional architecture describes all categories of sensitive information processed or stored by the system application, and their specific protection plans (e.g., Privacy Act, HIPAA).

DCFA-1-5 Functional Architecture for AIS Applications - Restoration priority of subsystems, processes, or information.

Ensure that the system functional architecture states the restoration priority of all subsystems, processes, or information.

Obtain the appropriate system documentation that addresses the system architecture and detailed security-related information.

1. Review the system security documents for descriptions of unique system security requirements.

2. Verify that the system security document describes, in detail, the restoration priority of each subsystem, process, or information source.

3. Record the results.

The system functional architecture describes, in detail, the restoration priority of each subsystem, process, or information source.

DCHW-1-1 HW Baseline – Inventory Maintenance

Ensure that a current and comprehensive baseline inventory of all hardware (HW) (to include manufacturer, type, model, physical location and network topology or architecture) required to support enclave operations is maintained by the Configuration Control Board (CCB) and as part of the appropriate system security document.

1. Obtain a copy of the current baseline inventory of all system hardware.

2. Obtain a copy of CCB approved changes to the baseline for an appropriate representative interval of time (e.g. the last 30 days, last meeting, or other recent change)

3. Obtain the appropriate system security document(s).

1. Confirm that the baseline inventory of all system hardware contains detailed information, including manufacturer, type, model and physical location for each piece of hardware match the changes to the baseline approved by the CCB.

2. Review the system security documentation to verify that it includes a current baseline inventory of all system hardware in detail.

3. Record the results.

A current and comprehensive baseline inventory of all system hardware exists and contained in the appropriate system security documentation. Changes to the baseline have been, and routinely are approved by the

CCB.

C-7 17 MAY 2012

Validation Procedure

Procedure Name Procedure Objective Procedure Preparation Procedure Script Expected Results Actual Results

VALIDATION REPORT FOR MAC III SENSITIVE SYSTEMS

DCHW-1-2 HW Baseline – Backup Copy of Inventory

Ensure that a backup copy of the current HW baseline inventory is stored in a fire-rated container or otherwise not collocated with the original.

1. Obtain a copy of the current baseline inventory of all system hardware.

2. Verify that a backup copy of the HW inventory is maintained in a fire-rated container, at an off-site location, or otherwise not collocated with the original.

3. Coordinate an inspection with the IAM, system administrator, or other cognizant individual to view the backup HW inventory copy(ies).

1. Proceed to the location(s) where (a) backup copy(ies) of the baseline hardware inventory are maintained.

2. Obtain the backup copy of the current HW configuration baseline.

3. Compare the baseline copy with the current baseline inventory to ensure a match.

4. Record the results.

A backup copy of the current HW baseline inventory is stored in a fire-rated container or otherwise not collocated with the original, is current, and matches the original document.

DCID-1-1 Interconnection Documentation - Enclaves

Ensure that for enclaves, a list of all current or planned 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.

1. Obtain enclave interconnection documentation.

2. Schedule interview with IAM/IAO and network administrator.

1. Review the interconnection documentation to ensure that:

· Planned and current hosted system applications are identified and

· Methods are defined for security planning and coordinating with the enclave as early in the development cycle of the software release as possible based on the connection rules and requirements.

2. Interview IAM/IAO and network administrator and verify the procedures for coordinating with the application/system owners and/or outsources.

3. Record the results.

A list of planned and current-hosting enclaves is maintained along with evidence that they have been contacted for security coordination, and IA requirements have been exchanged.

N/A. There should be no current or planned hosting enclaves from partner DMZ's.

DCID-1-2 Interconnection Documentation – AIS Application

Ensure that for the system applications, a list of all current or planned hosting enclaves are maintained along with evidence of security planning and coordination and the exchange of connection rules and requirements.

1. Obtain application security documentation that addresses security planning and coordination and interconnection rules and requirements.

2. Schedule an interview with the IAM/IAO and system administrator.

1. Review the application security documentation to ensure that:

· Planned and current hosting enclaves are identified.

· Methods for security planning and coordination with the enclave as early in the development cycle of the software release as possible; and

· IA requirements have been identified and exchanged.

2. Interview the IAM/IAO and system administrator and verify the procedures for coordinating with the enclave for connection.

3. Record the results.

A list of planned and current-hosting enclaves is maintained along with evidence that they have been contacted for security coordination, and IA requirements have been exchanged.

N/A. There should be no current or planned hosting enclaves from partner DMZ's.

DCII-1-1 IA Impact Assessment

Ensure that proposed changes to the DoD information system are assessed for IA and accreditation impact prior to implementation.

1. Obtain all documentation relating to changes to the system (e.g. CM documents, requests for change, minutes of the CCB, etc.)

2. Identify the most recent 2-3, or other appropriate representative sample changes made to the system.

1. Review the documentation and ensure that for each change:

· The change is identified;

· The change was reviewed by the CCB and assessed for IA and accreditation impact; and

· The implementation was approved by the CCB.

2. Record the results.

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

C-8 17 MAY 2012

Validation Procedure

Procedure Name Procedure Objective Procedure Preparation Procedure Script Expected Results Actual Results

VALIDATION REPORT FOR MAC III SENSITIVE SYSTEMS

DCIT-1-1 IA for IT Services Ensure that the acquisition or outsourcing of IT services explicitly addresses Government, service provider and end user IA roles and responsibilities.

1. Review relevant functional or system security documentation to identify IT services that have been acquired or outsourced for the DoD information system.

2. Obtain acquisition and/or contract documentation(e.g., service agreements, MOA/MOUs, etc.) on the identified IT services, as well as any system security-related documentation concerning the outsourced IT facilities, if available.

1. Review appropriate acquisition or contract documentation addressing procurement of IT services and verify that government; service provider and end-user IA roles and responsibilities are clearly defined.

2. Record the results.

A list of all IT or IA service contracts is available. The IA roles and responsibilities of the government, service providers and end users are clearly defined in the acquisition or contract documentation.

Most likely this will be N/A. Most organizations do not oursource or acquire IT services.

DCMC-1-1 Mobile Code – Code Registration and Approval Process

Ensure that a mobile code registration and approval process is implemented that prevents the development or acquisition of unacceptable mobile code for deployment within the system or enclave.

1. Obtain copies of the DoD or DoD Component Mobile Code Policy & Procedures.

2. Obtain a copy of the CJCSM 6510.01, Information Assurance (IA) and Computer Network Defense (CND).

3. Obtain a copy of the system's CM Implementation Plan.

4. Obtain a copy of system's CCB baseline.

1. Review the system's CM Implementation Plan, noting compliance with CJCSM 6510.01, DoD or DoD Component Mobile Code Policy & Procedures and CCB approval for the use of mobile code.

2. Review the documentation on the use of mobile code within the DoD information system and verify that procedures are in place to restrict Category 1 and 2 mobile codes in accordance with CJCSM 6510.01.

3. Record the results.

The system has an approved CM process to prevent development, acquisition or deployment of unacceptable mobile code and procedures are in place to restrict mobile code in accordance with CJCSM 6510.01.

DCMC-1-2 Mobile Code – Prevention of Download or Execution of Prohibited Mobile Code

Ensure that system workstations and host software are configured to prevent the download and execution of mobile code that is prohibited.

1. Obtain a list of mobile code that is prohibited by the system (refer to the appropriate system security documentation).

2. Identify the type of host software and workstation operating systems and their associated missions.

3. Select a sampling of workstations to test for mobile code (sampling size should be between five and ten percent of your system workstations).

4. Develop or access existing test procedures to verify operating systems' configuration for mobile code prevention.

5. Schedule inspection with IAM/IAO and system administrator.

Using the test procedures, verify that the tested workstations and host software are configured properly to prevent download and execution of prohibited mobile code.

All of the tested workstations and host software are configured properly to prevent download and execution of prohibited mobile code.

DCNR-1-1 Non-repudiation – Cryptography Standard

Ensure that in order to support non-repudiation, the current NIST FIPS validated cryptography standard is used for encryption, key exchange, digital signature, and hash.

Obtain the relevant system security documentation, along with any other documents that indicate which transactions require implementation of digital signature for non-repudiation, if any.

1. Review the system security documentation, along with any other documentation describing or mandating non-repudiation capabilities (e.g. digital signatures) on the transactions.

2. Verify that the NIST FIPS 140-2 validated cryptography is used to implement encryption, key exchange, digital signature, and hash.

3. Review the results.

The current NIST FIPS cryptography standard (e.g., FIPS 140-2) validated cryptography is used for encryption, key exchange, digital signature, and hash as required.

DCPD-1-1 Public Domain Software Controls

Ensure that public domain software (e.g., freeware, shareware) is not used in the system unless compelling reasons are established, the product is assessed by the DAA for information assurance impact, and the product is approved for use by the DAA.

1. Obtain a copy of the software inventory.

2. Obtain a listing of the public domain software approved by the CCB for use within the DoD component.

3. Obtain copies of DAA-approved waivers authorizing the use of public domain software, if any.

1. Review the system software inventory to identify any public-domain software as part of the system configuration.

2. If public domain software is contained in the system software configuration, verify that it is either contained in the CCB-approved list, or has a DAA-approved waiver.

"Public domain software, if utilized, is listed in the CCB-approved software list."

C-9 17 MAY 2012

Validation Procedure

Procedure Name Procedure Objective Procedure Preparation Procedure Script Expected Results Actual Results

VALIDATION REPORT FOR MAC III SENSITIVE SYSTEMS

DCPP-1-1 Ports, Protocols, and Services

Ensure that the system complies with the DoD ports, protocols, and services guidance to be connected to the enclaves and to be registered by the enclaves.

1. Obtain the relevant system security documentation (e.g., IA Strategy).

2. Obtain MOAs with any interconnecting enclaves, if any.

3. Schedule an interview with the IAM/IAO and system administrator.

1. Review the security documentation and MOAs and verify that they identify ports, protocols and services the system requires and that the procedures for notifying the enclaves of required services are documented.

2. Conduct an interview with the IAM/IAO and system administrators to determine the proper procedure requesting and approving system interconnections between the system and other enclaves.

3. Review current system security architecture documentation to determine which ports, protocols, and services have been authorized as part of service interconnection between the system and the enclave.

4. Record the results.

The network ports, protocols, and services were identified as early in the life cycle, are currently documented in the system security architecture and agreements concluded between the system and interconnecting enclaves for the use of specified ports, protocols, and services.

DCPR-1-1 Configuration Management Process

Ensure that a configuration management (CM) plan has been developed to include detailed CM roles, test processes for the changes requested and processes to verify and validate the effectiveness of the CM process.

Obtain all relevant documentation, including:

· CM Plan

· CCB Charter

· Other relevant CM/CCB Documentation as the system requires

Review the CM plan and verify that it documents:

· CM roles and responsibilities;

· a CCB;

· a process to test the system changes requested;

· a verification process to ensure the effective CM process.

A configuration management (CM) plan has been developed to include detailed CM roles, CCB, test process for the changes requested and verification process that checks the effectiveness of the CM process.

DCSD-1-1 IA Documentation – System Security Documentation

Ensure that system security documentation is developed, describing the technical, administrative, and procedural IA program and policies that govern the system, and identifies its IA personnel and specific IA requirements and objectives.

Obtain a copy of all relevant system security documentation

Review the system security documentation to ensure that it identifies:

1. Technical, administrative, and procedural IA program and policies that govern the DoD information system.

2. Specific IA requirements for:

· data handling and dissemination

· system redundancy and backup, and

· emergency response.

3. Record the results.

The system security documentation identifies the governing IA program and policies for the system. It also identifies IA personnel and specifies IA requirements for data handling or dissemination, system redundancy and backup, and emergency response.

DCSD-1-2 IA Documentation – Appointments

Ensure that all appointments to required IA roles (e.g., DAA and IAM/IAO) are documented in writing, to include assigned duties and appointment requirements criteria such as training, security clearance, and IT-designation.

1. Obtain a copy of all relevant system security documentation, or other documentation that identifies the required IA roles for the DoD information system.

2. Obtain a listing of all personnel currently assigned to IA roles within the system.

1. Review the system security or other documentation to ensure that all appointments to required IA roles are documented in writing.

2. Check to ensure that the documentation identifies assigned duties and appointment requirements criteria such as training, security clearance and IT-designation.

3. Record the results.

All appointments to require IA roles are established in writing and include assigned duties and appointment criteria.

C-10 17 MAY 2012

Validation Procedure

Procedure Name Procedure Objective Procedure Preparation Procedure Script Expected Results Actual Results

VALIDATION REPORT FOR MAC III SENSITIVE SYSTEMS

DCSL-1-1 Source Code Libraries Access

System Library Management Controls

Obtain CM documentation relating to software configuration management.

1. Review all documentation to ensure that there are stated requirements that all changes to privileged programs require CCB approval prior to implementation.

2. Review all documentation to ensure that there are procedures that explicitly disallow introduction of unauthorized code.

3. Verify that access to the source code libraries is restricted to a limited number of authorized personnel, either through an approved configuration management software application or by manual means such as a locked safe, etc.

4. Record the results.

1. Source Code Libraries for the system are maintained and managed under Configuration Management Control.

2. CCB procedures and processes explicitly forbid implementation of changes to system programs without prior authorization.

3. Codes that permit changes to system software are CCB approved prior to implementation.

4. Access to the system containing source code libraries is restricted only to authorized personnel.

DCSL-1-2 Source Code Libraries Access

Ensure that all access to source code libraries is controlled to protect privileged programs and to prevent the introduction of unauthorized code.

Obtain CM documentation relating to software configuration management.

1. Review all documentation to ensure that there are stated requirements that all changes to privileged programs require CCB approval prior to implementation.

2. Review all documentation to ensure that there are procedures that explicitly disallow introduction of unauthorized code.

3. Verify that access to the source code libraries is restricted to a…