Appendix E
Naval Information Assurance Architectural Considerations

THE NEED FOR A NAVAL OBJECTIVE ENTERPRISE ARCHITECTURE

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

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

1

ADM Gary Roughead, USN, Chief of Naval Operations; Gen James T. Conway, USMC, Commandant of the Marine Corps; and ADM Thad W. Allen, Commandant of the Coast Guard. 2007. A Cooperative Strategy for 21st Century Seapower [Maritime Strategy], Washington, D.C., October. Available at <http://www.navy.mil/maritime/MaritimeStrategy.pdf>. Accessed April 30, 2009.

2

Honorable Donald C. Winter, Secretary of the Navy. 2008. 2008 Posture Statement of the Honorable Donald C. Winter, Secretary of the Navy, Washington, D.C., February 28. Available at <http://www.navy.mil/navydata/people/secnav/winter/2008_posture_statement2.pdf>. Accessed April 30, 2009.



The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 165
Appendix E Naval Information Assurance Architectural Considerations THE NEED FOR A NAVAL OBJECTIVE ENTERPRISE ARCHITECTURE As articulated in the 2008 Maritime Strategy,1 naval forces will provide regionally concentrated, credible combat power as well as globally distributed mission-tailored maritime forces. Some of these missions embody long-standing roles of the Navy, such as power projection and deterrence, while others are a product of globalization and the U.S. role in the world such as humanitarian assistance and disaster response. Some new missions, such as Maritime Domain Awareness (MDA), require the coordination of disparate government organiza- tions, international partners, and industry.2 Supporting these goals is complex owing to the diversity and dynamic nature of the missions. Command, control, communications, computers, intelligence, surveillance, and reconnaissance capabilities are important for these missions, and network-centric capabilities are sought in which all nodes contribute to the information superiority of the force. This concept is part of FORCEnet, which is “the operational construct and architectural framework for naval warfare in 1ADM Gary Roughead, USN, Chief of Naval Operations; Gen James T. Conway, USMC, Com - mandant of the Marine Corps; and ADM Thad W. Allen, Commandant of the Coast Guard. 2007. A Cooperative Strategy for 21st Century Seapower [Maritime Strategy], Washington, D.C., October. Available at . Accessed April 30, 2009. 2 Honorable Donald C. Winter, Secretary of the Navy. 2008. 2008 Posture Statement of the Honorable Donald C. Winter, Secretary of the Navy, Washington, D.C., February 28. Available at . Accessed April 30, 2009. 165

OCR for page 165
166 INFORMATION ASSURANCE FOR NETWORK-CENTRIC NAVAL FORCES the Information Age, integrating warriors, sensors, command and control, plat - forms, and weapons into a networks, distributed combat force.”3 The networking capabilities that FORCEnet must be able to support include a large range of new bandwidth-intensive applications in addition to providing strong protection against adversarial action. Unfortunately, the average age of a typical shipboard network is approaching 7 years, with some as old as 12 years, while industry is operating on a 4-year cycle.4 The Navy also has several major milestones ahead, such as the introduction of a service-oriented architecture (Consolidated Afloat Networks and Enterprise Services [CANES]), open-architecture computing infrastructure, 5 the follow-on to the Navy/Marine Corps Intranet, NMCI (Next Generation Enterprise Network [NGEN]), and new satellite communications capabilities, all of which require deliberate development and service acquisition strategies owing to their high cost and criticality to naval operations. Enterprise architecture (EA) provides the discipline for managing change and complexity within the naval enterprise, especially with constrained budgets. EA is required for a truly agile Navy, because the architectural artifacts will allow decision makers to proceed quickly, knowing the state of their informa - tion technology (IT) and how it is evolving. Without a fully accepted and lever- aged enterprise architecture, agile actions in one part of the enterprise could be detrimental to another part. Another extremely important use of enterprise architecture is in bridging the gap between mission operations and IT imple - mentation. Just as the blueprints for the structure of a house should capture and reflect how the owner desires to operate in the house, the architecture artifacts should be driven by concepts of operations (CONOPS) for the users, should capture and reflect their required capabilities, and should portray back to the owner (funding source) what needs to be built (IT capabilities) to satisfy the mission. Without the EA “bridge,” money may be spent on redundant or extra - neous IT capabilities. Enterprise architecture is the practice of applying a comprehensive and rig - orous method for describing a current and/or future structure and behavior for an organization’s processes, information systems, personnel, and organizational subunits so that they align with the organization’s core goals and strategic direc - tion. Although often associated strictly with information technology, EA relates 3Admiral Vern Clark, USN, Chief of Naval Operations, and General Michael W. Hagee, USMC, Commandant of the Marine Corps. 2005. “FORCEnet: A Functional Concept for the 21st Century,” Department of the Navy, Washington, D.C., February. Available at . Accessed April 30, 2009. 4 CDR Philip Turner, USN, PMW-160.5, Assistant CANES [Consolidated Afloat Networks and Enterprise Services] Program Manager. 2007. “The CANES Initiative: Bringing the Navy Warfighter onto the Global Information Grid,” CHIPS, October-December. 5 For additional discussion, see Open Architecture Enterprise Team, Program Executive Office Inte - grated Warfare Systems, 2008, The Fourth quarterly Report to Congress on Naval Open Architecture (NOA), Department of the Navy, Washington, D.C., November.

