As Microsoft's chief Trustworthy Computing strategist, Scott Charney can escalate his concerns directly to the senior leadership team headed by Bill Gates and Steve Ballmer. Charney, a former government prosecutor, also spearheads the company's Security Strategies Group, which works to advance the cause of secure products and services. During a recent visit to Boston, Charney met with Computerworld's Carol Sliwa and Robert L. Mitchell to talk about how Microsoft does security.
At Microsoft, much of the decision-making power rests with the product groups that, to some extent, might have competing interests with what you're trying to do. How much power do you have to effect the changes you need to make?
The Trustworthy Computing initiative was announced by Bill Gates. And Steve Ballmer is behind it. And Craig Mundie, my boss, is kind of the father of Trustworthy Computing. He sits on what's called the senior leadership team, which is Bill and Steve and Craig and Jim Allchin, who owns the Windows platform, and Jeff Raikes, who owns the Office platform. As a practical matter, at the highest levels of the company, there is a commitment to doing this. And if I see an issue and I say I'm going to make sure this is being handled the right way, my boss is Craig. So my escalation path is very short, and the people who I escalate to actually run the company.
There are always competing interests, no matter what your line of work may be. The company's publicly held. We have an obligation to shareholders. But security is now good business and very much aligned. So that tension, to some extent, post-9/11, has been reduced dramatically.
Isn't there tension between the business and the consumer sides, wanting to make things as easy as possible to use versus needing to make them as secure as you can?
There is tension there. To some extent, one of the ways to do it is to try to make the security as easy as possible and transparent to the user so they get the security without having to actually manage it or have it impact their experience. On the other hand, there are times when the technology is just not ready.
A smart phone is a great example. It allows me to resync my calendar and my mail. From a security perspective, a lot of people lose these in taxi cabs and leave them behind at restaurants. So maybe one of the things we should think about is encrypting everything on this device to protect the consumer who might lose this device. I've had this discussion with the mobile device people. And what they've said is, "This is a small device, very competitive market." They've got price points in the consumer market that, if they passed them, then people won't buy the product. Moreover, as a practical matter, people like the calendar and the e-mail, but they also want to make phone calls. If you encrypt everything on this device, every time anyone accesses anything like a contact, you have to decrypt it and then when you close that screen, it's got to be re-encrypted. If you encrypt and decrypt every piece of information in every e-mail on the fly, you will have two minutes of talk time. And the reason for that is the battery. There have been no major advancements in battery life. So right now, we're not going to encrypt this device, even though it'd be great for security, because the device becomes unusable.
For security to be embraced, it has to work. People understand that security creates a drag on productivity. The fact that you have to enter your password before you can sign on takes two or three seconds. People have acceptable levels. It takes a minute or two to lock your door when you leave your apartment and open it when you come back. I think most people say, "Locking my door is an acceptable amount of time."
Now you have to think about functionality in the same way. You have to figure out how to provide this functionality in a secure way, and then I figure out how to do this security in a way that doesn't undermine the functionality or so degrade the user experience that they turn it off.
The key thing is that as you try and balance these things. What you don't have anymore that you used to have is, "I don't want to talk about security. I don't want to have to do security. It's not important." Now, at every level of the company, whether it be a developer, an architect, it's like, "OK. How can we balance these competing interests, because they're all important?"
How have you measured progress on the Trustworthy Computing initiative?
There are different metrics that we use in different ways. Very often you look for proof points, and some are specific and some are more general. For example, one of the things we have now is the security push and review process. There are things that we can measure internally about the number of components that have gone through this percentage of large products and all of that. Then you get the external measures -- the number of bulletins you release. . . . Ultimately, the goal is to make the customer's life easier and make security more manageable. So you look at Sasser. For Windows Server 2000, you had to download this critical patch. For Windows Server 2003, it was a nonevent. When you look at that, you go, "Well, 2003 went through a security push." Someone designed a worm and this product was not affected. The customers who had upgraded to that product didn't have to deal with it at all. This is clearly better than where we were two years ago.
Did you establish specific metrics?
We didn't set targets. We didn't say we hope to get down to x vulnerabilities in x years. We're measuring where we're better than we were before and where we're not. Whenever we have a critical or an important vulnerability, we do a root-cause analysis. And the root-cause analysis is designed to figure out, OK, how did it come to pass? Is it just a question of training, bad application, bad development tools, bad testing tools? You can figure out how you can improve the process. You keep trying to make it better and better. And you measure your current state compared to your old state... Zero vulnerabilities would be our target. It's also not a realistic one.