maritime isr enterprise acquisition (miea)...

[i]

M A R I T I M E I S R E N T E R P R I S E A C Q U I S I T I O N ( M I E A ) R E V I E W

January 2011

Statement A: Approved for public release; distribution is unlimited (June 2011)

Maritime ISR Enterprise Acquisition (MIEA) Review

[ii]

THIS PAGE INTENTIONALLY LEFT BLANK


[iii]

TABLE OF CONTENTS

ENDORSEMENT ...................................................................................................................................... iv

DEDICATION............................................................................................................................................. v

TABLE OF FIGURES ............................................................................................................................... vi

1. EXECUTIVE SUMMARY ................................................................................................................. 7

SIGNED MIEA TASK LETTER .................................................................................................................... 4 MIEA Task Letter (con’t) ....................................................................................................................... 5

2. INTRODUCTION ............................................................................................................................... 6

2.1. BACKGROUND ................................................................................................................................ 6 2.2. HISTORY ......................................................................................................................................... 6

3. CHALLENGES ................................................................................................................................... 9

3.1. DATA ACCESS ................................................................................................................................. 9 3.2. ASHORE INFRASTRUCTURE........................................................................................................... 11 3.3. COLLABORATIVE ISR GATEWAY ................................................................................................. 12 3.4. C2ISR AUGMENT ......................................................................................................................... 14 3.5. INFORMATION ASSURANCE .......................................................................................................... 16 3.6. C2ISR ACQUISITION ..................................................................................................................... 16

4. FINDINGS & RECOMMENDATIONS .......................................................................................... 19

4.1. CRITICAL C2ISR DATA CHALLENGES .......................................................................................... 19 4.2. CRITICAL HIGH PERFORMANCE ASHORE (HPA) .......................................................................... 27 4.3. CRITICAL AFLOAT ISR GATEWAY CHALLENGES ......................................................................... 35 4.4. CRITICAL SMALL SHIP ISR (SS) ................................................................................................... 42 4.5. CRITICAL INFORMATION ASSURANCE (IA) .................................................................................. 46 4.6. CRITICAL C2ISR ACQUISITION (EA) ............................................................................................ 54

5. CONCLUSION .................................................................................................................................. 61

BIBLIOGRAPHY ..................................................................................................................................... 62


[iv]

ENDORSEMENT

Subj: Maritime Intelligence, Surveillance, and Reconnaissance Enterprise Acquisition (MIEA) Review

Ref: (a) ASN RDA memo of 01 Jun 09

The Maritime ISR Enterprise Acquisition (MIEA) Review was initiated in March 2009 in order to understand the best approach for delivering National and Joint ISR from the shore-based intelligence infrastructure and the Distributed Common Ground Station-Navy (DCGS–N) program. This office expanded the review (reference (a) pertains) to include an understanding of all ISR sensor acquisition programs to include associated data, communication links, exploitation, and dissemination capabilities.

The results of this study will form the basis from which OPNAV N2/N6 and ASN RDA will work together to transform the Navy’s ISR infrastructure to effectively incorporate the quantum growth in ISR sensor quality and quantity. I formally endorse the recommendations contained in this report.

Copy to: CNO (N2/N6, N8) DUSN (Attn: Ms. Kay) DASN (C4I/IO/Space, Ships, Air, ExW) PEO (C4I, IWS) RDA CHSENG MARCORPSYSCOM HQMC (C4,I) COMSPAWARSYSCOM COMNAVAIRSYSCOM COMNAVSEASYSCOM


[v]

DEDICATION

This report is dedicated to Dr. Gary Federici. On October 20th, 2010, just prior to the formal completion of this report, Dr. Federici passed away. This report is a small reflection of his lifelong vision, dedication, and quest for improvement in all aspects of Naval command & control. While serving as the Deputy Assistant Secretary of Navy for Research Development and Acquisition of C4I and Space, he led the initiative to broaden this ISR review to examine the full range of capabilities, architectures, and potential impediments to future naval warfare. Dr. Federici was a pioneer in the use of space-based surveillance and communication systems. As a result, he had the foresight to understand that the prolific use of unmanned surveillance and communications systems is creating a significant transformation of naval warfare.


[vi]

TABLE OF FIGURES

FIGURE 1 - SIGNED MIEA TASKER 4

FIGURE 2 - EXPONENTIAL GROWTH OF COMPUTING CHART 9

FIGURE 3 - NAVY ISR ROADMAP DATA CHALLENGES 10

FIGURE 4 - DATA GROWTH OVER NEXT 15+ YEARS 11

FIGURE 5 - DATA TRANSFER RATES 12

FIGURE 6 - NOTATIONAL NAVAL ID ARCHITECTURE CHART 13

FIGURE 7 - GCDS VISION 14

FIGURE 8 - QUANTIFIED VALUE OF MULTI-INT 15

FIGURE 9 - INFORMATION DOMINANCE DILEMMA 17


[vii]

1. EXECUTIVE SUMMARY

This review began in 2009, just prior to the stand-up of the Deputy Chief of Naval Operations (DCNO) for Information Dominance, OPNAV N2/N6 organization. This project was not funded as a large dedicated effort, but rather is the combined effort of subject matter experts (SMEs) from across the Department of Navy (DoN) material establishment, intelligence commands, and tactical operational commands. Throughout this review, information and ideas were vetted with the office of the Deputy Chief of Naval Operations (DCNO) for Information Dominance, offices within the Space and Naval Warfare Systems Command (SPAWAR), and within the Naval Air Systems Command (NAVAIR). Many of the findings and recommendations contained within this review were considered and/or addressed in the FY2012 and beyond Program Objective Memorandum (POM) budget process. Through this review, the MIEA team developed a clear understanding of the two primary technology drivers currently impacting the future of naval Command, Control, Intelligence, Surveillance, and Reconnaissance (C2ISR). These technology drivers are:

1. New information technology paradigm of ubiquitous networking, virtualized computing, and shared services applications (a.k.a., cloud computing);

2. Rapid, proliferating unmanned platforms carrying high capacity surveillance sensors.

Together, these synergistic technologies are revolutionizing the warfighter’s understanding of the battlefield, and the resultant options afforded each warfare commander. As a result of the potential provided by these technology drivers, this review identified 53 findings and recommendations that could improve C2ISR effectiveness. These findings and recommendations are grouped into the following six focus areas and their related challenges:

1. Data Access - massive ISR data feeds 2. Ashore Infrastructure - ineffective use of ashore advantages 3. Collaborative ISR Gateway - full ISR access to large deck ships 4. C2ISR Augment - enhance small deck ship capability 5. Information Assurance - IA processes divert capability 6. C2ISR Acquisition - acquisition process misalignment

Below are the recommendations based on the challenges identified in the six focus areas:

1. Massive ISR data feeds overwhelm information potential: Data focused programs 2. Ineffective use of ashore advantages: 2 plus 1 C2ISR Infrastructure 3. Large deck access to complete ISR knowledge: DCGS-N as collaborative afloat getaway 4. ISR augment to advantage small decks: C2ISR carry-on capability 5. Information Assurance process diverts capability: Separate infrastructure IA from

applications IA 6. C2ISR acquisition process prevents capability: Agile, disciplined, incremental C2ISR

programs


[2]

The important and most notable key points from these findings are:

New DoN ISR sensors are very capable and being fielded in significant numbers.

These sensors are capable of producing 100-150 terabytes of data per day; joint and national sensors are producing equivalent amounts of data.

Data is difficult and expensive to move, but 1,000 times less difficult to move through terrestrial networks than radio-frequency networks; one terabyte requires approximately three days to move on DoN’s newest Wideband Global SATCOM channel.

Processing and storage of data is inexpensive, but 100 times more expensive afloat than ashore; local processing is needed to augment centralized ISR processing and minimize large data set movement.

DoN does not yet have a data strategy to adequately address the relationship between ISR data processing, storage, movement, and continuity of operations (COOP) ashore and afloat.

Navy does not yet have an ashore or afloat information infrastructure capable of effectively utilizing emerging large data sets.

Fusing multiple ISR inputs improves warfare capability but cannot be accomplished within current programs and without an effective data strategy.

Processing large data sets to enable the push of a small amount of the right data at the right time can be an effective way to support tactical operations and gain infrastructure efficiencies.

DoD Intelligence and joint tactical information infrastructures are available to support Navy capability. These infrastructures can provide capability at significantly less expense and implementation time.

Current information assurance practices are misaligned from new information technologies (virtualized shared services) being deployed by programs like the Consolidated Afloat Networks and Enterprise Services (CANES) program and the Intelligence Maritime Architecture.

Current requirements, budget, and acquisition practices are aligned to legacy information technologies (independent client-server based systems) and impeding Navy’s ability to effectively use shared-services and shared-data to support needed C2ISR capability.

The MIEA Review team determined early in its research that ongoing Navy ISR acquisition programs will generate far more new data than the existing C2ISR afloat and ashore infrastructure and associated acquisition programs can realistically accommodate. To address these challenges, the MIEA Review focuses on the information technology paradigm shift, currently underway, and how this paradigm shift can be leveraged to enhance future C2ISR capability. The goal of this review is to provide a broad understanding of these challenges and opportunities, a framework to capitalize on opportunities, and recommendations that institutionalize corrective measures as the Navy moves forward into the next decade.


[3]

With respect to what the CNO and DCNO for Information Dominance have said, the Navy is undergoing a naval transformation equivalent to previous naval transformations such as sail to steam, steam to nuclear propulsion, and battleship to naval aviation warfare. As was the case in each of the previous naval transformations, the afloat Navy forces are dependent upon a rich shore-based infrastructure to support the new capabilities. This dependence proves true for the Information Dominance transformation the Navy is currently experiencing. This MIEA Review details a set of actionable recommendations that will facilitate this current transformation.


[4]

SIGNED MIEA TASK LETTER

FIGURE 1 - SIGNED MIEA TASKER


[5]

MIEA TASK LETTER (CON’T)


[6]

2. INTRODUCTION

2.1. BACKGROUND

The Maritime ISR Enterprise Acquisition (MIEA) Review was initiated in March 2009 to understand the best approach for delivering national and joint ISR from the shore-based intelligence infrastructure and the Distributed Common Ground System-Navy (DCGS–N) program.

This 18-month MIEA Review originally began as a short term effort to identify an effective functional split between DCGS-N ISR application capability being fielded at each large deck ship and Maritime Operations Center (MOC) ashore, and the ISR content delivery capability, fielded at the DCGS-N Enterprise Node (DEN) located at the Office of Naval Intelligence (ONI).

The shore-based component of DCGS-N is termed the DCGS Enterprise Node (DEN). The DEN is an evolutionary capability derived from the legacy Joint Concentrator Architecture (JCA). The JCA toolset provides national imagery to support fleet operations planning.

The MIEA Review was expanded by the Office of the Assistant Secretary of Navy for Research Development and Acquisition, ASN (RD&A), to take a broader look at the Navy's evolving situation with respect to ISR sensors as well as the manned and unmanned platforms supporting those sensors. Subsequent to the beginning of this study, the Navy headquarters staff reorganized and merged the previous Intelligence (N2) Directorate and the Communications Networks (N6) Directorate into a newly combined N2/N6 Information Dominance Requirements and Resourcing Directorate. This initiative was a key component of the Chief of Naval Operations’ (CNO’s) bold move to create decision superiority across all aspects of naval warfare.

This task involved understanding national, joint, and naval ISR information sources, and the associated shore and afloat-based processing, exploitation, and dissemination (PED) capabilities that would feed and support the DCGS-N and DEN systems. Three months after the review began this effort was broadened to include an understanding of all ISR sensor acquisition programs to include associated data, communication links, exploitation, and dissemination capabilities.

Intelligence, Surveillance and Reconnaissance (ISR) are key components of an information dominant maritime force. The ASN (RD&A) was interested in understanding how the current set of acquisition programs were working together to support the CNO's Information Dominance vision and tasked this MIEA Review to take a broad look at the sensors, and associated platforms, communication networks, and applications that support the CNO’s initiative in the maritime environment. This effort has worked primarily with the Program Executive Officer for Command, Control, Communications, Computers and Intelligence (PEO C4I), the Office of Naval Intelligence (ONI), Naval Air Systems Command (NAVAIR), and the Space and Naval Warfare Systems Command (SPAWAR) to understand how their combined set of sensor platforms as well as command and control programs were aligned to achieve Information Dominance.

2.2. HISTORY


[7]

Like all support frameworks, recognition of the role played by infrastructure in transformative capabilities is often lost under the attention given to the front line capability. The evolution of the Navy’s “Main Battery” and the transition associated with shore-based infrastructure has continued in order to support the perpetual growth of Naval warfare capability.

When the Navy transitioned from sail to steam power, afloat units were no longer dependent on the caprice of wind direction during tactical engagements, and were freed of the seasonal weather patterns during strategic movements. This new freedom came at a cost – coaling stations were needed to replenish the bunkers at regular intervals. Since coal was fast becoming a strategic resource other nations might not willingly supply, the United States had to establish its own coaling stations and did so by installing 157 stations around the world.

A similar establishment of infrastructure had to be undertaken when the Navy finally accepted the emergence of the aircraft

carrier as a key weapon system. In order to produce a ready aircraft and crew on the deck of a carrier, shore-based airfields, training facilities, and maintenance facilities had to be established and operated. The Navy invested in 168 air stations, 250 outlying airfields, and by the end of World War II had more than 100 aircraft carries, 41,000 aircrafts, 431,000 personnel, and 6,700 ships.

The advent of nuclear power was as revolutionary as steam, in particular for the submarine force. The limiting factor for how long a boat could stay submerged was no longer the charge in its batteries, but how much food the submarine could carry. Like steam power and aircraft carriers, an incredibly robust shore-based infrastructure had to be established to safely and effectively operate nuclear powerplants afloat. This transition forced the Navy to invest in Naval Reactors Facilities and Nuclear Power Schools.

An additional example of evolving infrastructure that can be identified on the commercial side of Information Dominance is that of Google. From the seemingly simple search engine, to e-mail services, data warehousing, and the knowledge-rich Google Earth, these services have revolutionized the way both private and professional people access information. The majority of people enjoying these information-rich services, however, are unaware of the large and growing globally-distributed infrastructure behind Google’s service offerings. Because all such information infrastructures could be vulnerable to physical and cyber disruption, Google works hard to keep specific knowledge of its infrastructure hidden from public view.

The MIEA team spent several hours with Google to learn more about its infrastructure growth and how it


[8]

supports the services they offer, with key details identified within this review. The MIEA team also spent significant time with Akamai, a company that has taken its commercially available technology that delivers more than 2.3 Terabits per second of information to commercial web service consumers and adapted it for a military implementation.


[9]

3. CHALLENGES

3.1. DATA ACCESS

Challenge: Quickly finding useful and relevant information across massive quantities of data that do not share common ontology, semantic data models, and implementation schemas.

Discussion: Data is the foundation of the knowledge pyramid, and it can be structured in a multitude of ways. In many cases, the data’s ultimate usage may dictate the methodology around which it is structured. Ontologies (what entities exist and how they can be grouped), semantics (meaning of data within the context of its relationships), and schemas (templates that identify specific meanings of data with strings of data) all play a part in establishing the utility of a given data set. Unfortunately, these same attributes also play a part in discoverability and interoperability. Unlike a Google search, users have to know not only what they are looking for, but also where to look for it. This leads to situations where critical data is left unused. To compound the problem, DoN and DoD data are often locked away in databases accessible only to authorized users, stored on LANs that are not exposed to the enterprise, or spread across multiple classification levels.

FIGURE 2 - EXPONENTIAL GROWTH OF COMPUTING CHART


[10]

In examining the issues surrounding data, one of the things that became evident is processing is no longer the “long pole in the tent.” For many years, high performance processors were rare and expensive to operate, and were treated as the scarce resource that needed to be guarded. The current overcapacity in processing resources was one of the factors that led to the establishment of commercial cloud computing. Hand held devices also blazed a trail to the point where processing can now be deployed at the point of data generation, ultimately benefiting bandwidth usage since data could be better preprocessed and prioritized before transmission to another node. These technologies should be applied to minimize the streaming of unnecessary data across constrained bandwidth as the number of ISR sensors producing large quantities of data come online.

FIGURE 3 - NAVY ISR ROADMAP DATA CHALLENGES

Data management has also garnered increased attention, as it became evident that data can be useful to more users than it was intended for. Problems with data formats arise in understanding how to navigate data structures that may be incompatible with external systems. Metadata goes a long way in solving many of these types of problems, but can be leveraged in a much more efficient manner when common metadata conventions are consistently applied.

Recommendations: The nine recommendations contained in Section 4.1 focus on how to smartly manage the increasing volume and types of C2ISR data to effectively support afloat C2ISR operations.


[11]

3.2. ASHORE INFRASTRUCTURE

Challenge: Effectively use ashore network, computing infrastructure and personnel resources to ensure effective C2ISR that aligns with real-time afloat operations.

Discussion: The Navy has traditionally been reluctant to invest in ashore infrastructure, preferring instead to bolster afloat capabilities. This may have made sense when the main batteries of the Navy consisted of 16-inch guns or naval aircraft, but the adoption of “information as a main battery” shifts the paradigm. Limiting factors for Naval Information Dominance capabilities include bandwidth, manpower, and ‘Size Weight and Power’ (SWaP).