OCR for page 165
167 APPENDIX E more broadly to the practice of mission optimization in that it addresses busi - ness mission architecture, performance management, and process architecture as well. An EA is a structured plan for evolving an enterprise from its current state to a desired end state based on enterprise strategies, required capabilities, guiding principles, and external influences. Taking this definition one term at a time: • The structure is a logically organized rubric or architecture decomposition that clearly shows where all of the components of the enterprise fit within the EA. • The plan is a set of blueprints for the enterprise along with a transition roadmap or acquisition schedule. It is also beneficial if along with the detailed blueprints there is a corresponding set of high-level artifacts (floor plans and eleva- tions in the building industry) based on the detailed blueprints that aid leadership in decision making. • The current state is the “as is” architecture or the baseline configuration from which point one needs to migrate. Without this starting point of the journey, the roadmap cannot be drawn. • The desired end state is the “to be,” or target, architecture. • The enterprise strategies are the mission, vision, goals, and objectives of the enterprise, usually established by the enterprise leadership. • The required capabilities are the shortfalls or gaps of the as-is architecture that are identified and prioritized by the operations part of the enterprise. • The guiding principles are tenets of the enterprise that will be used to drive architectural trade-offs and decisions. • The external influences are architectural drivers such as standards, technol- ogy evolution, and the environment within which the enterprise operates. CURRENT STATE OF NAVY INFORMATION ASSURANCE ARCHITECTURE DEVELOPMENT The naval forces network can best be described with multiple tiers, a core network, and various types of distribution and access tiers, sometimes called edge networks. The core exists in fiber-optic connectivity, which allows opera - tions in the continental United States as well as at specific fixed regional sites such as military bases. The ability to reach naval forces responding to global conflicts requires communications capabilities beyond core networks, and for this the naval forces rely extensively on satellite communications (SATCOM), with an emphasis on protected (extremely high frequency), for assured avail - ability of low-rate information today, to be followed by megabit-class assured connectivity to be provided by the Transformational Satellite Communication System when it is deployed. This capacity is augmented by wideband (super high frequency), narrowband (ultra high frequency), and commercial SATCOM; however, these systems are easily jammed by relatively simple equipment and

