Q&A

Q&A: Mark Russinovich on 'Zero Day' and Beyond

The Microsoft technical fellow discusses his new novel about dangerous malware a security expert must eliminate.

• By Kurt Mackie
• 12/02/2011

Security researchers describe a "zero-day threat" as a malware threat capable of exploiting vulnerabilities in software that were largely unknown beforehand. "Zero Day" is also the title of a novel by Mark Russinovich, a technical fellow at Microsoft and the author of Sysinternals tools and the "Windows Internals" series of books (Microsoft Press, 2009). He's an expert lecturer as well, having given talks at the Black Hat security conference, among other venues.

In "Zero Day" (Thomas Dunne Books, 2011), readers get a glimpse into a ticking time-bomb scenario that software security expert, Jeff Aiken, races to defuse. Kurt Mackie, news editor for the 1105 Enterprise Computing Group, asked Russinovich about some of the ideas postulated in the novel, as well as the challenges faced by security experts, both now and in the future.

Redmond: One theme in the novel appears to be the deskilling of labor due to software, which then exacerbates tragedies in the book -- it that the backdrop?
Mark Russinovich: I think that's part of it. We see a headline almost everyday about a major company being hacked, Web sites being defaced, government organizations being infiltrated. And many of these breaches are due to misconfiguration, lack of patching, and weak passwords -- things where management and IT staffs are cutting corners and basically leaving doors open. It's one thing to say that no system will ever be 100 percent secure, but it's another to just not follow well-known practices for making systems as secure as we know how to make them, and I think that both of those things are at play.

The novel presents some characters as having to act as babysitters of complex equipment. What's your view there?
Russinovich: I think you're referring to some of the people operating equipment in plants, and isn't it a bad thing that people don't know how to manually operate things? This lesson is being well learned right now. I'm in the Windows Azure cloud operating system team at Microsoft. And one of the lessons we've learned when it comes to running cloud services is that "humans are bad, automation is good." Whenever you stick a human in the mix, your chance of a mistake goes up by orders of magnitude. So that's one reason to have humans sitting there babysitting and not messing with things. And then when it comes to being able to override, there are systems that are so complex that a human wouldn't know how to override it in a safe way potentially, without assistance electronically. So I think it's inevitable that we're going to have more and more systems become automated in this way with very little human oversight. Microsoft's datacenter is just another example. There's just basically skeleton staff in these massive datacenters with tens of thousands of servers in them, just because everything is automated.

What about government regulation -- is it effective for addressing complex systems reliant on software? For instance, the novel looks at the nuclear industry.
Russinovich: The nuclear industry specifically is more regulated in terms of cybersecurity than just about any other sector of critical infrastructure, but that regulation really has only kicked in seriously in the last year, and then it's kind of self-reporting compliance. So the nuclear industry has got a whole bunch of cybersecurity guidelines and the power plants that are run by the private sector are required to submit reports that explain how they're meeting these cybersecurity requirements, and as far as I can tell from the public information, it's not like the Nuclear Regulatory Commission is sending out cybersecurity experts to these places and verifying everything they've written -- trusting these guys to say, "This is what we're doing; we're keeping all of our systems patched." And maybe they're not.

What about the example of the Stuxnet worm that attacked industrial control systems (or "SCADA") associated with Iran's nuclear centrifuge technology? It attacked zero-day Windows vulnerabilities. Was it just some script-kiddie job?
Russinovich: The fact that it had four zero-day vulnerabilities, right there you know that it's not from script kiddies. Zero-day vulnerabilities are out there that nobody knows about to be discovered and they're discovered all of the time. It's rare to run across a piece of new malware that takes advantage of one zero-day vulnerability -- much less four in one shot. You add in the fact that this thing had essentially a rootkit for SCADA from Siemens, which requires a whole other level of sophistication. And you combine these two -- the Windows aspect of it plus the SCADA system aspect -- and you've got a very sophisticated operation. So, there is no question that there are some organized, highly professional people behind this thing in my mind.

Maybe that's a scenario for novel No. 2?
Russinovich: I'm working on the sequel, "Trojan Horse." It picks up with the protagonists from "Zero Day" two years later, this time focusing on state-sponsored cyber-espionage, something that we've also seen a lot of in the news. It's scheduled for publication early Fall next year.

What are "rootkits" and how effective are they in cloaking malware?
Russinovich: There's no one really precise definition for "rootkit." The only definition that I believe is applicable is that it's malware that's hiding its presence in some manner from standard diagnostic and administration tools. Many of those techniques that they can use to hide their presence are very hard to distinguish from legitimate software. One example is a file system driver. If a piece of malware wanted to hide a file, it could implement something called a file system filter driver in Windows, which would intercept the directory listing API call and on the results take out the malicious file from the listing. That filter driver mechanism is a supported part of Windows, and in fact, antivirus software is built using filter drivers. So it would be very difficult for Windows to know that this thing is doing something malicious.

Commercial antivirus programs and firewalls seem to fail from time to time. Will some other way of ensuring security be required for OSes?
Russinovich: One of the burdens of Windows and the desktop OSes that are out there is this legacy that they've got of being designed in a world where security wasn't the problem that it is today. We started out in this world where everyone was an admin of your machine. Whatever you ran had admin rights, and then over time, we threatened to close the door on that. There are varieties of these new mobile OSes that have created an opportunity to reset because there's no application incompatibility to worry about. So they're introducing two gates to try to control the malware problem. One is these app stores, which have a vetting process, which is a first line of defense against malware getting into the system. And the second is the sandboxes that they've created as part of the application model, which are much more restrictive -- and can be because the apps that are being designed for these things are new so they can be designed to operate in the sandboxes. Windows Phone has got this app store plus the sandbox -- Android, iPhone and RIM also have it. So, you're seeing this in all of the mobile OSes and you're seeing it move up in the desktop OSes.

