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 296
I Secrecy of Design Secrecy of design is often deprecated with the phrase "security through obscurity," and one often hears arguments that security-critical systems or elements should be developed in an open environment that encourages peer review by the general community. Evidence is readily at hand of systems that were developed in secret only to be reverse engi- neered and have their details published on the Internet and their flaws pointed out for all to see. The argument for open development rests on assumptions that gen- erally, but not universally, hold. These assumptions are that the open community will devote adequate effort to locate vulnerabilities, that they will come forth with vulnerabilities that they find, and that vulnerabili- ties, once discovered, can be closed even after the system is deployed. There are environments, such as military and diplomatic settings, in which these assumptions do not necessarily hold. Groups interested in finding vulnerabilities here will mount long-term and well-funded analy- sis efforts efforts that are likely to dwarf those that might be launched by individuals or organizations in the open community. Further, these well-funded groups will take great care to ensure that any vulnerabilities they discover are kept secret, so that they may be exploited (in secret) for as long as possible. Finally, military systems in particular often exist in environments where postdeployment upgrades are difficult to achieve. Special problems arise when partial public knowledge is necessary about the nature of the security mechanisms, such as when a military security module is designed for integration into COTS equipment. Re 296

OCR for page 296
APPENDIX I 297 sidual vulnerabilities are inevitable, and the discovery and publication of even one such vulnerability may, in certain circumstances, render the system defenseless. It is, in general, not sufficient to protect only the exact nature of a vulnerability. The precursor information from which the vulnerability could be readily discovered must also be protected, and that requires an exactness of judgment not often found in group endeavors. When public knowledge of aspects of a military system is required, the most prudent course is to conduct the entire development process under cover of secrecy. Only after the entire assurance and evaluation process has been completed and the known residual vulnerabilities identified- should a decision be made about what portions of the system description are safe to release. Any imposition of secrecy, about either part or all of the design, car- ries two risks: that a residual vulnerability could have been discovered by a friendly peer reviewer in time to be fixed, and that the secret parts of the system will be reverse engineered and made public, leading to the further discovery, publication, and exploitation of vulnerabilities. The first risk has historically been mitigated by devoting substantial resources to analysis and assurance. (Evaluation efforts that exceed the design effort by an order of magnitude or more are not unheard of in certain environments.) The second risk is addressed with a combination of tech- nology aimed at defeating reverse engineering and strict procedural con- trols on the storage, transport, and use of the devices in question. These controls are difficult to impose in a military environment and effectively impossible in a commercial or consumer one.