OCR for page 165
168 INFORMATION ASSURANCE FOR NETWORK-CENTRIC NAVAL FORCES therefore cannot be relied on for assured connectivity. The Navy’s approach to SATCOM is not stovepiped. It includes the integrating element Advanced Digital Network System (ADNS), which adds the essential networking functions on top of the SATCOM links.6 A similar degree of diversity is found in terrestrial wireless communications in support of tactical and strategic communications. These missions reflect the operational environments such as Navy battle groups operating in blue water and vessels engaged in littoral operations, as well as United States Marine Corps (USMC) amphibious and ground forces. The Navy also has a critical role in nuclear forces, where architectures must support low-rate but extremely high integrity message transfer. Navy strategic communications to ballistic missile submarines is normally accomplished through a network of very low frequency and low frequency transmitters located throughout the world. The service, application, and computing elements of the naval architecture are also complex and dynamic (e.g., NMCI migrating to NGEN). The Naval Open Architecture Initiative was established by the Department of the Navy (DON) to shift focus from a platform-centered warfare system acquisition and development approach to an integrated approach centered on the battle force 7,8 In addition, the naval forces have focused on service-oriented architectures as a critical open- architecture technology trend.9 Several key challenges are associated with the development and deployment of the naval implementation of a service-oriented architecture (SOA), not the least of which is knowing when SOA is the right approach to naval business and weapons system information exchange. Some weapons and combat systems may have latency and data-processing volume requirements that necessitate tightly coupled, real-time, distributed applications and computing components, features that can be difficult to implement based on SOA design principles. However, the potential rigor of SOA configuration control can be useful in such conditions to ensure information availability and integrity; also, the capability of processing is increasing quickly enough that the inefficien - cies of SOA could be overcome. 6 National Research Council. 2005. Navy’s Needs in Space for Providing Future Capabilities, The National Academies Press, Washington, D.C., pp. 216-217. 7 Naval Surface Warfare Center, Dahlgren Division. 2004. Open Architecture (OA) Computing Envi- ronment Design Guidance, Version 1.0, Naval Surface Warfare Center (Dahlgren Division), August 23. Available at . Accessed April 30, 2009. 8 Naval Surface Warfare Center, Dahlgren Division. 2004. Open Architecture (OA) Computing Envi- ronment Design Guidance, Version 1.0, Naval Surface Warfare Center (Dahlgren Division), August 23. Available at . Accessed April 30, 2009. 9 Program Executive Office for Integrated Warfare Systems and Open Architecture Enterprise Team. 2007. Emerging Trends Affecting Future Naval Acquisitions, Version 7, Washington, D.C., February.

OCR for page 165
169 APPENDIX E The CANES initiative is a follow-on to the IT-21 Initiative established nearly 10 years ago. The overarching goal of the N6-directed CANES initiative, developed in collaboration with the elements of the Naval NETWAR FORCEnet Enterprise (NNFE), is the same as that of IT-21, which is to establish essential components of the naval afloat (including Maritime Headquarters and Maritime Operations Centers) IT infrastructure that enable deployment of flexible, agile, and cost-effective C4ISR systems and applications. Naval organizations and pro - grams associated with specific domains (i.e., air, space, subsurface, surface, and C4I) have initiated efforts to explore the feasibility of factoring in and deploying key warfighting applications on an SOA.10 The naval forces are to be commended for their current enterprise vision 11 and their existing detailed architectures at program levels. They must now ensure that their objective detailed, end-to-end architecture is modified to include the attributes necessary to assure information availability and integrity, and then that they are refined, communicated, accepted broadly, and implemented according to plan. Moreover, a focus on integration and transition from the current state to the desired end state must be maintained. From an IA perspective, the enterprise architecture must enable naval forces to keep pace with new trends in Department of Defense (DOD) computing, such as the movement toward Web services, and incorporate information assurance mechanisms that deal with threats related to these trends. “Bolting on” IA to naval systems during and after development instead of “building in” IA from system inception appears to be a continuing issue, given the state of implementation relative to the objective enterprise architecture. The problem is exacerbated by quick-reaction development of capabilities and urgent requests from current theaters of operation. Having overall guidance embodied in an IA set of principles for the naval enterprise architecture could allow IA developers to create solutions that can be more easily and rapidly integrated into naval systems. The prudent, targeted, and timely incorporation of related IA technologies in affected naval IA architectures is therefore an important priority. In this context, Table E.1 briefly considers selected emerging IA technologies as they relate to each major state of data: in transit, at rest, and in process. An additional category covers technologies and issues that cut across these areas. The naval forces should also seek to leverage testing and evaluation capabilities being developed more broadly by the DOD (e.g., the Defense Advanced Research Proj - ects Agency’s National Cyber Range) to evaluate the robustness of architectural implementations and new capabilities, technologies, and systems. 10 “Emerging Trends Affecting Future Naval Acquisitions,” Program Executive Office for Integrated Warfare Systems, 7.0, and the Open Architecture Enterprise Team, February 2007. 11Victor Ecarma. 2009. “DON Enterprise Architecture Development Supports Naval Transforma - tion,” CHIPS, Vol. 27, No. 1, January-March, pp. 30-32. Available at . Accessed April 30, 2009.