FIGURE 4 - DATA GROWTH OVER NEXT 15+ YEARS

In an era where the Navy is producing hundreds of terabytes of data per day, it is not unreasonable to anticipate the need to transfer one terabyte of data per day. Moving large data files through satellite systems or through terrestrial network systems is time consuming and requires significant investment in communications infrastructure. Current Navy ashore and afloat infrastructures are severely inadequate to support data transmission rates demanded to support operations in the very near future. Even if it were permissible to allow 50Mbps channel (the maximum channel size anticipated with the Navy’s planned Navy Worldwide Global Satellite (WGS) System), the transfer of one terabyte of data would take three full days of dedicated channel usage.

As the aggregate amount of data continues to increase, manpower will be needed to analyze and manage it, centers will be needed to store it, and servers will be needed to process it. Manning ashore will always outnumber manning afloat. In the past, commanders were hesitant to rely on


[12]

the ashore manpower because of intermittent communications. Today, communications are much more reliable but the data movement challenge degrades the performance. Nevertheless, the resources ashore are much more robust and can provide significant, cost-effective support to afloat units if managed smartly.

FIGURE 5 - DATA TRANSFER RATES

Recommendations: The 11 recommendations contained in Section 4.2 focus on how to smartly modernize the shore infrastructure and align personnel resources to effectively support afloat C2ISR operations.

3.3. COLLABORATIVE ISR GATEWAY

Challenge: Effectively deliver afloat and ashore derived ISR to support naval operations in the face of the full range of operations.

Discussion: The current paradigm of “produce afloat, push ashore” creates a “knowledge chokepoint” wherein neither coordinated optimization of information delivery nor coherent net-centric C2 of its users exists. Though shared data is required by Secretary of Navy instruction, little has been done to implement a data strategy truly capable of supporting a shared enterprise vision.

Maximizing and optimizing the use of the Global Broadcast Service (GBS) can help to alleviate this chokepoint. Limited radio frequency bandwidth afloat constrains each Navy afloat unit to being its own information “sub-enterprise,” but significant improvements in data collection, production, indexing and security management to enable discoverability across all mission areas “within the skin of the ship” are required. Lack of coherent afloat ISR tactics, techniques and procedures (TTPs) additionally limit the ability to network sensors in support of strike group or combatant commander (COCOM) tasking.


[13]

Large-deck ships provide an opportunity to use good relative bandwidth, network, and computer resources to support smaller afloat units as afloat C2ISR data centers. The DCGS-N acquisition program has the potential to function as the Navy’s common ground/surface system and ashore/afloat gateway, but significant improvements in governance and joint engagement and continued evolution of the DCGS-N and Global Command and Control System-Maritime (GCCS-M) programs need to occur to achieve this goal. The Consolidated Afloat Networks and Enterprise Services (CANES) program afloat and the Intelligence Maritime Architecture (IMA) ashore will provide the network and micro-cloud compute infrastructure to facilitate semi-independence between C2ISR application evolution and the infrastructure supporting those applications.

The vision is to enable at least one Information Dominance Corps (IDC) exploitation Center of Excellence, where resources and product are culled together and fused to properly support theater warfighter needs. Disparate, stove-piped processes, whether they are data management, a specialized INT, or professional manpower allocations, must be centrally managed to some degree in order to maximize efficiencies under the new IDC construct. These IDC nodes would also be strategically placed in order to effectively support sister services, and leverage greater DoD/Defense Information Systems Agency (DISA) infrastructure as required.

FIGURE 6 - NOTATIONAL NAVAL ID ARCHITECTURE CHART

Another shared enterprise technology worthy of consideration for DoN infrastructure services is the GIG Content Delivery Service (GCDS), currently provided by DISA as an added content support capability. This technology is the military’s implementation of the commercial technology provided


[14]

by Akamai. By placing edge servers in physical locations close to large user areas, this service creates the ability to minimize infrastructure requirements for most application services it supports while providing extremely fast assured access to those extremely large virtualized data stores.

FIGURE 7 - GCDS VISION

Recommendations: The eight recommendations contained in Section 4.3 provide details for how to move the Navy away from the “produce afloat, push ashore” paradigm that inhibits its ability to function as a netted force.

3.4. C2ISR AUGMENT

Challenge: Effectively using Group and Unit level ship resources across the breadth of afloat operations.

Discussion: Tactical afloat units have become increasingly capable, but don’t necessarily receive parallel C2ISR system/software capability suites that allow them to maintain advantage over their adversaries at the tactical edge. The lack of systems, bandwidth and manpower supporting C2ISR


[15]

inhibits the ability of these units to act as fully netted sensors in an afloat C2ISR enterprise. In iterative budget cycles the investments needed to upgrade these units have not been made.

FIGURE 8 - QUANTIFIED VALUE OF MULTI-INT

Embarkable carry-on packages that can be deployed on an as-needed basis, supported by a small group of trained personnel, can provide a viable option given the advances that have been made in processing, storage, and portability. This concept maximizes the expertise and proficiency of the ashore community by concentrating capability at the right time, in the right place, and in support of the right user. Independent teams of Information Dominance Corps specialists can provide a greater all-source perspective and capability to our command staffs at the smallest unit level.

Integrating data from sensors with different characteristics offers potential improvements in knowledge of the battlefield not effectively achievable by any other means. Integrating data from multiple sensors offers cost-effective, potentially significant improvements in geolocation accuracy as a result of better detection geometries due to geographically separated platforms; lower detection thresholds with false alarm control by requiring detection by more than one sensor; cueing by one sensor to initiate tracking in another; and angle diversity from radar sensors on different platforms.

Recommendations: The five recommendations contained in Section 4.4 provide details for improving small ship C2ISR capabilities as part of a netted afloat C2ISR force.


[16]

3.5. INFORMATION ASSURANCE

Challenge: Operating with an effective risk trade-space to ensure adequate Information Assurance (IA) without causing operational capability to lag the changing threat landscape.

Discussion: Many tactical ISR platforms exchange data with ground stations using unencrypted links. Current IA processes divert capability, resulting in lost implementation time for questionable gain. Virtual Secure Enclaves (VSEs) have the potential to provide high information assurance, greater flexibility, and better resource management at a lower cost than Virtual Private Networks (VPNs).

The increasing number of heterogeneous sensors across different security domains demands that exploitation of the resulting data streams and products be consistently and properly security-tagged. Current processes are neither responsive nor consistent enough to allow for effective and timely exploitation and dissemination across security domains. Role-based, attribute-based and authorization-based access control technologies, as well as a variety of cross-domain solutions, should provide the means for improving user access and machine-to-machine security.

Current IA certification processes require applications and infrastructure be certified by system, wherein any change to any component of the overall system requires recertification of the entire system. These ineffective Information Assurance Certification and Accreditation business process costs put a significant drag on effective IT acquisition, conservatively estimated to add 50%-75% to the overall fiscal resource burden of realizing an installed capability. Cryptographic binding and High Assurance Platform technologies offer mechanisms whereby infrastructure and application certifications can be decoupled, reducing time and cost associated with the IA certification process and thus improving speed of capability delivery.

Recommendations: The nine recommendations contained in Section 4.5 provide details to mitigate the current information assurance challenges that provide high information assurance and improve C2ISR interoperability.

3.6. C2ISR ACQUISITION

Challenge: Efficiently leveraging acquisition processes to deliver threat-pacing capability that can support evolving joint, coalition, and naval forces need.

Discussion: Critical challenges with the DoD’s current IT acquisition processes have proven repeatedly they are ineffective, over-burdened and overly bureaucratic. The IT acquisition processes must support acquisition practices that enable, not hinder, capturing technology opportunities before they become useless or outdated. The acquisition process must recognize and make efficient and cost-effective accommodations for shared IT infrastructure having to evolve under a framework of effective, collaborative governance and a set of well-defined, rapidly responsive acquisition processes, whereby deployed applications are encouraged to leverage that shared infrastructure.


[17]

Cloud computing or services oriented architectures cannot be delivered within traditional budget profiles. Budgets and funding must be built, defended, executed and evaluated across many organizational boundaries to produce cloud-enabled computing services. The IT acquisition directives and guidelines must recognize IT “services” are not systems in the traditional sense of an autonomous, discreet system. IT systems are a continuously evolving collection of infrastructure and shared capabilities to meet changing needs of a wide variety of consumers, very similar to how other utilities (power, gas, water, cable TV) are commonly used and thought of in today’s world. IT systems provide the IT service “utility” by which the warfighting, business and logistical activities of the services are carried out on a daily basis by IT customers globally.

Information technology can be depicted as three primary evolutions or generational developments of computing, storage, and networking technologies. Wave 1 represents the mainframe era of computing (1950s up to almost the 1990s). Wave 2 represents the client/server era of computing (starting in mid-1970s), the technologies that fueled the entire Internet growth and has enabled the modern information technology world of today.

FIGURE 9 - INFORMATION DOMINANCE DILEMMA

Because Wave 2 technologies enabled semi-independent information systems composed of servers feeding a number of clients and interfacing with other client/server systems, it lent itself to the project-based DOD acquisition processes that emerged in the 1950s, the evolution of which remains


[18]

in use today. Now, Wave 3 technologies are radically changing the processes serving both commercial and government organizations and the 1950’s era acquisition process is struggling to keep pace.

A successful incubator of new IT capabilities requires science and technology projects able to effectively transition into programs of record (PORs), something not currently possible due to the many levels of oversight and tight, risk-averse budget controls. These sets of circumstances leave no flexibility for trial and error in the successful transition of science and technology incubation projects into successful PORs and ultimately the hands of warfighters never see these new, some-times life-saving technologies. New IT applications should be more like plug-and-play appliances. These modular, ready-to-use appliances should be engineered in the science and technology domains and integrated into the shared cloud computing or services oriented architecture using an iterative POR budget authority that incentivizes IT as a utility shared across a wide range of customers and a diverse set of mission-aligned organizations. Ultimately, the challenge is to efficiently and effectively leverage acquisition processes to deliver threat-pacing (and threat anticipating) capabilities that can support evolving joint, coalition, and naval force needs.

Recommendations: The 11 recommendations contained in Section 4.6 provide details for reshaping the current IT acquisition framework to enable the delivery of more timely and relevant C2ISR capability to afloat and ashore operating forces.


[19]

4. FINDINGS & RECOMMENDATIONS

4.1. CRITICAL C2ISR DATA CHALLENGES

Data is the foundation of the knowledge pyramid; however, data can unfortunately be structured in a multitude of ways. In many cases, the data’s ultimate usage may dictate the methodology around which it is structured. Ontologies, semantics, and schemas all play a part in establishing the utility of a given data set. Unfortunately, these same attributes also play a part in discoverability and interoperability. Unlike a Google search, users have to know not only what they are looking for, but also where to look for it. This leads to situations where critical data is left unused. To compound the problem, DoN and DoD databases are often locked away in databases accessible only to authorized users, stored on LANs that are not exposed to the enterprise, or spread across multiple classification levels.

SHARED DATA – RECOMMENDED PRINCIPLES

In examining the issues surrounding data, one of the things that became evident is that processing is no longer the “long pole in the tent.” For many years, high performance processors were rare and expensive to operate and were treated as a scarce resource that needed to be guarded. The current overcapacity in processing resources was one of the factors that led to the establishment of commercial cloud computing. Handheld devices also blazed a trail, to the point where processing can now be deployed at the point of data generation, ultimately benefiting bandwidth usage since data could be better preprocessed and prioritized before transmission to another node.

Data management has also garnered increased attention, as it became evident that data can be useful to more users than intended. The problem arises from data formats and how to navigate data structures that may be incompatible with external systems. Metadata goes a long way in solving many of these types of problems, but can be leveraged in a much more efficient manner when common metadata conventions are consistently applied.

The following recommended shared data principles underpin the recommendations laid out herein:

1. Move processes to the data; computer processing and storage have become inexpensive and data movement has become the “long pole in the tent.”

2. Apply the UCore common data model where possible but accommodate non-standard models and schemas when necessary.

3. Some data must be moved to support fusion, intelligence, and forensics.

4. Apply metadata to identify contents of data prior to movement; minimize movement of data from afloat to ashore.

5. Process data at all forward points to include the source, first ground location, etc.


[20]

6. Design machine-to-machine algorithms to facilitate data processing and allow operators to focus on high value analysis.

7. Establish smart-data, cross-source continuous searches to pull data from noise and facilitate mission process operations.

8. An over-arching data strategy is not adequate for all situations; establish sub-strategies that are context specific and that support the overall data strategy.

FINDING SD-1:

Naval ISR covers the spectrum of intelligence disciplines – MASINT, SIGINT, IMINT, etc. The discipline that has seen the greatest expansion is IMINT, with imaging systems focused on electro-optic, infra-red, and full motion video capabilities. These capabilities are also extremely bandwidth-intensive. According to the Motion Imagery Standards Protocol, the lowest quality full motion video optimized for a low-bandwidth environment (640 x 480, 24 frames per second, 8-bit depth, 110:1 compression) will consume 1.5 Mbps.1 At this quality, the full motion video would have limited intelligence value. Standard quality full motion video (480 x 720, 24 frames per second, 8-bit depth, 2.5:1 compression) will consume 270 Mbps.2 As the number of sensor platforms increases, the bandwidth requirement similarly escalates.

The bandwidth requirement is not just a wireless transport issue. As an example, the P-8A has been estimated to generate approximately five to eight terabytes of data during every sortie. Much of the data may need additional Processing, Exploitation, and Dissemination (PED) at locales other than the P-8A’s launch and recovery location. Transmitting terabytes of data across the existing global infrastructure, even via exclusively ground connections, would take days and make the data operationally irrelevant. Considering multiple P-8A sorties will be flown each day, sometimes in the same theater of operations, the shortfalls of using legacy systems, transport, and processes will severely limit the utility and effectiveness of the sensors in which the DoN and nation have made significant investments.

Every P-8A and BAMS sortie alone will generate several terabytes of data. Additional unmanned undersea and surface systems will be creating equivalently sized data sets, adding to the existing manned platforms that already produce sizeable data sets. Combat and weapon system data provide additional large data sets. Taken in the aggregate, naval data production volume will reach petabytes (1015 bytes) each year; this level of data production requires deliberate planning and data architecture implementation to effectively enable future naval forces.

RECOMMENDATION SD-1:

a) Develop a maritime data strategy to store, search, distribute and make exploitable maritime ISR data across the full range of operational missions.

b) Implement a Maritime Data Infrastructure capability over the next decade.

1 Motion Imagery Standards Profile (MISP) v4.5, May 2008 http://www.gwg.nga.mil/misb/docs/MISP45.pdf

2 Ibid.

http://www.gwg.nga.mil/misb/docs/MISP45.pdf


[21]

FINDING SD-2:

Electro-optic, infra-red, hyperspectral imagery/multispectral imagery , and still imagery all generate large data files, with the corresponding challenges of transporting and analyzing the products in a timely manner.

Almost all unmanned aerial vehicles (UAVs) currently in development or near fielding have unique proprietary ground control stations (GCSs) or mission control stations. None of these GCS are interoperable with any other UAV, and in most cases the GCS is also the primary downlink site for the sensor data collected by the UAV. The UAV programs have not accounted for transferring data from the GCS to the larger ISR PED infrastructure or archiving the data in an organized fashion. In addition, there may not be consistent metadata standards applied across the various platforms’ data.

Traditionally, the way in which databases are structured in response to varying data inputs can impact the effectiveness of search results, as well as impacting the resulting military utility of the data. In order to use a data set held in multiple databases, the associated metadata tag must match and the associated data needs to be stored in the same format.

Unfortunately, data architecture and database design are largely “non-practices” in current naval systems development, reducing the operational value of collected sensor data by making the data harder to discover. However, emerging multi-dimensional data search technology is radically changing the value of cross-indexed metadata. Advances in contextual searches enable consistent results across databases lacking share similar metadata hierarchies.


Dedicate new resources creating data-focused MDI acquisition programs. Rather than allow each program to establish its own data strategy, initiate a dedicated program mandated to consolidate guidance and ensure compliance with overarching directives.

Leverage advancements from the S&T, Intelligence Community, and other joint development efforts to obtain best value from available data. Re-tagging or converting databases can be costly and time consuming, but evolving methodology for searching disparate database types will alleviate these issues.

FINDING SD-3:

DoDD 8320.023 and SECNAVINST 5000.36A4 were intended to foster visible, discoverable, and understandable data. For example, a user needs data but may not know it exists; or may know the

3 Department of Defense Directive 8320.02, “SUBJECT: Data Sharing in a Net-Centric Department of Defense”,

December 2, 2004 http://www.dtic.mil/whs/directives/corres/pdf/832002p.pdf

4 Secretary of the Navy Instruction 5000.36A, “SUBJECT: Department of the Navy Information Technology

Applications and Data Management,” December 19, 2005,

http://DoNi.daps.dla.mil/Directives/05000%20General%20Management%20Security%20and%20Safety%20Services

/05-00%20General%20Admin%20and%20Management%20Support/5000.36A.pdf

http://www.dtic.mil/whs/directives/corres/pdf/832002p.pdf

