It’s not easy being Ben Fathi. As corporate vice president of Microsoft’s Security Technology Unit, Fathi took the place of longtime STU leader Mike Nash in March amid a larger management shake-up just days after Microsoft announced that the shipment date for Vista was slipping yet again. After Nash’s high-profile tenure, Fathi’s charge is more subtle: building what he calls a “trust ecosystem” around Vista and its new security features and promoting the company’s secure development practices. But first he must help get Vista out the door. Fathi sat down to talk with InfoWorld Senior Editor Paul Roberts at the recent Security Standard Conference in Boston about Vista’s progress, and the world after Vista.
InfoWorld: Recently there’s been some back and forth with Symantec about issues such as Vista’s Kernel Patch Protection feature for 64-bit systems, as well as some public criticism of Vista code for having security holes. What should enterprise folks make of that?
Ben Fathi: First, on the paper Symantec published: We thank them for their input. I think it’s unusual for a partner to go public with a paper like this on a beta product, but they did identify a few issues. To the best of my knowledge, all those were already fixed in more recent beta releases. We love to hear feedback on beta products. That’s why we’re in beta. It’s a test. We’ll fix them as long as they report them to us.
As for the kernel patching, we fundamentally believe that the current model of kernel patching is broken and not sustainable. We never recommended it or supported it on any version of our operating systems. As we’ve been telling our vendor partners, this is the only chance we have, as 64-bit computing becomes available, to start with a clean architecture and build on top of that. We want to work with you to find ways to extend the kernel functionality by having a clean architecture, APIs, and filters. … instead of patching instructions and data structures in the kernel. In the long term, what we want to do is move a lot of these functionalities to a hypervisor that sits under the kernel to make the kernel even smaller and the trusted computing base even more secure. We still have a window of opportunity here. … and we’re working with two or three vendors in the space to come up with that kind of architecture.
One of the other comments that’s been made is that [Kernel Patch Protection] is anti-trust. That we’ll go back in with our own products and get around it. That’s absolutely not true. We’d never do that.
IW: You recently patched a beta version of Vista. Is it a bad sign that you’re patching beta Vista?
BF: I believe that Vista is significantly more secure than any version of XP or anything else we’ve shipped in the past. Just SDL (secure development lifecycle) in general and the process of penetration testing and hardening kernel services. These all created a stronger, defense in depth strategy. What I would say is, Yeah, there will be patches and vulnerabilities as we move forward. What we’re hoping is that by creating these layers of defense, we’re giving customers, especially enterprise customers, a longer time to test and make sure things are not broken.
IW: Do you see your job description and responsibilities changing after Vista?
BF: There are six different areas that we call “Big Bets” that have been identified in my division. I will mention two. The first, Application ID, is a way to identify an application that includes an executable, the library it uses, configuration files, registry settings, any patches that are applied to it. So you’ll have a cryptographically signed version of the application, and you’ll be able to identify that and whitelist or blacklist that.
When we talk about a trust ecosystem today, the ability to trust people based on an ID and trust machines based on an ID, we can’t do that with applications. If it’s called powerpoint.exe, we go and run it. So having strong IDs based on the application and [making] sure they haven’t been tampered with after download is an important investment for us.
The second area is isolation. Creating guest operating systems that sit on top of hypervisors allow us to create better isolation mechanisms so that even if malware comes in, it only affects one subset of the machine and not everything else. We’ve done some great work on server hypervisors and server virtualization. We need to extend that to the client. We’re seeing partners do that already, and so we’re going to invest in that space.