From: rslade at vcn.bc.ca (Robert Michael Slade)
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 ...


rslade@....bc.ca      slade@...toria.tc.ca      rslade@....soci.niu.edu
Find virus, book info http://victoria.tc.ca/techrev/rms.htm
        Mirrored at http://sun.soci.niu.edu/~rslade/rms.htm
Review mailing list: send mail to techbooks-subscribe@...oups.com

Powered by blists - more mailing lists