4
A Suggested Technical Response to Cyberthreats and Information Assurance Needs

This chapter addresses technical issues associated with information assurance (IA) and suggests technical responses to help address exposure of naval forces to future cyberthreats and unsecure system structures. The committee’s view is that the Department of the Navy (DON) needs to enhance its present network architecture plans and IA principles significantly to mitigate the present and future threats to its critical operational information technology (IT) systems, which were discussed in Chapter 1. Dependency on elements of the Global Information Grid (GIG) for certain naval missions, in particular, requires that significant IA-related accommodations be made as part of the naval enterprise architecture (EA). In general, it is understood that commercial off-the-shelf (COTS) systems and communication services, while of tremendous benefit to the Department of Defense (DOD) in terms of developmental speed and economic efficiency, are not typically designed with the levels of assurance expected of critical military applications. Intermediate stages of the GIG IA architecture are likely achievable in reasonable time frames and at reasonable cost, but will require substantial improvements to supplement current IA technologies. Recognizing the expected long lifetime of the GIG architecture and its derivatives, the committee’s view is that the DON needs to plan actively for the insertion of emerging technologies as part of its architectural plan.

This chapter also offers recommendations focused on naval research and development (R&D) investments and on the rapid acquisition of new, responsive IA capabilities when they are necessary to counter threats.



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 72
4 A Suggested Technical Response to Cyberthreats and Information Assurance Needs This chapter addresses technical issues associated with information assurance (IA) and suggests technical responses to help address exposure of naval forces to future cyberthreats and unsecure system structures. The committee’s view is that the Department of the Navy (DON) needs to enhance its present network architecture plans and IA principles significantly to mitigate the present and future threats to its critical operational information technology (IT) systems, which were discussed in Chapter 1. Dependency on elements of the Global Informa - tion Grid (GIG) for certain naval missions, in particular, requires that significant IA-related accommodations be made as part of the naval enterprise architecture (EA). In general, it is understood that commercial off-the-shelf (COTS) systems and communication services, while of tremendous benefit to the Department of Defense (DOD) in terms of developmental speed and economic efficiency, are not typically designed with the levels of assurance expected of critical military applications. Intermediate stages of the GIG IA architecture are likely achievable in reasonable time frames and at reasonable cost, but will require substantial improvements to supplement current IA technologies. Recognizing the expected long lifetime of the GIG architecture and its derivatives, the committee’s view is that the DON needs to plan actively for the insertion of emerging technologies as part of its architectural plan. This chapter also offers recommendations focused on naval research and development (R&D) investments and on the rapid acquisition of new, responsive IA capabilities when they are necessary to counter threats. 72

OCR for page 72
73 A SUGGESTED TECHNICAL RESPONSE ARCHITECTURAL VIEWS FOR NAVY INFORMATION ASSURANCE RISK MITIgATION Enterprise architecture refers to the practice of applying a comprehensive and rigorous methodology for describing the structure and behavior of an organiza - tion’s processes, information systems, personnel, and organizational subunits so that they align with the organization’s core goals and strategic direction. Although often associated with information technology systems, EA is the highest level of an architecture that relates more broadly to the practice of mission optimization by addressing the business mission architecture, performance management, and process architecture. As applied to the Navy and Marine Corps, the enterprise architecture provides the discipline for managing change and complexity within the naval enterprise, especially with constrained budgets. Without an accepted and broadly leveraged enterprise architecture, agile actions in one part of an enterprise could inadvertently be detrimental to another part. For the naval forces, EA must be viewed broadly, extending well beyond the traditional boundaries often associated with IT architectures. For the purposes of information security, IA considerations are a critical aspect of the EA. Taking into account key mission areas, IA considerations must include the following: • How to engage in and respond to information attacks; • How to deal with insider threat issues; • What the impact and response mechanism should be for communications system jamming and data-link loss; • What the placement and use of both physical and cyber intrusion sensors should be for optimum protection; • How to best detect and mitigate information theft and tampering; • How to allocate user access to information systems dynamically, to account for rapidly changing circumstances; and • How to monitor IA performance as a necessary aspect of continuous sys - tem improvement as threats evolve. Today, systems are being integrated without full consideration of the impacts on information assurance, which can lead to unanticipated vulnerabilities 1 and overarching system weaknesses. To counter such vulnerabilities, the EA should be designed according to a set of principles that address the essential characteristics of a system for assuring information. The process for architecture development must be iterative and adaptive to ensure that naval systems will remain robust in the face of emerging threats and evolving technologies. The remainder of this section discusses a set of principles to guide the incorporation of IA throughout a 1 In some cases vulnerabilities are known but are considered acceptably low risks.

OCR for page 72
74 INFORMATION ASSURANCE FOR NETWORK-CENTRIC NAVAL FORCES capability life cycle and describes a set of technologies that the naval forces could consider to enhance their assurance. The Influence of the global Information grid Architecture on Current Developments The missions of all Department of Defense Services are becoming more complex and dependent on information sources distributed widely around the globe. Consequently, the DOD has developed a vision for the GIG. Current plans are to build out a DOD-wide architecture serving the needs of all Services and coalition partners for its information, warfighting, and business needs. It is this broad vision for the GIG to encompass all aspects of naval operations that causes concern to this committee. The GIG’s guiding principles are to provide information services anywhere and anytime in an architecture that is extensible, affordable, and assurable, providing the full range of services necessary to support the (joint) missions of each of the Services.2 Thus, one key issue of concern for this committee is the integrity and the trust of the information networks and the computational systems that constitute the GIG. Based on a core set of attributes that the DOD and the DON have advocated, a set of principles can be enumerated from GIG architecture descriptions that should guide naval information and computational systems design and development: • Design for interoperation across (mobile) platforms. The basic informa- tion architecture should enable interoperability and should be augmented to ensure that information assurance and trust can be achieved. Furthermore, the gateway of services and data should be conducted through the application of high-assurance devices. • Encapsulate modules for extensibility. For a system to operate properly, functions and services should be encapsulated in a manner that supports easy integration into multiple solutions and applications. • Isolate application content data from process control information. Data, applications, and business processes should be separated to ensure isolation of control information from application-related content. These principles are at the core of object-oriented design and provide exten - sibility, incremental development, and efficiency through reuse of common services and data. With respect to the defense of the GIG and protection of its critical services and interfaces, the IA architecture aspects of the GIG must also 2 Department of Defense Chief Information Officer. 2007. Global Information Grid Architectural Vision: Vision for a Net-Centric, Service-Oriented DoD Enterprise, Version 1.0, Department of Defense, Washington, D.C., June, p. 24. Available at < http://www.defenselink.mil/cio-nii/docs/ GIGArchVision.pdf>. Accessed November 17, 2008.