http://doni.daps.dla.mil/Directives/05000%20General%20Management%20Security%20and%20Safety%20Services/05-00%20General%20Admin%20and%20Management%20Support/5000.36A.pdf



[22]

data exists but is unable to access it due to technical issues; or may discover data but not understand what the data means. The goals of visible, discoverable, and understandable data are achievable, as long as a unified approach is established, maintained, and adhered to.

Following are relevant excerpts:

1. DoDD 8320.2, 4.2: Data assets shall be made visible by creating and associating metadata (“tagging”), including discovery metadata, for each asset.

2. DoDD 8320.2, 4.3: Data assets shall be made accessible by making data available in shared spaces.

3. DoDD 8320.2, 4.4: Data assets shall be made understandable by publishing associated semantic and structural metadata in a federated DoD metadata registry.

4. SECNAVINST 5000.36A: Use DoN Applications and Database Management System (DADMS) as the DoN Authoritative Data Source.

5. SECNAVINST 5000.36A: Register DoN IT systems, applications, and databases with associated metadata, server hardware, and network information, in DADMS.


a) Align DoN N2/N6 budgets to support data sharing policy. As budgets become more pressurized, program managers prioritize delivering their specific capabilities on schedule and on budget. Less attention should be given to efforts only benefitting the wider enterprise as they lack incentive; resources must be committed to aligning data if the Navy wishes to prioritize Information Dominance.

b) Enforce data sharing policy through technical authority certifications. Individual program offices are often left with little oversight when implementing their data policy, and adherence to a data interface standard does not always result in discoverable or accessible data storage. Technical Authorities should be extended to certifying stored data generated by a program is discoverable, accessible, and in compliance with applicable directives.

FINDING SD-4:

Virtual Alabama5 is a 3D visualization tool initiated in 2005 by the Alabama Department of Homeland Security6. The department explored and identified ways to leverage existing state asset imagery and infrastructure data into a visualization tool that is affordable, scalable, maintainable, and capable of employing the power of existing and evolving Internet-based applications.

S&T development projects, such as Radiant Lava and Command and Control Rapid Prototype Continuum have been delayed and therefore made less effective. DoN shared data is still being held

5 http://www.dhs.alabama.gov/virtual_alabama/home.aspx

6 Ibid

http://www.dhs.alabama.gov/virtual_alabama/home.aspx


[23]

by the data owners making it difficult to locate. Sharing data is driven by human nature, not policy; data owners desire to share data when it becomes obvious, and not sharing their data puts it at risk of becoming irrelevant. When Virtual Alabama was established, state agencies were directed to make their data compatible and displayable on Google Earth. Not all agencies immediately signed on but enough critical data sets were added to demonstrate the value, providing the momentum and visibility to encourage remaining agencies to conform. Layered-earth shared data systems illuminates the benefits of sharing data and thus incentivizes data sharing participation.


a) Establish a Shared Data Program as a component of the Maritime Data Infrastructure. By establishing a common frame of reference (such as Google Earth), disparate data sets become relevant to the user and corresponding relationships between data become easier to recognize, thus facilitating the data-to-knowledge evolution.

b) Assign this Shared Data Program responsibility for implementing and maintaining the multiple security-level, layered-earth, shared repository for all DoN ISR and associated data sets.

FINDING SD-5:

Data models provide standards to bridge data ontology, semantics, and schemas; yet, despite 40-plus years of effort and policy, they have not provided universal solutions. An example of this is latitude and longitude data – it can be represented with traditional degrees (38°53'23"N, 77°00'27"W) or in decimal format (38.889722N, 77.0075W), and the metadata schema can divide the coordinate in numerous ways. In most cases, converting one format to the other is not problematic, but is critical for capabilities such as targeting, navigation, or fire control. While modifying data format may be feasible, modifying the systems that consume data can be prohibitively expensive.

Despite these challenges, UCore and extensions like NIEM, MIEM, and C2 Core represent a useful effort toward standardizing around data models and should be encouraged and incentivized. As legacy systems are updated or replaced, standardized data models will facilitate interoperability and visualization. Even more importantly, as new sensors that produce new outputs are fielded, standardized data models prevent fractured references and processing associated with current ISR sensor outputs. A standardization policy is imperative at the DoD level as agreements and consensus is achieved regarding the metadata tags for new sensors; otherwise, existing challenges of exposing data and not allowing the data to be operationally viable will be perpetuated.


a) Incentivize using UCore and associated extensions, per OSD and DoN Policy (DoDD 8320.2; SECNAVINST 5000.36A), as the foundation for data standardization implementation requirements for the ISR Shared Data Program.

FINDING SD-6:


[24]

The DoN CIO defines knowledge management as “the integration of people and processes, enabled by technology, to facilitate the exchange of operationally relevant information and expertise to increase organizational performance",7 but emphasis needs to be added to the technical dimension as the volume of data grows, while manpower and tactical bandwidth remains constant.

Similar to requirements of data access, , visualization, and fusion require new acquisition programs to enhance ISR operational use of large data sets require operational specialists who understand and can control the effect of data usage within operational contexts. Simply ensuring the communications networks are operating and data sets are discoverable are not enough; aggregate user behavior may inhibit optimal data flow across the network. For example, bandwidth usage may spike in the mornings as daily briefings are e-mailed and VTCs are conducted. Future shared data availability will enhance warfare support if there is active operational control over ISR data usage. Being able to anticipate the data needs of the tactical users – whether the data pertains to weather, targeting, force disposition, operational tasking, ISR sensor data, or something else – will optimize the network and mitigate the risk of an overburdened architecture.

Additionally, in an ideal scenario, knowledge operators should be able to stage the right data at the right time, thereby enhancing tactical operations by reducing the “data overload” that continues to grow.


a) Evaluate the idea of data/knowledge operational positions to ensure naval operations remain uncompromised by improper use of data as well as shared data applications as operations change.

b) Consider using fleet knowledge managers as the primary data/knowledge operators.

FINDING SD-7:

As the amount of data produced exponentially increases each year, the manpower devoted to examining this data remains fixed (or increases linearly at best). In addition, legacy analysis methods continue to be used, with manual search processes consuming much of the time users devote for analysis, thus making manpower less and less efficient.

The Maritime Domain Awareness Comprehensive Maritime Awareness (MDA CMA) Joint Concept Technology Demonstrator (JCTD) and resulting MDA capability is one of the few examples where data design and architecture were based upon specific operational threads. The CMA JCTD vision is to share maritime shipping information throughout the world to deter use of commercial maritime shipping for terrorism, weapons of mass destruction proliferation, drugs, piracy, and human trafficking. CMA serves as an exemplar for a “culture of sharing” of maritime information between the United States and international partners. The project takes advantage of ongoing efforts, proven technologies, and current information-sharing agreements. CMA has two main focus areas: 1) demonstrate the importance of interagency and international information-sharing for improved maritime awareness; and 2) demonstrate improved information management techniques, such as application of DoD’s Net-Centric Data Strategy, to enable effective management of large volumes of

7 Wennergrin, D.M., DoN CIO Memorandum, “Subj: DEPARTMENT OF THE NAVY KNOWLEDGE MANAGEMENT

STRATEGY,” 20 October 2005, para 2., http://www.DoNcio.navy.mil/PolicyView.aspx?ID=424

http://www.doncio.navy.mil/PolicyView.aspx?ID=424


[25]

shared data. CMA is working cooperatively with the Republic of Singapore to accomplish this. Singapore’s position as a nexus for shipping in Southeast Asia provides a unique opportunity for sharing information.8

Most of the DoN’s data exploitation processes have embedded manual processes that require analysts to devote a majority of their time to finding and extracting salient data for analysis. This is especially true if the data resides in different databases and classification levels. Even if a single workstation can access multiple security domains and databases, analyzing the data can be extremely time consuming to simply navigate across these enclaves to discover needed data. Although DoD agencies expend resources in these areas, little is being done within the DoN to understand and extend these technologies.


a) Apply S&T resources to transition transformational commercial data technology for more efficient data discovery ultimately satisfying information requirements and utilizing limited manpower more efficiently.

FINDING SD-8:

The MDA (Maritime Domain Awareness) CMA (Comprehensive Maritime Awareness) JCTD and resulting MDA capability is one of the few examples where data design and architecture were based upon specific operational needs. Valuable Information at the Right Time (VIRT) is a body of work being led by Professor Rick Hayes-Roth at the Naval Postgraduate School. VIRT has the potential to provide a “five-order” capability improvement for operational effectiveness per system/bandwidth expense.9

VIRT abstract: “Defense and homeland security leaders have focused recently on the problems of fielding networks to enable rapid decision-making and agile responses to various crises. Mostly these leaders have concentrated on the lowest levels of system infrastructure, namely the hardware and software to enable bits to flow from senders to receivers. However, most crises require a different approach, one that emphasizes the highest levels of system design. At these levels, the problems focused on are: who needs what information and how does the information find them? Because people in crises have so little time, an answer to these questions must be found to ensure that receivers are not glutted by a deluge of low-value data and consumed by attendant low-value tasks. Answers to these questions employ dynamic context and operator requirements to assure high-value information flows quickly where it’s needed and is processed promptly by recipients. This approach is called Valued Information at the Right Time (VIRT). Initial studies have shown this approach reduces the volume of bits by several orders of magnitude. This approach also raises the productivity of every operator enormously by assuring each operator can give immediate attention to truly valued information. A VIRT perspective leads us to see networks as information supply chains. Well-designed supply chains will dramatically improve the performance of Hastily Formed Networks (HFNs).”10

8 http://www.nrl.navy.mil/content_images/07Information(Dwyer).pdf

9 http://faculty.nps.edu/fahayesr/virt.html

10 Ibid.

http://www.nrl.navy.mil/content_images/07Information(Dwyer).pdf

http://faculty.nps.edu/fahayesr/virt.html


[26]


a) Apply the discipline and practice of VIRT across the full set of ISR programs to reducing operational data overload and improving the relevant information sent to specific mission operators.

FINDING SD-9:

At a basic level, metadata is data about the underlying data. Simply, it describes the corresponding file or database it is associated with, including some additional attributes to help make the data easily discoverable. As an example, most digital cameras automatically add metadata to the images they produce – date taken, exposure settings, focal length, and some new cameras can also add location information via embedded GPS.

Although metadata is mandated in SECNAVINST 5000.36A,11 very little metadata is created across the DoN. Part of the problem is legacy systems do not automatically tag their data as it is produced, and tagging the data manually is labor intensive. Tactical users are already time-constrained and often do not appreciate the larger enterprise usage of the data they manage. Metadata is a key component of the DCGS-Enterprise sharing effort and a requirement for DCGS-N. However, DCGS-N is not in a programmatic position to enforce metadata tagging on the subordinate databases it uses – this is up to the individual programs that may not be structured to comply.

Metadata is the most effective way to minimize large data movement and to inform naval operators of the availability and content of shared data. Metadata creates the ability for users to understand what kind of data is stored within a given location, and deciding whether data needs to be transported for further analysis. This determination can be especially critical if data is stored at the tactical edge, where bandwidth and transport are critically scarce resources. For example, an unmanned aerial vehicle may record full motion video of a particular incident and retain the file aboard ship. If the file is properly tagged, analysts ashore can assess whether the file needs to be transferred for further exploitation. In addition, the metadata would also make the file discoverable by other analysts.


a) Utilize N2/N6 Information Dominance Roadmaps as a way to determine how to expose metadata in the Information Dominance portfolio and ensure all DoN data is exposed through the MDI to the Naval Enterprise.

11 Secretary of the Navy Instruction 5000.36A, “SUBJECT: Department of the Navy Information Technology

Applications and Data Management,” December 19, 2005, DoN IT Applications and Data Management Directive



[27]

4.2. CRITICAL HIGH PERFORMANCE ASHORE (HPA)

The Navy has traditionally been reluctant to invest in ashore infrastructure, preferring instead to bolster afloat capabilities. This may have made sense when the main batteries of the Navy consisted of 16-inch guns or naval aircraft, but the adoption of “information as a main battery” shifts the paradigm. Limiting factors for Information Dominance capabilities include bandwidth, manpower, and ‘size weight and power’ (SWaP).

As the aggregate amount of data continues to increase, manpower will be needed to analyze and manage it; centers will be needed to store it; and servers will be needed to process it. In addition, the current and near-term network infrastructures are set up to redundantly transfer data as it is received from afloat units. For example, an unmanned aerial vehicle will relay its data to a DoN ground station via a teleport site; if that data needs to be sent to a non-DoN node, it will be sent to a Network Operations Center (NOC) and transferred to another network. If the processed data needs to be sent to an afloat unit, it will traverse the same path in reverse, so a given data chain may pass through a NOC multiple times.

Manning ashore will always outnumber manning afloat. In the past, commanders were hesitant to rely on the ashore manpower because of intermittent communications. Today, communications are much more reliable but the data movement challenge degrades the performance. Nevertheless, the resources ashore are much more robust and can provide significant support to afloat units if managed smartly.

FINDING HPA-1:

All areas of afloat capabilities – manpower, computing, storage, bandwidth – are a mere fraction of the ashore capabilities. The acquisition inertia behind upgrading shipboard systems currently inhibits rapid, meaningful capability enhancements. Additionally, even if the bulk of afloat infrastructure could be upgraded, the severely restricted satellite communications (SATCOM) bandwidth limitations will remain an issue. Terrestrial connection speeds continue to develop and increase, but SATCOM development is limited to maximizing existing bandwidth.

Shipboard SATCOM is incapable of moving, at best, more than a range of low gigabytes of information. The available bandwidth also has to serve other needs, including administrative data, telemedicine, quality of life, training, and communications. In order to simply sustain Information Dominance, the Navy will require the movement of terabytes of information daily. This means that in a best case scenario, the transmission of one terabyte of data across 50 Mbps connection would take three days, resulting in latent analysis and dissemination and ultimately delivering irrelevant data.

An additional issue is related to cost. Shipboard network, computing, and storage infrastructure is significantly more expensive than equivalent ashore infrastructure. From a cost-benefit perspective, any investment made ashore results in significantly higher overall capability and the resulting challenge is confined to smartly managing the data flow, staging data storage afloat, and deploying exploitation and analysis personnel and systems at key nodes afloat.


[28]

RECOMMENDATION HPA-1:

a) Recognize critical need for high capacity infrastructure12 ashore to transform exponential growth in national, joint, naval, partner, and open source data into actionable information.

b) Prepare related plans to include operating agreements, CONOPS, training, MOUs/MOAs, etc.

c) Establish budgets; examine leveraging joint investments and capabilities in lieu of establishing separate DoN capabilities.

d) Implement through existing and/or new acquisition programs.

FINDING HPA-2:

It is neither efficient nor information-effective to provision and build new, unique facilities or computing environments at each ashore location participating in the ISR mission. The Defense acquisition environment – from the Joint Concept Integration and Development System (JCIDS), Planning, Programming, Budgeting and Execution (PPBE), and DoD 5000 series acquisition policies and directives – implicitly encourages the establishment of stand-alone programs and systems. A successful, risk-averse program will avoid relying on external solutions that could possibly impact the schedule if not fielded on time. As a result, most ISR programs provision their own computing nodes. In the absence of an over-arching ISR concept of operations, the resulting ISR data becomes distributed, inaccessible, and tailored to a small core of users, often via these stove-piped nodes or stand-alone environments.

Initiatives such as the Real Time Regional Gateway and Turbulent Wave have demonstrated the value of consolidated computing environments where massive amounts of data are archived and made accessible to multiple analysts. This paradigm mitigates a lack of discoverability by facilitating the search process, making disparate data accessible to a wider audience.

ONI’s Integrated Maritime Architecture is highly aligned with the CANES afloat architecture providing a good baseline to build efficient ashore ISR infrastructure. As the CANES program progresses, it may be able to utilize the same protocols ashore to foster interoperability. From an acquisition perspective, ashore processing centers may also be possible to leverage the CANES contracts without having to stand up an additional “ashore infrastructure” program office. The ashore ISR infrastructure should also include the data processing requirements of Tactical Operational Centers (TOCs), Fleet Information Operational Centers, Fleet Network Operations Centers, and Meteorological and Oceanographic centers. Enterprise savings would be achieved by consolidating administrative personnel with the associated training and corporate expertise, providing enhanced efficiencies. The resulting data consolidation may also foster a “Medici Effect” of ISR fusion.

12 Wide Area Networks (WANs), computing capacity, storage capacity, and operators


[29]


a) Consolidate ashore warfare domain data processing facilities into Disaster Recovery/Continuity of Operations highly available capable Maritime Centers of Data to facilitate high performance ISR capability.

b) Perform analysis, beginning with ONI Suitland, identifying locations and capacity of other global and regional Maritime Centers of Data nodes.

FINDING HPA-3:

For large data management, Multi-INT Analysis and Archive System (MAAS), an National Geospatial Agency (NGA) tool being evaluated at the DCGS-DEN lab, is one such tool: “MAAS® is a scalable software suite that provides imagery analysts with the tools to capture, exploit (screen, view, analyze, tag, report, search), disseminate, and archive full motion video. Analysts can screen and tag intelligence events in one or more video missions as they occur for immediate reporting, or for later forensic type research. MAAS provides an advanced video player with zoom, pan, filtering (e.g., edge detection, etc.) multi-speed play and a full annotation capability. Reports can be generated and published in real-time in several formats including HTML for web dissemination, PowerPoint® slides and/or Word® documents. All data in the MAAS library component is completely searchable – from keywords analysts have entered or textual data captured from mission chat rooms – to the sensor/platform metadata. The MAAS library holds all this information and more making information available for search and retrieval.”13

