Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.org.eff.talk Subject: Re: "Computers at Risk" Message-ID: <1990Dec15.174416.6338@Think.COM> Date: 15 Dec 90 17:44:16 GMT References: <1990Dec11.213718.13211@Think.COM> <90349.014530SPRAGGEJ@QUCDN.QueensU.CA> Sender: news@Think.COM Distribution: na Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 66 Newsgroups: comp.org.eff.talk Subject: Re: "Computers at Risk" Summary: Expires: References: <1990Dec11.213718.13211@Think.COM> <90349.014530SPRAGGEJ@QUCDN.QueensU.CA> Sender: Followup-To: Distribution: na Organization: Thinking Machines Corporation, Cambridge MA, USA Keywords: In article <90349.014530SPRAGGEJ@QUCDN.QueensU.CA> SPRAGGEJ@QUCDN.QueensU.CA (John G. Spragge) writes: >Perhaps purchasers are more concerned about protection from mistakes >than they are from malice. I have certainly restored my share of >files through the years, and I have never yet seen a file wiped >out by a virus or a trojan. The majority of failures were due >(depending on your perspective) either to user error, or to systems >that were too hard to learn or understand. If a buyer asked me >whether they should buy a hard to understand system with good >security, or a user friendly system with little security, I would >always recommend the latter. The recommendation wouldn't depend at all on the planned use of the computer? I admit that there are environments where security is not tantamount, but for applications such as banking and the Defense Department, security can be very important. As a former developer of a secure system (Multics), I can tell you that the design processes that go into developing a secure system naturally result in a more correct system. Thinking about security forces developers to consider all the ways that different pieces of the system may interact. They must pay more attention to details, because that's where most security flaws are. Better design and development methodologies are used. Good system structuring is necessary so that it is possible to understand the system and believe that it is secure. Once you are in this mindset, it is normal to think this way for all the software on the system, not just the security-related parts. For instance, in Multics development, all changes to the system are subject to peer review of the proposed change, and the code must be reviewed and approved by at least one other developer familiar with that area of the system. The problem with many "secure" systems today is that the security was grafted on as an afterthought. Thus, the systems were not designed in the careful ways that security promotes. Adding security to a poorly-structured system is like patching leaks in a roof made of inferior raw materials: you can be pretty sure that new leaks will form. The same design processes that result in more correct systems can also produce easier to use systems. For instance, the peer design review was good at preventing user interface inconsistencies from being implemented. Good system structuring generally means encapsulating common facilities into libraries, and when this is done for user interface routines you get a more uniform environment (example: on Multics, the same command-line parsing subroutine is used by the shell and by most commands with internal command lines, such as the mail and conferencing user interfaces). Yes, Multics is harder to use than a Macintosh, but that's true of most systems. It's no harder to use than MS-DOS, Unix, or VMS. And if your personal computer hasn't been hit by a virus, you've just been lucky so far; I think part of the problem is an "it won't happen to me" attitude by many people. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar