Locking the Barn Door

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.

About the Author

Em C. Pea, MCP, is a technology consultant, writer and now budding nanotechnologist who you can expect to turn up somewhere writing about technology once again.