OCR for page 72
75 A SUGGESTED TECHNICAL RESPONSE include principles to prevent attack and security breaches, and to detect when security is compromised and to respond. The following principles are suggested by the committee: • Segment systems and separate communication pathways into trust levels. Wherever practical, efforts should be made to segment information systems into tiers corresponding to different levels of needed security. Separation into dif - ferent tiers must include the establishment of suitable controls (technical and procedural) related to accessing higher security tiers from lower security tiers. Technical controls can be software-based and hardware-based, depending on the level of security desired and the specifics of the systems in question. Suitability depends on the risks associated with undesired access occurring and the costs associated with implementing tighter controls (cost can be measured in dollars, system performance degradations, system usability, and other ways). • Encrypt channels and enforce (policy-based) access controls at the inter- faces. To help protect the core network and critical services from attack, data and control information on the network should be encrypted and the interfaces to the network should have strict access controls.3 • Audit and archive encapsulated modules for security. Information services that are part of the core should be implemented as encapsulated software modules, with strong configuration control of their interfaces and with the requirement that they be subjected to a monitoring infrastructure that audits the use or misuse of modules to isolate trouble or IA failure. • Advanced IA design principles, IA tools, and IA products should be per- vasively deployed at the network level and to the end points and should be con - tinuously refreshed. To allow rigorous audit and response to the data entering and moving through the GIG, IA tools, such as those being developed and deployed for the Comprehensive National Cyber Initiative, should be installed at the edge and broadly across the critical internal systems and services that constitute the GIG, providing the basis for boundary protection within a layered-defense assur- ance system. Assurance cannot be guaranteed without also pushing IA tools to the hosts and client machines that use and depend on the GIG.4 3 Encryption policies and technology for sensitive information are well defined in DOD policy documents, such as the National Policy on the Use of the Advanced Encryption Standard to Protect National Security Systems and National Security Information (CNSSP-15), and the classified encryp - tion technologies maintained by the National Security Agency. See . Accessed February 18, 2009. 4 One example of such tools is the Host-Based Security System, based on McAfee and other COTS products and being deployed across the GIG by the Defense Information Systems Agency. However, as discussed in Chapter 2, current COTS products do not protect against so called “zero-day” exploits that have not been previously seen. See Secunia, 2008, Internet Security Suite Test, October. Avail - able on the Internet at . Accessed November 14, 2008.

OCR for page 72
76 INFORMATION ASSURANCE FOR NETWORK-CENTRIC NAVAL FORCES The Dependency of the global Information grid on COTS Technologies The application of the design principles provided above to Navy systems is a critical part of achieving needed information assurance levels. However, without demanding that DON system designs consider IA properties to be of comparable priority with additional system functions, system cost, and system efficiency, the Navy and Marine Corps will be in the position of assuming levels of risk that have not been given sufficient consideration. Example of the Need for IA Principles to Support global Information grid Design Principles Service-Oriented Architectures The design principle of extensibility of the enterprise architecture is largely provided by the traditional object-oriented paradigms that have culminated in a service-oriented architecture (SOA) implementation. SOAs enable open, flex- ible, and adaptable systems and are designed to readily enable interoperability across disparate systems that may be under the control of different ownership domains.5,6 This architecture also allows for faster integration of mission or busi - ness processes, both within the DON as well as across the larger DOD organiza - tion. However, SOA can be both an opportunity and a vulnerability for the GIG, as it offers flexibility to evolve capability over a wide class of users, but also offers paths for potentially vicious code to find its way into a warfighting system. Within the DON as well as the larger DOD community, SOA implementations have focused heavily on Web services as the enabling technology. A discussion of SOA approaches planned by the Navy and associated IA design consideration is provided in Appendix E. SOA as an architectural approach to building distributed systems is not inher- ently vulnerable; however, implementations of SOA using specific technologies, such as Web services, could require the application of special security protection to mitigate broad threats to the DON and DOD enterprises. For example, in an object-oriented, distributed computing environment such as that supported by SOAs, communicated data can include embedded code that the recipient uses to integrate with another information service(s). The consequence to IA is obvious: an object-oriented framework provides a code-injection platform that not only serves the intended system participants, but also can serve potential attackers who 5 OASIS [Organization for the Advancement of Structure Information Standards] Open Organiza- tion. 2006. Reference Model for Service Oriented Architecture (SOA) 1.0, Billerica, Mass., October 12. Available at . Accessed August 22, 2008. 6 M. Brian Blake. 2007. “Decomposing Composition: Service-Oriented Software Engineers,” Special Issue on Realizing Service-Centric Software Systems, IEEE Software, Vol. 24, No. 6, pp. 68-77, November/December.

