Use of COTS Technology in C2 Information Systems: Balancing the Benefits and Risks

Introduction

The military sector is declining in importance as a developer and purchaser of high technology [1]. Industrial R&D spending has grown to be several times that of the US Department of Defense. DoD purchases of computers and electronics are now less than 5% of the total.

Development of customised military products is increasingly difficult to justify in technology areas with strong commercial competition. In mid-1994, US Secretary of Defense Dr William Perry decreed [2] that future DoD purchases should use performance-based or commercial standards where possible rather than Milspec, reversing the previous policy. He noted that “in the fields of technology most important to the Defense Department today - semiconductors, computers, software, telecommunications - the technical leadership is in [commercial] industry. If we do not accept their standards, we are not only paying the extra price needed to adapt their equipment and their technology to our requirements, but we’re also buying a generation of delay in being able to get the equipment” [1].

Military use of COTS products in areas such as personnel, logistics and finance is well advanced. Because of their different requirements and critical importance, military operational systems are usually considered separately from business systems. Superiority in C2 capability is an important strategic and tactical asset. To maintain such superiority, supporting information systems must allow ready insertion of new technology and functionality. These systems must also be robust, reliable and affordable. Use of COTS technology in operational information systems offers potential advantages here but also raises legitimate concerns regarding security and reliability.

Drivers for take-up of COTS technology

A central concept of the current Revolution in Military Affairs is that “force multiplication” can be achieved through a combination of dominant battlespace awareness, speed/mobility, coordination of various force elements, precise targeting and delivery of munitions, focused logistics, and full-spectrum defence. These factors in turn depend on advanced C2 information systems that can interoperate across system, functional and organisational boundaries. The following sections outline characteristics that favour use of COTS technology in such systems.

Converging military and commercial requirements

The functional and infrastructure requirements of military and commercial information systems are steadily growing closer. COTS office automation and database technologies, for example, are already widely used in both business and operational military systems. Consider the military parallels with the following examples:

Businesses with large fleets of vehicles use GPS and GIS to maintain real-time displays of vehicle locations.

Multinational corporations use encrypted data links for secure connectivity between separate divisions.

Commercial inter-application messaging systems meet requirements for reliable delivery (once and once only), authentication, confidentiality and integrity.

Executives at separate locations use Computer Supported Cooperative Work tools to plan confidential marketing campaigns, etc.

Software Bisque’s telescope management package could no doubt be delivered within a matter of days, whereas a custom solution could take many months. If suitable major functional elements already exist, the technological risk in large scale projects can be minimised. Functional mock-ups, using Rapid Application Development techniques with existing products, can let users clarify their requirements early in a project, reducing an important element of risk.

Interoperability

Modern military information systems should preferably be intrinsically interoperable. In support of military operations, they will need to exchange data and services with a range of other systems not specifiable at design time. Peacekeeping operations may, for example, require coordinated action between Coalition forces.

With sufficient resolve, a customised system can achieve ad hoc “bolt-on” interoperability between a list of applications and host systems. Applications and systems undergo more or less continuous development, however, and unanticipated requirements can arise at short notice. With an ad hoc approach, the overall effort required to establish and maintain interoperability increases rapidly with the number of different systems involved. If all systems can agree on common reference targets for interoperability, the effort grows more slowly. In some areas there are obvious open standards to follow such as TCP/IP. In areas of strong commercial competition, however, emerging technologies may well be either proprietary or at best supported by a coalition of vendors; stable consensus standards tend to follow somewhat later. Open standards may thus be of limited relevance with leading-edge technology, complicating efforts to establish and maintain interoperability.

Adoption of popular COTS technologies as de facto standards can help resolve the impasse here in areas such as office automation, database and GIS. In each application domain, one COTS product or family tends to dominate. Popular packages usually include import and export filters for the file formats of their main competitors. Note that agreement on a COTS database product is only a starting point here: seamless interoperability of data requires conformity of entities, attributes, schemata, etc.

Effective planning and execution of defence force operations needs up-to-date knowledge of the disposition of personnel and other assets, requiring a degree of integration between operational systems and supporting business systems [5]. Use of COTS infrastructure and applications in business areas such as logistics, personnel and office automation thus provides further impetus for use of compatible technologies in operational systems.

