PLATFORM IT GUIDANCE.docx

1、PLATFORM IT GUIDANCEPLATFORM IT GUIDANCE1. Introduction1.1 Purpose and ScopeAcquisition guidance detailed in references (a) through (c) states that Major Defense Acquisition Programs (MDAP) and Major Automated Information System Programs (MAISP) that include information technology (IT) always have i

2、nformation assurance (IA) requirements, but these IA requirements may be satisfied through the normal system design and test regimen, and these programs may not be required to comply with the DoD Information Assurance Policy (reference (d). Reference (d) defines Platform IT (PIT) and states that pro

3、grams that develop PIT must include IA requirements, but do not have to comply with reference (e). However, references (a) through (e) do not clearly articulate guidance for certification and accreditation of PIT or guidance to integrate IA into the normal system design and test regimen for MDAPs an

4、d MAISPs that have been designated PIT.This document provides guidance to Program Managers (PM), Acquisition Professionals, Information Assurance Managers (IAM), and associated IA professionals to better integrate IA into the acquisition process for MDAPs and MAISPs that will be or have been designa

5、ted PIT, and ensures that IA is incorporated into the functional design of all systems. For clarity in guidance and to account for differences between SYSCOMs, PEOs, and Programs, the terms “PM” and “IAM” will refer to the program management team and IA professional staff supporting a particular pro

6、gram. This guidebook includes information on the designation process, implementation of IA requirements, and authorization to operate for Platform IT systems.1.2 ApplicabilityThe guidelines contained herein are applicable to Department of the Navy (DON) MDAPs and MAISPs (including ACAT IV and abbrev

7、iated acquisition programs) that have been designated PIT. This document is written in accordance with references (a) through (q); definitions, concepts and interpretation are derived from these sources. This document provides guidance to support standardization of IA across the DON and should be ta

8、ilored as necessary to support the program under development. If a system is an MAISP or MDAP and designated PIT, but is not required to adhere to the mandates of the DoD Acquisition Process, then that program should comply with reference (e).1.3 CancellationThis document supersedes reference (q).1.

9、4 References(a) DoD Directive 5000.1, The Defense Acquisition System, May 2003(b) DoD Instruction 5000.2, Operation of the Defense Acquisition System, Dec 2008(c) Defense Acquisition Guidebook, Chapter 7, Dec 2004(d) DoD Directive 8500.01E, Information Assurance Policy, Oct 2002(e) DoD Instruction 8

10、510.01 Information Assurance Certification and Accreditation Process (DIACAP), Nov 2007(f) DoD Instruction 8500.2, Information Assurance Implementation, Feb 2003(g) DoD Instruction 8580.1, Information Assurance (IA) in the Defense Acquisition System, Jul 2004(h) DoD Manual 8570.01-M, Information Ass

11、urance Workforce Improvement Program, Dec 2005 (Change 1 incorporated May 2008).(i) SECNAVINST 5239.3A, Department of the Navy Information Assurance (IA) Policy, Dec 2004(j) SECNAV M-5239.1 Department of the Navy Information Assurance Program, Information Assurance Manual, Nov 2005(k) DON CIO Platfo

12、rm IT Policy Memorandum (l) Navy CA Navy Certification Agent Qualification Standards and Registration Guidebook, Version 1.1 (Revision A), Feb 2008(m) CJCSI 3170.01F Joint Capabilities Integration and Development System, May 2007(n) Risk Management Guide for DoD Acquisition, Sixth Edition, Version 1

13、.0, Aug 2006(o) Naval SYSCOM Risk Management Policy, Jul 2008(p) DoDI 4630.8, Procedures for Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS), Jun 2004(q) Navy CA Platform IT Clarification Guidance, May 20071.5 Acronyms and DefinitionsRefer to Ap

14、pendix G.2. Platform IT DesignationThis chapter provides guidance to the PM and IAM intended to define terms and describes the process for obtaining a statement of exemption from the C&A process for IT systems and IT components designated as Platform IT (PIT). Per DoDD 8500.1, the C&A process (e.g.,

15、 DIACAP) is applicable to all DON-owned or controlled information systems that receive, process, store, display or transmit DoD information, regardless of MAC, classification or sensitivity, except - per DoDD 8500.1 Paragraph 2.3 - IT that is considered Platform IT.2.1 Stand-Alone SystemsPer DoDD 85

