Will MVPs crack down on Mary-Jo Foley?

Mary-Jo Foley, whose articles I only read when other people direct me to them, has a new speculative blog entry, musing about whether Microsoft will continue down the track of openness and transparency, now that a few champions of openness – okay, Jim Allchin and Robert Scoble – have left the company.

[What brought this on is the current issue of Wired magazine, and its cover article on transparency, with a cover photo that cleverly features transparency. My wife wants to know whether Wired will be putting John Krasinski on the cover any time soon.]

In Mary-Jo’s post, she rambles about how wonderful it is that Microsoft has become open, and then treads into pure fantasy, to ask “Will Microsoft attempt to extend any kind of blogging/transparency crackdown to its Most Valuable Professionals (MVPs), featured communities and other constituencies, claiming that it’s for everyone’s best?

I thought Mary-Jo was supposed to be clued-in on everything Microsoft.

First, let’s address the “featured communities and other constituencies” – clearly, Microsoft provides the current venue for many of these communities and constituencies. Sure, Microsoft could say “you either post nice stuff about us, or we close down your access”. But Microsoft knows, or at least, those concerned with community at Microsoft know, that when you start putting the squeeze on a community, like a toothpaste tube, all that happens is that all the toothpaste comes out of the tube, and makes more of a mess elsewhere.

In the case of communities of Microsoft users, that “elsewhere” would very quickly pop up in Usenet, other web sites and fora, and would garner visitors purely on the basis of being an independent voice. This has happened already to several other companies who don’t manage their own communities, or who manage their own communities with an iron fist.

As for Microsoft restricting MVPs in that fashion, I think Mary-Jo’s lost it.

Microsoft provides exactly no blog space to MVPs. Something about maintaining our independence. The current MVP motto is “Independent Experts. Real World Answers.” [I think maybe that should be “Real Weird Answers” some days.] For anyone to believe Microsoft’s MVP programme is about Independent Experts, Microsoft really needs to make it clear that we get to say what we like as MVPs. To that end:

  • The MVP award is retrospective – you get it for your previous year’s work. So, in a very real way, when you’re an MVP, you can say what you want and still be an MVP until the end of the year (my year ends on April 1, I hope I get re-awarded).

  • The Microsoft criteria for MVPs says only that on balance, candidates should be neutral-to-positive towards Microsoft (I’m paraphrasing). Makes sense, really – someone who’s universally negative to you is unlikely to receive a “thank you” gift from you. But look at the MVPs – we even have MVPs whose primary source of income is supporting Linux systems; There are MVPs who don’t even use Windows! And you only have to peruse the blogs of MVPs to find plenty of comments where we’re taking Microsoft to task for things we believe are stupid.

  • Last time a Microsoft employee told me to do something was … when I worked for Microsoft. Most of my communications from Microsoft as an MVP consist of “what can we do for you?”, whether it’s hosting mini-meetings at Microsoft-related events, or product group feedback.

So, yeah, I think Microsoft can crack down on the MVP blogs about as easily as the MVPs can crack down on Mary-Jo Foley’s blogs when she says these fanciful things.

Only you can prevent security fires.

Here are a few sayings I like to throw at my co-workers from time to time:

  • When you’re wrestling alligators and winning, it can be difficult to remember that your job is to drain the swamp – you only got into the alligator wrestling to get them away from the pumps.

  • When you’re fighting fires … no, the fire-fighting metaphor is way over-used in IT already.

  • When you’re busy bailing water out of the boat, sometimes it’s difficult to stop doing that long enough to go plug holes in the boat – never mind taking time to hunt down the idiot with the drill.

These all address the basic truth that it’s really easy to focus too hard on the things like day-to-day monitoring of process, and miss the opportunity to educate your co-workers, to spend time on a design that prevents an exploit from occurring in the first place, or to assist a team that’s designing a new project, so that they can make good decisions.

So, what’s my answer to this problem?

It’s a little bit ruthless – simply stop doing the reactive stuff after a while, and spend some time on the preventive work.

If you’re only doing reactive troubleshooting (“fire-fighting”), you’re not progressing. If you’re not progressing, you’re not preventing the fires. You can reasonably say that you don’t have time to do more troubleshooting than you’re doing, even though you could potentially take time away from the design work, the learning, the teaching, the planning.

You do at some point have to put down the hose, and teach people to stop using so much wood and sawdust in their buildings.

EFS in a domain expires after three years

I enjoyed the research for writing my article on EFS, for the Technet Security Newsletter, but there’s always something experience will teach you.

