Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
RE: [Full-Disclosure] Security Watch Essay
From: Rob, grandpa of Ryan, Trevor, Devon & Hannah (rsladesprint.ca)
Date: Fri Feb 13 2004 - 02:53:03 CST
From: "roberta bragg" <freouwebbemsn.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
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
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)
rsladevcn.bc.ca sladevictoria.tc.ca rsladesun.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.