16、00.1, systems having no external connections (stand-alone systems) are subject to the C&A process unless they have been designated as PIT. For stand-alone systems that have been designated as PIT, the processes outlined in this guidebook should be followed.2.2 Actions Required of Program ManagersTo

17、obtain a designation of an IT system or IT component as Platform IT, the PM should follow the procedures in this guidebook. The system will be evaluated against the definition of Platform IT and the final designation statement will be issued by the Operational Designated Accrediting Authority (ODAA)

18、 or Marine Corps Enterprise Network Designated Accrediting Authority (MCEN DAA).2.3 Process StepsThe PIT Designation Process is shown in Figure 1. To initiate the PIT Designation process, PMs need to submit the following information: Identify the special purpose system, including its Name, Acronym a

19、nd Version Number Complete the Platform IT Determination Checklist provided in Appendix A Describe the special purpose system and its mission. In addition to a brief, textual description, include a high-level block diagram of the system that also depicts the PIT boundary. The diagram should allow th

20、e Certification Authority (CA) and DAA to clearly understand and identify the systems hardware, software and other components, as well as any interconnection with other systems, networks or IT. For systems with multiple variants, if the diagram accurately describes the variants then a single diagram

21、 may be submitted to cover multiple variants. The diagram should clearly identify the system and any variants it describes. The PMs justification and rationale should include supporting statements that describe how the system meets the criteria for PIT. Request evaluation to determine if the IT syst

22、em or IT component is Platform IT.The completed PIT Determination package is submitted to the cognizant Echelon II (EII) or Major Subordinate Command (MSC). EII/MSC will review the package to determine if the package is complete and if the system/component meets the PIT determination criteria. At th

23、is point, the EII/MSC will either:(1) Return the request to the PM to address any identified package deficiencies-or-(2) Endorse and forward the request to the CAIf the package is forwarded to the CA, they will either:(1) Return the request to EII/MSC to address any identified issues-or-(2) Endorse

24、the request and forward it to the ODAA/MCEN DAA for final determination and designation of Platform ITThe ODAA/MCEN DAA will review the package and the CAs assessment, and issue a statement to the PM classifying the IT system or IT component as Platform IT, or the ODAA/MCEN DAA will explain why the

25、system does not meet the criteria for Platform IT.Figure 1 PIT Designation Process3. Objectives and Implementation of IA into Platform IT Design3.1 IA ObjectivesThe objective of this chapter is: to help the PM understand why he needs to consider information assurance principles during the developmen

26、t of his program strategy to help the PM and IAM/IAO understand where he needs to go to find information and guidance for developing an Information Assurance Strategy to help the PM and IAM/IAO understand the resources (in terms of funding and personnel) that are required to effectively implement in

27、formation assurance.PMs and Program Lead Systems Engineers who are unfamiliar with the details of the DoD IA regulations and policies may find it easier to consider the following five principles when trying to balance specific IA requirements with the other requirements that apply to their system: C

28、onfidentiality - Only authorized persons gain access to the information received, processed, stored or published by the system. Integrity of the information received, processed, stored or published meaning it has not been altered either by defect or malicious tampering. Availability of the informati

29、on received, processed, stored or published to those who need it when they need it. Non-repudiation by those who gain access to the information received, processed, stored or published by the system so that they can not deny having interacted with the system or its information. Authentication of tho

30、se who gain access to the information received, processed, stored or published by the system. Authentication takes confidence to the next level and imposes more specific and rigorous requirements for access.Moreover, it is critical to understand that IA extends beyond the bounds of information secur

31、ity, to also include: Sound Engineering include design features that promote stability and security Training and Awareness should provide Fleet with proper training to ensure they are vigilant Response, Recovery, and Restoration - actively respond to internal and external malicious attacks, as well

32、as recover from system failures caused by inadvertent operator error, internal and external malicious attack, and major calamities3.2 IA ImplementationThe first part of the IA Implementation Process is shown in Figure 2. Once a PIT determination has been issued for a particular system in writing by the ODAA/MCEN DAA, the PM is responsible for ensuring due diligence in meeting information assurance requirements throughout the lifecycle of the program. The process is intended to be tailored to the individual program, in keepin