OCR for page 165
170 INFORMATION ASSURANCE FOR NETWORK-CENTRIC NAVAL FORCES TABLE E.1 Selected Emerging Information Assurance Technologies As They Relate to Major States of Data Technology Discussion Relating to Data in Transit The evolving High Assurance Internet Protocol Encryptor (HAIPE)a HAIPE standard helps protect data as they transit potentially untrusted networks. HAIPEs are National Security Agency (NSA)-approved Type 1 “in-line” network encryption devices that protect traffic to and from individual devices or entire enclaves. Architects can leverage HAIPE for domain-per-tunnel encryption atop a shared common network backbone. Issues to track include Internet Protocol version 6 compatibility, release of HAIPE 3.0, and the future possibility of HAIPE in software hosted by trusted platforms. OTNK Over-the-Network Keying (OTNK) is an approach for establishing cryptographic keys via network-based negotiation rather than by “out-of-band” techniques (e.g., human couriers). Commercial information assurance (IA) protocols (e.g., IPSec, SSL,b XMKSc) have long employed OTNK techniques, but OTNK for Type 1 keys is an emerging area in Department of Defense (DOD) computing. The coupling of Key Management Infrastructures with OTNK in HAIPE is an important development to monitor. WS-Security; WS-Policy Web Service (WS)-Security is a World Wide Web Consortium specification for protecting Web services messages that employ Extensible Markup Language (XML) signature and XML encryption (see below); WS-Policy expresses security requirements between Web services. Remote attestation The Trusted Computing Group (TCG) is developing standards (e.g., Trusted Network Connect protocol) related to remote attestation. Remote attestation protocols help parties verify the integrity of remote hosts prior to engagement. The area of attestation depends in turn on trust in the reported results; technologies such as Trusted Platform Modules are useful in establishing trust. Application firewalls Firewalls are a first line of defense that block internal assets from external access. The appearance of application-level firewalls to complement their network brethren help secure key communications pathways (e.g., port 80) that are often left open to permit Web traffic. Web services firewallsd are an important subcategory of such firewalls. Relating to Data at Rest Domain encryption Just as specifications such as HAIPE allow domain-specific encryption via network connections, a similar capability is required for data at rest. A number of vendors are working with NSA to develop approved technologies in this area. continued

OCR for page 165
171 APPENDIX E TABLE E.1 Continued Technology Discussion Threshold schemes Threshold schemes are cryptographic approaches for providing both data confidentiality and availability.e When coupled with domain encryption, they can provide a level of robustness attractive particularly to tactical environments where connectivity and survivability are key. Relating to Data in Process Virtualization Virtualization has been in use since the 1960s; however, the recent IA interest in virtualization pertains to allowing multiple separate domains to inhabit the same physical platform. Trust in such virtualization is in part based on trust in the underlying hardware. TPMs, TXT An important trend to monitor is the increasing availability of hardware-based security primitives found on mass-produced platforms. Technologies such as TCG’s Trusted Platform Modules and Intel’s Trusted Execution Technology (TXT) are emerging. HBSS The DOD relies extensively on commercial operating systems that have been subject to intensive attacks over many years. To help counter attacks, the Defense Information Systems Agency has selected the McAfee e-Policy Orchestrator suite of tools as part of its Host Based Security Services (HBSS) programf to provide a range of protection. HBSS eventually will be deployed throughout the DOD, and, as a result, the Navy will need to keep its systems compatible with the HBSS suite. RAdAC Access control is an IA area evolving from relatively static approaches, such as access control lists, to more powerful and general-rule-based approaches. Risk Adaptive Access Control (RAdAC) has been created from a desire to make access control more dynamic.g Web services XML-based Web services are seen as an important trend in architecting distributed systems that cuts across many areas of IT and IA.h Examples of prominent Web services security standards include XML encryption and XML Signature for XML data-level security, the Security Assertions Markup Language (SAML) for expressing security assertions (e.g., assertions for authentication events, attributes, and access decisions), and the Extensible Access Control Markup Language (XACML) for distributed access control. Policy Certification and accreditation (C&A) comprise an ever-present issue when new IA technologies are incorporated into DOD IT systems. A key concern has been the cost and time associated with repeated evaluations of such systems, either because of an evolution of the technology used or the context for system use changed. The National Institute of Standards and Technology is currently leading an effort to streamline and standardize the evaluation process across DOD and the intelligence community.i In addition, today’s high-level policies will have to be revisited and potentially revised as new technologies mature.