User familiarity and training

Complex C2 systems may intimidate occasional users. Because of the popularity of Web browsers and Microsoft Windows, these offer distinct advantages as user interfaces. DSTO’s Command Support Systems Group has observed several distributed planning exercises in networked command centres. During formulation and evaluation of plans, commanders often preferred to use familiar tools (eg. e-mail, word processing and presentation packages) even if specialised tools had better-targeted functionality.

In contrast with customised products, most popular COTS products have suitable training materials already available. Users may also be better motivated to achieve competence with popular COTS packages than with custom systems.

Management of change and complexity

With new generations of information technology arriving every two to three years, the pace of change presents uniquely challenging problems for military planners. Conceiving of, defining, developing and fielding complex C2 information systems with significant elements of innovation can easily span several generations of technology. Systems procured in the traditional manner could well be obsolescent at their time of deployment. An evolutionary development and acquisition approach [6] and selective use of functional segments from a COE library can certainly help here. Nevertheless, the march of technology still threatens to outpace customised military development. Trying to maintain state-of-the-art capability through frequent introduction of major new versions of important C2 systems will also be quite disruptive.

A basic engineering principle (applicable to hardware and software alike) is that complex systems should be structured in terms of encapsulated major areas of functionality that interact via simple clearly-defined connections. The main attractions of this focus on boundaries and interfaces (which underlies the DII COE) are that it facilitates reuse of existing design and functional elements, simplifies system analysis and construction, allows elements to evolve independently, and facilitates diagnosis of problems. In the “software component” model [7], functional building blocks obey a common set of protocols and plug into a “software backplane”. Each functional element can be decomposed hierarchically in a similar manner. Compared with tightly integrated monolithic systems, this approach simplifies overall management of complexity and facilitates incremental evolution in both functionality and technology.

A “plug and play” approach thus promises to help maintain superiority in C2 systems without overwhelming developers and users by the pace and magnitude of changes. The plug-and-play components can be COTS, semi-custom (such as with DII COE code segments) or system-unique. The opportunities presented by component frameworks such as ActiveX and JavaBeans have led to the emergence of a vibrant marketplace in “componentware”.

Problems associated with use of COTS modules in C2 information systems

The financial rewards that follow from useful innovations in information technology have led to a substantial increase in R&D in this area; the flow of improvements in hardware, software and communications technology continues unabated. Unfortunately, there are potentially serious side effects of this competition as far as use of COTS technology in critical C2 systems is concerned.

Management of instability and immaturity

Mainly through product development and differentiation, commercial suppliers strive to establish and maintain a competitive edge for their products. The so-called “feature wars” between competing office automation suites are one aspect of this jostling for market dominance. Suppliers leap-frog each other: as one product achieves nominal superiority in terms of new and apparently useful features, other suppliers match these and then go on to add even more features. Being first to market with useful new features yields distinct competitive advantages. Suppliers with no clear threat to their market dominance still have to keep introducing attractive new versions of their products, or market saturation leads to declining revenues.

The overall result is that immature new versions of products can be released in unseemly haste, with multiple “bug fix” releases before a product approaches stability and maturity (by which point it is often effectively obsolete). Customers have little option but to “upgrade” to successive releases as development and support of earlier versions ceases. Different products have different release cycles, making it difficult to synchronise system updates across several products at a time. With possible changes to APIs, file formats, etc., accompanying each major version release, the effect on a complex system with several large COTS packages can be quite disruptive. While use of COTS technology may well simplify implementation and support of individual functional components, the danger is that overall system management could become rather complex. The Software Engineering Institute at Carnegie Mellon University has performed much of the pioneering research on military application of COTS-based systems [8], including the associated management problems.

Vendor “lock in”

Having decided on a given vendor and product family to implement an area of functionality in a composite system, changing to a different vendor and/or product can be quite difficult. Circumstances outside the end-user’s control may necessitate such a change. For example, products can lose their popularity, or vendors may cease business, withdraw products, or change product orientation. Vendors deliberately seek to differentiate their products from competitors, so that closely similar replacement products are unlikely. Having chosen a set of COTS products with which to implement functional areas of a complex C2 system, one or more of these products may well have to be replaced with alternatives during system development, let alone during deployment.