Here’s an issue I experienced just last week, with EFS. It shouldn’t have been a surprise, given what I already know, and if I put the two facts together, you’ll probably spot it straight away:

  • EFS certificates are automatically issued, and expire after three years if you use the default EFS template.
  • When you create a domain, the administrator account on the first domain controller is automatically given an EFS certificate, so he can become the domain’s default DRA.

You’ve spotted it already (and the title helped you, right?) – after three years, the administrator’s EFS certificate expires.

His certificate may get renewed, so he can encrypt more documents, and of course his old private key still allows him to read files that were encrypted while the certificate was still valid.

That assumes, though, that the administrator’s account is an actively used one.

Whether it’s used or not, though, the fact remains that the DRA certificate does not get updated in the default Group Policy Object – and as a result, even if the administrator renews his EFS certificate, EFS will be effectively disabled throughout the domain.

Here’s the dialog you get:


For those of you using search engines, that dialog says “Error Applying Attributes”, “An error occurred applying attributes to the file:”, and “Recovery policy configured for this system contains invalid recovery certificate.”

Pretty much your only good choice here is “Cancel”, until you can generate a new certificate and add it to the default domain policy, being sure to remove the old expired cert.


[That old private key can be used to recover anything that was encrypted using EFS before the key expired. Always hold PFX files on keys that can be used to decrypt information – always, always, always.]

There’s no easy way to put the new certificate into the default domain policy, so you have to do it by hand. You might as well also generate the certificate by hand, and make sure that it’s not associated with a particular user account (why should it be? it’s just a key with a purpose, and that purpose is not associated with a user.)

How do you do this best?

A simple command line is easiest, in my opinion:

C:\>cipher /R:EFS_DRA_20070324
Please type in the password to protect your .PFX file:
Please type in the password to protect your .PFX file:

Your .CER file was created successfully.
Your .PFX file was created successfully.

That generates two files – EFS_DRA_20070324.PFX, and EFS_DRA_20070324.CER. As hinted at in the output, the PFX file is protected by a password (as they all should be) – move this immediately to a floppy disk and lock it in a cabinet, along with documentation of the password you used (or segregate the two, whatever your certificate handling policies dictate). Or maybe you expect to have frequent requests to recover EFS-encrypted files, so you want the Service Desk to own the PFX file.

Then, go through whatever change management nightmares you have to do in order to edit the default domain policy, delete the old expired certificate, and import the one you just created.

Now, encrypt away, knowing that your encrypted files can be recovered using the PFX file you just created.

Couldn’t have done that at Microsoft

Today, another reminder of things I couldn’t have done at Microsoft.

Last night, I rushed home from work in time to take my kid to his Webelos den meeting.

There, we worked on his Pinewood Derby car.

He’s been sick most of last week and weekend, so he hasn’t done as much work on it as he’d like.

So, I stayed up late last night, gluing parts together, and finishing up painting on spots he hadn’t managed to get to.

I got up early this morning to finish the job.

And I even managed to put in some time on my own car.

I never could have done something so time-consuming while I worked at Microsoft.

Microsoft may be great for some, but I couldn’t successfully maintain their lifestyle.

WIP: Principles of Secure Software Development

This is a work-in-progress, but I’d like your opinions on it:

 Principles of Secure Software Development

  1. You’re not that good – someone will find a hole in your software. Find as many as you can, first.

  2. You’re still not that good – you didn’t find all the holes.  Someone will find a hole in your software. Have a plan in place for when that happens. Pay someone to find holes.
    [Corollary: If you aren’t that good now, you weren’t any better before, and you’ll be just as bad in the future – so when someone finds a hole, scan for other similar behaviours in the rest of your code, and put processes into place that prevent you from making the same mistake in the future.]

  3. Someone else is better (or has had more time to iron out the wrinkles) – if someone else has written it well already, use theirs. Make sure you keep up-to-date with fixes on it!

  4. Even they are not that good – review and test for security threats in anyone else’s software you use.
    [Corollary: You were never that good, nor was anyone else, and you / they never will be. Re-visit old code with new understanding. Document new code as you write it and as you change it, and make sure it is simple enough to understand. Complex code has complex bugs that are hard to find.]

  5. They wrote it for themselves, not for you – if you use someone else’s software, review their assumptions and see if they still apply in your environment. [c.f. Rocky Horror Picture Show, “I didn’t make him for you”]

  6. Comments are not code (but code should read like comments) – use comments as a suggestion of how the code was supposed to run, and remember that code is often changed without updating comments. Make your code tell all the story it needs to.

  7. If it’s not your code, it’s data, and data is evil until proven good – anything that you don’t hard-code into the program is data. That includes mouse movements, window messages, network traffic, keyboard input, etc, etc. Anything that isn’t in your source code should be treated as malicious until proven otherwise.

  8. People are replaced easily, processes are not – ensure that your secure development processes revolve around processes, not personalities.

  9. Secure development just plain takes longer – so make time for it. If you don’t have time to do it right, when will you have time to make it right?

  10. Secure code just plain works better – it’s more reliable, has fewer bugs, is simpler to maintain. It may bring you to market slightly later, but a “second-to-market” product can beat a “first-to-market” product if it has an improved reputation for reliability.

