A Blog for Graymad

Today I finished up my week in the sunny Florida panhandle presenting security talks for MSDN. On Tuesday, I was in Pensacola. The folks there were great, and a fun crowd. I also had a good time with my group today in Fort Walton Beach (the actual event was in Mary Esther). In between, my wife and son and I got to spend a little time at the beach. My son, who just turned 1 year old, got to stick his toes in the sand for the first time. He wasn’t quite sure what to make of it at first, but warmed up to the beach after a while.

Next up for me are the more Northern Exposures of Portland and Bangor, Maine, where I’ll be speaking next week. Here’s the rest of my schedule, at least as far as I know it now:

UPDATE: Added the last few dates on this tour. For those of you in Jersey, looks like I'll be making it up your way after all!

4/27 – Portland, ME
4/29 – Bangor, ME
5/11 – Cumberland, MD
5/12 – Hagerstown, MD (Martinsburg, WV)
5/13 – Baltimore, MD (Bethesda, MD)
5/18 – Richmond, VA
5/19 – Norfolk, VA
5/25 – Honolulu, HI
6/1 – Allentown (Bethlehem), PA
6/2 – North Brunswick (Bridgewater), NJ

Fortunately, after Maine, I get to stay a little closer to home. If you’re in one of the areas listed above, please register for the event (they’re free!), and come out and say “hi!”. Also, note that for each of my half-day events, which start at 1pm, there is an accompanying TechNet security presentation, targeted towards IT administrators, that begins at 8am, and runs ‘til noon. So there’s lot’s of great security information to be had just for the asking. Hope to see you at one of the events!

I’ve written about the problems of running your machine day-to-day as Administrator, and tips for making development as a non-Admin easier on a number of occasions. As a brief reminder, there are many viruses and other malware that would never have spread as widely as they did if the infected user had not been running as admin. Additionally, developers who run as admin when they develop and test software can inflict errors on those who use their software while running with lower privileges. And unfortunately, the ad-hoc “fix” for such problems often ends up being for that user to run with elevated privileges.

This week, I had the opportunity to address a question on this topic to Steve Ballmer at the MVP Summit in Seattle. I’ve noticed, to my dismay, that many Microsoft presenters continue to run as Administrator in their demos, with no discussion of what the security implications of that choice are. So I asked Mr. Ballmer how those of us who speak to Microsoft customers about security can credibly argue for not running as Admin when many Microsoft presenters are running their demos with elevated privileges. I’m pleased to report that he took the issue seriously, but if things are going to change on this issue, it’s also going to take help from you.

If you attend a Microsoft presentation, and the presenter is clearly running their demos as Administrator, ask them about it. Ask them why they’re doing it, and ask them to discuss the security implications of that choice. I’m certainly hopeful that Steve Ballmer will address the issue from the top, but it can’t hurt to have Microsoft’s customers and developers in the community asking the right questions as well.

The good news is that tool support for developing as non-admin is getting better. One example is that in Visual Studio 2005, it will no longer be necessary to have admin rights to debug ASP.NET applications (because Visual Studio 2005 will ship with its own web server that works only from the local machine). The more improvements like this in tools and OS support for running as a non-admin, the fewer excuses there will be for working with higher privileges than necessary. Combine that with presenters leading by example, and perhaps we can make a dent in this issue.

Useful tidbit from the MVP summit:

To start from a clean slate with an install of Visual Studio 2005 CTP, open a command prompt, navigate to the Visual Studio install directory, and enter the following command:

devenv /resetuserdata

This will reset user-specific settings, etc. to provide you with a (mostly) clean install without any customizations you may have made. This can be useful for demos, etc.