Significant value is also available through cross sensor integration as demonstrated by RTRG, NCCT, and others, and articulated by the Defense Science Board’s report on Integrating Sensor Collected Intelligence: “… the task force concluded more and better sensors alone are not the answer to the ISR problem. In particular, the most relevant conclusion of our study was the identification of the performance potential of integrating data from different sensors and platforms. We determined signal-to-noise improvements, over the performance of a single sensor, of 4 to 8 dB, factors of 10 reductions in convergence and identification times, and as much as 100 times better geolocation accuracy were achievable through multi-sensor integration.”14


a) Define and implement effective ISR data management business process at Maritime Centers of Data..

b) Define and implement data management and data services at large data ingress locations, such as TOCs, MTOCs [MTOCs referenced previously??], and large deck naval ships.

c) Adopt data parsing tools to minimize movement of low value data.

d) Move post-processed data to Maritime Centers of Data..

13 http://www.gd-space.com/index.cfm?acronym=MAAS

14 Joint Defense Science Board Intelligence Science Board Task Force on “Integrating Sensor-Collected Intelligence,”

Nov. 2008, pg 5. http://www.acq.osd.mil/dsb/reports/ADA491047.pdf

http://www.gd-space.com/index.cfm?acronym=MAAS

http://www.acq.osd.mil/dsb/reports/ADA491047.pdf


[30]

FINDING HPA-4:

The Joint Concentrator Architecture (JCA) was collaboratively established between DoN and the NGA to deliver imagery and provide fly-away team operational support. The JCA supports dynamic bandwidth allocation access to multiple imagery databases (national, tactical, commercial) and acts as an injection point for other data types. Future NGA imagery will be available as an NGA imagery service via the JCA.

The JCA has been absorbed into DCGS-N to provide DIB metadata services and evolve as the ashore component of DCGS-N: “DCGS-N sites will be capable of receiving, processing, and manipulating IMINT, SIGINT, and general military intelligence data from a variety of internal and external sources. NTM imagery is provided to DCGS-N sites from a land-based central dissemination site, the DCGS-N Concentrator, located at ONI in Suitland, Maryland. The DCGS-N Concentrator is the gateway between the NGA imagery dissemination architecture and all DCGS-N sites. The DCGS-N Concentrator is where imagery is stored, retrieved by profile or request, and exposed for DCGS sites across the Joint enterprise. The DCGS-N Concentrator provides a centralized access point for Fleet imagery and products as well as content staging of NTM imagery. Imagery is passed from the DCGS-N Concentrator to DCGS-N sites afloat via a commercial or military wideband satellite system at a bandwidth designated by the operational commander (typical bandwidth is 0.768 Mbps). A limited capability Backup Concentrator (BUC) is provided for contingency use should the primary Concentrator fail.”15


a) Adapt JCA Concept of Operations to provide a single point of access to all enterprise (national / service / partner) ISR data/information resources. Build upon a proven architecture and process to provide a “head-start” for other communities, rather than developing CONOPS and architectures for other intelligence products (SIGINT, ELINT, etc.) from the ground up.

FINDING HPA-5:

The Navy Tactical Wide Area Network’s (NTWAN) maximum bandwidth is 155 Mbps service. At this rate, it is unfeasible to regularly transmit large data files, as the data would become time-late when received by the processing node. Additionally, due to the patchwork nature of Navy, joint, and Intelligence Community networks, Navy ISR sensor data may traverse multiple networks at differing bandwidths before it is received at an Intelligence Community exploitation node. For example, UAV ISR sensor data is sent to a teleport site, passed by the Navy node to the Navy NOC, then transmitted via terrestrial connections to the UAV mission control station, and ultimately sent to the IC WAN for further exploitation. The transport becomes more complicated if ISR data is sent to an afloat unit first.

An Intelligence Community WAN capability, augmented with a Naval Tactical WAN, provides 10 Gbps high and low-side data transport sufficient to support tactical Naval operations in the near term. In addition, all of the Navy exploitation nodes are already connected to the IC WAN, so rather

15 DCGS-N Increment 1 CPD


[31]

than follow an unnecessarily complicated transport path from an ISR sensor to the IC WAN, ISR sensor data could be injected into the IC WAN directly, exploited at the Navy centers of excellence, and the products disseminated more quickly to users. This WAN architecture could provide data transport from TOCs, FIOCs, FNOCs, and METOC centers as a component of an MCD ISR architecture.


a) Establish a formal relationship with the Intelligence Community to support a high side MCD WAN architecture.

b) Identify Intelligence Community WAN augmentation requirements needed to support MCDs.

FINDING HPA-6:

The Large Data JCTD has proven 80+ percent wide area bandwidth efficiency by utilizing three core concepts: structured data access, a global file system and Remote Direct Memory Access (RDMA).16 Structured data access provides global data ingest and direct file access; as soon as data is ingested into the Large Data domain, users anywhere searching the domain will have access to the ingested data. The global file system organizes storage nodes and the data that resides there via a Lustre file system in order to smartly stage data. The RDMA interconnect is based on the Infiniband architecture that has been used inside data centers but not previously deployed in a WAN configuration.17

Taken together, the Large Data JCTD technologies have demonstrated an efficiency increase of up to 80 percent over existing circuits by improving the bandwidth management as well as the bandwidth utilization. Even without enhancing the baseline DISN service, the NTWAN usable bandwidth increases from 62 Mbps to 124 Mbps – double the capacity. When coupled with an enhancement of the baseline service to 10 Gbps service, the NTWAN could move one terabyte in 17 minutes, rather than 39 hours.18 NTWAN would then be capable of Gbps-class mission critical service for all tactical data shore C2 and ISR nodes such as MOCs, TOCs, METOC centers, etc.


a) Provide tactical mission critical WAN capacity for MCD architecture by integrating NTWAN into MCDs and increasing transport throughput to the 10 Gbps class service.

b) Investigate alternative protocols and mechanisms as proven by the Large Data JCTD and recommend solutions to provide more effective use of available bandwidth.

FINDING HPA-7:

16 Large Data JCTD Report on Operational Utility Assessment NSAD-R-2009-199R, 2009

17 Ibid.

18 Ibid.


[32]

Current plans call for two TOCs, both likely to be in the continental United States, and multiple Mobile TOCs (MTOCs) deployed as needed worldwide. The plans have estimated that a single P-8A sortie can generate between five to eight terabytes of data that can be offloaded from the aircraft via a data transfer device (also referred to as a “brick”). As multiple P-8A sorties are flown each day, the total amount of data that will need to be stored will accumulate. With aggregate data volumes that will easily approach the petabyte range in short order, the TOCs will have to stand up a data management corps just to effectively maintain the data. The problem is exacerbated when data is stored at the MTOCs, where connectivity is inconsistent and possibly intermittent.

Similar data and information staging occurs at other ashore facilities such as FIOC, FNOC and METOC locations. Access to high performance network bandwidth and large data processing infrastructure enhances capability in each of these domains through multi-INT sharing and analysis. Rather than devote personnel at each location to manage, process, and store data, high capacity connectivity allows for the transmission of data to a central store, with a corresponding consolidation of processing and storage infrastructure, personnel, training and expertise.


a) Connect MOC, TOC, FIOC, FNOC, and METOC centers to the Intelligence Community and/or NTWAN network infrastructure to enable sharing and distributed storage of data across the Naval C2ISR MCD architecture.

FINDING HPA-8:

Google is an excellent comparative example of the fusion required to execute something as grand as the Navy’s Information Dominance vision. Google provides a central point for searching disparate data sets (text, images, video), offers communication services (Gmail), and provides a visualization tool (Google Earth). Additionally, Google archives documents (Google books) and provides a rudimentary translation service. In order to do all of this in a seamless fashion, Google has committed to making substantial investments in its infrastructure.

Some estimates place Google as the fourth largest computer manufacturer in the world; but unlike vendors such as Dell or HP, which manufacture computers for resale, all of Google’s computers are for internal use. It has been estimated that Google operates approximately 451,000 servers, requiring 20 megawatts of power at a monthly cost of $2 million. This entire infrastructure is required to simply process and transfer the Exabytes (1018 bytes) of data that Google handles on a weekly basis.

In order to maintain Information Dominance during this decade and beyond, critical C2ISR information requires that the Navy step up to a Google-type data center. As the volume of ISR sensor data expands, the ability to navigate the disparate data sets will be a crucial enabler for the limited manpower tasked with providing analysis. Maritime data will become a critical enabler of future joint and homeland security capability, but only if the data can be processed and shared. In addition, putting this type of infrastructure afloat is unfeasible. Even at a basic level, force-level ships will not always be available to provide the needed continuity of operations when, they are laid up for maintenance or repair.



[33]

a) Implement processing and storage capability in the MCD data architecture to support near term petabyte/exabyte class capability with the ability to scale to meet future requirements.

FINDING HPA-9:

Naval C2ISR processes can be improved through the use of multi-INT fusion capabilities enabled by JDISS, IMA, I2 Pilot and other information sources. Currently, the Navy maintains a de facto federated intelligence process to support the operational Fleet. The Fleet Imagery Support Team (FIST/FID) and the Fleet Information Operations Centers (FIOCs) use similar processes to conduct Fleet support for IMINT and SIGINT. However, the various intelligence disciplines, though using similar processes, are not well coordinated from an all-source production and cross-cueing perspective. The Maritime Operations Centers (MOCs), though equipped with intelligence staffs, have no homogenous systems and methods across the fleet commands (??). Only one MOC currently conducts first-phase imagery exploitation in support of ISR. Efforts must be made to ensure FIOCs and FIST/FID efforts are properly synergized to the maximum extent possible. Ashore MCD data nodes may offer the best primary source of shared naval ISR data.


a) Some sort of centralized all-source node (MOCs or other) should be established to ensure proper fusion and coordination with the greater national Intelligence Community. Migrate DEN, IMA and I2 Pilot data processing and analysis tools into an ISR capability for the DoN that enables data sharing within national, joint, and coalition sources. Centralized all-source nodes should be codified to take advantage of current intelligence investments (bandwidth, storage, etc.) while simultaneously ensuring Fleet support is accurate and properly coordinated across all the various intelligence disciplines.

b) Develop roadmap/action plan to migrate ISR capabilities into the MCD architecture consistent with the Information Dominance principles. Close coordination with the IC is recommended to see if DoN can leverage existing infrastructure, rather than reinvest along a duplicative path. The DoN’s full TC-PED (Tasking, Collection – Process, Exploitation, Dissemination) should be considered when mapping out optimum architecture paths.

FINDING HPA-10:

National agencies are currently implementing high performance architectures to facilitate data discovery and access to leverage remote processing and storage capabilities. The national agencies have understood and appreciated to a higher degree the implications of diverse sensor employment and the resulting data explosion. In anticipation of the exponential growth in data volume, they have established data centers and the requisite bandwidth required to connect them with the analysts that need the data. In addition, emerging network technology such as the Large Data JCTD can increase bandwidth efficiency over existing lines, as well as enable analysts to open and modify files from remote locations before they are fully downloaded. Finally, remote staging of data via services like the GCDS service provided by Akamai for DISA can drastically reduce the bandwidth requirements for remote users.

Many of the agencies are also openly soliciting data from the services, offering archival services for almost all collected data. For example, NGA will archive imagery for five years; at the end of five years, it will allow the services to review the data and indicate whether it still needs to be stored or


[34]

can be deleted. As a result, the amount of data that a single service needs to store can be vastly reduced and more effectively managed. The Maritime Centers of Data (MCD) can focus on storing DoN-specific capabilities, instead of DoN-specific products. For example, an image of a vessel of interest can be stored at an NGA data facility, while sonar data would be archived at an MCD.

Given high performance networks, reach-back for national data and related data pointers can be a cost and performance effective way to improve warfare capability.


a) Preserve processing and storage infrastructure by adopting access into national agencies for all data not required to be stored within the MCD architecture.

FINDING HPA-11:

Manpower levels are expected to be a fixed limitation for the foreseeable future, so it is crucial to develop a plan that maximizes the aggregate output of Navy analysts. Rather than segregate analysts into separate communities and according to discipline (imagery, signals, cryptography, etc), establishing centers where these analysts are collocated facilitates multi-INT fusion. Overall knowledge of intelligence disciplines can cross-pollinate, and as analysts’ tours overlap, training and expertise will increase and local organizational knowledge will have more continuity.

Analyst tools require data access as well as the bandwidth to move data and the resulting information. Although the global terrestrial backbone is fairly robust, adding nodes can be expensive and time consuming. Additionally, synchronizing system upgrades across multiple sites often takes years and creates interoperability issues. Shared data is also more useful when viewed by multiple analysis disciplines, and efforts to cue sensors in support of real-time tasking can benefit as analysts learn to appreciate the capabilities and limitations of other disciplines. Sensor platform employment, target prioritization, and ISR CONOPS development would all benefit from the cross-discipline approach.

Consolidating data processing and analysis provides savings that offset the MCD architecture costs. Enterprise computing environments, reduced circuit costs, and fewer personnel rotations are some of the savings that could be realized in support of establishing the MCD.


a) Concentrate ISR analysts to take advantage of ashore MCD infrastructure in order to more directly support warfare operators at MOCs, large decks, group- and unit-level ships.

b) Develop and/or leverage enterprise social collaboration tools ISR analysts can employ and utilize wherever they are located.

c) Sensor platform employment, target prioritization, and ISR CONOPS development would all benefit from the cross-discipline approach.


[35]

4.3. CRITICAL AFLOAT ISR GATEWAY CHALLENGES

Large-deck ships, for the most part, have the resources and opportunity to use relatively sufficient bandwidth access, network infrastructure, and moderately sufficient computing resources to support effective ISR through cloud computing or information technology services. These resources will continue to evolve through the DCGS-N acquisition program and related DoD DCGS family of emerging capabilities. Force-level platform capabilities will soon provide the bandwidth, throughput, capacity and tools for serving as the ISR gateway between the ashore and afloat clouds. The ashore cloud is NOT a central, consolidated or singular database server, of course – rather, a well-orchestrated set of scalable hardware and software services and infrastructure ensuring the right data is made available to authorized users within the service-level agreements of time/performance established to support the users’ various roles and on their various end-devices.

CANES provides afloat network and micro-cloud computing infrastructure that facilitate semi-independence between C2ISR application evolution and the network or computing infrastructure supporting those applications. Global Command and Control System-Maritime (GCCS-M) and DCGS-N are evolving programs capable of delivering effective C2ISR capability afloat while taking advantage of high performance ashore C2ISR support. The cloud of computing services and information is dynamic, adding capacity when and where needed (based on priorities and budget) reaching out to the tactical edge where content is staged just once by any of a number of major content providers including DCGS-Enterprise ashore. Architectural decisions are made to enable afloat users or their supporting software services to discover the exposed data and deliver or make notification of options for delivery. Actual transfer of data will be defined through prioritization and dynamically managed to optimize use of available bandwidth. The sheer volume of data will be the initial challenge; however, this requires evaluating options for reducing the total volume and automating some of the processing. Another challenge is defining and implementing governance of the mechanisms required to appropriately control the “publish and subscribe” functions within the situational-awareness enhancer.

The overarching challenge is efficiently and effectively delivering afloat and ashore-derived ISR products to support the combined naval, and ultimately Joint, operations in the face of the full range of operations whether they are deterrence, power projection, offensive operations or humanitarian assistance/aid.

FINDING AG-1:

The current paradigm of “produce afloat, push ashore” pre-dates net-centricity and violates key net-centric principles by assuming the afloat producer knows exactly what information is “best” for the rest of enterprise. The current paradigm does not, however, process the data closest to collection, disseminate distilled information instead of raw data over bandwidth from afloat nodes, articulate dynamic priorities for collection and exploitation, focus on tactical needs, nor understand impacts of netted sensors on the afloat gateway. A single, consolidated and orchestrated approach is needed, one focused on the ship to shore exchange of discovery metadata to “inform” consumers of available services, while simultaneously “requesting” only pertinent information from the ships.

This fundamental “publish and subscribe” ontology is foundational to a service-oriented architecture. It will optimize actual data requests, make appropriate services available to all joint task force entities, and make the most appropriate updated and timely data transfers maximizing


[36]

data exposure while minimizing the “push” of unwanted data through the “knowledge chokepoint.” Careful consideration must be given when determining appropriate smart data management options to ensure appropriate information disclosed is, in fact, received by the correct user and at the right time. Crucial governance is needed to define these capabilities in detail. If overlooked, the “knowledge chokepoint” becomes constrained, further limiting the employment of our military resources and ultimately limiting the nation’s offensive and defensive capabilities. With already realized and further planned reductions in afloat manpower, the addition of a significant number and variety of persistent, multi-sensor, multi-mission UxVs will make getting information “across the seawall” barrier more difficult.

RECOMMENDATION AG-1:

a) Create single ship-shore Information Dominance Corps governance (data exposure, discovery, and retrieval) integrated product/process team (IPT) to optimize the use of ship-to-shore data interfaces.