OCR for page 72
77 A SUGGESTED TECHNICAL RESPONSE intend to insert their system exploitation code. Without IA design principles that are applied to help mitigate the risks attendant with new commercial technologies, IA can be severely impacted in a variety of undesirable ways. The capability just described is exemplified in modern computing on the Web and within COTS products generally. Web pages fetched from a server are not passive documents, but rather are complex objects extended with code (such as JavaScript) to render the document’s content, including perhaps a rich set of embedded media, in a local client browser. Indeed, modern document formats (Word .doc, and Adobe .pdf) are not passive text files, but are full-fledged com - putational objects with embedded code that must execute in order to render and display the document at a client machine. When code is injected into any coop- erating process, the key IA question is this: Is that code benign and friendly, or malicious and dangerous? Irrespective of the manner in which the active data are communicated (whether they are encrypted and protected in transit or not), the data injected into a process may pierce security boundaries by appearing compli - ant with the interface policy. Consequently, object-oriented computing invites certain IA risks by serving adversaries who have seized the opportunity to inject their malicious code in myriad ways. SOA environments that fully embrace the object-oriented paradigm inherent in Web services thus require special attention from an IA perspective. Traditional perimeter and host-based security solutions and technologies are limited in their ability to protect Web services, given the dynamic nature of Web services-based SOA environments that often extend beyond the operational and physical boundaries of a single domain or network. This situation is exacerbated because, all too often, many organizations allow Web services traffic to flow, without restrictions, through firewalls, given that they use the same ports and protocols as Web traffic. Although enterprise service buses have been introduced as enterprise-wide containers of Web services, the state of the art in these systems lacks the interoperability policies and protocols required to securely integrate an organization as large as the DON’s system of systems. The GIG-influenced archi- tectural design principles envisioned for future naval platforms and systems clearly point toward making use of COTS products within an SOA framework, and pos- sibly cloud computing architectures as well.7 Hence, the committee believes it to be inevitable that future Navy systems will be subjected to new and more complex IA vulnerabilities presented by the use of SOAs and related COTS products. 7 Cloud computing is a computing paradigm in which tasks are assigned to a combination of con - nections, software, and services accessed over a network. This network of servers and connections is collectively known as “the cloud.” The concept of cloud computing and acquisition of software as a service for naval forces was not examined in detail by the committee; however, these concepts also carry IA risks and vulnerabilities of which the naval forces should be aware. For a recent article discussing these risks, see Dan Goodin, 2009, “Multi-Site Bug Exposes Cloud Computing’s Dark Lining,” The Register®, March 12. Available at . Accessed March 23, 2009.

OCR for page 72
78 INFORMATION ASSURANCE FOR NETWORK-CENTRIC NAVAL FORCES MAJOR FINDINg: As part of its implementation of network-centric warfare capabilities, the Department of the Navy is aggressively embracing integra - tive 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. MAJOR RECOMMENDATION: In order to provide the appropriate level of information assurance, the Office of the ASN(RDA) should adopt and 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. In addition, these principles need to be embraced throughout the system life cycle and adopted by existing naval systems as they are upgraded. IA Risks of Current COTS Technologies Naval mission capabilities are being designed and built today by logically integrating and coupling information systems and capabilities to weapons and sensor systems. Correspondingly, assuring access to and use of this information technology is becoming increasingly critical to avoiding degradation in mission performance. Given the pervasive use of COTS technologies as the basis for these integrations and the questionable state of information assurance that these prod - ucts provide, defending naval systems is significantly more difficult. It requires protections against opportunities for adversaries to attack using jamming, cyber manipulation, physical attack, malicious code injection, and sabotage anywhere in the network. As described in Chapter 1, new vulnerabilities associated with COTS software and hardware are regularly reported by government agencies established to monitor cyberthreat activities. For example, weekly bulletins listing and rank - ing newly discovered software and hardware vulnerabilities are provided by the United States Computer Emergency Readiness Team.8 Additionally, examples of COTS-related vulnerable hardware and software incidents are routinely reported in the public media.9 Related to this risk, the long-term vision of the GIG provides for a phased approach to the development of a common communication infrastructure, pro- viding multiple security levels and IA by logically isolating disparate levels (as 8A profile of weekly vulnerability bulletins is available at . Accessed March 19, 2009. 9 See footnote 27 in Chapter 1 of this report for examples of postings of daily cyberthreats and Internet security news alerts on CyberInsecure.com.

OCR for page 72
79 A SUGGESTED TECHNICAL RESPONSE represented in Figure 4.1).10 In this vision, IA technology improvements are expected, over time, to provide the technical means for safely integrating multiple communications paths with the levels of assured separation required for a rich variety of naval missions. yet, in the opinion of this committee, for certain criti- cal military applications, such technical capabilities may not be sufficient when relying on today’s COTS technology or on that available in the foreseeable future. Given the current state of IA in the commercial marketplace today and the long- term vision of the GIG’s communication substrate, as represented in Figure 4.2, the committee believes that—for critically sensitive systems—it is technically prudent to depend on physical isolation of multiple data paths in current Navy communication systems designs, even though one might find various efficiencies in relying on software-based logical isolation. This situation creates a new set of security design issues that is well repre - sented by the specific cases of the Navy’s current design of the DDG-1000 and the Consolidated Afloat Networks and Enterprise Services (CANES) communication subsystems. For example, the logical block diagram of the onboard communica - tion system and its physical layout aboard ship of the DDG-1000 was presented to the committee.11 The design reveals that the communication channels spanning multiple trust levels, including control of the ship, all flow within the same physi - cal cabling and switching subsystems. The vulnerable COTS networking products cited above serve as the core equipment used in this design. Although the com - mittee did not conduct a detailed review of the IA analyses that were performed to certify and accredit this design, it is concerned by this approach. The design has been certified and accredited, but the approach of relying solely on logical (software-based) isolation of critical networks nonetheless introduces a level of risk that physical separation of specific critical network systems would avoid. The committee believes that the Navy has to decide in its overarching IA policy which levels of risk it is willing to take. The level of risk associated with consolidated critical networks may be appropriate; however, the committee believes that deci- sions about such levels of risk should not be delegated to system designers to decide, and should include the inputs of a broader set of naval leadership. Through many decades of evolutionary development, the naval forces have acquired a vast array of information-based systems. In aggregate, these systems address naval forces requirements for communications and networking, data pro - cessing, and command and control. With FORCEnet as the context, the challenge now is to get broad user acceptance of the architecture, incorporate various naval 10 Department of Defense Chief Information Officer. 2007. Global Information Grid Archi - tectural Vision: Vision for a Net-Centric, Service-Oriented DoD Enterprise , Version 1.0, Depart- ment of Defense, Washington, D.C., June. Available at . Accessed February 17, 2009. 11 Myron Liszniansky, DDG-1000 Software Integration Manager, Program Executive Office Ships, “A Cost-Effective Approach to Certification, Test, and Evaluation (CTE),” presentation to the com - mittee, June 18, 2008, Washington, D.C.

