Warm, Gushy Microsoft
By Seth Ross
Corporate information security breaches occur each and every day.
Intruders steal confidential information, deface web sites, and
muck around with financial records on a regular basis. For the most
part, the impact of these breaches is limited to the target company,
its stakeholders, or perhaps immediate trading partners.
From time to time, a breach has earth-shattering implications.
One example is the massive leak of nuclear weapons design secrets
from the US to China. A more timely case surfaced in October, raising
serious concerns about the integrity of the entire global personal
and corporate computing infrastructures: Microsoft's security was
breached by an intruder using the Windows-based QAZ Trojan Horse.
The intruder's reported access to the source code of popular Microsoft
products raises serious questions about whether those products -
and Microsoft in general - can be trusted.
To recap the public information about how the Microsoft break-in
occurred:
- A system cracker sends the QAZ Trojan Horse to the home computer
of a Microsoft employee
- The employee connects to Microsoft's corporate network from
home
- The QAZ Trojan snarfs the employee's password files and makes
them available to the cracker
- The cracker is able to log into Microsoft's systems posing as
the employee
- The cracker opens new accounts with elevated privilege and wanders
the Microsoft corporate network at will.
This occurred despite Microsoft's rigorous security policies governing
access to the corporate network from home. Ironically, Microsoft's
corporate security officer, Howard A. Schmidt, contributed an article
on "Securing the Home Front" to the November 2000 issue of Information
Security magazine (see http://www.infosecuritymag.com/nov2000/microsoft.htm).
He touts Microsoft's detailed home computing policy which includes
items like:
- Remote connections use Virtual Private Network (VPN) encryption
- Each home LAN must use a packet-filtering device
- Each home system must run personal firewall software
- Each home user must encrypt sensitive company information
- Home users may not modify the routing tables on their home machines
In the days after the attack was first publicized, several different
Microsoft spokespeople produced several conflicting sets of facts.
President and CEO Steve Ballmer noted that the crackers saw source
code, a claim that was later denied. The cracker was on Microsoft's
network one week, or 12 days, up to six weeks, or up to three months,
depending on the spin du jour.
The possibility that intruders were able to access the source
code of Microsoft operating system and/or application software is
serious indeed. Many tens of millions of people and all of the largest
corporations in the world depend on Microsoft software. What assurance
do any of these Microsoft customers have that the intruders didn't
plant a Trojan Horse or other malicious code in Word, Windows 2000,
or the forthcoming .NET platform? There are tens of millions of
lines of code in a complex OS like Windows 2000 - it would take
hundreds of thousands of programmer hours to audit the entire code
base, something that Microsoft is not likely to do (assuming the
company is even capable of doing it). A well-planted Trojan could
remain hidden for years, targeting certain features, companies,
networks, or even individuals.
Can anyone trust that Microsoft's products have not been riddled
with serious but unfindable bits of malicious code? Trust is a delicate
concept. It requires an assured reliance on the character, ability,
strength, or truth of someone or something. Let's look at these
one at a time.
- Character - Microsoft's legal troubles speak to this (see http://www.albion.com/microsoft/)
- Ability - Microsoft clearly is a very able company, but is it
able to secure its far-flung network operations? Is it able to
audit hundreds of millions of lines of code for security holes?
- Strength - Has Microsoft historically built strong security
into its products?
- Truth - Given the equivocation of company statements in the
aftermath of the attack, the "truth" is still out there.
Clearly, it's difficult to trust the integrity of Microsoft's products.
What can Microsoft customers do? What can Microsoft do to rebuild
trust?
Two words: open source. Microsoft's customers should demand that
the company release the source code of its programs and operating
systems so they can be publicly reviewed and audited for security.
The open source development model has proven to be a boon for a
wide variety of development efforts, including the very popular
Linux operating system, the Apache web server software, and Netscape
Navigator. As noted on the Open Source Initiative's web site (http://www.opensource.org):
The basic idea behind open source is very simple. When
programmers on the Internet can read, redistribute, and modify the
source for a piece of software, it evolves. People improve it, people
adapt it, people fix bugs. And this can happen at a speed that,
if one is used to the slow pace of conventional software development,
seems astonishing. We in the open-source community have learned
that this rapid evolutionary process produces better software than
the traditional closed model, in which only a very few programmers
can see source and everybody else must blindly use an opaque block
of bits.
One role model for Microsoft is OpenBSD, a Unix operating system that's
been open sourced and ruthlessly audited for bugs in general and security
vulnerabilities in particular. OpenBSD is volunteer-run project that's
serious about security. Its open auditing process has resulted in
the most robust and security- hardened operating system that money
can't buy (since it's free). From the group's security page (http://www.openbsd.org/security.html):
We have been auditing since the summer of 1996. The process
we follow to increase security is simply a comprehensive file-by-file
analysis of every critical software component. We are not so much
looking for security holes, as we are looking for basic software
bugs, and if years later someone discovers the problem used to be
a security issue, and we fixed it because it was just a bug, well,
all the better. Flaws have been found in just about every area of
the system.
By publishing its source code and encouraging independent auditing,
Microsoft could show that it has nothing to hide and go a long way
to restoring customer trust. There might be additional benefits as
well, such as a quick and dramatic resolution to some of the company's
legal problems.
I'm certainly not the first to suggest this course of action for
Microsoft. For example, see Nicholas Petreley's Infoworld column,
"Microsoft's road to consumer trust is to open source Windows":
http://www.infoworld.com/articles/op/xml/00/11/13/001113oppetreley.xml
For more about the Microsoft break-in, read this analysis by famous
computer intruder Kevin Mitnick:
http://www.securityfocus.com/commentary/112
ZDNet published this set of ponderings by security experts:
http://www.zdnet.com/enterprise/stories/main/0,10228,2652161,00.html
SecurityPortal offered these bits of insight:
http://www.securityportal.com/articles/mshacked20001029.html
For technical details of how the Qaz Trojan works, see
http://www.symantec.com/avcenter/venc/data/w32.hllw.qaz.a.html
For a good rant on the topic, see "Microsoft Can't Spin This Worm":
http://www.zdnet.com/sp/stories/column/0,4712,2645942,00.html
|