b) IPT membership or multiple IPTs must include all stakeholders across the Naval Enterprise as well as the appropriate joint communities.

c) Governance must not only address technical data issues, but must also address programmatic and fiscal issues, policies and procedures across all necessary organizational boundaries, ultimately enabling the appropriate free flow of information. Consider assigning a seasoned fleet knowledge manager as the IPT leader.

FINDING AG-2:

The physical laws of nature, space segment costs and technical constraints, limited research and development efforts, and other RF-limiting bandwidth considerations uniquely constrain each afloat unit. In comparison to its terrestrial counterpart, the global maritime environment essentially reduces naval afloat resources into a functionally distinct information “sub-enterprise” with its inescapable attendant restrictions, operational considerations and employment constraints.

As a distinct information “sub-enterprise”, each afloat unit should be coherently architected as an “independent information enterprise” with the ability to continue the full range of military operations when disconnected from shore-based resources. The independent nature of these afloat “sub-enterprises” dictates the need for continued and uninterrupted technical capabilities whether or not the afloat unit is on an independent mission or an assigned joint task force member. These afloat “sub-enterprises” must also be required to monitor against, recognize, defend and attack appropriate cyber threats to maintain operational mission capabilities.

Each “sub-enterprise” platform must also be able to operate like an information services cloud, transparently managing content and making the appropriate content available to the appropriate users (i.e., sharing all manner of metadata, associated schema, and data indexing). Additionally, these collaborative requirements also apply to the full range of mission areas and the data that supports them (e.g., ISR, C2, Strike, ASW, ASuW, Amphibious Warfare, SOF, TAMD, IO, METOC, etc.)


[37]


a) Implement technical requirements, standards implementations, data exposure, and interoperability testing to enforce coherence across the entire afloat unit “sub-enterprise.”

b) These technical requirements must be supported by governance, fiscal, organizational, training, doctrine, manpower, testing and facilities to realize the full benefit of moving to a Wave 3 environment.

FINDING AG-3:

Split IP capability aims to improve upon previous GBS capability by supporting small, outgoing bandwidth requests while providing large GBS bandwidth capabilities for returned information feeds. This concept of varying upload and download speeds has long since been recognized through many network usage studies which show uplink speeds are very small in comparison to download capabilities since user data uplink activities are more often requesting information rather than delivering information. The downlink reply to those requests is usually quite large in comparison (e.g., web sites with multimedia content, downloads of pictures, large files, etc.).

With current Internet and common usage patterns, this Split IP concept supported by current GBS capabilities maximizes the download bandwidth while minimizing bandwidth used for small uplink requirements. GBS Split IP capability is the best, most cost-effective and readily available near-term bandwidth solution for delivering high-volume download data bandwidth in support of afloat operations without compromising the small data uplink requirements. The broadcast downlink is currently capable of a much broader bandwidth capacity supporting the large data sets that return from relatively small requests.

Despite over a decade of reliable GBS SATCOM availability, GBS is unfortunately not routinely used to alleviate ashore/afloat communications constraints. Although large DoD investments have been made in GBS, it is still not fully exploited to augment SHF, UHF and other SATCOM capabilities. Even if traditional SHF or UHF Follow-On satellites were providing adequate bandwidth today, it is clear from empirical data (and the requirements for new satellites like Wideband GapFiller, etc.) that DoD and DoN are reaching the current capability limits of SATCOM. Some operational users would contend constrained SATCOM capabilities already hamper operational warfighting methods capabilities. With large national and joint data sources, GBS is extremely well positioned provide a natural, cost-effective asynchronous communications resource aligned with Wave 3 technologies.


a) Maximize and optimize GBS use for shore-to-ship data transfer to alleviate pressure from ship-shore requirements and significantly open up the “knowledge chokepoint.” In concert with this, comprehensive training should be given to all appropriate personnel and the Fleet should adopt widespread operational use of GBS immediately.

FINDING AG-4:


[38]

Current economic and technological advances have progressed to a point where a petabyte of storage costs approximately $100,000 and is contained within two standard equipment racks. Using a reasonable number of equipment racks, large deck or capital ships are fully capable of locally supporting data intensive services afloat with minimal equipment requirements. Economic factors have combined to make information technology resources affordable and ubiquitous, while the approach to ship-to-shore communications must be mitigated by “rationing” to only the absolutely necessary.

Unfortunately, it is anticipated that non-terrestrial bandwidth exceeding 50 Mbps will not be widely fielded for many years to come despite advancements in technology, compression, and encryption. Therefore, large deck ships must support full-spectrum missions through onboard, autonomous data centers. In the past, the afloat community was justifiably concerned about cost (in both fiscal and real estate terms) of storage configurations afloat, so they encouraged applications to be very thin. Today, the afloat community can have petabytes of storage for under $100,000 in two racks and, as a result, bandwidth has replaced storage as the scarce resource. The bandwidth available to large decks has increased to 50Mbps - a major improvement in just a few years, yet not enough to support unconstrained ship-to-shore communications.


a) Equip large deck ships with enough computing and storage infrastructure to serve as afloat C2ISR data centers capable of autonomous “at sea” operations. Overarching governance will need to be designed to minimize ship/shore transactions. The afloat data center will serve as a local strike group or joint task force afloat repository and will manage local content, synchronizing content with shore (given defined and modifiable rule sets) while minimizing duplication of data or requiring unnecessary use of network and communications assets. Efficient and effective afloat autonomous data center management will include establishing policy for limiting subscription notification for non-time–critical data to receipt of alerts or tags from shore content managers and translation of those tags/alerts into meaningful notices to the subscribers, who will have options for how and when to download data. Critical data will be sent per priority and established business rules, and the determination of what data is critical will have to be addressed in governance/policy.

FINDING AG-5:

The Distributed Common Ground System-Navy (DCGS-N) is a program of record established, resourced and funded to be the Navy’s “common ground/surface system” for ISR asset visibility and management. The potential opportunity still exists for the Navy and DCGS-N program office to recapture its original vision; unfortunately, the current program management and acquisition path DCGS-N is on will not achieve this goal.

Through changes in technical, program management and acquisition approaches, DCGS-N should provide a Navy-wide common set of tools, services, and processes enabling ISR asset visibility, ISR asset management, data ingest and exploitation, intelligence analysis, and collaborative data exposure for discovery and exploitation across Navy, joint and coalition C2 and ISR enterprise stakeholders.


[39]

These Navy, joint and coalition C2 and ISR enterprise data discovery and exploitation efforts must be supported by a collaboratively governed “ISR consortium” approach across these enterprises rather than the “single program, single systems command” approach currently used. This collaborative “ISR consortium” must expose, exploit and take full advantage of Army, Air Force and other agency developed ISR tools, and aggressively seek new and innovative ways to collaboratively employ them to increase warfighter effectiveness and efficiencies in target identification and prosecution.


a) This finding strongly recommends that DCGS-N undergo some technical, programmatic and acquisition updates to fulfill the originally envisioned common surface ISR gateway. These changes must aggressively and collaboratively implement DCGS-N as the common surface ISR gateway between ashore and afloat assets, across the naval, joint and coalition ISR enterprises for the full spectrum of warfare. As such, DCGS-N will become the naval ISR focus for all afloat ISR mission needs.

b) Aggressively pursue a governed ISR consortium approach amongst all naval, joint, coalition and government agency ISR enterprise stakeholders to ensure DCGS-N is augmented with new and innovative ways to collaboratively employ ISR resources across a common set of tools, services and processes for all ISR tasks with the sole purpose to increase warfighter effectiveness and efficiency in all ISR mission areas.

FINDING AG-6:

The DCGS Enterprise Integrated Backbone (DIB) has a significant amount of engineering, utility and capability and is used across all DoD services and government agencies. The DIB is commonly considered to be a mature ISR service amongst a large percentage of ISR domain stakeholders. The DIB is widely used across DoD to perform ISR metadata tagging, enabling ISR data exposure and discovery. Additionally, the DIB is used to multicast appropriate metadata or user-defined data to the appropriate users, minimizing unnecessary transmission of similar data as well as the transmissions of data to unnecessary end users.

The DIB metadata framework is mature and robust enough to provide a useful, commonly accepted or de facto DoD capability framework for ISR tagging, search, discovery, utilization, dissemination, delivery and exploitation services for all ISR domain stakeholders. The DIB enables exposure to and discovery of structured data and/or ISR products that can enable and improve intra- and inter- strike group operations.

Another main advantage of the DIB is its ability to facilitate the significant egress reduction of afloat ISR data by publishing only tagged metadata. This metadata tagging reduces not only transmission time or product discovery time, but also provides for wider search criteria and greater capabilities while making better use of ISR data or products already in the database, thereby reducing the collection requests/overhead or making much better refined or narrowly focused requests. Requested afloat ISR data can be multi-cast and delivered from the strike group or joint task force no more than once using this effective data architecture. Tagging and appropriately disseminating metadata increases ISR data product efficiency and effectiveness possible.



[40]

a) Implement the DIB metadata framework on all large deck and capital ships to establish an efficient way to support data exposure, dissemination, and exploitation while minimizing unnecessary data transfer by enabling metadata tagging and discovery and increasing the effectiveness and efficiency of sharing afloat originated data. By implementing the DIB metadata framework afloat and integrating it with the ashore infrastructure, there will be a standardized ISR architecture, better positioned to gain efficiencies and provide improved warfighting operational support through a naval, joint, coalition and government agency supported ISR architecture.

FINDING AG-7:

In the world of collaborative planning and integrated ISR products across specialties, topical areas, risks, threats and requirements that span many different organizational and technical boundaries, data security continues to be a barrier to effective and efficient use of data, limiting our ability to maximize support to the warfighter in an operational, time critical manner. Data security further constrains data sharing, discoverability, exploitation and dissemination on each afloat unit due to the requirement to maintain multiple security enclaves within the skin of the ship. These multiple security enclaves prevent collaborative, synergistic sharing and employment of data while simultaneously creating unnecessary burdens on other technical, fiscal or human capital resources to constantly overcome these artificial security protections.

Unnecessary security constraints continue to be a major challenge to DoN knowledge distribution, use, employment, exploitation and refined data analysis, particularly on large deck and capital ships. These rigid security constraints ultimately translate into increased costs for all ISR stakeholders. The operational support warfighters require agile, collaborative and multidisciplinary responses to counter time-sensitive, extremely precise and asymmetric targets. These kinds of responses and data require a much more robust, fluid and dynamic approach to the employment of available ISR national resources. This approach to ISR data and resources demands that security barriers must be the limited exception and not the general rule to prevent users in one security domain from discovering data and products in other security domains. This cross-enclave collaboration is absolutely critical to employing all available DoN, joint, coalition and government agency ISR resources in the most cost-efficient, collaborative, effective and time-sensitive manner possible.


a) Develop and govern the implementation of a complete set of collaborative security policies and directives that encourage and support data discovery services across afloat security enclaves common to all mission areas and security enclaves.

b) Governance should ensure common security and discovery services are applied across enclaves, wherever possible.

c) Support and invest in cross-domain security enclave technologies to allow discoverable, integrated and exploitable data while maintaining underlying security restrictions, where absolutely necessary.


[41]

FINDING AG-8:

As ISR service capabilities grow and continue to be extremely data intensive, it is not clear how strike group platforms view their mission, or tactics, techniques and procedures (TTPs), or how their missions align among other DoN and DoD sensor grid participants. In particular, potential ISR tasking may not be of immediate use or the requirements known to the ship, strike group or joint task force asset, but will be required to support combatant commander tasking.

To be mission-effective and resource-efficient, TTPs must be planned, coordinated, taught and trained in a cohesive manner across the entire ashore and afloat communities.

TTPs that embrace Information Dominance principles must be inclusive to Ship’s Signals Exploitation Equipment, combat systems, traditional ISR activities and METOC while being sufficiently flexible and adaptive to accommodate new mission, targeting, surveillance, intelligence and reconnaissance opportunities enabled by new sensor and platform types.

There are no standard ISR TTPs for integrated sensor grid operations. The critical need for standard ISR TTPs for integrated sensor grid operations will become more evident as the amount of ISR data begins to move up the exponential curve, thus becoming untenable.


a) Develop and implement a complete set of afloat ISR TTPs that enable the large deck/capital ship and associated platforms as part of the larger naval sensor grid. Rather than wait and continue to struggle through ISR missions without TTPs, an effort should begin in earnest to define, document and operationalize a set of appropriate afloat ISR TTPs for strike and expeditionary group ISR, creating more effective and efficient operational employment of the nation’s sensor grid assets.


[42]

4.4. CRITICAL SMALL SHIP ISR (SS)

Tactical afloat units have become increasingly capable, but don’t necessarily receive parallel C2ISR system/software capability suites that allow them to maintain advantage over their adversaries at the tactical edge. The limiting factors remaining are bandwidth and manpower. In iterative budget cycles, the investments needed to leverage these units have not been made.

The use of embarkable carry-on packages that can be deployed on an as-needed basis, supported by a small group of trained personnel, is a viable option with the advances that have been made in processing, storage, and portability. This concept maximizes the expertise and proficiency of the ashore community by concentrating capability at the right time, in the right place, and in support of the right user. Independent teams of Information Dominance Corps (IDC) specialists can provide a greater all-source perspective and capability to our command staffs at the smallest unit level.

FINDING SS-1:

CG, DDG, LCS, detached staffs, and NECC units have limited access to non-organic ISR services to support mission activities across all levels of warfare. DCGS-N installations are limited to large deck ships; in its current configuration, the size, weight, and power requirements do not lend itself to installation in a unit-level ship or as an embarkable system for an expeditionary force. Unit level ships do not always conduct missions requiring use of full DCGS-N capabilities, so it may not make sense from a cost perspective to pursue a full fielding plan.

In addition to capability gaps in receiving non-organic ISR data, small units are also unable to expose data derived from organic combat systems, including embarked SH-60 or unmanned vehicles, to the ISR enterprise. One reason is due to the disciplined segregation of the Combat LAN from other aboard-ship LANs. Although this was done to prevent weapon-related mistakes, the downside is impeded ISR information flow. The bigger issue, however, is the absence of an ISR data processing and transmission capability. Most of the ISR-related data derived from organic Combat systems are transmitted via voice or text reports, with the actual raw data transferred at a later point in time (if at all) for further exploitation by analysts. In some cases, the latency injected into the PED process for this data has negative impacts on mission effectiveness.

Small units are also not manned with appropriate manpower or skill sets to provide analysis of organic sensors and ISR fusion/correlation activities of organic/non-organic ISR data. Training, manning, and space limitations prohibit effective employment of a full DCGS-N suite aboard a CG or DDG class ship, where ship’s manning normally include only one or two Intelligence Specialists (ISs). These ISs have specific duties in support of the ship and may likely not have the formal training necessary for the exploitation and analysis of specific ISR sensor outputs.

RECOMMENDATION SS-1:

a) Develop and deploy a DCGS-N Intel Carry-On Program (ICOP) scalable capability with detached operators for unit level forces (CG, DDG, LCS, detached staffs, etc.) to enhance organic capability and to provide organic data back into the MDI.


[43]

FINDING SS-2:

Historically, combat systems afloat have been segregated from other LANs for various reasons: testing requirements, certification and accreditation, survivability, mission assurance, classification levels, information assurance and system implementations designed to support specific capabilities not necessarily readily interoperable with other LANs.

Although done for good reasons, this architecture often prevents efficient integration of non-organic ISR data into the ship’s combat system to support the kill chain. The interface between the C4I LAN and the combat LAN is often just a messaging service, not equipped to deal with the diversity and volume of ISR data. Additionally, reducing ISR data into a message can strip the value it adds to a Common Operational Picture or Common Intel Picture, removing its contribution to a targeting solution. Conversely, this architecture also prevents exposure of organic sensor and ship’s combat system data to the ISR enterprise by limiting outgoing data to the same message script restrictions applied to incoming data.

The capability to offload combat system data to inject relevant non-organic ISR data into the combat system could be achieved via gateway interfaces. Changing AEGIS weapon system baseline configurations is expensive and time-consuming; however, developing a gateway to take advantage of specific combat system interfaces without changing the overall combat system reduces the acquisition burden almost to a strictly Certification and Accreditation level, outpacing a combat system baseline upgrade by years.

Using Global Broadcast System asynchronous communications could provide good bandwidth support from ashore to afloat units and augment afloat operators with national and joint information responsive to unit level requests.


a) Expose off-board data to ship combat systems and ship combat systems data to the DCGS-N network via an Intel Carry-On Program (ICOP).

b) Include ship organic systems (e.g., helicopter, unmanned systems).

c) Use gateway interfaces between combat systems and ICOP to avoid integration issues.

FINDING SS-3:

Disparate management of personnel, supporting systems, and pre-deployment preparations blunts the synergies of ISR analytic teams.

ISR personnel are generally considered to include intelligence specialists and cryptologic technicians. Historically, the intelligence specialist rating focused on analysis of sensor products, especially imagery, in support of pre-mission preparations such as developing validated target lists. With the advent of digital imaging, reduced processing times and Full Motion Video, this rating has become more involved in real-time mission execution.


[44]

