Featured Download
Speak Like a CEO
This chapter describes ten helpful actions and behaviors that will bring you...
Content provided in partnership with
Government Industry
Self-inflicted vulnerabilities
Naval War College Review, Autumn, 2004 by Stephen D. Wolthusen
One of the most prominent, if sometimes controversial, figures in software engineering resigned in 1985 from the Panel on Computing in Support of Battle Management of the Strategic Defense Initiative Office, publishing a series of essays declaring it unlikely that the program would meet the goals implicitly set forth by President Ronald Reagan for the SDI program. (1) Two decades later, this assessment has gained in pertinence as transformation technologies become reality and reliance increases on network-centric operations and C4ISR * assets to achieve critical operational objectives. Concern has spread even to the level of individual tactical units, while the potential persists for damage or at least costly friction and lost options at the strategic level. (2)
- Most Popular Articles in News
- The Ten Best Laptop bags
- Tata plans cheapest-ever car for Indian market
- GLOBALIZATION AND THE DEVELOPMENT OF UNDERDEVELOPMENT OF THE THIRD WORLD
- Corn is good for you; Corn is not only a tasty treat, but also a cereal that ...
- THE 50 BEST STYLISH HANDBAGS TO CARRY
- More »
While information technology has become a highly efficient force multiplier in a large number of roles--from producing transparency in logistics flows to providing target data for strike packages in near real time to guiding munitions themselves--there are differences between information systems and other engineering artifacts that are dangerous to ignore. As information system components suffuse what had previously been the domain of mechanical engineering, as well as similar disciplines, these engineering artifacts frequently come to rely on information technology for their core functionality and hence take on the properties previously associated only with pure information systems.
Software engineering has made only limited progress in producing large, reliable, and trustworthy information systems. Developing such systems (or even their software components) that can be mathematically proven, or at least argued convincingly, to be correct and complete is feasible on a relatively small scale, but it remains, given the consequences of faults, a daunting task at the scale contemplated and necessary for network-centric operations. Unlike in mechanical artifacts, uncertainty in such design criteria generally cannot be adequately compensated for by safety margins. (3) Any effort to develop trustworthy, high-assurance systems faces limitations as to what can be subjected to independent verification and validation, let alone mathematical proof with the precision and completeness of requirements and specifications. (4) Success is extremely rare.
BUILDING FORTRESSES ON SAND
Two examples suggest the gulf in scope between the systems for which capabilities and correctness have been proven with mathematical rigor and those actually used in mission-critical tasks. The Ship's Helicopter Operating Limits System, initially deployed with the Royal Navy's Merlin helicopter on Type 23 frigates, was developed to the standard of mathematically provable correctness. A highly specialized and experienced team of scientists and engineers required five years to generate 27 KLoC (thousands of lines of code) of proven and verified software. (5) Moreover, there existed a physical system for the software to control, one that could be modeled precisely, complete with kinematic parameters, and that could therefore be described exactly in a formal specification, from which code could be derived without ambiguity.
A contrasting example would be a COTS (commercial off-the-shelf) general-purpose operating system. One of them, Microsoft Windows 2000, contains more than 10,000 KLoC critical to system security and operational capability; depending on metrics used, Microsoft Windows 2003 contains approximately 50,000 KLoC. None of that code is modeled, specified, or implemented in such a way as to permit even evaluation of the trustworthiness of a component running this operating system, regardless of the characteristics of the layered applications. Interactions between the layered application and the underlying operating system escape, by definition, modeling and specification. Despite advances in computer science and software engineering, it is not at all clear that such large demands are within reach of the methods used for smaller systems even if the resources and time for such an effort are not bounded.
This is in large part due to the fact that the complexity of interactions among software components typically increases significantly faster than the size of the code base, and it does so in a superlinear fashion (i.e., typically as a polynomial in the LoC). While strict hierarchical design methodologies and implementations have long been the subject of research, success in the field has been somewhat limited. (6) Even under optimistic assumptions regarding defect rates, therefore, statistical models predict the presence of several thousand defects for such a COTS product--even with the additional caveat noted above, that unspecified behavior can result in ambiguity as to what constitutes a defect. Though the Microsoft Windows 2000 operating system has been certified as meeting the Common Criteria Evaluation Assurance Level 4 for trustworthiness, critical vulnerabilities are still discovered with some regularity, which is extremely likely to continue for the lifetime of the system. (7)
