|
|
|
ONLINE FEATURES
Book Reviews
BW Video
Columnists
Interactive Gallery
Newsletters
Past Covers
Philanthropy
Podcasts
Special Reports
BLOGS
The Auto Beat
Byte of the Apple
Europe Insight
Eye on Asia
Getting In
Investing Insights
The New Entrepreneur
NEXT: Innovation Tools & Trends
On Media
Technology at Work
The Tech Beat
Traveler's Check
TECHNOLOGY
Product Reviews
Tech Stats
Hands On
AUTOS
Home Page
Auto Reviews
Car Care & Safety
INNOVATION
& DESIGN Home Page Architecture Brand Equity Auto Design Game Room SMALLBIZ Smart Answers Success Stories Today's Tip FINANCE Investing: Europe Annual Reports Bloomberg BW50 SCOREBOARDS Hot Growth Companies: 2008 Mutual Funds Info Tech 100 B-SCHOOLS Undergrad Programs Rankings & Profiles |
MAY 20, 2003
By Alex Salkever Bug-Zapping, Microsoft Style Mike Nash takes offense when people (like me) bash Redmond's software, because it's up to him to make it safe. Here's his defense Looking for a tough job? Try Mike Nash's. He's the executive in charge of Microsoft's "Trusted Computing" initiative charged with building more secure software. Nash has the unenviable task of taking on Redmond bashers who decry Microsoft's lax security. And he has to convince the world that, yes, Virginia, Microsoft products are secure. It may be ugly, but Nash has taken this one on with relish, leading brown-bag breakfast lectures on security topics at the Microsoft Campus and, by his account, infusing the new religion of security into every corner and cubicle of the software-development process. When I wrote a piece criticizing Microsoft's latest operating system as suffering from the cardinal sins of complexity and code bloat (both of which promote vulnerability) in late April, Nash called me to respond and give me his take on why Microsoft (MSFT ) products are a lot more secure these days and probably should be getting more credit (see BW Online, 4/29/03, "For Windows, Less Fat Means Fewer Bugs"). It was an interesting conversation, and he made some good points. So in the interest of fairness, this week's column will probe Nash's point of view on this hot topic. CAN'T KNOW IT ALL. The argument that code bloat means less secure software is based on simple mathematics. Complexity rises very quickly for each additional element added to any system or equation. With complexity comes vulnerability, because mere mortals -- even the brainiacs at Microsoft -- have a hard time wrapping their minds around millions of lines of code. In fact, no one disputes that it would be truly impossible right now for any human being to have an effective working knowledge of all the parts of a complex operating system, be it Windows, Unix, Linux, or Apple's OS X. The way society and business have thus far conquered complexity is through automation and process controls. Engineers don't have to use slide rules to calculate tensile strength required of cable strands on suspensions bridges because sophisticated computer programs do it for them. Likewise, space flight is possible only through rigorous processes that harness hundreds of individual minds into a disciplined whole. Nash argues that Microsoft is now using both approaches to mitigate complexity risks inherent in big software. And he says Microsoft is already producing much safer products because of new automated tools to spot bugs and better processes to emphasize software security. FLAW FINDERS. Here's a thumbnail sketch of his points. Over the last year, Microsoft has begun more extensive use of programs designed to automatically detect bugs in code. One is called PREfix, and the other is called PREfast. Both were developed by the folks at Microsoft Research, and both use complex algorithms to search for software constructions that will likely result in flaws. PREfix was first used to find problems in Windows 2000 code, but Nash claims it's greatly improved and has been used more proactively in more recent software-development processes. PREfast is a smaller, less complicated program that software developers can use to pinpoint obvious bugs. Microsoft developers employ it to vet their code, and Nash says outside developers are also starting to use PREfast. As for process, Microsoft's big initiative to train all its software engineers in secure software design got wide publicity. The company halted all code development in early 2002 for several weeks to put everyone through the training. Microsoft also changed its code-checking process. Rather than having dedicated security engineers come in after the fact and clean up the code -- a process that can be disruptive -- Microsoft chose to designate a lead security person for each component of the Windows source code. GIVE SERVER A CHANCE. "From a process perspective, we have provided accountability to all parts of the operating system. We created specific accountability system so that we know every component of source has a developer responsible for the security quality of that source," says Nash. Neither concept is entirely new. Researchers have been working on automated bug-fixing tools for years, although they're particularly hard to build because distinguishing bad code from good code is often a matter of taste and opinion, and closing one type of vulnerability can open another. Sun Microsystems (SUNW ), IBM (IBM ), and other big software shops have long followed similarly rigorous security mechanisms, and they've been rewarded with reputations for relatively strong security. Nash argues, however, that the people who bash Microsoft should give Windows 2003 Server a chance because it's the first generation to really reap full benefits from Redmond's new tools and process.
| |