OCR for page 72
80 FIgURE 4.1 The long-term vision of the Global Information Grid (GIG) with fully integrated but logically separated multi-tier security channels. NOTE: REL = Rights Expression Language, used to enable the authorized distribution and protection of valuable data. Other acronyms are defined in Appendix A. SOURCE: Adapted from Craig Harber, Enterprise IA Architecture and Systems Engineering Office, Information Assurance Directorate, National Security Agency, 2008, “GIG Information Assurance Architecture, Protecting National Security Enterprises” (viewgraph presentation). Available at . Accessed October 23, 2008.

OCR for page 72
Transition to the GIG End-State Requires an Evolving Role for Cross-Domain Connectivity Intermediate Stage Transactional Point Solutions Deployed Standardized Solutions Cross-Domain Between Security Deployed in Access Decisions Domains “Guard Farms” FIGURE 4.2 Phased transition of the Global Information Grid (GIG) architecture includes an intermediate stage that may be achievable in a reasonable time frame (dates shown are notional). SOURCE: Adapted from Department of Defense Chief Information Officer, 2007, Global Information Grid Architectural Vision: Vision for a Net-Centric, Service-Oriented DoD Enterprise, Version 1.0, Department of Defense, Washington, D.C., June. Available at . Accessed November 17, 2008. 81 Figure 4-2 R01471 top half vector editable lower half uneditable bitmapped image

OCR for page 72
82 INFORMATION ASSURANCE FOR NETWORK-CENTRIC NAVAL FORCES assets into the architecture, and ensure that naval capabilities fully embrace the IA principles previously discussed. The architecture should also align with the broader GIG vision, which incorporates many of the core principles. Although the naval forces have made an excellent start with their “to-be” architecture, the committee’s assessment is that successful realization will be challenging. The naval enterprise is as complex and diverse as any commercial or other government infrastructure. Making the situation more difficult are the challenging requirements of naval operational missions relying on global reach, a vast user base, a highly diverse set of platform types, and time sensitivities in an environment in which information attack can cripple operational capabilities. The designers of the to-be GIG architecture recognized the need for a phased introduction to the long-term vision of a fully enabled, globally accessible SOA as IA matured over time. Figure 4.2 displays this phased transition, showing an intermediate stage that is likely achievable in a reasonable time frame, given substantive and realistic improvements in IA capabilities and a case-by-case reconsideration of COTS dependencies. The ultimate long-term capabilities of the fully developed GIG remain largely out of reach without substantial new breakthroughs in IA. Although the naval forces can implement security protection on a service-by- service basis, a more effective IA strategy to securing Web-service-based SOAs is to externalize crosscutting security functionality, such as encryption, authentica - tion, auditing, policy enforcement, and so on, into a shared services infrastructure that can be consistently managed, configured, and coordinated by security pro - fessionals rather than by individual development teams. An example of a shared security services infrastructure would be the integration of the Navy’s CANES Web services implementation with the Net-Centric Enterprise Services (NCES) security services structure developed and deployed by the Defense Information Systems Agency (DISA).12 It is recognized that there are IA trade-offs associated with externalizing and centralizing security functionality (e.g., concentration of risk or overdependence on a central security organization to be capable of adequately addressing the security and operational needs of a complex distributed system). However, the DON, as part of implementing SOA-based capabilities, should explore the trade-off space to find the most viable solution. In any case, because of GIG-based interdependencies, the Navy and Marine Corps SOAs will need to be developed in very close coordination with the DOD community. MAJOR FINDINg: The Global Information Grid (GIG) architecture promises to provide secure information services that are envisioned to be electronically integrated into weapons systems and other mission-critical control systems. This vision is highly dependent on trustworthy commercial off-the-shelf (COTS) 12 See DISA’s NCES Service Oriented Architecture Foundation services. Available at . Accessed November 14, 2008.