The CT rating contains specialties, with the three most relevant specialties for this discussion being the CT-Collection (CTR CTC?), CT-Technical (CTT) and CT-Interpretive (CTI) specialties. Together, these specialties focused on electronic warfare and signals intelligence to include analysis and exploitation of foreign language materials.

Due to the differing nature of their specialties, intelligence specialists and cryptologic technicians have different training tracks, are trained at physical locations separated by hundreds or thousands of miles, and associated with differing communities in the Information Dominance Corps (IDC). This results in sub-optimal employment of the aggregate ISR personnel assigned to a given task force,since they are deployed to support carrier / expeditionary strike group activities by separate processes and are not trained as a cooperative direct support element. This degrades readiness, prohibits effective cross-cueing or collaborative sensor employment, and impedes long-term development and evolution of ISR doctrine and CONOPS.

The systems utilized by the IS and CT personnel are inherently different, and as a result are managed/supported by dissimilar processes. There are multiple program offices and agencies developing IMINT or SIGINT support systems and LANs, not to mention the diversity of sensors that IS and CT personnel must be ready to support. A further issue that arises from this situation is that ships’ pre-grooming activities are not coordinated between intelligence and cryptologic systems.


a) Combine CCOP and ICOP hardware services.

b) Combine intelligence and cryptologic direct support services into a single program and deploy as a single team.

FINDING SS-4:

Ships are still required to utilize SATCOM connectivity and an ashore infrastructure to support afloat networks, even when ships are within each other’s line-of-sight. This places somewhat redundant and unnecessary bandwidth demands on the SATCOM architecture and also becomes a vulnerability in a satellite-denied environment.

Communications packages are small enough to deploy on most airborne manned and unmanned platforms. One S&T initiative demonstrated that multi-purpose airborne payloads, in addition to networking capabilities, can provide SIGINT and relay capabilities as well. The payload can be integrated as an internal assembly or attached to a hardpoint. In hard-point configuration, the total weight is less than 25 pounds, including the air case.19 If launched on an organic UAV, afloat networking ranges increase significantly by using an organic beyond-line-of-sight (BLOS) relay capability that mitigates the risk of SATCOM loss.

In addition to DoD initiatives, commercial directional antenna technology is revolutionizing rural commercial Wi-Fi capability and could be applied to naval platforms. The addition of Wi-Fi and Wi-Max technologies offers the promise of relatively large bandwidth to afloat operations, allowing increased intra-battlegroup networking and better use of BLOS communications. This in turn would also allow for maximized leveraging of ashore capabilities by increasing available bandwidth

19 Naval Research Laboratory’s Deep Lightning Bolt Program, Software Reprogrammable Payload.


[45]

for classified data or communications. Such a system could connect to commercial Internet service providers to create an alternative communications path to targeted DoD and naval enterprise networks.


a) Develop line-of-sight network between ships and aircraft to provide ROWC2 fail safe and to reduce SATCOM bandwidth challenges.

FINDING SS-5:

Netted sensor activities add value by using existing sensors; a diverse deployment of sensors can produce higher quality contact than simply fusing or correlating data link reports via individual platforms. Direct sensor netting can shrink a given contact ellipsoid by triangulating sensor outputs deployed from different azimuths.

Using add-on modules, existing sensors are capable of supplying data hidden in normal combat system modes. For example, netting different surveillance radars with different capabilities (height finding versus azimuth, for example) could produce contact reports that radar alone would not be able to produce, such as the disposition of an aircraft formation. In addition, geographic diversity among netted sensor participants has improved detection and targeting capability for relatively low cost, since netting a diverse array of existing sensors is often less expensive than developing and fielding a single sensor that incorporates multiple capabilities. Even if such a sensor were developed and deployed, environmental conditions (such as terrain, buildings, or weather) could still compel the sensor deployment in multiple locations.

Augmenting netted sensor capability with ashore ISR services can provide additional value to time-sensitive detection and targeting missions. Increased fidelity in target reports allow collection managers to more efficiently employ their ISR assets since a traditional cueing report might require the use of ISR assets to localize a given contact. ISR assets that would have otherwise been used to further refine its location can be allocated to other missions.


a) Enable the Netted Sensor Grid to improve mission capability of ship/aircraft task forces.


[46]

4.5. CRITICAL INFORMATION ASSURANCE (IA)

Current IA certification processes ensure C2ISR capabilities cannot pace the need; separating IA certification between infrastructure and applications can radically improve this situation. Role-based access control technology is close at hand and using this technology improves one of the most significant issues facing IA operations. Virtual Secure Enclave architecture technology has been red-team-challenged during the past three Terminal Fury events and passed with flying colors; it is time to begin implementing this near-term IA solution.

The following citations articulate the concerns associated with current IA processes in delivering relevant and timely C2ISR capabilities.

DEFENSE SCIENCE BOARD ON IA

Warfare Commanders: “We are no longer network enabled. We are now network dependent.”20

“The task force reached an overall conclusion that without an integrated net-centric/cyberspace plan, threats from cyber-intelligent adversaries represent a clear and present danger to U.S. national security.”21

“The primary finding in this study is that the major impediment to attaining an assured joint DOD and interagency interoperable net-centric enterprise is governance—the ‘who is in charge?’ issue.”22

NAVAL STUDIES BOARD ON IA

“At the request of the Chief of Naval Operations, the Naval Studies Board, under the auspices of the National Research Council (NRC), established a committee to examine a wide set of issues associated with information assurance (IA) for network-centric naval forces. Owing to the expansion of network-centric operating concepts across the Department of Defense (DOD) and the growing threat to information and cyber security from lone actors, groups of like-minded actors, nation-states, and malicious insiders, information assurance is an area of significant and growing importance and concern. Because of the forward positioning of both the Navy’s afloat and the Marine

20 Defense Science Board; Creating an Assured Joint DOD and Interagency Interoperable Net-Centric Enterprise,

March 2009

21 Ibid.

22 Ibid.


[47]

Corps expeditionary forces, IA issues for naval forces are exacerbated, and are tightly linked to operational success.”23

“As part of its implementation of network-centric warfare capabilities, the Department of the Navy is aggressively embracing integrative COTS technologies such as service-oriented architectures in order to take advantage of potential positive benefits, including wider information availability. However, these adaptations also have the potential to introduce new and possibly serious IA risks into naval systems. Unfortunately, existing naval systems do not appear to have been designed with consideration of the collateral IA risks as a foundational system attribute.…manage system developments using sets of IA principles that are explicitly specified and required to be incorporated into the naval forces enterprise architecture, including specifically addressing the IA requirements of service-oriented architectures.…”24

“The four cyberspace IA-related domains of protecting, exploiting, attacking, and intelligence do not appear to be closely integrated in the DoN. In particular, the Department of the Navy does not appear to be aggressively considering and assessing alternatives to gain greater IA advantages through such integration.… The Office of the CNO and the Office of the CMC should consider approaches for reducing the separation and enhancing the integration across emerging offense, defense, and intelligence organizations related to IA.”25

FINDING IA-1:

Below are examples from three recent press articles:

“Militants in Iraq have used $26 off-the-shelf software to intercept live video feeds from U.S. Predator drones, potentially providing them with information they need to evade or monitor U.S. military operations. Senior defense and intelligence officials said Iranian-backed insurgents intercepted the video feeds by taking advantage of an unprotected communications link in some of the remotely flown planes' systems... The stolen video feeds also indicate U.S. adversaries continue to find simple ways of counteracting sophisticated American military technology. In the summer 2009 incident, the military found "days and days and hours and hours of proof" that the feeds were being intercepted and shared with multiple extremist groups, the person said. "It is part of their kit now."26

“Drones aren't the only U.S. systems that transmit unencrypted video signals. The military's … ROVER… is part of a widely used system that allows drones, helicopters and planes to transmit live video footage to nearby troops on the ground. Former military officials say the signals aren't encrypted, leaving tactical information

23 Naval Studies Board: Information Assurance for Network-Centric Naval Forces; March 2009

24 Ibid.

25 Ibid.

26 Insurgents Hack U.S. Drones, Wall Street Journal, Dec 17, 2009.


[48]

vulnerable to interception and deception. One drone used in Iraq and Afghanistan is the Scan Eagle, not currently encrypted, according to a person familiar with the matter.”27

“The military initially developed … ROVER, in 2002... Since then, nearly every airplane in the American fleet … has been outfitted with equipment that lets them transmit to ROVERs. Thousands of ROVER terminals have been distributed to troops in Afghanistan and Iraq. But those early units were “fielded so fast that it was done with an unencrypted signal. It could be both intercepted (e.g. hacked into) and jammed,” e-mails an Air Force officer with knowledge of the program. In a presentation last month before a conference of the Army Aviation Association of America, a military official noted that the current ROVER terminal “receives only unencrypted L, C, S, Ku bands.”28

There have been many plans to start including encryption and HAIPE devices on ISR assets, but few concrete efforts. The Office of Naval Research has already demonstrated small, lightweight, encrypted communication devices designed for UxV implementations.

RECOMMENDATION IA-1:

a) Ensure proper encryption of control signals and data transmissions between all maritime ISR sensors, aircraft, ground stations and all assets involved in producing or disseminating ISR data.

FINDING IA-2:

Virtual Secure Enclaves (VSEs) provide more flexibility and better resource management than a Virtual Private Network (VPN). Although both utilize commercial or Enterprise transport, a VPN requires the user to have dedicated computer resources, which is essentially a point-to-point connection. A VSE still uses external transport but is able to segregate a collection of resources into enclaves, inaccessible from general users but selectively available to authorized collaborators via simple two-person rule architecture implemented using IP-SEC VPN (virtual private network) technology.

COMPACFLT/PACOM are funding virtual-enclave demonstrations seeking near-term solutions to IA challenges. VSE technology has shown potential applicability to the energy and utilities sector as a way to protect against intrusions while allowing the necessary coordination across multiple organizations, geographically dispersed.29 DDR&E supports this work and may stand-up a JCTD to facilitate moving VSE into programs of record. VSE implementations have demonstrated successful capability against red teams during the last three Terminal Fury Exercises.


27 Officers Warned of Flaw in U.S. Drones in 2004, Wall Street Journal, Dec. 18th, 2009.

28 Not Just Drones: Militants Can Snoop on Most U.S. Warplanes, Wired, Dec. 17th, 2009.

29 PACOM/NORTHCOM SPIDER Energy Security JCTD Proposal Brief, February 2010


[49]

a) Implement Virtual Secure Enclaves (within SIPRnet) on ashore and afloat ISR installations to include DCGS-N and DCGS-N Enterprise Node.

FINDING IA-3:

Many existing Cross Domain Solutions (CDS) rely on data-specific or system-specific parameters for vetting and allowing transfers. In some cases, the transfer is entirely manual. In order to safely expedite data transfer across security domains, data should be tagged as closely as possible to the generating source in a manner usable by multiple CDS.

This concept of security tagging is foundational for all IA technology implementations, and not only provides the data necessary for crossing security domains, but can also provide the pedigree needed to establish authoritative data sources. Automating security tagging relieves the burden of security tags as an operator function and enables cross domain security capabilities. This process reduces manpower requirements at multiple sites, facilitates multi-INT fusion, improves situational awareness and ISR sensor allocation, and possibly shortens decision timelines.


Investigate real-time security tagging of all maritime ISR data (both data streams and data products) using the IC-ISM standards.

FINDING IA-4:

Cryptographic Binding (CB) of data establishes a relationship between one or more data objects using cryptography as a mechanism that assures integrity and authenticity. The CB service is based on secure labeling of metadata that is cryptographically bound, and generates a Binding Information File (BIF) containing the information needed to validate a CB. Cryptographic Binding Validation (CBV) ensures the data objects have not been altered either maliciously or accidentally since the CB occurred. This process also ensures the identity of the binding entity can be authenticated.

NSA continues to support CB technology as it offers the potential to separate infrastructure certifications from application certifications, thereby accelerating delivery of new capability. NSA enhancements to the information assurance certification processes and advancements in open, secure and flexible information architectures employ a methodology of CB and Metadata Tagging. This technology and approach to security maintains verifiable relationship integrity throughout the system ensuring the user can trust what they read. CB technologies assure information discovery and provide a fundamental building block to secure open architecture development. CB technologies provide a robust information assurance infrastructure that enables true multilevel secure system processing.

CB technology will reduce overall system costs; reduce certification and accreditation time, costs and risks; is extremely scalable; and provides a very flexible and cost efficient, yet secure, IA


[50]

infrastructure capable of being configured to almost any conceivable physical platform. Elements employing CB can be added or upgraded with minimal impact to deployed systems. This approach also supports reach-back to legacy networks and can incrementally add multiple level security enclaves as needed. This innovative approach to IA infrastructure enables an evolutionary, secure network architecture by allowing affordable security technology insertions when necessary. The technical framework to support this can be added incrementally to support current and future applications. Current CB technology is Type 1, HAIPE compliant and Type 1 for data-at-rest.


a) Investigate the maturity, development, application, and implementation of real-time crypto-binding technology of all maritime ISR metadata to ensure integrity of maritime ISR data and further enable open architecture development.

FINDING IA-5:

NSA’s HAP (High Assurance Platform) Release 1 is certified and currently available for workstation computers. This version provides a secure separation of the kernel on the workstation, ensuring labeled information will not cross security barriers. This version can be purchased from computer manufacturers as an additional software load. This software creates the ability to run multiple security inputs to a single workstation with no risk of information “spillage” from one security enclave to another.

HAP Release 2 and 3 are moving this secure kernel concept into virtualized server clusters (clouds) to support multiple application security levels on the same cloud distributed over many clustered servers. This approach supports the separation of infrastructure certification from the applications hosted within a specific environment. HAP Release 2 can support two simultaneous security enclaves while HAP Release 3 is working to support three simultaneous security enclaves in the 2013 time frame. By using a secure kernel to separate the virtualized computer infrastructure from the applications, IA certification would require less time, cost and be done asynchronously.

This technology is also being reviewed as an opportunity to allow UxV sensor systems to support multiple security levels at the platform source.


a) Investigate opportunities to move HAP IA technologies into PEO C4I programs of record.

FINDING IA-6:

Navy-developed role-based, attribute-based, and authorization-based access control IA technology offers the ability to improve user access and computer-to-computer security in support of services-based architectures.

ONR-funded C2RPC investigations have demonstrated the value of role-based access control but remain concerned about reduced system performance.


[51]

Authorization-based access control offers both performance and access security based upon operational situations and system configuration.


a) Implement attribute/role/authorization-based access control capabilities for controlling user access to all maritime ISR data and analytical services.

FINDING IA-7:

Many cross-domain solutions (CDS) have been developed throughout the DoD. However, they are generally tailored to specific systems and, depending on the security boundaries being crossed, are governed by different agencies or services. As a result, there can be a patchwork of CDS not only between data sources and consolidated processing nodes, but also between different processing nodes themselves.

A high speed CDS is needed to take advantage of high-side multi-INT fusion and support to GENSER (?) tactical operations. The Defense Science Board has endorsed the value of multi-INT fusion, citing the orders of magnitude improvements in localization and identification possible with fused information. In order to achieve these improvements, good cross domain solutions are needed to collect and redistribute fused products to the appropriate security domains.

The ideal location to implement a streamlined CDS strategy is the ashore architecture. Most afloat units receive their ISR data via a single point of entry but ashore systems are more segregated. The establishment of an MCD presents an opportunity to streamline or establish a consolidated CDS solution for the ashore Maritime ISR infrastructure. This could improve CDS implementation between ashore and afloat units enhancing the use of ISR sources and improving tactical operations. Updating the Common Operational Picture and Common Tactical Picture with timely and relevant ISR data, regardless of classification, allows the tactical commander to better allocate resources.


a) Investigate and Implement cross-domain data exchange capabilities at the Maritime Centers of Data to facilitate rapid distribution, replication and storage of maritime ISR data to all appropriate security enclaves.

FINDING IA-8:

Current C&A processes unnecessarily increase risk to warfighters due to the fact that the processes impede timely capability fielding. The current DIACAP processes empower local certification authorities who interpret certification requirements separately and unevenly enforce standards or make different manual evaluations of system risk. Certification reciprocity has been authorized between Navy, Marine Corps, and DISA but is not commonly practiced.

With modern framework-based software development technology, a new application can be built in a matter of weeks, yet can take months, even years, to have it fielded. The process needs to be quicker and more efficient. A warfighter in the field should be able to write a piece of software, take


[52]

it through testing and provisioning, and have it be operational in hours in some cases, rather than weeks, months or years. Even in an ideal programmatic scenario, it will still take months to certify and accredit under the current structure. Certification and Accreditation processes have evolved from bolt-on, piece-meal responses to cyber security concerns originating many years ago. It is an ideal time to revamp the entire process, using technology as an enabler, and make C&A an integral part of all stages of system development, testing and deployment.


a) Pursue developing modular IA technologies that support “Wave 3” separation of processing infrastructure and maritime ISR data services. Implement a truly modular approach to all C&A activities, whereby only the smallest piece of altered software or system component gets re-evaluated. Changing one software application shouldn’t necessitate redoing the entire system accreditation from end-to-end, which is time, resource and cost intensive. NSA High Assurance Program and Cryptographic Binding technologies support separation of infrastructure and application certification processes, offering the potential to better pace the need.

