Locking the Barn Door

Of bowling and certifications.

• By Em C. Pea
• October 01, 2003

The most excellent Fabio and your sweet Auntie were bowling the other night. (No, it’s not all evenings at the opera for us.) The dear man was crowing about his prowess after reducing his third 7-10 split in a row to a spare. At least, he was crowing until I suggested it might prove more about his worth as a bowler to not leave 7-10 splits in the first place. After another pull at the longneck, I proceeded to throw a strike myself and contemplate the similarity between our evening at the lanes and Microsoft certifications.

Don’t see the connection? Allow me to explain. At this year’s TechEd, Micro-soft’s Lutz Ziob announced the launch of the MCSA: Security and MCSE: Security certifications (or more precisely, certification specializations). Candidates must pass some prescribed exams from the regular choices that demonstrate their ability to design and implement secure Windows 2000 networks.

Designing and implementing secure networks. There’s a 7-10 split if ever I heard! What’s the equivalent strike? Why, installing a network product that’s secure in the first place, of course. But to get that product, one has to turn from the sys admins to the developers.

Think back to early 2002 when Microsoft was trying to stem a flood of bad publicity by getting serious about security in its products. Under the rubric “Trustworthy Computing,” it invested a sum of money roughly equivalent to the cost of running a decent minor league baseball team in retraining developers to write secure code. Senior Vice President Craig Mundie churned out a white paper on Trustworthy Computing (http://www.microsoft.com/presspass/exec/ craig/10-02trustworthywp.asp) that was trumpeted far and wide. The very first means Mundie identifies for Trustworthy Computing is, “Secure by Design, Secure by Default, Secure in Deployment.” He goes on to write about the importance of secure development up front: “All code is thoroughly checked for common vulnerabilities using automatic or manual tools. Threat modeling is built into the software design process.”

So, why didn’t the certification folks get the message? If the Trustworthy Computing vision is fulfilled, then implementing a secure network should only be a matter of popping the right DVD into the server and letting it rip. The effort comes up front, in writing secure code. And—just in case I haven’t already belabored the point sufficiently—that means that Microsoft should have come out with an MCSD: Security specialization. Without secure software in the first place, the sys admins are in the unenviable position of locking all the doors to the barn without even knowing if there’s a horse inside.

You would think, after all, that Microsoft learned a thing or two about secure development in tearing apart those millions of lines of source code. And we know that they have people on staff whose job is to teach such lessons to the rest of us. So, why haven’t we seen official curriculum on secure development? Why no MCSD security exams? Why not try to cover all of the security bases if you’re going to announce security specializations?

Only a cynic would mention that there were already existing security exams for the MCSE track, so that Microsoft didn’t have to invest any exam-writing dollars to back up the TechEd announcement.

Then again, perhaps there are good reasons why Microsoft chose not to emphasize secure development in the new certifications. Windows 2003, the poster child for “secure by design,” launched April 24. The first security patch for Windows 2003 came out June 4. Six weeks without a patch isn’t all that impressive a result for the hundreds of millions of dollars spent on hardening the Windows source code.

Whoops! Excuse me... Fabio just plopped my color-coordinated hot-pink bowling ball into my lap, and it’s time for me to show him what a sys admin can do with it.