From: rslade at sprint.ca (Rob, grandpa of Ryan, Trevor, Devon & Hannah)
Subject: Security Watch Essay 

From:           	"roberta bragg" <freouwebbe@....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@....bc.ca      slade@...toria.tc.ca      rslade@....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

Powered by blists - more mailing lists