The Interface Certification Process (ICP)

A less formal and less intense process of introducing a new application onto the GIG is the Interface Certification Process (ICP). This process builds off an existing system, a Program of Record (POR) already in service that holds an ATO. The new system or application submits to the POR a request asking them to amend their system with the new application or system. The General overview of the ICP starts with software development and Interface Change Request (ICR), and if approved, goes to Engineering Change Plan (ECP) for implementation, as depicted in Figure 30.

Figure 30. Notional ICR Progression Events Waterfall Chart

All POR have their own ICP process, though all follow common DoD guidelines to ensure new software is assessed, certified, and interoperable with the existing software packages (Figure 31). The controlling DAA of the sponsor POR designates a

Configuration Manager (CM) who is charged with the processing and evaluation of all ICR for its POR area of responsibility. The designation of a POR CM reduces the time delay from solution development to integration, and it enables Type Commanders (TYCOMS) with a direct means to control their networks to meet mission needs. The CM objectives are to test and evaluate all ICR and provide reports of the same:

 Interoperability

o Ports and Protocol management

o Network utilization / Bandwidth control

 Installation

o System Configuration o Uninstall procedures

o Funding

 Security

Vulnerabilities

Figure 31. DoD Afloat Change Request Flowchart Example

a. U.S. Navy Afloat ICP Example

A case example of the ICP process is the U.S. Navy (USN) Afloat

network POR. For the USN Afloat POR, Commander Navy Network Warfare Command (CNNWC) is assigned as the DAA, and has designated Space and Naval Warfare

Systems Center Pacific (SPAWAR) as the CM to evaluate all ICR for the afloat

networks. All directives, submission and tracking processes for the USN Afloat networks are maintained at SPAWAR’s Web site https://navalnetworks.spawar.navy.mil/. This site is the official source for afloat networks, specifically listing what can and cannot be on afloat networks. The site also provides an interface for submitting change request to the approved list of items. SPAWAR maintains three lists of approved, installable items that have been assessed not to interfere with the existing afloat architecture. Only items found on these lists may be installed on an afloat network:

o Preferred Product List (PPL): What software is deemed safe and approved for installation.

o System/Subsystem Interface List (SSIL): What systems are approved for integration into an afloat network.

o Certified Parts List (CPL): What network components (routers, switches, printer, etc.) are approved for integration into an afloat network.

b. U.S. Navy Afloat ICR Submission Process

The initiation of a change to a network (such as adding OPENER-EXI as approved software) begins with a Network Change Request (NCR) from the developer or fleet user to the CM. The NCR requester does not submit an actual ICR, only a POR can submit an ICR. This affords the POR control over their programs by allowing them veto authority before an ICR reaches the DAA.

A NCR is initiated on the SPAWAR site requesting an update to the one or more of the list of approved items and directed to the sponsor POR. The NCR defines the item in terms of its applicability and need along with initial Test and Evaluation (T&E) reports. The exact submission of the NCR is relative to the type of change. If the NCR is simply asking that an updated version of an approved application with an

established process be authorized for use, the NCR will be very simple. If the NCR is asking for permission to add something without a history, such as OPENER-EXI, the submission will require much more details.

c. U.S. Navy Afloat ICR Endorsement

The sponsoring POR receives the NCR and evaluates the validity and accuracy of the request. After review and approval of the NCR the POR creates an ICR in the name of the NCR submitter. POR are the only ones that can submit an ICR because they own the system. Within the ICR, the change requests must define the system and the application, list previous approved updates, and a proposal for ECP funding plan as applicable.

Beyond the technical aspects of a new item, the change must be

supportable over the expected life of the item; technical support factors such as training have to be planned and accounted. The POR has the onerous obligations, based on initial NCR, of mapping the life of the new item: training, funding, installation and life cycle support. This is documented in the ICR and forwarded to the CM for review, T&E, and ultimate ATO on the DoD network under the supervision of the POR if approved.

d. U.S. Navy Afloat CM Assumes the ICR for Test and Evaluation (T&E)

The CM receives the full ICR form the POR and validates the request. If the CM finds the ICR to be of value, the CM then forwards the request to the T&E phase.

The purpose of the T&E is to verify and validate the risk that the new item poses to the existing architecture of both the POR and DoD in general. The exact tests conducted vary depending on the scope of the change item. OPENER-EXI for example, will likely undergo network vulnerability scanning and interoperability testing with the existing USN afloat architecture components. Since OPENER-EXI is scoped for the Web server environment, tests will be conducted to ensure the existing server software is not

impacted by OPENER-EXI. For example, if an application must use GZip as its

transmission compression, test will be run to verify that OPENER-EXI does not override GZip, and that those application that are EXI compliant can use the implemented

OPENER-EXI version.

Successful exiting the CM T&E occurs after extensive testing shows the ICR item poses no degradation to existing architecture, and moreover, that the requested change adds value that did not previously exist.

e. U.S. Navy Afloat ECP and Installation

With successful validation of the ICR by the CM, an ECP is generated that list the funding, installation plan, and training for all commands that will receive the ECP. For OPENER-EXI, there is likely no funding required, only authorization to add.

Additionally, the corresponding list, PPL, SSIL or CPL, will be updated to reflect the

approval enabling the installation on any of the POR’s networks. OPENER-EXI would be reflected on the PPL list given it is an application.

Ultimately, the ECP is the official funding and approval to add an item (OPENER-EXI) to the DoD network.

F. CHAPTER CONCLUSION

OPENER-EXI must be licensed as a non-viral Open source Software to ensure successful adoption. The best EXI deployment platform is the http server/browser environment. A good pairing of both open source and Web is the Apache Software Foundation as sponsor of initial implementation and deployment efforts.

DoD should only leverage standardized tools and solutions, including EXI, that are also widely used throughout the Information Technology world. Without adhering to these points, the DoD risks ending up with a modern stovepipe that is unable to

interoperate with existing and future systems.

An EXI application will benefit from integration into an existing POR

sponsorship. Without a POR sponsor, EXI is subject to pursuing the DIACAP alone, a process that is likely to prove too costly and time consuming to pursue for a standalone application.

G. CHAPTER SUMMARY

This chapter discusses the administrative considerations of an EXI solution in terms of licensing, deployment considerations, and DoD specific constraints. The NPS EXI implementation, OPENER-EXI, is used as the example case study.

THIS PAGE INTENTIONALLY LEFT BLANK