The Microsoft Security Debate, Part One
Two users critique Microsoft's understanding of security.
Recently I sent out a request to those who think Microsoft, despite its efforts
over the last two years, still "doesn't get" security. My purpose
isn't to bash Microsoft, but rather to have a debate between knowledgeable IT
folks, since so much criticism of Redmond on the topic of security is, I believe,
I received some terrific feedback, with strong, substantive arguments about
Microsoft's security shortcomings. My original purpose was to pick the best
critique and have regular columnist Roberta Bragg respond to its arguments.
But there are two that Roberta and I feel are specially deserving, so we're
printing both of those today, and I'll post Roberta's response next Monday.
I received so many good essays, however, that I'd like to get more of them
published. Look for information on that in an upcoming Security Watch.
Security at Microsoft is a "Fad"
By Robert Michael Slade
Security is currently a bit of a fad in the marketplace, 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 Microsoft and IBM were best buds. I remember Microsoft Anti-Virus.
I remember Windows 1. I've seen the Trusted Computing Platform initiative (a
hardware-based PKI with no provision for certificate revocation) and Palladium.
I've 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 isn't a "one-off" deal. It takes time. And when you're 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, mindset, attitudes, official
policies, and the unofficial and unwritten ones that actually rule what goes
on. I'm 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 recently 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, in fact.)
(There has been much discussion in regard to the latest ASN.1 buffer overflow,
about the delay of six months in releasing the patch. Unconsciously 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 (Windows 2000, Windows XP, Windows
Server 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)
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
effects 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 gotten it.
Microsoft is Confused About Security
By Martin Levasseur
There are a million things I'd like for Microsoft to change about security.
I've done jobs involving security myself, and have held numerous positions with
security responsibilities, including network administrator; software tester;
software designer; and onsite engineer. I'm competent with Solaris, Windows,
Linux, Unix in general.
Microsoft just doesn't get it because they're doing things that are only limiting
and confusing their OS/customers/developers:
- They still don't understand that they should shut down useless services
by default, and not just rehash port numbers.
- They're creating too many Windows versions. They should create one Windows
and stick with it, understand it and master it; then not let the marketing
department try to sell it under a new name every year or two by rehashing
and re-merging all the modules together with some new functionalities. That's
when the security issues appear or reappear.
- Users, for their part, should also stay with one Windows version and become
as familiar with it as possible, so they can sense when problems might be
security-related. By having to get used to a new Windows version every year,
they get confused again. They assume the new version is better quality/better
software, but they're often surprised.
- Microsoft never scales their products to [the enterprise]. How many times
have we seen old features reappearing with the same problems as before, but
with a fresh new interface? I suspect there are a lot more artists at Microsoft
than actual core developers and testers. Or perhaps the core developers are
retired, and [current developers] wouldn't dare touch the kernel code without
- NTFS is the worst file system I've seen. Security is easily overruled by
Linux NTFS mounts. WinFS (already another file system?) is going to be the
same thing, I'm sure. The worst thing is that it blocks me as an admin. I
can't repair a Windows installation from DOS anymore (when a Blue Screen of
Death appears after using Windows update) from a good old Windows 98 boot
disk, and can't make reliable backups with utilities like Norton Ghost. And
Microsoft goes as far in its arrogance as selecting NTFS by default when installing
Windows, forcing everyone to use it.
- Microsoft is doing things that are supposedly enforcing the use of the
GUI, but the company itself isn't even following it. Just look at MS-DOS,
which is—thank God—still a part of the Windows OS. How many times
has it saved my life, or permitted me to bypass stupid security measures that
have been implemented? How many times have I seen patches opening a DOS window
for a brief second, bypassing the new security features, in order to give
the impression the software is working?
I think that while Microsoft is getting more and more confused and wondering
where they're going today, the more the Unix/Linux movement is freeing everybody
from those limitations and getting a clear picture of where they want to go
in the future.
About the Author
Keith Ward is the editor in chief of Virtualization & Cloud Review. Follow him on Twitter @VirtReviewKeith.