b) Rework entire DIACAP processes to significantly simplify, consolidate and combine roles/responsibilities where possible. Combine or eliminate non value-added intermediaries. Eliminate increasingly unwieldy, confusing and more unresponsive (and costly) C&A processes. Define C&A standards (technical and processes) so the modularity interfaces to other systems, credentials, identity management and accreditation of automated C&A processes are repeatable and verifiable. Leverage increased automation capabilities throughout the entire C&A processes, to include generating the supporting documentation, testing, reporting, and all C&A artifacts, thereby making the processes more efficient.

FINDING IA-9:

Information Assurance is not only a critical combat mission success factor, but critical to the successful mission accomplishment of all logistics, business and support missions of the DoN as well. As a result of an ever-increasing cyber threat environment where threats and attacks become more sophisticated and complex and are performed using a vast array of globally connected assets, information assurance protections, data assurance and the reliability of mission critical applications and data necessitates a robust IA capability. IA capabilities must continue to mature to better protect mission critical applications and data on multiple security levels across national, joint, allied and coalition partners. This increased challenge creates additional operational considerations and opens the door wider to possible security compromises all while potential adversaries improve their destructive and potentially life-threatening capabilities.

The advent of new cloud computing capabilities and service-oriented technologies in a highly mobile and globally collaborative environment presents new and significant IA challenges. The National Research Council’s study on information assurance addresses the potential unknowns and threats associated with service oriented architectures (SOA) and virtualized computing


[53]

technologies.30 The very design principle of SOA is extensibility and flexibility, so SOA is designed to readily interoperate across disparate systems and across various domains. This flexible architecture is an opportunity to deliver better capability to the fleet faster, but it also opens up vulnerabilities not previously considered. The SOA architectural approach is not inherently vulnerable but implementing specific services-based technologies based on otherwise inherently risky (or more easily exploitable) technology creates new vulnerabilities. The same extensibility, flexibility and adaptability derived from dynamic software also presents new opportunities for would-be attackers to inject their own.


a) Establish a new N2/N6-funded “Mission Assurance” program that has a mission to invest in IA S&T, develop, field and operate cross-domain IA capabilities in support of virtualized, services based C2ISR capabilities. This new mission assurance program must leverage joint, DoD and other governmental organizations’ initiatives while exploring new and innovative methods for providing increased IA capabilities to support SOA, virtualized systems and mobile wireless computing devices at all security levels. This program must also consider the supporting DOTMLPF and fiscal requirements of supporting such IA capabilities. This Mission Assurance program must be the designated authoritative source for all IA program initiatives and polices for the DoN across all platforms and organizations.

30 National Research Council’s Committee on Information Assurance for Network-Centric Naval Forces’ study,

“Information Assurance for Network-Centric Naval Forces,” March 2009, Chapter 4.


[54]

4.6. CRITICAL C2ISR ACQUISITION (EA)

Critical challenges with the Department of Defense’s current acquisition processes have proven time and again they are ineffective, over-burdened and overly bureaucratic. The IT acquisition processes must support acquisition practices that enable, not hinder, capturing technology opportunities before they become useless or outdated. The acquisition process must recognize and make efficient and cost-effective accommodations for shared IT infrastructure having to evolve under a framework of effective, collaborative governance and a set of well-defined, rapidly responsive acquisition processes, whereby deployed applications are encouraged to leverage that shared infrastructure.

Another challenge faced by the current IT acquisition processes are the ineffective information assurance certification and accreditation business process costs. These collective time and resource costs increase, by most conservative estimates 50-75 percent, the overall fiscal resource burden of realizing an installed capability. In contrast, a cloud computing or services oriented architecture is dependent upon shared IA certifications and accreditations to protect capability enclaves. In the current IT acquisition process, budgets are built, defended, executed and evaluated in a manner that perpetuates the broken, stove-piped status quo. In contrast, cloud computing or service oriented architecture cannot be delivered within traditional budget profiles. Budgets and funding must be built, defended, executed and evaluated across many organizational boundaries to produce cloud-enabled computing services. The IT acquisition directives and guidelines must recognize IT “services” are not systems in the traditional sense of an autonomous, discreet system. IT systems are a continuously evolving collection of infrastructure and shared capabilities to meet changing needs of a wide variety of consumers, very similar to how other utilities (power, gas, water, cable TV) are commonly used and thought of in today’s world. IT systems provide IT service “utility” by which the warfighting, business and logistical activities of the services are carried out on a daily basis by IT customers globally.

A successful incubator of new IT capabilities requires science and technology projects able to effectively transition into programs of record (PORs), something not currently possible due to the many levels of oversight and tight, risk-averse budget controls. These sets of circumstances leave no flexibility for trial and error in the successful transition of science and technology incubation projects into successful PORs and ultimately the warfighters never see these new, sometimes life-saving technologies. New IT applications should be more like plug-and-play appliances. These modular, ready-to-use appliances should be engineered in the science and technology domains and integrated into the shared cloud computing or services oriented architecture using an iterative POR budget authority that incentivizes IT as a utility shared across a wide range of customers and a diverse set of mission-aligned organizations. Ultimately, the challenge is to efficiently and effectively leverage acquisition processes to deliver threat-pacing (and threat-anticipating) capabilities that can support evolving joint, coalition and naval force needs.

FINDING EA-1:

The current C2ISR acquisition practices and processes are not able to satisfy the current dynamic, real-time and threat-responsive (or anticipatory) operational needs of warfighters. Nor do they achieve Information Dominance of the cyber warfighting areas currently engaged by deployed


[55]

forces. The JCIDS, PPBE and DODD 5000.1 have evolved into bureaucratic processes that require excessive time, funding and personnel to field even modest, incrementally new C2ISR capabilities. Public Law 111-84, the National Defense Authorization Act for Fiscal Year 2010, SEC. 804. IMPLEMENTATION OF NEW ACQUISITION PROCESS FOR INFORMATION TECHNOLOGY SYSTEMS recommends, “The Secretary of Defense shall develop and implement a new acquisition process for information technology systems.” … be designed to include--(A) early and continual involvement of the user; (B) multiple, rapidly executed increments or releases of capability; (C) early, successive prototyping to support an evolutionary approach; and (D) a modular, open-systems approach.

RECOMMENDATION EA-1:

b) The Defense Department adopts the rapid, iterative and cross-organizational boundary IT acquisition model recommended by the National Research Council and Public Law 111-84 Section 804.

FINDING EA-2:

The evolutionary and uniquely collaborative requirements of cloud computing, a service-oriented architecture, and rapid, responsive technology fundamentally and permanently change current client-server system development processes. Within the last five years, there has been a profound trend in IT systems to separate the communications and computing infrastructure from the applications. This separation of infrastructure from the end-user applications is a major game changer in the development, deployment and sustainability of current IT capabilities. In freeing applications from the underlying, and often cumbersome, monolithic infrastructure, this opens previously unimagined possibilities for satisfying time-critical operational needs even in dynamic, flexible, adaptable and ever-changing military environments. Supporting an enterprise infrastructure and applications that are now separated and thought of autonomously requires new governance and processes to deliver on the application agility promise.


a) Provide budgets across mission aligned organizational boundaries to support updating both ISR infrastructure and applications within yearly build cycles to create a continuous improvement cycle that aligns with the dynamic operational need.

b) Validate inherent cost savings over Wave 2 processes by capturing operationally relevant metrics in adaptability, flexibility, time-to-capability and alignment with operational threat categories.

FINDING EA-3:

Without collaborative, cross-organizational engineering processes such as those found in the Java Community Process, DoN engineering efforts will create stove-piped islands of data where the intended cloud computing or services will be no better than current legacy systems employed today. The Space and Naval Warfare Systems Command has recognized the need for collaborative, cross-organizational and platform-independent engineering but continues to struggle to find resources and program support for their Enterprise Engineering and Certification (E2C) capability. The current technical authority processes are audit-based and do not validate information


[56]

interoperability, nor are they focused on producing capabilities in an environment where collaboration is embraced. E2C supports agile collaboration and a technical authority-driven certification to enable production of a shared infrastructure as the gateway to operational test and evaluation.


a) Continue refining E2C capability currently underway at SPAWAR and its Echelon III systems centers.

b) Modify contracts to require collaborative, agile engineering processes and shared service reuse.

c) Require participation, active support and budgetary alignments to enable E2C from all the other systems commands, CNO, OPNAV staff and platform managers.

FINDING EA-4:

The concept of shared and collaborative enterprise governance practices are a far different activity than previous DoD/DoN Wave Two, top-down, serially-threaded governance activities. Shared enterprise governance and/or certification must be bottom-up, mission-oriented, and platform-independent engineering processes. These processes should drive making implementation best practices, and enterprise evolution should determine the evolving standards, specific technical implementations, and certified interoperability of shared resources. E2C is part of this collaborative capability required to tie together disparate and varied government and contractor engineering teams around shared enterprise capabilities.


a) Recognize, adopt/adapt and enthusiastically embrace commercial IT governance practices that support the agile, flexible, quick, adaptive and iterative acquisition of new C2ISR capabilities.

b) Enforce this approach by certifying compliance through technical authorities across DoD and DoN.

c) Engage OSD(P), OSD(C), ASN(FM&C) and all appropriate stakeholders to define financial, governance and business processes to work across organizational boundaries and continue maturing this new Wave 3 approach to acquisition and system development.

FINDING EA-5:

Wave 3 infrastructure or application S&T developments are more readily available and easily adopted into an iterative acquisition build cycle methodology. Given appropriate, cross-organizational, platform-independent, overarching requirements supported by full funding flexibility, S&T products can be fielded within six-12 months of operational acceptance. Engineering certification environments like E2C allow S&T development to take full advantage of shared infrastructure, collaborative application development, and platform-independent and


[57]

shared application services, reducing complexity of integrating new S&T capabilities with those already fielded.


a) Conduct broad-based, bottom-up review, refine and adopt fleet/combatant command approved and prioritized S&T ISR capabilities within the next POR build cycle for inclusion into both infrastructure and applications program capabilities.

FINDING EA-6:

Often in the acquisition of new capabilities, the requirements definition and vetting processes can be very time consuming and costly in fiscal and human resources. The current JCIDS process should examine and validate the appropriate requirements, remain high level and general enough to accommodate flexibility in application development details but specific enough to address the warfighter’s operational need. In contrast, the detailed C2ISR requirements needed for rapid application development are far more dynamic and time-critical than formalized JCIDS processes can and will ever be able to accommodate. SECNAVINST 5000.2E endorses the use of the “IT Box” concept for establishing dynamic requirements for IT systems.31 In this framework, detailed capabilities can be filled from S&T developments and evolved in an almost real-time manner onto baseline programs of record for infrastructure or applications following successful COCOM testing and approval.


a) Focus the C2ISR JCIDS process toward vetting and approving more generalized, overarching system or capability requirements using the IT Box process.

b) Reduce the level of review of the “IT Box” process necessary to the lowest possible knowledgeable working level managers. This can help eliminate redundancies in oversight, and empower those managers that are the most familiar with the requirements and capabilities desired.

c) Establish detailed requirements through fleet approved S&T demonstrated capabilities.

FINDING EA-7:

The testing and evaluation processes and procedures must also adapt in order to prevent undue resource investment in obsolete testing processes, testing the wrong requirements, or testing the wrong capabilities. Our complex system-of-systems designs and engineering approaches have driven the testing community to try and verify all possible system/software paths and all possible combinations or permutations of the manner in which an entire system may or may not ever be employed; an impossible (and extremely costly) task. This complete end-to-end, every-possible-employment testing process consumes significant time and resources without measurably improving warfare capability.

31 The SECNAVINST 5000.2E was in the process of being promulgated at the time of writing


[58]


a) Evolve operational testing and evaluation tactics, techniques and procedures to understand the inherent separation between infrastructure and applications. The testing and evaluation communities must first understand the new service-based system approach and work with the designers and engineers to develop an appropriate level of testing processes to recognize and adequately test the separate capabilities of infrastructure and applications while accommodating their needed interaction.

b) In understanding the new service-based system approach to testing and evaluation, part of the new testing tactics, techniques and procedures must be able to test each component of a service in a semi-independent or autonomous manner and do so in shorter, quicker and more responsive testing cycles.

FINDING EA-8:

The current certification and accreditation processes are complex, confusing, often duplicative and unduly lengthy. These same certification and accreditation processes require lengthy manual assessments, engineering studies, technical assessments and voluminous written documentation to support a certification decision by the designated approving authority. Over the past few years, information assurance certifications are consuming 30-50 percent of the IT development time. These numbers are the result of a trend that has only been growing over time in response to newer, more complex and technologically sophisticated capabilities. Under the current DIACAP certification processes, risk assessments and certification decisions have as much or more to do with the personal risk preferences of the approving authority than the actual computer science underpinning Information Assurance. Cryptologic binding and labeling of certain data when first used or introduced into a service or system is a new approach to security, promising significant simplification in the IA certification processes as well as the separation between infrastructure and application certification. High Assurance Platform is also another innovative technology working to support the secure separation between infrastructure and applications, facilitating radical changes in IA certification complexity, speed, and modularity.


a) Modernize and evolve the IA certification tactics, techniques and procedures to create repeatable processes that recognize that separate infrastructure and applications now need separate certification requirements if they are to support a service-oriented architecture.

b) Put in place standards, written policies or guidelines that ensure each approving authority treats similar capabilities in a similar manner and is done using defined, measurable and repeatable processes.

FINDING EA-9:

The two-year PPBE budgeting processes governing the C2ISR programs of record remain locked in Wave 2 budget curves and focused on delivering stove-piped, platform-centric systems. This


[59]

approach negatively impacts IT-driven acquisition processes associated with systems that require collaborative engineering and requirements development from many different organizations and many different budget FYDP program elements across the DoN and other services/agencies.

Continuing to assume flexible, adaptive, agile, modular and quickly evolved C2ISR programs can be built through start-finish, two-year budget program cycles is not only misguided, but has been shown repeatedly not to be effective and negatively impacts the evolutionary reality of delivering the next generation of modern cloud computing services technology. C2ISR IT capabilities in support of today’s time-critical requirements, when properly executed, are long-term living and evolving capabilities. These dynamic, changing, time-critical warfighting requirements demand a budget process that supports evolutionary growth in infrastructure, data, and application programs. Additionally, and as a mere fact of technological evolution, these infrastructure, data and application programs are no longer tightly coupled together in a bound system nor are they designed, developed, engineered, implemented, tested, fielded or supported in like manner. Infrastructure, data and applications are now semi-autonomous and have become decoupled from each other. Today, these independent components to any C2ISR system are much more fluid in their maturation. The Defense Science Board, National Research Council and Public Law 111-84, Sec 804 all recommend revolutionary changes in the IT acquisition processes. Each supporting recommendation is identified in this MIEA review. As part of these revolutionary changes to how C2ISR systems are thought about and acquired, iterative C2ISR budgets must be created around a nominal stable investment percentage of the budget just as any other “utility.” To address all aspects of this changed perspective and institute true long-standing change, this approach would require and support reassignment of OPNAV staff personnel to be aligned with this kind of services-oriented acquisition.


a) Initiate a dialog with congressional members’ staffs and professional committee staffs of the SASC and HASC, with the support of OLA, CNO, CMC, SECNAV, UNSECNAV and ASN(RD&A) to support year-by-year, iterative C2ISR budgets as the foundation of C2ISR capability evolution.

FINDING EA-10:

In a technological world evolving extremely quickly, the DoN’s ability to adopt and deploy technologies that could rapidly improving warfighting is severely diminished. In particular, the fiscal and fiduciary circumstances surrounding the difficulties in applying new technologies not only make it challenging to insert new technologies into warfighters’ hands, but it unnecessarily gives our adversaries an advantage because it also lowers their technology adoption bar, allowing our enemies to inflict damage or injury, putting warfighters’ lives in needless jeopardy. The current C2ISR acquisition framework is unable to keep pace in response to industry changes because budget processes fail to recognize the negative impact of sustaining old, dedicated infrastructure tied to applications. Sustaining Wave 2 legacy-capabilities while trying to develop, train, engineer, deploy and transition into Wave 3 technologies without the budgetary means, processes and perspective to support them defeats the enormous benefit of the newer technologies and once again ultimately lowers the bar for our adversaries. Sustaining Wave 2 infrastructure and keeping applications tied directly to dedicated systems marginalizes the effectiveness of Wave 3 and continues to push warfare benefits out decades while ultimately increasing costs as DoN and DoD force new technologies to “behave,” “perform,” or “simulate” under Wave 2 constraints. Wave 2


[60]

applications can be fielded into Wave 3 infrastructure equipment at little to no cost while saving the cost of maintaining obsolete equipment as long as the appropriate perspective and engineering efforts are supported and sustained to make the eventual transition to Wave 3.


a) Identify the cost savings of a capability evolution approach using shared infrastructure and independent applications as justification for developing new fiscal processes to support service-oriented, collaborative development across all domains, organizations and FYDP program elements.

b) Protect and reinvest cost savings into developing service-oriented Wave 3 technologies to replace legacy infrastructure over three years vice 10 years and make the processes respond to warfighter technology needs in weeks rather than months or years.

FINDING EA-11:

