Information Assurance for Network-Centric Naval Forces (2010)

As articulated in the 2008 Maritime Strategy,¹ naval forces will provide regionally concentrated, credible combat power as well as globally distributed mission-tailored maritime forces. Some of these missions embody long-standing roles of the Navy, such as power projection and deterrence, while others are a product of globalization and the U.S. role in the world such as humanitarian assistance and disaster response. Some new missions, such as Maritime Domain Awareness (MDA), require the coordination of disparate government organizations, international partners, and industry.²

Supporting these goals is complex owing to the diversity and dynamic nature of the missions. Command, control, communications, computers, intelligence, surveillance, and reconnaissance capabilities are important for these missions, and network-centric capabilities are sought in which all nodes contribute to the information superiority of the force. This concept is part of FORCEnet, which is “the operational construct and architectural framework for naval warfare in

the Information Age, integrating warriors, sensors, command and control, platforms, and weapons into a networks, distributed combat force.”³ The networking capabilities that FORCEnet must be able to support include a large range of new bandwidth-intensive applications in addition to providing strong protection against adversarial action. Unfortunately, the average age of a typical shipboard network is approaching 7 years, with some as old as 12 years, while industry is operating on a 4-year cycle.⁴ The Navy also has several major milestones ahead, such as the introduction of a service-oriented architecture (Consolidated Afloat Networks and Enterprise Services [CANES]), open-architecture computing infrastructure,⁵ the follow-on to the Navy/Marine Corps Intranet, NMCI (Next Generation Enterprise Network [NGEN]), and new satellite communications capabilities, all of which require deliberate development and service acquisition strategies owing to their high cost and criticality to naval operations.

Enterprise architecture (EA) provides the discipline for managing change and complexity within the naval enterprise, especially with constrained budgets. EA is required for a truly agile Navy, because the architectural artifacts will allow decision makers to proceed quickly, knowing the state of their information technology (IT) and how it is evolving. Without a fully accepted and leveraged enterprise architecture, agile actions in one part of the enterprise could be detrimental to another part. Another extremely important use of enterprise architecture is in bridging the gap between mission operations and IT implementation. Just as the blueprints for the structure of a house should capture and reflect how the owner desires to operate in the house, the architecture artifacts should be driven by concepts of operations (CONOPS) for the users, should capture and reflect their required capabilities, and should portray back to the owner (funding source) what needs to be built (IT capabilities) to satisfy the mission. Without the EA “bridge,” money may be spent on redundant or extraneous IT capabilities.

Enterprise architecture is the practice of applying a comprehensive and rigorous method for describing a current and/or future structure and behavior for an organization’s processes, information systems, personnel, and organizational subunits so that they align with the organization’s core goals and strategic direction. Although often associated strictly with information technology, EA relates

more broadly to the practice of mission optimization in that it addresses business mission architecture, performance management, and process architecture as well.

An EA is a structured plan for evolving an enterprise from its current state to a desired end state based on enterprise strategies, required capabilities, guiding principles, and external influences. Taking this definition one term at a time:

• The structure is a logically organized rubric or architecture decomposition that clearly shows where all of the components of the enterprise fit within the EA.

• The plan is a set of blueprints for the enterprise along with a transition roadmap or acquisition schedule. It is also beneficial if along with the detailed blueprints there is a corresponding set of high-level artifacts (floor plans and elevations in the building industry) based on the detailed blueprints that aid leadership in decision making.

• The current state is the “as is” architecture or the baseline configuration from which point one needs to migrate. Without this starting point of the journey, the roadmap cannot be drawn.

• The desired end state is the “to be,” or target, architecture.

• The enterprise strategies are the mission, vision, goals, and objectives of the enterprise, usually established by the enterprise leadership.

• The required capabilities are the shortfalls or gaps of the as-is architecture that are identified and prioritized by the operations part of the enterprise.

• The guiding principles are tenets of the enterprise that will be used to drive architectural trade-offs and decisions.

• The external influences are architectural drivers such as standards, technology evolution, and the environment within which the enterprise operates.

The naval forces network can best be described with multiple tiers, a core network, and various types of distribution and access tiers, sometimes called edge networks. The core exists in fiber-optic connectivity, which allows operations in the continental United States as well as at specific fixed regional sites such as military bases. The ability to reach naval forces responding to global conflicts requires communications capabilities beyond core networks, and for this the naval forces rely extensively on satellite communications (SATCOM), with an emphasis on protected (extremely high frequency), for assured availability of low-rate information today, to be followed by megabit-class assured connectivity to be provided by the Transformational Satellite Communication System when it is deployed. This capacity is augmented by wideband (super high frequency), narrowband (ultra high frequency), and commercial SATCOM; however, these systems are easily jammed by relatively simple equipment and