So, let me know what you think of these – ten is a number picked rather arbitrarily, I could extend or reduce the list if you think I should.

Just say anything…

If there’s a message I heard repeatedly over the last week while I was at the MVP Summit, it’s this:

Blog more.

There were a number of people who said this to me, and I was reminded of the advice I gave to other people when they ask what to blog about, how often to blog, etc.

So, I’m going to take my own advice, and I’m going to offer it here:

  • Set a reminder to yourself to blog on a schedule. Use Outlook, or whatever calendar software you favour, to bring up a reminder on a repeating basis, that you need to use some time to blog.
  • Blog daily, weekly, every other day, hourly, whatever you have time for, and try to keep to a schedule that’s slightly more frequent than you think you should – that way, when you skip, it won’t matter so much.
  • If you don’t have anything to say, don’t say anything – but think really long and hard about whether you truly have nothing to say.
  • Bring up an old memory – a topic that you know well, a piece of global knowledge, even a universal truism that you think everyone already accepts. I can guarantee some of your readers haven’t ever read it.
  • Write keywords into your article – most new readers will hit your blog based on a web search or a recommendation from a friend. Recommendations will come from good content; searches come from good keywords. Creatively mis-spell some keywrods, so that bad typists discover your blog first.
  • Ask a question, to elicit comments – page views are one measure of a blog’s success, comments are another.
  • Keep an eye on the spam comments – remove them if they slip through, and remember, if you’re getting spammed to, that means you’re popular in someone’s eyes.
  • Keep it short, but don’t skimp on the information content. Provide a complete article, but don’t scare people away with length.

On that last note, of course, I should wind up this posting.

So, what advice would you offer bloggers who don’t know how to blog?

Global MVP Summit March 12-15

About every eighteen months or so, Microsoft throws a big party for all of the Microsoft MVPs around the world.

The next Global MVP Summit is in Redmond (as always), next week – March 12th to March 15th.

In honour of the MVPs being away from their usual desks, Microsoft have promised not to deliver any security-related patches, and to keep us away from the chaos that follows any misapplications of the Daylight Saving Time patches.

[I’m kidding, of course – Microsoft didn’t deliberately schedule this around DST, nor are they holding any security patches back for us, they simply have no security patches to give to the world as yet.]

So, yeah, I’m excited. I get to meet with a large number of good friends that I’ve only ever met online, and a few people with whom I frequently disagree, but I’m certain to get on well with them all.

Did I say “party”? Well, yes, there’s one or two of those, in the evenings, but the day starts early – the buses depart from hotels at 7am, and Microsoft likes to spend the day shoveling us full of knowledge about new software, new ways of working, or even better ways of using what’s currently out there.

What’s truly exciting about this – and different from any other conference I’ve been to – is that everyone at the MVP Summit is there because they love to figure out new things and to help other people figure them out, too.

At other conferences I’ve been to, I’ve seen people who are simply there because their employer sent them, and they really can’t imagine what use they’ll get out of half of the sessions.

At MVP Summits, some of the attendees are there despite their employers – many are doing this entirely on personal funds and personal time off work – and they are all keen to get maximum use out of their time in Redmond.

As with any time of the year, there are some people who can’t make it – last time I went to a Summit, it was scheduled around the same time as Passover, so many observant Jews couldn’t make it. Last time, it was right after I left Microsoft, so I couldn’t make it, as I wasn’t re-awarded yet. This time, it’s right before April, so many accountants can’t make it. They will be sorely missed.

There are also things to be nervous about – my MVP award expires on April 1 – but I don’t yet know whether I’ll be re-awarded for this last year’s community contributions. I’m also going to be a part of one of the sessions – that should be entertaining.

Most of what’s put out by Microsoft at the Summit is covered under an NDA – Non-Disclosure Agreement – meaning that I can’t share them with you – but of course, we’ll all be blogging what we can, because that’s one of the things we do that made us MVPs in the first place!