Apple has created sandbox technology in Mac OS and applied it in a few different pieces of Mac. Windows has it in some places -- Office is a great example. Microsoft has created a sandbox for their Office viewers that try to contain malware in a malicious document that a user opens to look at. This is why if you're using a newer version of Office and you get a document from somebody and open it from e-mail, it will open in read-only mode, and that's because Word is running in the sandbox. As far as networking changes, we've still got a ways to go on figuring out how to deal with the networking problem because we've got an application-compatibility problem here.

The novel posits malware that can evade the honeypot URLs of security vendors. Does such malware exist?
Russinovich: That's a fictional creation. But it's not implausible to think that the malware community couldn't figure out where some of these things are.

What tools would security expert Jeff Aiken, the protagonist in the novel, take with him to track malware at a client's location? Would it be your Sysinternals tools?
Russinovich: Absolutely, those tools would be an integral part of his toolkit. Not that those would be the only tools in the toolkit, but of course he'd be using them. In fact, I've been giving talks about using the Sysinternals tools to hunt and clean malware, both to security professionals at Black Hat and the local information security group here from the Information Security Association. And the talk is really well-received. There are other tools he'd be using, though. He'd be using debuggers, a virtual machine, code analyzers, rootkit analyzers -- systems that are looking for anomalies in Windows. There are forensic tools on the market that are pretty sophisticated for taking a look at images of systems and finding interesting tidbits in them.

At a certain point in the novel, Jeff Aiken decides it's best if the public becomes aware of a malware threat. How should vulnerabilities be disclosed?
Russinovich: Microsoft has a policy that we call "responsible disclosure," and I think this is a policy that's intended not to hide bad news or cover up the dirty laundry but to help protect customers and computer users. That is, if somebody discovers a vulnerability, they should approach the vendor, report the vulnerability directly to them and then give them a reasonable amount of time to respond to it. And if the vendor hasn't responded within a reasonable amount of time, they're free to disclose it publicly if they want to, understanding the implications of doing so. If you find a vulnerability and disclose it immediately without giving the vendor time to look at the vulnerability, understand it, and see what it would take to fix it, and actually get a fix made and test it, and get it made available to customers, you're basically creating a zero-day vulnerability.

Many people look at the processes running in Windows Task Manager when they suspect malware on a machine. Is that an effective approach?
Russinovich: In the malware talks that I give, I talk about how to use Process Explorer to investigate suspicious processes. There are many types of malware where Process Explorer and other tools from Sysinternals will enable you to get clues about them. If you're suspicious, you can drill in and find out really what this thing is from, and what it's for. But that said, there's nothing that says that malware needs to hide as a process. It can be hiding as a DLL -- that's harder to find. Or it could just be a snippet of code sitting some place in memory in some random process. Really, that's almost impossible to find without knowing where to look because there's so much noise that this thing is going to be like a needle in a haystack.

What's your background in getting employed by Microsoft after starting your Winternals company?
Russinovich: Well, my relationship with Microsoft goes back to the mid-90s. I started causing trouble for Microsoft by publicizing bugs in Windows, writing tools that exploited those bugs, and then I really got in hot water with them when this Workstation vs. Server controversy in the press started up. It's ancient history, but in any case, marketing people were saying that Server and Workstation were very different, but I did some research and found that it's actually built and runs from the same binaries and that runtime determines its behavior. I made a tool that would flip Server into Workstation and vice versa that they didn't like, and the press got a hold of it and said, "Microsoft's lying." So Microsoft reached out to me at that point and I finally contacted the Windows kernel team with Mark Lucovsky [former Microsoft employee who's now vice president of engineering in charge of Cloud Foundry at VMware Inc.].

I started working more closely with Microsoft in sending bugs directly to them. So I started to build up some good will. And then in 1999, Dave Solomon, a friend of mine who'd I met on the speaking circuit who was teaching Windows internals, had authored the second edition of the "Inside Windows NT" book and was working on the third edition, which covered Windows 2000. I'd always wanted to write Windows Internals books so I asked him if he was interested in a coauthor and he said, "Yes," and so I coauthored that edition with him. And I brought in a lot more experiments using the Sysinternals tools. I also stood at teaching Windows internals with Dave, which included many deliveries here on [the Microsoft] campus to Windows developers.

I became good friends with a lot of people on the Windows team, including people like [former Platform Products and Services Group Co-President] Jim Allchin, who at the time was running Server and Windows. So that relationship that I established led into discussions about working at Microsoft. Of course I had this software company, Winternals, and I said, "Sure, buy Winternals and I'll come work at Microsoft." In 2005, Jim Allchin said he wanted to make things work in getting me in and having an acquisition of Winternals. They offered some amount and we couldn't come to an agreement. About a year later, we came to a price we both liked and I came to Microsoft.

Finally, will "Zero Day" ever see the light of the "silver screen" -- that is, movie rights in the near future?
Russinovich: I'd love to, if somebody in Hollywood is interested. I'm available.