therefore cannot be relied on for assured connectivity. The Navy’s approach to SATCOM is not stovepiped. It includes the integrating element Advanced Digital Network System (ADNS), which adds the essential networking functions on top of the SATCOM links.⁶

A similar degree of diversity is found in terrestrial wireless communications in support of tactical and strategic communications. These missions reflect the operational environments such as Navy battle groups operating in blue water and vessels engaged in littoral operations, as well as United States Marine Corps (USMC) amphibious and ground forces. The Navy also has a critical role in nuclear forces, where architectures must support low-rate but extremely high integrity message transfer. Navy strategic communications to ballistic missile submarines is normally accomplished through a network of very low frequency and low frequency transmitters located throughout the world.

The service, application, and computing elements of the naval architecture are also complex and dynamic (e.g., NMCI migrating to NGEN). The Naval Open Architecture Initiative was established by the Department of the Navy (DON) to shift focus from a platform-centered warfare system acquisition and development approach to an integrated approach centered on the battle force^7,8 In addition, the naval forces have focused on service-oriented architectures as a critical open-architecture technology trend.⁹ Several key challenges are associated with the development and deployment of the naval implementation of a service-oriented architecture (SOA), not the least of which is knowing when SOA is the right approach to naval business and weapons system information exchange. Some weapons and combat systems may have latency and data-processing volume requirements that necessitate tightly coupled, real-time, distributed applications and computing components, features that can be difficult to implement based on SOA design principles. However, the potential rigor of SOA configuration control can be useful in such conditions to ensure information availability and integrity; also, the capability of processing is increasing quickly enough that the inefficiencies of SOA could be overcome.

The CANES initiative is a follow-on to the IT-21 Initiative established nearly 10 years ago. The overarching goal of the N6-directed CANES initiative, developed in collaboration with the elements of the Naval NETWAR FORCEnet Enterprise (NNFE), is the same as that of IT-21, which is to establish essential components of the naval afloat (including Maritime Headquarters and Maritime Operations Centers) IT infrastructure that enable deployment of flexible, agile, and cost-effective C4ISR systems and applications. Naval organizations and programs associated with specific domains (i.e., air, space, subsurface, surface, and C4I) have initiated efforts to explore the feasibility of factoring in and deploying key warfighting applications on an SOA.¹⁰

The naval forces are to be commended for their current enterprise vision¹¹ and their existing detailed architectures at program levels. They must now ensure that their objective detailed, end-to-end architecture is modified to include the attributes necessary to assure information availability and integrity, and then that they are refined, communicated, accepted broadly, and implemented according to plan. Moreover, a focus on integration and transition from the current state to the desired end state must be maintained.

From an IA perspective, the enterprise architecture must enable naval forces to keep pace with new trends in Department of Defense (DOD) computing, such as the movement toward Web services, and incorporate information assurance mechanisms that deal with threats related to these trends. “Bolting on” IA to naval systems during and after development instead of “building in” IA from system inception appears to be a continuing issue, given the state of implementation relative to the objective enterprise architecture. The problem is exacerbated by quick-reaction development of capabilities and urgent requests from current theaters of operation.

Having overall guidance embodied in an IA set of principles for the naval enterprise architecture could allow IA developers to create solutions that can be more easily and rapidly integrated into naval systems. The prudent, targeted, and timely incorporation of related IA technologies in affected naval IA architectures is therefore an important priority.

In this context, Table E.1 briefly considers selected emerging IA technologies as they relate to each major state of data: in transit, at rest, and in process. An additional category covers technologies and issues that cut across these areas. The naval forces should also seek to leverage testing and evaluation capabilities being developed more broadly by the DOD (e.g., the Defense Advanced Research Projects Agency’s National Cyber Range) to evaluate the robustness of architectural implementations and new capabilities, technologies, and systems.

The naval forces are to be commended for their current enterprise vision¹² and their existing detailed architectures at program levels. They must now ensure that their objective detailed, end-to-end architecture is refined and communicated and accepted broadly. Moreover, a focus on integration and transition from the current state to the desired end state must be maintained.