Multiplexer: A device that combines several independent data streams into one data stream at a higher signaling speed for transmission to a similar device that separates the high-speed signal into the original independent data streams. Note: multiplexers are software-driven and are similar to concentrators; however, most of them are non-intelligent hard-wired devices. 9. Concentrator: 10. A programmable device that will perform the same function as a multiplexer with added functions such as data storage (buffering), message error checking, data flow control, polling, etc. Front-End Communication Processor: A programmable device that interfaces a communication network to a host computer. Some of the functions that can be performed by a "front-end" are polling, code and speed conversion, error detection and correction, store and forward functions, format checking, data flow control, network statistics gathering, message authentication, communication routing and control, and the like. 11. Message Switch: A privately owned programmable device that accepts messages from many users, stores them, and at some time after receiving them transmits them to their intended destination. This device generally receives messages at slow speeds over dialup lines. 12. Protocols: 13. Software or hardware rules that facilitate the transmission between devices. Some protocols provide for error control. Test Equipment (technical control facility): A combination of equipment that facilitates the physical monitoring, diagnostics, and restoration of communication systems should they fail. They can contain circuit patching, spare equipment, alternate switches, and might involve message text monitoring or quantitative measuring equipment. 14. Audio Response Unit: A unit that accepts analog, audio voice, or digital signals and converts them to digital computer signaling or can also convert digital signals from a computer into human understandable voice signals. 15. 16. Auto Answering: A device that automatically answers a telephone and establishes a connection between data communication devices. Auto Dialing Unit: A device that accepts computer signals and automatically dials the telephone number of a remote communication device. 17. Terminals: An input/output device that is used to enter messages into the system and/or receive messages from the system. From left to right: Peter Tasker, James E. Rife, Peter Neumann, Clark Weissman, Gerald J. Popek, Theodore M. P. Lee, (Stephen T. Walker absent). Note: Titles and addresses of attendees can be found in Appendix B. EDITOR'S NOTES THEODORE M. P. LEE Dr. Theodore M. P. Lee is Manager, Systems Security, for Sperry Univac ́s major systems development organization, where he is the focal point for the security aspects of all present and future products, hardware and software. Just prior to assuming his present position in late 1978 he was a staff consultant in Sperry Univac ́s Product Strategy and Requirements organization, working as part of a large R&D project for potential future products, where he had major roles in the design of addressing and protection hardware, implementation languages, and operating system structure. His previous experience at Sperry Univac includes five years in their Defense Systems Division, where his assignments dealt with computer graphics, man-machine considerations, computer and data networks, general systems design, and where he was principal investigator for an R&D project on computer security. He has been an Adjunct Assistant Professor at the University of Minnesota, teaching courses in artificial intelligence, is a member of ACM, acts as a reviewer and referee, and has lectured at various conferences and workshops in both Europe and the U.S. He studied at Harvard University, receiving a B.A. summa cum laude in Physics and a Ph.D. in Applied Mathematics (Computer Science). THE CHARGE TO THE GROUP This session was to consider the vulnerabilities associated with the operation and maintenance of the central processor, operating system and hard-wire peripheral devices. Appropriate controls were to be considered from two different perspectives: the system design and acquisition phase and the ongoing system phase. [See Part I, Section 2 for the complete charge give to this group.] The report that follows is the consensus view of this session. Processors, Operating Systems and A Consensus Report Theodore M.P. Lee (Chairperson) Peter Neumann Peter Tasker Clark Weissman James E. Rife (Recorder) Note: This report was written by the chairperson but has been reviewed, revised and approved by all members. The views expressed represent the individual and collective opinions of the participants, and do not necessarily represent the views of their respective organizations, the NBS, the GAO, or of the sponsors of any work they have participated in. The task charged to our session was to list the vulnerabilities of the subject areas, and the counters to them, with some evaluation of costs. We decided fairly quickly that the general purposes of the workshop as a whole would be better served in a somewhat different way. We interpreted our charge as being better expressed as: "What authoritative ways exist, or should exist, to decide whether a particular computer system is 'secure enough' for a particular intended environment of operation, and, if a given system is not 'secure enough' for an intended application, what measures could or should be taken to make it so?" We were well aware that even beginning to discuss this question in a coherent way, much less giving a complete and technically and administratively acceptable answer to it, is a formidable task. It was, however, the consensus that the state of the art is now such that the beginnings of an answer, in the form of both the technical steps to be taken and the administrative support for them, are close to reality. Accordingly, we formulated number of steps, which are described here, and strongly recommend that they be considered by NBS and GAO as a program of action. Although we appreciate the desire of NBS and GAO for a report that could form part of a Federal Standard, it is our conclusion that in the time available we could not directly prepare much that would be of use itself. Until the program recommended is substantially complete, the necessary information will not be available. 2. SCOPE was charged to deal with processors, operating systems, and nearby peripherals. Experience has shown hardware not to be a very important aspect of the problem. The significant computer security problem lies in any software that is supposed to fulfill a role in enforcing security. Accordingly, most of our discussion dealt with that problem. (The evaluation methodology to be discussed below does cover hardware, but that subject will not be discussed much.) The major emphasis is on operating systems, but it must be recognized that other forms of software can and do play a critical role in security. Included in our scope therefore are also any special software subsystems, such as data management, management, transaction systems, or even micro-code, that are intended to perform security functions above and beyond those provided (or not provided) by the operating system. |