OCR for page 165
172 INFORMATION ASSURANCE FOR NETWORK-CENTRIC NAVAL FORCES TABLE E.1 Continued Technology Discussion Accountability DOD IT systems have become so complex, interwoven, and dependent on commercial off-the-shelf technologies that they have exceeded their collective ability to confidently assert a guarantee of protection. An open research problem is the development of techniques for measuring assurance that scale to today’s complex systems. Lacking such techniques, the secure collection of forensic evidence, including security-critical events, is crucial to help investigators carry out after-the-fact damage assessments. A key challenge, however, is effectively processing a large volume of events. Audit-log reduction tools can help in this regard; they can also help verify that vital services are in use and functioning correctly. aCommittee on National Security Systems (CNSS). 2007. National Policy Governing the Use of High Assurance Internet Protocol Encryptor (HAIPE) Products, CNSS Policy No. 19, National Security Agency, Ft. Meade, Md., February. bThe Transport Layer Security (TLS) Protocol Version 1.1, 2006, April. Available at . Accessed August 22, 2008. cWorld Wide Web Consortium (W3C). 2005. XML Key Management Specification (XKMS 2.0), June 28, 2005. (W3C comprises Massachusetts Institute of Technology, United States; ERCIM [European Research Consortium for Informatics and Mathematics] consisting of 20 countries; and Keio University, Japan). Available at . Accessed August 22, 2008. dKaren Scarfone and Paul Hoffman, Computer Security Division. 2008. Guidelines on Firewalls and Firewall Policy, Special Publication 800-41, Revision 1 (Draft), Information Technology Labora- tory, National Institute of Standards and Technology, Gaithersburg, Md., July. Available at . Accessed April 30, 2009. eAlfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone. 1996 (1st ed.), 2001 (5th ed.). Handbook of Applied Cryptography, Section 12.7.2., CRC Press, New york. fDefense Information Systems Agency. 2009. “Host Based Security System (HBSS) Fact Sheet,” Department of Defense, Washington, D.C. Available at . Accessed August 22, 2008. gGary Machon, National Information Assurance Research Laboratory (NIARL). 2007. “A Mech- anism for Risk Adaptive Access Control (RAdAC),” National Security Agency, Ft. Meade, Md., March 14. Available at . Accessed August 22, 2008. hAnoop Singhal, Theodore Winograd, and Karen Scarfone. 2007. Guide to Web Services Security, NIST Special Publication 800-95, Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology, Gaithersburg, Md., August. Available at . Accessed August 22, 2008. iEustace King. 2008. “Transforming IA Certification and Accreditation Across the National Secu- rity Community,” Crosstalk: The Journal of Defense Software Engineering, July. Available at . Accessed August 22, 2008.

OCR for page 165
173 APPENDIX E The naval forces are to be commended for their current enterprise vision 12 and their existing detailed architectures at program levels. They must now ensure that their objective detailed, end-to-end architecture is refined and communicated and accepted broadly. Moreover, a focus on integration and transition from the current state to the desired end state must be maintained. 12Victor Ecarma. 2009. “DON Enterprise Architecture Development Supports Naval Transformation,” CHIPS, Vol. 27, No. 1, January-March, pp. 30-32. Available at . Accessed April 30, 2009.