Developers still don't get it.
I'm perplexed by a statement made by one of the commentors on a recent Michael Howard blog posting.
Why would you NOT run [Visual Studio] as an administrator at all times?
As a developer, I spend enough time on my own work. I don't need to be spending ONE second switching profiles, typing passwords, or wondering when something fails whether it is a security issue or not.
I know many developers, and not a single person I know develops as non-admin. Since VS2005 needs to run as Admin, I'd be willing to bet that 99% of the Visual Studio team does the same thing too.
(and yes, I own (and read) Writing Secure Code, and I do keep a low-privilege account to test my apps, so I'm not *totally* ignorant about security issues)
This emphasises a few things I've said on numerous occasions in the past:
- Developers are prima donnas (you may have heard me use a different description, beginning with an "a", and ending in "rseholes"). I can say this because I am a developer, and I've spent a lot of my career in the company of developers. "I am not willing to spend ONE second ... wondering when something fails whether it is a security issue or not". Heads up, Bucky - it's your job, very specifically, your job, to spend a lot of time wondering how something will fail, and whether or not it's because of a security issue. If not the developer, then who? Tech support? What you get wrong in Development comes back a thousand fold to Tech Support.
- Owning and reading "Writing Secure Code" is only the start. You actually have to get it. You have to live it and breathe it - and keep abreast of new issues that aren't covered in the book.
- Testing security in to the product never works. It's too late by then, because the insecurity is already there, and it's good at hiding. All testing does is demonstrate that your testing was unable to find the holes.
- Most code is never run by anyone other than the developer, until it gets to a few thousand users - as such, it always runs as administrator under its test environment, so it never fails until it reaches the user.
- Developers are not administrators. Most of them don't even know what group policy is, let alone how to spell it. Even in a managed domain, developers' machines are segregated into their own OU, so that the developers can pretty much do whatever they want with "their" machines. As a result, unit tests are never run on machines that mimic production environments, even for in-house applications.
- You can teach as much as you like, but some people just aren't that interested in learning.
Rather than asking for reasons why a developer shouldn't be an administrator, development team managers should be asking why a developer ever should be an administrator. Have an administrator account, perhaps, but almost all of a developer's work should be done as a local user, unless that developer is producing an administration tool designed only to be run by administrators.
[Nods go out to Susan Bradley and Dana Epps, who brought this article to my attention in the first place.]