OCR for page 72
86 INFORMATION ASSURANCE FOR NETWORK-CENTRIC NAVAL FORCES DON needs to be prepared to defend its own portions of the GIG as advised in this chapter. Advanced Research and Development Strategy For the reasons outlined above, the committee believes that it is necessary for the DON to significantly increase its own science and technology program in IA19 and to develop relationships with a sufficient number of leading researchers focused on IA. The Navy’s own science and technology program can be grown quickly by leveraging ongoing advanced R&D programs at the Defense Advanced Research Projects Agency (DARPA), Air Force Office of Scientific Research (AFOSR), Army Research Office (ARO), Intelligence Advanced Research Projects Activity (IARPA), National Security Agency (NSA), National Science Foundation (NSF), Department of Homeland Security (DHS), other federal R&D agencies, University Affiliated Research Centers, Federally Funded Research and Devel - opment Centers, and industry investments as appropriate. Leveraging advanced R&D from others could bridge the technical capability gap, enabling the DON to potentially leap ahead of the current cyberthreat and better position naval forces against a clear and present cybersecurity danger that threatens the ability of the naval forces to execute their missions. Given the trends in military information technology and networks, the cur- rent and growing sophistication of potential adversaries in cyberspace, the current posture of DON information assurance, and the capability gaps in defending against the cyberthreat, the committee recommends a double-pronged naval IA research strategy: (1) invest in cybersecurity research (a) to address naval- specific capability gaps and develop a robust research program that is relevant to the Navy and that may not be currently addressed elsewhere, and (b) become an active participant in the IA research community to develop the knowledge and relationships needed to rapidly transition technology; and (2) establish a rapid technology testing and evaluation laboratory and a technology insertion program to leverage and accelerate ongoing research in cybersecurity into Navy networks.20 The committee recommends below that the Office of Naval Research (ONR) play a leading role in IA research and development to establish the knowl- edge base and intellectual property of the Navy and Marine Corps for insertion of IA into naval systems. 19 I n conformance with the Secretary of the Navy Instruction (SECNAVINST) 5239.3A, from the Secretary of the Navy to All Ships and Stations re: Department of the Navy Information Assurance Policy, Department of Defense, Washington, D.C., December 20, 2004, p. 15, item 3. 20 In 1999, the Department of the Navy adopted a new process for concentrating its scientific and technological resources to prepare for the Next Navy. The Future Naval Capabilities (FNC) process shifted the science and technology investment focus from individual technology goals to the most highly desired future capabilities for naval forces. Additional FNC information is found on the Internet at . Accessed November 12, 2008.

OCR for page 72
87 A SUGGESTED TECHNICAL RESPONSE Suggested Elements of an Advanced Research Program The committee reviewed a number of previous R&D surveys in IA, includ- ing a 2006 federal interagency report,21 an Air Force-commissioned study,22 a Defense Science Board report,23 and previous cybersecurity R&D reports from the National Research Council.24 The committee’s view is largely in agreement with many of the findings and conclusions in those studies. By way of summary, the severity of current and future threats has been identified, and research activities have responded to these threats by studying new concepts in system design and security functions. Broadly, active research is ongoing in the following areas: • Secure network functions (routing, addressing); • Computing systems that are of high integrity and trusted; • Survivability and recovery of networks after large-scale attack, including rapidly reestablishing trust; • Secure compositions of complex systems composed of insecure elements; • Trustworthy platforms and secure application designs; • New authentication and access control systems to protect the privacy of data and restrict access to critical systems; and • New models and metrics for security. Nonetheless, based on the committee’s review of these studies and on brief - ings from Navy personnel responsible for the Navy’s R&D initiatives,25 a number of capability gaps in network, system, host, user, and privileged-user security became apparent. There are existing federal government research investments in these areas, but the Navy needs to be a stronger participant in the IA research com- munity to help ensure that these efforts are directed at Navy-specific needs and to be able to understand and leverage the research results. The briefing on naval research efforts from the Office of Naval Research to the committee revealed that ONR has limited resources and few programs in IA that address important aspects 21 Interagency Working Group on Cyber Security and Information Assurance. 2006. Federal Plan for Cyber Security and Information Assurance Research and Development, Executive Office of the President of the United States, Washington, D.C., April. 22 Thomas F. Saunders, Chair, USAF Scientific Advisory Board Summer Study, “Implications of Cyber Warfare,” presentation to the committee, March 6, 2008, Washington, D.C. 23 Defense Science Board. 2007. Defense Science Board 2006 Summer Study on Information Management for Net-Centric Operations, Volume I, Main Report, Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics, Washington, D.C., April; presentation [of this report’s results] to the committee by Vincent Vitto, Washington, D.C., March 6, 2008. 24 National Research Council, 2007, Toward a Safer and More Secure Cyberspace, The National Academies Press, Washington, D.C.; and National Research Council, 2002, Cybersecurity Today and Tomorrow: Pay Now or Pay Later, National Academy Press, Washington, D.C. 25 Ralph Wachter, Program Director, Software and Computer Systems, Office of Naval Research, “Overview of the Office of Naval Research and the Naval Research Laboratory’s Information Assur- ance Related R&D,” presentation to the committee, June 18, 2008, Washington, D.C.

OCR for page 72
88 INFORMATION ASSURANCE FOR NETWORK-CENTRIC NAVAL FORCES of current and future threats. Appendix F of this report provides a representative sample and discussion of advanced security and IA concepts being pursued by academic and industrial research laboratories. This sample can serve as a starting point for the naval research community to consider as candidates for transfer into naval application.26 In making this suggestion to the Navy, the committee’s premise is that there is no clear, demonstrably precise set of technology elements that will provide suf - ficient IA within the long-term vision of the GIG architecture. However, IA is an ongoing challenge that must keep ahead of the growing threats devised by clever adversaries. (It is also noted that although the research topics suggested do not include encryption and cryptography, the committee views advances in encryption as an obviously important area of IA, and at the same time it views such advances as representing only a fraction of the needed set of technologies to address fully the IA threats discussed in Chapter 1.) Overall, IA is a continuously sought end goal cutting across the entire enterprise; it must be refreshed and maintained on an ongoing basis, largely driven by (1) new research (and intelligence) into the nature of adversarial threats, (2) new concepts and techniques to counter those threats, and (3) the degree of increasing dependence on information systems to carry out critical naval missions. A summary of suggested IA advanced research topics for the Navy is pre- sented in Table 4.1, organized by topic under the headings Network Level, Sys - tem Level, Host Level, User Level, and Privileged-User Level. (As previously noted, a more complete discussion of these topics, including current sponsoring organizations, is presented in Appendix F.) The committee suggests that these topics be used to help formulate a naval IA R&D roadmap, drawn from a yet-to- be-prioritized set of naval IA system needs. Many examples of naval IA needs are common across the Services and are spelled out in the Navy’s Information Systems Security Program (ISSP).27 Examples of naval-specific IA needs include advances to address naval afloat and marine forward-deployed forces, such as resilient networks, artificial diversity, and virtualization for security. 26 Naval-specificIA needs evolve through a network-centric operation that links together Navy ships, aircraft, and shore installations into highly integrated computer and telecommunications net - works, which include integrated air defense and integrating targeting data gathered by other ships and aircraft. Forward-deployed expeditionary Marines will also have specific needs associated with data integrity and availability. The DON has identified its broad-topic IA needs in its Information Systems Security Program, as summarized in Table 2.3 in Chapter 2 of this report. 27As described in Chapter 2, the Navy ISSP research, development, testing, and evaluation pro - gram works to provide the Navy with these essential information assurance elements: (1) assured separation of information levels and user communities, including coalition partners; (2) assurance of the telecommunications infrastructure; (3) assurance of joint user enclaves, using a defense-in-depth architecture; (4) assurance of the computing base and information store; and (5) support for assurance technologies, including a Public Key Infrastructure and directories.

OCR for page 72
89 A SUGGESTED TECHNICAL RESPONSE TABLE 4.1 Suggested Elements of an Advanced Naval Information Assurance Research Program Program Element Description • Border Gateway Protocol/Domain Name Service protocol “hardening”— Network Level core network protocols responsible for routing and naming services for all Internet Protocol traffic. • Network filtering—filtering strategies to detect incoming attacks as well as outgoing exfiltration of sensitive information. • Network visualization—tools for alerting network operation to attack conditions. • Resilient networks—networks to ensure continual service while under denial-of-service attacks. • Source attribution—tools for ascertaining where a connection or attack is actually coming from. • Decoy networking—strategy to lure an adversary to an isolated network from which it can be monitored for intelligence (methods, behavior, and sources). • Secure composition—means to ensure security properties of the whole System Level system. • Artificial diversity—techniques to diversify computing fabric that allows interoperability, but also allows a change in structure of the same software for another implementation. • Collaborative software communities—a sharing of attack data to harden other instances of software against in-progress attacks and developing related security alert sharing technologies. • Privacy-preserving technologies—technologies to allow effective sharing of data while maintaining strict compartmentalization. • Counter-evasion techniques for obfuscated malware—methods to identify Host Level malware-embedded content flows. • Virtualization for security—technology for server consolidation and isolation of untrusted applications from the host operating system. • Self-healing software—software that monitors and models its own behavior. • Hardware life-cycle tamper resistance—techniques to detect compromises in chip-level designs and implementations during supply chain life-cycle attacks. • Behavior-based security—analysis of user behavior patterns to detect User Level threats with reasonably high reliability. • Defense through uncertainty—leveraging uncertainty in deployed environments to make exploitation difficult by adversary. • Role- and behavior-based access control—means of associating logical Privileged-User Level roles of a user with the specific data and applications used by the specific roles defined with an enterprise and a means of granting access to network resources. • Self-protecting security technologies—means of preventing denial-of- service attacks caused by a user accidentally or by design.

OCR for page 72
90 INFORMATION ASSURANCE FOR NETWORK-CENTRIC NAVAL FORCES Current Naval Information Assurance Research and Development Budget Based on presentations to the committee and on the Navy RDT&E (Research, Development, Test and Evaluation) Budget Item justifications documents for Fy 2009, the Navy IA research budget over the past several years appears to the committee to be to grossly underfunded for properly addressing the escalating IA threats and challenges confronting the Navy. In the committee’s view, this research budget appears to be underfunded even to be able to leverage the research invest- ments of other agencies properly.28 The information assurance basic research funding level requested by the Office of Naval Research, at approximately $2 million per year, is approximately a factor of 20 less than the yearly invest - ment in IA research by NSF and a significant factor less than funding investments by DHS and IARPA and by other relevant agencies with science and technology programs in IA.29 A similar deficiency is found when comparing Navy RDT&E “IA basic research” with similar DOD military service research organizations’ RDT&E Exhibit R-2 budget justification. For example, the Air Force describes in its ISSP RDT&E Exhibit R-2 a requested basic research program for leveraging IA investments at DARPA, NSA, IARPA, DHS Advanced Research Activity, and leading universities.30 The funding in this Air Force program is consistently three to four times higher than the closest similar Navy ISSP funding expressed for such activities at ONR. This Air Force program represents an example IA leveraging activity that can, in theory, provide access to leading-edge IA technology and maximum return on the Navy’s IA R&D investment. The current gaps in capability for naval forces information assurance are made even more significant by a lack of strategy for investing in advanced R&D to redress these gaps, and thus should be corrected. The committee is not suggesting that the DON needs to match the investments of these other organizations, but it does need to be resourced as a 28 Department of the Navy. 2008. Research, Development, Test and Evaluation, Exhibit R-2, Fiscal Year 2009 Budget Estimates, Justification of Estimates. Washington, D.C., February. 29 The National Science Foundation Program Solicitation 08-521 (Cyber Trust, March 24, 2008), reported $34 million in NSF Cyber Trust program funds for Fy 2008. The successor to this solicitation, NSF Program Solicitation 08-578 (CISE [Computer and Information Science and Engineering] Cross- Cutting Programs, Fy 2009 and Fy 2010, October 1, 2008), reports $45 million in program funds available each year in Fy 2009 and Fy 2010 for Trustworthy Computing. NSF, July 1, 2008, online solicitation publications: . Accessed April 29, 2009. DHS announced awards of $11.7 million in grants for cybersecurity research to 13 recipients from industry and academia. See Federal Computer Week, online publication, “DHS Awards $11.7 Million for Cyber Research,” August 13, 2008. Available at . Accessed April 29, 2009. 30 Department of the Air Force. 2008. “Exhibit R-2, RDT&E Budget Item Justification: 0303140F Information Systems Security Program,” Fiscal Year (FY) 2009 Budget Estimates: Research, Devel- opment, Test and Evaluation (RDT&E), Descriptive Summaries, Volume III, Budget Activity 7, Wash- ington, D.C., February, p. 1549. Available at . Accessed April 29, 2009.