Relative inflexibility of COTS technology

For a variety of reasons, including ease of installation and use, and protection of intellectual property, COTS software modules tend to be provided as “black boxes”, usually in the form of binary executables that are difficult to analyse and modify. Licence conditions often explicitly forbid any attempts to analyse the internal structure or to “reverse engineer” and modify COTS products. Even where some degree of customisation is possible, this has to be employed carefully. If a product is modified in any non-trivial way, the user rather than the vendor will probably have to accept responsibility for ongoing development and support (thus forgoing one of the major attractions of COTS). In addition, the interoperability benefits associated with use of popular COTS could well be lost. If customised to any extent, the same COTS packages used in different C2 systems may well fail to interoperate. Inability to significantly modify COTS packages can mean that requirements of C2 systems may well have to be adapted to fit the characteristics of chosen COTS packages.

Code security and reliability issues

The problems with use of COTS technology examined above are relatively minor compared with the possible consequences of malicious and/or incompetent code in a COTS product, or of undesirable interactions between products. The black box nature of COTS products is one of their major strengths in terms of the software engineering principles of modularity and encapsulation. Without access to design and implementation information, however, the disciplined design, construction and testing procedures traditionally employed with military grade software systems cannot be used to assure the overall security and quality of design and implementation of COTS-based systems.

