Full Disclosure mailing list archives
RE: Security Watch Essay
From: "Rob, grandpa of Ryan, Trevor, Devon & Hannah" <rslade () sprint ca>
Date: Fri, 13 Feb 2004 00:53:03 -0800
From: "roberta bragg" <freouwebbe () msn com> Date sent: Thu, 12 Feb 2004 01:05:30 -0600
What gets published in any publication is usually an editorial decision. Then again, they have to have something to choose from. If no one writes anything, then the editors have to scramble. No telling what they'll do. No telling what they'll publish.
Oh, a thrust! A palpable thrust! We are cut to the quick! If we do not fall in line with this exercise in cheap fodder-feeding, then there is no telling *what* they might say! They might [*shudder*] say that we all *trust* Microsoft!
Long before I became a writer I spent a couple of decades paying dues: I was a keypunch operator, FORTRAN, Cobol, C, C++, LISP, Delphi, dbase, VB, Prolog, etc. programmer, project leader, systems analyst, computer salesperson, teacher, consultant, network admin, systems admin, graduate student in computer science, whatever. Was doing computer security before it was kool. You?
Oh, come, Roberta! Surely you can do better than that! *My* bio includes such irrelevant fluff as paper boy (sorry, paper small person), cook, and hovercraft skirt repair technician.
No, my comment "if you believe ... Is a pro MS publication" was not meant to claim that it was an anti ms publication,, or even a neutral one..but to ask that anyone who saw it as a publication that would only publish pro-MS content --- take the opportunity to write something anti-MS and see it published.
Very well, then. In debating terms, we have been asked to defend the statement that, as Keith put it, "Microsoft just doesn't "get it" when it comes to security." The reasons are many and varied. It is probably impossible even to state them within the restricted scope of a thousand words (the insecurity that launched a thousand essays?), let alone present the necessary structure, framework, flow, and supporting backup. But let us commence, at the very least. You will, of course, expect me to parrot the recent paper on monolithic culture. "Least common mechanism" and "separation of duties" are standard security principles, and "requisite variety" is a maxim of ecology, so lets just take that as read, and say it's old news. Security is currently a bit of a fad, in the market-place, and definitely within Microsoft. Microsoft is rather big on following fads. This is easy enough to see when you are extremely old. I remember "Bob." I remember OS/2, and when MS and IBM were best buds. I remember Microsoft Anti-Virus. I remember Windows 1. I have seen the Trusted Computing Platform initiative (a hardware based PKI with no provision for certificate revocation) and Palladium. I have seen fads come and go at Microsoft. I have very little expectation that Microsoft has the sticking power necessary to do the long, hard, boring work required to produce programs, mindset, and corporate culture central to real security. Security isn't a "one-off" deal. It takes time. And when you are retrofitting, it takes exponentially greater time. I'm not just talking about retrofitting products and systems, although that is true as well. I'm talking about retrofitting the company itself: the practices, procedures, the mindset, the attitudes, the official policies, and the unofficial and unwritten ones that actually rule what goes on. I am reliably informed that Microsoft has had an official policy, for at least the past eight years, stating that all input buffers must be crafted in such a way that the dread buffer overflow is a thing of the past. (It can be done.) And yet we see buffer overflow conditions being introduced time after time. These are not old buffer overflows inherited from legacy code, either. Just this week we have seen the release of a patch for yet another buffer overflow. Actually, I don't have to install this patch. Dinosaur that I am, I am using a really old version of Windows. The vulnerability was introduced in a file that was released (irony of ironies) as a security patch that was developed long *after* my version of Windows. (After the last service pack for my OS, come to that.) (There has been much discussion, in regard to the latest ASN.1 buffer overflow, about the delay of six months in releasing the patch. Unconciously borrowing a line from John Calvin, a Microsoft apologist has said that this delay proves Microsoft is committed to security: look at how long they took to test the patch! It took that long to fix because every part of Windows, and every application, affects every other part. Excuse me, but that is yet another nail in the Microsoft security coffin. Simplicity is security. Least common mechanism is security. Complexity, obscurity, and labyrinthine structure are problems.) Let's go back to retrofitting. Security is really an add-on to Microsoft products. Yes, in the operating systems based on NT (2K, XP, 2003) you can see the traces of the VMS security core (as well as increasing accretions of UNIX ideas). But there isn't the central security framework that there was in VMS and is in UNIX. Secure operating systems (and secure systems, come to that) have a clearly recognizable and identifiable security structure, simple and elegant. Windows, and other Microsoft products, have an ad-hoc collection of security-related gizmos and gadgets. This includes, strangely enough, the various security management tools. The simple fact that there are so many tools for managing security is rather telling. Which leads to a rather major point. Security is a people issue: always has been, always will be. The Microsoft user interface with regard to security, on pretty much every product, is a nightmare. Important settings are buried in a bewildering variety of locations. Explanations available in regard to the effect of various settings are incomplete at best, and frequently misleading. Products are configured, and patches are issued, with a "trust us, we know best" attitude. To be most charitable about the ultimate outcome of this position, it completely ignores the fact that people have different needs with regard to security. More realistically, some of the choices defy any kind of reasonable explanation. A while back, Microsoft's answer to an early version of the "iframe" vulnerability was not to disallow auto-execution of programs, but to delete, without reference to the user, any file with an executable extension. More recently, the response to malformed or obfuscated URLs was not to inform the user, but to disallow the "username:password" structure that had become commonly used--and then, without much fanfare, to reinstate the capability. The tortured logic underlying these decisions has to relate, in some way, to the interface design that seems to completely ignore any studies in human factors engineering. Can Microsoft products be made absolutely secure? No. But then, neither can anything else. Can Microsoft products be made secure enough? Yes. Is it difficult? Yes indeed! Is Microsoft working on security? Currently, indications are that Microsoft is. Does Microsoft "get" security? History and current actions demonstrate that Microsoft has made, and is making serious and basic errors in regard to security design and practice, and, overall, one has to say that Microsoft still hasn't got it. Finally, in keeping with my total lack of talent, and even literary knowledge, excuse me while I butcher at least two famous poems: How do I distrust Microsoft security? Let me count the ways: Thou art constant, in thine affections, as an anopheles mosquito. Thou art bigger and more uncaring than the government. Thou art clear as mud ... ====================== (quote inserted randomly by Pegasus Mailer) rslade () vcn bc ca slade () victoria tc ca rslade () sun soci niu edu You see things; and you say, 'Why?' But I dream things that never were, and I say, 'Why not?' - George Bernard Shaw http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- RE: Security Watch Essay (was: (no subject)) Chris Cozad (Feb 11)
- <Possible follow-ups>
- Security Watch Essay (was: (no subject)) http-equiv () excite com (Feb 11)
- RE: Security Watch Essay (was: (no subject)) roberta bragg (Feb 11)
- RE: Security Watch Essay (was: (no subject)) Trevor Benson (Feb 12)
- RE: Security Watch Essay (was: (no subject)) Paul Schmehl (Feb 12)
- RE: Security Watch Essay Rob, grandpa of Ryan, Trevor, Devon & Hannah (Feb 13)
- RE: Security Watch Essay (was: (no subject)) roberta bragg (Feb 11)
- RE: Security Watch Essay (was: (no subject)) Schmehl, Paul L (Feb 12)
- RE: Security Watch Essay (was: (no subject)) Keith Ward (Feb 12)
- Re: RE: Security Watch Essay (was: (no subject)) James Bliss (Feb 12)