OCR for page 72
91 A SUGGESTED TECHNICAL RESPONSE stronger IA R&D participant, in order to, at a minimum, understand the ongoing IA research and to be able to rapidly insert it into naval networks.31 MAJOR FINDINg: The Department of the Navy has not established a suffi- ciently robust research program in IA. The funding level requested by the Office of Naval Research (ONR), approximately $2 million per year, is inadequate even to ensure that the DON effectively leverages the research investments of other agencies. Current gaps in information assurance capability for naval forces are made even more significant by a lack of strategy for investing in advanced R&D to redress these gaps. MAJOR RECOMMENDATION: The Director, Naval Research, should develop—and the Chief of Naval Operations (CNO) and the Commandant of the Marine Corps (CMC) should ensure funding for—a robust science and technol - ogy research program in information assurance. An order-of-magnitude increase in funding levels through ONR’s Naval Research Laboratory would establish the Navy as a full participant in IA technology R&D, providing the knowledge base to guide and prioritize naval implementation choices and allowing the Navy to draw from the work of outstanding members of the academic and industrial research communities. The Navy should focus its research efforts on addressing capability gaps specifically related to the needs of naval forces that are not being sufficiently addressed elsewhere. Concurrently, the Office of Naval Research should develop a rapid technology insertion program to enable the rapid deployment of solutions for responding to new threats, based on both the leveraging of internal Navy research results and the use of ongoing research results derived from the funding of other R&D organizations, such as at the Defense Advanced Research Projects Agency, National Security Agency, Army Research Office, Air Force Office of Scientific Research, National Science Foundation, Department of Energy, and Department of Homeland Security. 31 In deciding what approximate increase for an ONR IA R&D investment would be appropriate, the committee recognizes that information technology research is not a particularly capital-intensive undertaking; that is, the primary cost for such an investment is direct and indirect manpower cost. For example, according to R&D survey data available from the National Science Foundation (see ; accessed April 3, 2009), a fully funded staff-year of effort in IT R&D research effort is typically available at $200,000 to $300,000 per year, with graduate student research efforts available at a fraction of that cost. Therefore, the committee estimates that, based on a typical project staffed at three to four full-time-equivalents of effort, ONR could maintain or lever- age a core group of 10 to 15 substantive research projects by increasing its current IA funding by an order of magnitude—to the neighborhood of $20 million per year. Such an increase would allow ONR to participate more broadly in the 10 priority areas for research named in the 2006 Federal Plan for Cyber Security and Information Assurance Research and Development, as applied to naval-specific needs (see footnote 21 above in this chapter). This suggested increase to ONR IA funding should also be accompanied by proper internal milestones and mechanisms to judge whether the investment is being managed appropriately and is yielding the expected mission benefits.

OCR for page 72
92 INFORMATION ASSURANCE FOR NETWORK-CENTRIC NAVAL FORCES SPECIFIC CONSIDERATIONS FOR NAVAL RESEARCH AND DEVELOPMENT AND ACQUISITIONS WITH RESPECT TO INFORMATION ASSURANCE It is generally recognized that new types of software tools that enable the exploitation of communications networks and software applications change at a very fast pace. As a result, with regard to IA tools to counter attacks, the commit- tee places the speed of acquisition and deployment on the critical path for defense and exploitation. Correspondingly, in reviewing the R&D and acquisitions for naval forces, the committee gave significant attention to the agility that enables naval forces to conceptualize, acquire, evaluate, implement, and deploy IA tech - nology that directly supports naval systems. Indeed, coordination and integration are the strongest enablers for agility in R&D acquisitions. Three significant considerations for R&D and acquisitions form the basis for the committee’s findings and recommendations in this area: • Because security is a “weakest link” problem, the strength of an organi - zation’s security relies on the unified adoption of IA techniques against the most recently recognized exploits that pose significant risk. It is important to note that strong security at one end of the enterprise can be undermined by poor security in other parts of the network, and in fact by a single entity elsewhere in the network.32 • Time to deployment is critical. With the increasing pace of attacks, an important IA solution that is deployed too late will not be effective. The R&D organization must be agile enough to respond to threats quickly and to develop solutions that anticipate new threats. • “Fast-time implementation processes” must incorporate the full life-cycle needs and must meet IA-related standards of implementation.33 The processes for developing new solutions must account for (1) the time required for the estab - lishment of funding; (2) needed research, development, testing, evaluation, and deployment time; and (3) the establishment of life-cycle support. Existing Naval Research and Development and Acquisition Processes A review of current acquisition legislation and management instructions provided a useful basis for the committee’s finding and recommendations related to fast-time implementations. First, it appears that SECNAV Note 5000—“Rapid Development and Deployment Response to Urgent Global War on Terrorism 32 Mark Clancy, Executive Vice President, IT Risk and Program Management, Citigroup, “ Over- view of Information Assurance Best Practices—A Financial Institution Perspective,” presentation to the committee, July 17, 2008, Washington, D.C. 33 The committee defines “fast-time implementation processes” as any process adaptations that are designed to deliver targeted solutions quickly and with minimal risk.