Software is so intrinsically complex and history-dependent that it is usually not possible to exhaustively test modules of even moderate size and complexity. With black box modules, what you see is not necessarily all you get — witness the hidden “Easter Eggs” in many COTS products. The Easter Egg Web site (http://www.eeggs.com) catalogues numerous Eggs in popular products, including the following notable example in Microsoft’s Excel 97. Using a PC with DirectX drivers installed, open a new spreadsheet, press F5, type X97:L97 in the Reference box, click “OK”, tab from cell L97 to M97, then hold down the left control and shift keys and left click on the Chart Wizard. After this unusual “trigger” sequence, a full-screen undulating 3D landscape appears. Moving the mouse and clicking its buttons controls the observation point. At one point on the landscape, a scrolling display lists the Excel '97 developers. In the culture of commercial software development, development teams often try to “mark their territory” in this fashion while management tries (often unsuccessfully) to stop them.

Viruses demonstrate that covert functionality can be malicious as well as amusing. During conflict, an apparently innocuous message (containing trigger words in a predefined order, for example, and possibly sent by someone with legitimate access to the system) could activate covert functions hidden in a critical C2 information system. The system operation could then be subverted in some subtle yet effective manner, such as by delaying situation updates or generating fictitious threats, so that it would not be apparent that the system had been compromised. The covert functions could write to non-volatile memory such as a disk file to record their activation. On rebooting or installing a fresh copy of the system, the covert functions would then simply reactivate.

Software, hardware or firmware technology can be compromised during design and manufacture, while in the supply chain, or later in the field. An encrypting modem used for inter-bank electronic funds transfers in Europe was returned to the manufacturer for repair of an intermittent fault. A sharp-eyed service technician noticed that a ROM chip had been replaced with a different type. The data and programs stored in the ROM had been modified, no doubt to provide some form of trapdoor (lying dormant and not yet used as far as the bank could tell).

Intel has experienced several well-publicised problems with its Pentium series processors. To reduce the impact of design errors, Intel has introduced a “BIOS Update Feature” that modifies the microcode of certain Pentium processors when the system is initialised [9]. Although a strict authentication procedure aims to prevent unauthorised modifications, this type of development still poses a threat to critical C2 information systems — over time, details of any such authentication procedure are likely to leak out. Processors could be modified, for example, to respond to a particular nonsensical sequence of instructions by disabling hardware process and memory protection, rendering software security models ineffective. In another development that raises similar concerns, Microsoft and other software vendors provide automatic Internet-based software updates.

Traditional (low-technology) armed forces are being scaled back in the developed world, on the assumption that overall defensive capability can be maintained via superior training, systems and equipment. C2 systems are of vital importance in this context and thus become a natural target. Any thorough assessment of threats here needs to consider the range of possibilities open to a determined adversary. Several different types of remotely triggered attack are possible with compromised software and hardware, especially if given help from system developers and military personnel. Where critical C2 information systems are networked, widely deployed and use the same software and hardware, the potential impact of a successful attack is magnified. Specially designed “stealth” viruses that propagate between systems until they reach a specific target, and then remain dormant until remotely activated, are a new form of threat here [10]. Mounting a successful attack without substantial help from the inside could still be quite difficult, however. While the risks need to be kept in perspective and balanced against the benefits, the consequences of any loss of C2 capability mean that all risks must be considered carefully.

Frequent releases of new versions of COTS products not only cause management difficulties but can also raise serious concerns with respect to product quality. Software modules can be tested over part of their domain of operation, but any undiscovered problems are most likely to reveal themselves during the stress of conflict when the effects will be most disruptive. Processing loads, queue lengths, variations in timings, etc. will all increase and systems are likely to enter previously untested domains of operation. Disciplined design, implementation and test procedures are all important here in terms of producing software modules that can be trusted to perform correctly in such circumstances.

A system that includes several COTS products from different suppliers with different development teams runs the risk that the products will interact in unintended ways or will be based on conflicting assumptions about their run-time environment and behaviour. Such conflicts may well surface only when the various interacting elements enter a new regime. Hissam [11] reports on one example in a COTS-based system where conflicting assumptions regarding thread management, in conjunction with changes between operating system versions, led to serialised rather than concurrent processing of requests.

Vulnerability versus functionality

Use of COTS technology in C2 information systems can pose significant security and reliability problems. In practice, however, can defence forces procure leading edge C2 systems that are not to some extent vulnerable? Information systems and many of the technologies that comprise them are usually too complex to analyse by inspection. Whenever we accept encapsulated software or hardware on trust we expose potential vulnerabilities. Current, largely custom-built, C2 systems are still likely to use at least commercial database and office automation packages, and to execute on a commercially supplied platform and operating system. Even when full design information and source code is thoroughly analysed, experience shows that many security and reliability problems are discovered only during operational use. Customised C2 systems are thus already vulnerable in certain respects. To significantly reduce the incidence of faults and security “holes”, most of the hardware, operating systems and application software would have to be designed and constructed to military standards in a trusted environment. This approach is impractical for complex systems, and the issue becomes one of balancing functionality, cost and risk.

Risk management strategies

Adoption of a layered approach can help minimise the possibility that incompetent or malicious code could subvert important C2 systems during military operations. First, we should concentrate on reducing the incidence of such code. Second, we can try to limit the possible avenues for remote activation of hidden functions. Third, we can design systems so that any disruption is localised. Fourth, we can seek to quickly re-establish system operation and prevent hidden functions from reactivating. Finally, we can devise contingency plans to prepare for primary system failure and have backup systems/procedures ready. Secondary risks include COTS vendors going out of business or withdrawing support, “finger pointing” when modules interfere with one another, interoperability problems during joint/combined operations and incompatible new versions of COTS packages. The following paragraphs examine possible strategies for reducing the risks associated with COTS technology.

Collaboration with vendors

One key to improving the quality of COTS products is for military customers to work more closely with vendors’ design and production staff (on a non-disclosure basis). Military involvement here should improve the quality of products for the commercial market as well as making them more relevant to the military market. Insistence that vendors implement traceability of design and code should, for example, discourage insertion of hidden functionality.

Over time, vendors could gain increasing levels of qualification as suppliers of trusted technology, based on their demonstrated discipline in design and construction, their willingness to collaborate fully with military customers, and practical experience with their products. The approach here could draw on Carnegie Mellon University’s Capability Maturity Model [12]. Through assessment of functionality, quality, market acceptance and other characteristics, a library of preferred COTS components could be established. (The effort required to qualify COTS vendors and products will exacerbate problems associated with vendor lock-in, however.)

Sales of information technology to the military sector are still substantial, and have high profile, even if they have shrunk in comparison to the overall market. Vendors could thus be encouraged to expand production of militarised versions of popular packages, such as the versions of Lotus Notes and Microsoft Exchange that comply with US Defense Message System specifications.

“Second-source” software

For certain types of technology used in critical defence systems, such as logic chips and electronic components, the availability of alternate suppliers (or “second-sources”) was once mandatory. To qualify for defence use, developers of new technology would license basic design intellectual property to second-sources, who were free to improve functionality and performance as long as product specifications were met. This approach worked very well with products such as the 74 series logic family. A variation could well be adopted with software, using trusted military systems developers as second sources.

To avoid propagation of design/coding flaws or hidden functions, the sharing of intellectual property would have to be at a relatively high level (overall system structure and function) rather than at the level of detailed design or code. The original product could act as the reference to resolve any ambiguities in design or behaviour. Second-sourcing of software would probably work best with software components, which are usually well defined in terms of their methods, properties and generated events. Not only could vendor lock-in be avoided in this way, but the rigorous design and implementation methodologies used in producing military-grade versions of COTS products would also reduce concerns with security and reliability. (To minimise any delay between release of the commercial and military versions, military systems developers would need to work with the commercial vendor from early in the product development cycle.)

Isolation of modules

Whenever software modules share resources, they can interfere with one another’s operation or even communicate covertly. Certain existing component frameworks allow COTS components to share the same process (and memory) space, thus inviting security and reliability problems. Small “Single Board Computers” with Pentium processors, 32MB of memory and Ethernet chips are available for a few hundred dollars each. Emerging technology and development environments will soon make implementation of distributed systems little more difficult than single processor versions.

The major elements of COTS functionality comprising a C2 information system could be distributed across several SBCs in a desktop cabinet, connected via star-coupled 10-baseT Ethernet. An internal “firewall” could mediate communications both internal and external to the cabinet, and limit the ability of a rogue or errant module to compromise other modules (eg. by a “denial of service” attack). Such isolation of modules would largely remove their ability to interact or interfere with each other except according to their defined interfaces, improving security and reliability. Logging of firewall-mediated interactions between modules would provide a reasonably comprehensive audit trail and assist in both detecting and diagnosing malfunctions. In a variation of the Java “sandbox” concept, COTS modules could be restricted to accessing only those system services and resources necessary for their advertised functions. In this way, the possibilities for remotely activating hidden functionality and for subverting system operation could also be reduced.

Diversity and redundancy

To protect the C2 function against serious disruption, and to help detect that supporting information systems are malfunctioning, a simple “hot standby” system that provides baseline C2 capability could be custom-built to military standards. As a final resort, manual procedures based on fax, telephone and text-based messaging, for example, should be practised regularly. Redundancy, diversity and isolation can reduce the probability and impact of a successful electronic attack on critical systems, as well as limiting the effects of accidental failures. Note that duplication offers little protection against software flaws: the giant Ariane 5 rocket had to be destroyed during its maiden flight when primary and backup guidance control units both failed with the same coding error!

Discussion

Given the cost, functionality, interoperability and other advantages, use of COTS technology in C2 systems is almost certain to grow, despite the potential reliability and security problems. The goal of the US Navy’s IT-21 initiative is that Navy C4I systems will move towards implementations based on COTS software and commodity Windows NT platforms [13]. At a different level, Version 3.1 of the DII COE includes Windows NT and the Office 97 suite [3]. Such developments will promote use of similar COTS technology among US Allies.

Strong tactical and strategic advantages follow from superiority in C2. Most technologies required for fully functional C2 systems will soon be available commercially on a worldwide basis. How then can a capability edge with C2 systems be maintained? The new challenge is to achieve superiority in management of complexity and change, so that critical C2 systems can stay close to the leading edge in technology and functionality, yet preserve security and robust reliability.

Substantial time and cost savings will accrue if COTS products supply much of the functionality of an overall C2 system. By reserving part of these savings for initiatives such as second-sourcing of software and development of multi-processor platforms to enforce isolation of modules, a suitable balance between benefits and risks can be struck.

References

Author

Iain Macleod is a Senior Research Scientist in the Command and Control Information Systems Interoperability Laboratory of the Defence Science and Technology Organisation, Australian Department of Defence. He holds a BE in Electrical Engineering and a PhD in Computer Science.