Each part has its own constraints, timelines, reporting requirements and other considerations, resulting in high priority fleet requirements and new technology insertion pilot projects often not supported by programs of record. As a result of our current acquisition processes, programs of record have traditionally been slow to respond to new requirements, slow in getting the requisite funding, and even slower at putting a capability in the hands of the deployed warfighter. As part of this, science and technology C2ISR projects often never transition into deployable fleet capabilities despite the fleet actively supporting and requesting them. C2ISR budgets, review processes and priorities, when stacked against the other budgetary considerations, do not always support the fleet’s explicit desires and wishes and are often times at odds with acquisition program priorities.


a) Create and update an annual C2ISR Capital Investment Plan to help align N2N6 budgets, fleet exercise prioritized projects, Office of Naval Intelligence S&T programs, PEO C4I programs, PEO Integrated Warfare Systems programs, and DASN C4I and Space policy and guidance.

b) Bring together all the stakeholders in the C2ISR domain (Navy, Marine Corps and OSD) to review, evolve and validate the C2ISR Capital Investment Plan in a yearly planning conference. This conference will coordinate requirements, funding, development, deployment, testing and certification and accreditation activities for the upcoming execution year as well as strategic plans for the out years.


[61]

5. CONCLUSION

With the advent of persistent ISR capabilities offered by unmanned systems on the horizon, a quantum leap in ISR data quality and quantity will be available to deployed naval forces. Unfortunately, the back-end infrastructure of systems, bandwidth, manpower and CONOPS required to effectively employ these assets and the information they can provide as they come online does not currently exist. DoN has not assigned organizations ownership of the challenge to be prepared to support the processing and distribution of the significant rise in ISR data that will be an inevitable result of these new sensor systems.

Within a constrained budgetary environment, an iterative, multidisciplinary, holistic view of all components of the TCPED infrastructure is required to mitigate the aforementioned anticipated capability gaps. In general, the planned manpower exploitation, in the few cases it exists, does not reflect the demonstrated demand for manpower to support persistent ISR. Even if significant increases in manpower and PED system funding were available, the current state of Maritime ISR fractured into isolated specialties minimizes the fleet’s ability to use the quantity and variety of information that its new unmanned sensors will provide, further exacerbating the need to smartly modernize its ISR TCPED infrastructure. This challenge is complex, with many interdependent organizations, systems and technologies, but it is not beyond the Navy’s ability to put such a capability in place. The establishment of the Information Dominance Corps provides a solid initial step for unifying the Navy’s information-intensive specialties into a multidisciplinary force through which a unified effort to modernize this infrastructure can be crafted.

Given the scope and complexity of this challenge, the MIEA team recommends addressing the MIEA review findings and recommendations over time, as this effort requires cooperation between OPNAV N2/N6, ASN RDA and PEO C4I. The building of an overarching C2ISR Plan, in partnership with N2/N6, is needed to help coordinate N2/N6 budgets, fleet C2ISR capabilities, fleet C2ISR shortfalls and S&T demonstration feedback, ONR C2ISR S&T, C2ISR governance (including standards, policy and implementation guidance), and C2ISR iterative acquisition build cycles as recommended by the DSB, national academies and Congress. [best to bulletize each facet rather than have 10 refs in para format] The establishment of a C2ISR annual planning conference is critical to managing this planning activity between users, builders, S&T, requirements and budgets.

The Navy's ability to quickly find useful and relevant information across massive quantities of heterogeneous data; its ability to use ashore network, computing infrastructure and personnel resources; its ability to deliver afloat and ashore derived ISR to support the full range of operations; its ability to use group and unit level ship resources across the breadth of afloat C2ISR operations; its ability to operate with an effective IA risk trade-space; and its ability to efficiently leverage acquisition processes to deliver timely and relevant material solutions are all critical to its successful transformation. This is the Navy’s most significant transformation in decades, and afloat naval forces are dependent upon a smartly modernized infrastructure to ensure that its new capabilities are effectively employed.


[62]

BIBLIOGRAPHY

Ackerman, R. K. (2009, February). Naval Intelligence Ramps up Activities. SIGNAL Magazine, pp. 1-6.

Andrews, M. (2010, April 14). Representative, 111th Congress, 2nd Session. House Resolution (H.R.) 5013 (Implementing Management for Performance and Related Reforms to Obtain Value in Every Acquisition Act of 2010). Washington, D.C., USA: House of Representatives Committee on Armed Services, Committee on Oversight and Government Reform.

Architzel, D. (2009, June 1). Vice Admiral, U.S. Navy, Principal Military Deputy. Memorandum, Subject: Maritime Intelligence, Surveillance and Reconnaissance Enterprise Acquisition (MIEA) Review. Washington, D.C., USA: Department of the Navy; Assistant Secretary for Research, Development and Acquisition.

Art Money, B. H. (2009). Creating an Assured Joint DOD and Interagency Interoperable Net-Centric Enterprise. Washington, D.C.: Defense Science Board Task Force on Achieving Ineroperability in a Net-Centric Environment.

Benioff, M. (2009, May 11). Chairman and CEO. Welcome to the Real-Time Cloud. Arlington, Virginia, USA: salesforce.com.

Bittman, T. J. (2009). Sever Virtualization: One Path That Leads to Cloud Computing. Gartner.

Boudreau, M. (2006). Acoustic Rapid COTS Insertion: A Case Study in Spiral Development. Naval Postgraduate School, Graduate School of Business & Public Policy. Monterey, California: Naval Postgraduate School.

Brien Alkire, J. G. (2010). Applications for Navy Unmanned Aircraft Systems. Santa Monica, California: RAND Corporation.

Burke, A. (1969, November 19). Admiral, U.S. Navy (Retired). Role of Naval Forces. Newport, Rhode Island, USA: Naval War College.

Charles A. Wells, M. F. (2009, November 30). Joint Staff J-8 Capabilities and Acquisition Division and Requirements Management Division. Information Technology Requirements Oversight and Management (The JCIDS "IT Box"). Washington, D.C., USA: Joint Staff J-8.

Cibula, A. (2008, September 04). Commander. Distributed Common Ground System - Navy, DCGS-N Block 1 Architecture Briefing. San Diego, California, USA: Program Executive Office; Command, Control, Communications, Computers and Intelligence.

Colby, G. (2009, November 12). Navy UCAS Briefing. Patuxent River, Maryland, USA: Naval Air Systems Command (PMA-268).

Coleman, B. (2041, October 17). Evolution of the Information Age: 1960 - 2040; A progress report at the inflection point of both the Cloud and the Web. Los Altos, California, USA: Bill Coleman.


[63]

Council, N. R. (2010). Achieving Effective Acquisition of Information Technology in the Department of Defense. Washington, D.C.: National Academy of Sciences.

CSC. (2008, July 3). US Army Service Oriented Architecture Life Cycle Management Model; Volume 4: SOA Funding and Acquisition (Version 2.1). Falls Church, Virginia, USA: Army SOA Foundation; U.S. Army Chief Information Officer (CIO) G-6.

Data, S. (2005, December). SkySite Network & SkySite Telemetry Services Overview. Space Data.

Davi M. D'Agostino, S. L. (2007). Intelligence, Surveillance, and Reconnaissance; Preliminary Observations on DoD's Approach to Managing Requirements for New Systems, Existing Assets, and Systems Development. Washington, D.C.: Government Accountability Office.

David A. Nichols, P. C. (1995). High-Latency, Low-Bandwidth Windowing in the Jupiter Collaboration System. Palo Alto, California, USA: Xerox Palo Alto Research Center (PARC).

Dorsett, D. J. (2010, May). Vice Admiral, U.S. Navy; Deputy Chief of Naval Operations for Information Dominance. The U.S. Navy's Vision for Information Dominance. Washington, D.C., USA: Deputy Chief of Naval Operations for Information Dominance.

England, G. (2008, August 27). Deputy Secretary of Defense. Department of Defense Directive, SUBJECT: Maritime Domain Awareness (MDA) in the Department of Defense. Washington, D.C., USA: Department of Defense, Directive Number 2005.02E, USD(P).

Fein, G. (2010, August 5). Study Recommends Processes For DoD To Implement Improved IT Acquisition. Defense Daily, pp. 2-4.

Fein, G. (Unknown, Unknown Unknown). Navy Developing Path Forward For Open Architecture Implementation. Defense Daily, pp. 1-3.

Forces, C. o.-C. (2010). Information Assurance for Netework-Centric Naval Forces. Washington, D.C.: National Research Council.

Fromkin, R. (2010, July 20). Intel Federal. Helping Solve Challenges in Computing Through Advancements in Processor Technologies. San Diego, California, USA: Intel Corporation.

Gansler, J. S. (2009). Fulfillment of Urgent Operational Needs. Washington, D.C.: Defense Science Board.

Grundhauser, L. K. (2007, May 29). Colonel, USAF; Vice Director for Intelligence, J2; Chairman Battlespace Awareness Functional Capabilities Board. Memorandum, Subject: Marine Corps Intelligence, Surveillance and Reconnaissance - Enterprise (MCISR-E), Initial Capability Document (ICD). Washington, D.C., USA: The Joint Staff.

Harry B. Harris, J. (2009, April 17). Vice Admiral, U.S. Navy; Deputy Chief of Naval Operations (Communication Networks) N6. Memorandum, Subject: Navy Information Technology Management Council (ITMC) of 10 April 2009 - Decision Memorandum (DM) 04-09. Washington, D.C., USA: Department of the Navy, Office of the Chief of Naval Operations.


[64]

Heely, T. (2007, August 8). Rear Admiral, U.S. Navy. Open Architecture; Enabling Affordable Integration of Unmanned Air Systems. Patuxent River, Maryland, USA: Program Executive Officer; Strike Weapons and Unmanned Aviation, Naval Air Systems Command.

Hoene, P. F. (2009, October 14). Brigadier General, USAF; Program Executive Officer, Command and Control Capabilities. Memorandum, Subject: Joint Command and Control (JC2) Objective Architecture. Arlington, Virginia, USA: Defense Information Systems Agency.

Hofmann, J. (2010, August 12). Large Data / Road Runner. Washington, D.C., USA: Naval Research Lab.

Huff, D. (2009). Chief Technology Officer. High Assurance Platform (HAP) for Operational Weather Forecasting. Monterey, California, USA.

Integrity Applications, I. (2009, March 12). Navy Intelligence Services Architecture (NISA). NAVAIR China Lake.

Intelligence, O. o. (2009, August 24). Information Integration (I2) Pilot: NMIC: Maritime Center of Data. Washington, D.C., USA: Hopper Information Services Center.

Jan VanTol, M. G. (2010, May 18). AirSea Battle. CSBA.

Ken Birman, J. C. (2009, May). Edge Mashups for Service-Oriented Collaboration. Computer, pp. 92-96.

Kevin D. Foster, J. J.-T. (2010). Removing the Boundaries: Steps Toward a Cloud Nirvana. Arlington, VA & Monterey, California: OSD NII & Naval Postgraduate School.

Kostka, D. C. (2009, 4th Quarter Issue 55). Moving Toward a Joint Acquisition Process to Support ISR. Joint Forces Quarterly(55), pp. 69-75.

Larry Meador, J. D. (2008). Integrating Sensor Collected Intelligence. Washington, D.C.: Defense Science Board (DSB) and the Intelligence Science Board (ISB) Joint Task Force.

M. Arakawa, G. B. (2007). An Enterprise Architecture Assessment for the Distributed Common Ground System - Navy (DCGS-N). Lincoln Laboratory. Lexington, Massachusetts: Massachusetts Institute of Technology.

Mabus, R. (2010, February 24). Secretary of the Navy. Testimony Before the House Armed Services Committee. Washington, D.C., USA: House Armed Services Committee.

Mark D. Andress, B. W. (2009, May 14). Navy Participation in Panda Development. Washington, D.C., USA.

Mason, C. (2009). Cryptographic Binding of Metadata. The Next Wave, 18(2), pp. 22-25.

McChrystal, D. (2008, June 11). Battlespace Awareness and Information Operations Program Office (PMW-120). Joint Concentrator Architecture (JCA) Overview. San Diego, California, USA: Program Executive Office, Command, Control, Communications, Computers and Intelligence.

Miller, C. A. (2008, August 12). PEO C4I Masterplan. San Diego, California, USA: PEO C4I.


[65]

Obama, B. H. (2010, May). President of the United States (POTUS). National Security Strategy (NSS). Washington, D.C., USA: The White House.

Operations, C. o. (2009, October 27). Information Dominance Kickoff Briefing. Washington, D.C., USA: Chief of Naval Operations.

Operations, C. o. (2010). Convergence To A Single Network Roadmap. Washington, D.C.: Chief of Naval Operations.

OSD (RFD), U. N. (2010, May 7). Large Data Joint Capability Technology Demonstration (JCTD). Washington, D.C., USA: OSD (RFD), USSTRATCOM, NRL, NGA, INSCOM, DISA.

Paul Gonsalves, R. C. (2001, July 13). Principal Scientist & Scientist. Automated ISR Collection Management System. Cambridge, MA, USA: Charles River Analytics, Inc.

Robey, J. L. (2010, March 19). CAPT, U.S. Navy; PAPM Air Sea Integration (PMW-750). TacMobile Program Overview. San Diego, California, USA: PEO C4I.

Roby, C. J. (2009). Department of Defense (DoD) Command and Control (C2) Implementation Plan. Washington, D.C.: Office of the Assistant Secretary of Defense for Networks and Information Integration / DoD Chief Information Officer.

Ronald Kerber, V. V. (2009). Department of Defense Policies and Procedures for the Acquisition of Information Technology. Washington, D.C.: Defense Science Board.

Roughead, G. (2008, September 2). Admiral, U.S. Navy; Chief of Naval Operations (CNO). Memorandum, Subject: Navy Intelligence, Surveillance, and Reconnaissance Strategy Development and Execution. Washington, D.C., USA: Chief of Naval Operations.

Roughead, G. (2009, July 23). Admiral, U. S. Navy; Chief of Naval Operations (CNO). Memorandum, SUBJECT: Fleet Cyber Command/Commander Tenth Fleet Implementation Plan. Washington, D.C., USA: Department of the Navy.

Roughead, G. (2009, September). Admiral, U.S. Navy; Chief of Naval Operations. CNO Guidance for 2010; Executing the Maritime Strategy. Washington, D.C., USA: Department of the Navy.

Roughead, G. (2009, June 26). Admiral, U.S. Navy; Chief of Naval Operations (CNO). Memorandum, Subject: Reorganization of the Office of the Chief of Naval Operations (OPNAV) Staff. Washington, D.C., USA: Department of the Navy, Chief of Naval Operations.

S. Yoakum-Stover, M. A. (2010). Fixing Intel and Operatinoalizing Data - The Data & Processing Syndicate. Alexandria, VA: Institute for Modern Intelligence.

Salyan, D. (2007, May 17). Commander. Consolidated Adaptive Networks and Edge Services (CANES). Washington, D.C., USA: OPNAV N6 F2F3.

Shaw, B. D. (2010, May). Director of Cyber Warfare, DASN C4I / IO / Space. Cyber Protection, Prioritization, and Plan; What Does a Cyber Secure Navy Look Like? Washington, D.C., USA: DASN C4I / IO / Space.

Shaw, P. (2010, June 30). Information Dominance Data Strategy. San Diego, California, USA: Space and Naval Warfare Systems Command.


[66]

Staff, J. (2009). Manual for the Operation of the Joint Capabilities Integration and Development System (JCIDS). Washington, D.C.: Department of Defense.

Sweitzer, D. (2009, July 22). DCGS Enterprise Update.

Systems, B. (2008, February). DCGS Program Restructure - Afloat Node. BAE Systems Company.

Tatiana Malyuta, S. Y.-S. (2009, August 24). Associate Professor & Research Fellow. Principles In Support of Viable Data Integration and Semantic Enrichment. Lyon, France: Very Large Database Endowment (VLDB).

Technologies, I. (2006). The Economics of SOA; Case Study: Quantifying the Savings of a Service-Oriented Architecture (SOA). Waltham, MA: IONA Technologies.

Trentley, F. (2010). Senior Director. 2010 & Beyond: Catalysts Shaping the Internet Revolution. Fairfax, VA, USA: Akamai, Inc.

Wald, B. (2009, October 9). Navy Acquisition of Information Systems. Washington, D.C., USA.

Wennergren, D. M. (2009, October 14). ASD (NII)/DoD CIO (Acting). Policy Memorandum, SUBJECT: Designation of Geospatial Visualization as a Shared Enterprise Service. Washington, D.C., USA: Department of Defense.

Willard, R. F., Navy, A. U., & Fleet, C. S. (2002, October). Rediscover the Art of Command and Control. U.S. Naval Institute Proceedings, pp. 52-54.

William Schneider, J. (2009). Operations Research Applications for Intelligence, Surveillance and Reconnaissance (ISR). Washington, D.C.: Defense Science Board Advisory Group on Defense Intelligence.

Winter, D. C. (2009, March 6). Secretary of the Navy. SECNAVINST 3052.2, Subject: Cyberspace Policy and Administration Within The Department Of The Navy. Washington, D.C., USA: Department of the Navy, Deputy Under Secretary of the Navy (DUSN).

maritime isr enterprise acquisition (miea)...

Documents