OCR for page 72
93 A SUGGESTED TECHNICAL RESPONSE Needs”—allows the Assistant Secretary of the Navy for Research, Development and Acquisition (ASN[RDA]) “to refine the Naval Innovation Laboratory (NaIL) environment and process for rapid development and fielding of prototype solutions to meet urgent needs in the Global War on Terrorism (GWOT).”34 To paraphrase the prescribed process, an urgent need identified from the fleet or forces can get quick consideration from a Rapid Development and Deployment Committee (RDDC). The RDDC is an ad hoc committee with membership consisting of rep - resentatives from (1) the Future Naval Capabilities Technology Oversight Group; (2) the Assistant Secretary of the Navy, Financial Management, and Comptroller (ASN[FM&C]); (3) the Deputy Chief of Naval Operations, Resources, Require - ments, and Assessments (N8); (4) the Commanding General, Marine Corps Combat Development Command; and (5) the ASN(RD&A). Additional ad hoc participants are invited as needed. Figure 4.3 illustrates the fast-track process. The catalyst for the process is an urgent need with respect to GWOT. In the committee’s view, IA threats represent a concern comparable to GWOT with respect to the national security. As a result, the committee first recommends a corresponding, customized process for IA that can be initiated when an urgent need is identified. Second, one can anticipate that the current Department of the Navy opera - tions and maintenance (O&M) processes and controls provide an existing set of processes for addressing fast-track IA implementations as augmentation to already fielded systems, integrating the appropriate mixture of laboratory capabilities and available O&M resources. Given the general nature of anticipated IA implementa- tions, in the current organizational structure the committee views the DON Chief Information Officer (CIO) as an appropriate office for (1) building the business cases and deciding to go forward with the needed implementations, (2) selecting the best resources for rapid implementation, and (3) setting standards and guide - lines for secure technical implementation. In addition to the committee’s finding and recommendation reported below, a review of acquisition policy for the DOD C3I [command, control, communica - tions, and intelligence] and Weapon Programs, conducted in 2007 for the Navy and the Office of the Secretary of Defense, includes an analysis of issues associ - ated with IA acquisition.35 The committee agrees with the findings and recom- mendation from that review as summarized in Box 4.1. Two of the underlying acquisition issues reported in the review were as follows: (1) There are multiple, noncoordinated policies from various authorities governing IA (no single line of authority within the Navy), and (2) for the program managers charged with 34 Secretaryof the Navy. 2008. “Rapid Development and Deployment Response to Urgent Global War on Terrorism Needs,” SECNAV Notice 5000 [Cancelled SECNAVNOTE 5000, dated March 8, 2007], Department of the Navy, Washington, D.C., January, p. 1. 35 Daniel Gonzales, Eric Landree, John Hollywood, Steven Berner, and Carolyn Wong. 2007. Navy/OSD Collaborative Review of Acquisition Policy for DOD C3I and Weapon Programs, RAND National Defense Research Institute, RAND Corporation, Santa Monica, Calif.

OCR for page 72
94 FIGURE 4.3 Time-line illustration of the rapid development and deployment (RDD) process. This figure assumes that an urgent need is determined at the beginning of Fy 2010. RDD is a 1-year deployment process versus the multiyear process defined in Secretary of the Navy [SECNAV] Note 5000: “Rapid Development and Deployment Response to Urgent Global War on Terrorism Needs.” NOTE: Acronyms are defined in Appendix A. Figure 4-3 R01471 uneditable bitmapped image

OCR for page 72
95 A SUGGESTED TECHNICAL RESPONSE BOX 4.1 Acquisition-Related Findings and Recommendations from 2007 Navy/OSD Collaborative Review of Acquisition Policy for DOD C3I and Weapon Program Finding: There has been a proliferation of IA policy documents in recent years and guidance is often not actionable. • IA policy issuance has sharply increased in the past few years, and • Conflicts and overlaps have been found in interoperability policy. Finding: GIG IA guidance and standards are still evolving and not yet “stable.” • Rapid technology change, • PA framework under development, and • Key technologies are being developed under the leadership of industry. Finding: Large number of IA policies—many will have to be updated to be consistent with DOD Instruction 8510.bb which is now in effect. Recommendation: Acquisition • Establish technology risk areas and Technology Readiness Level for GIG interoperability areas. • Ensure independent technical assessment of GIG Program inter- operability approaches by appropriate SYSCOMs or DISA. • Move Milestone B to preliminary design review, at least for high-IT content programs. ________________________ SOURCE: Reprinted from Daniel Gonzales, Eric Landree, John Hollywood, Steven Berner, and Carolyn Wong, 2007, Navy/OSD Collaborative Review of Acquisition Policy for DOD C3I and Weapon Programs, RAND National Defense Research Institute, RAND Corporation, Santa Monica, Calif. delivering complex systems, the processes for performing IA-related capability- based assessments are often separate and distinct from system acquisition deci - sions. This committee has independently identified the same acquisition issues for naval IA. The committee’s “Organizational Considerations,” this report’s Chapter 6, discuss and propose potential solutions that would help mitigate these issues.

OCR for page 72
96 INFORMATION ASSURANCE FOR NETWORK-CENTRIC NAVAL FORCES MAJOR FINDINg: Cyberthreats change on a timescale much shorter than the DOD acquisition life cycle for developing and deploying cybersecurity technolo - gies. There are increasing risks from these cyberthreats, including risks of being unable to respond to assigned warfighting missions. Rapid acquisition and fielding of IA solutions are critical, but the committee did not see processes being put into place to support this need. MAJOR RECOMMENDATION: The committee recommends that the follow- ing specific actions be undertaken by the ASN(RDA), with the support of the Director, Naval Research, to address the timely acquisition and implementation of IA solutions: • Actively participate in DOD efforts to define and establish intelligence that provides predictions about future cyberattack techniques which are sufficient to stimulate development of defensive responses, • Use existing operations and maintenance processes supplemented by design and prototyping activities carried out by naval laboratories to more rapidly develop and implement solutions, • Establish a rapid technology testing and evaluation laboratory and a technology insertion program—modeled after the Future Naval Capabilities program—to leverage and accelerate ongoing research in cybersecurity into Navy networks, and • Establish a standard management process styled after the urgent-need process for the Global War on Terrorism (as defined in SECNAV [Secretary of the Navy] Note 5000 on “Rapid Development and Deployment Response to Urgent Global War on Terrorism Needs”).