Published: March 1, 2005
Steve Riley: Hi, I'm Steve Riley, a Senior Program Manager in the Security Business and Technology Unit. Our group is responsible for all of the security bits in the operating system, as well as security products like ISA Server and Rights Management Server. Today, I have with me Anne Legato from Microsoft IT and together, we will tell you a little bit more about Windows XP Service Pack 2, some of the security features in it, as well as what we've done in Microsoft IT to get secure with the Service Pack.
Anne Legato: I'm Anne Legato and I work in Microsoft IT, and we manage all the corporate infrastructure and desktops within Microsoft. We play a strategic role in the testing and deploying of Microsoft software before customer release, and call ourselves Microsoft's first and best customer. We set shared goals with our product groups, which include us deploying beta products into production, our production environment, providing a positive user experience when they install our products and minimizing the impact on our user desktops by testing our applications well before we deploy [them] in production. We also develop our call center and user training to reduce our number of support calls. Our second key partnership with the product groups is to provide critical feedback on the products during the development cycle, so we can improve the products before they're sold to our customers.
Steve Riley: Thanks, Anne. Before we get into exploring some of the security features in the service pack: I spend a lot of time with customers and they seem to face many of the same kinds of pain, no matter who the customer is or where they're located. Tell me a little bit about maybe the kinds of pain Microsoft IT was facing in its efforts to try to get our environment more secure.
Anne Legato: We have the same issues as most companies, when it comes to security. We have implemented a number of measures to protect our perimeter and our infrastructure. One of the larger issues that we face is on our desktops. Traditionally the desktop operating system has not been given a lot of attention when it comes to security, and with this particular product we're looking at that squarely and determining what type of a tax do we have on our desktops and what can we do to reduce that pain.
Some of the things that we do have attacking our desktops are spyware, the regular worms, e-mail attachments that execute maliciously internally and, because a lot of this comes from the Internet, it's very difficult to detect and block this at the desktop. One of the issues that we need to deal with is a central management of the desktop and what we use at Microsoft is the Active Directory group policy objects, in order to deploy and manage our desktop security.
Steve Riley: So it's good. It sounds like many of the features in the security pack were addressing specifically the needs that we had. I'm also finding it's true [for] many of our other customers. Let's talk for a moment about some of the goals in the security pack and what we had in mind when we developed the security features that were present. A long time ago, back in the days of NT 4 - I think it was around Service Pack 4 - we made a promise to you. We said that there would never be any more features in a service pack, and we promised that service packs would only contain hot fixes, patches, updates that had gone through more regression testing because we had more time. Well, we felt that with some of the things that we were doing in Windows XP with this service pack, the security features especially, that we wanted organizations to treat that as critically as they would treat a service pack. If you were looking at Microsoft.com and you saw a download called the security feature pack, it might not receive the same amount of critical attention that a service pack would.
Therefore, we admit we broke our promise and we added features to a service pack, but we did it because we believed it was absolutely necessary to improve the resiliency of the operating system to live in the hostile network that we have now that designers of software and even software as recent as Windows XP never really imagined that the Internet would become the hostile place that it is right now. And it's more imperative to software designers than ever before that they build in features that can increase the resiliency and security management, for example, so that it's easier to configure and maintain.
We also found that even with the features that were present in the original release of Windows XP, they were very difficult to find. There was a firewall, but it was switched off and discovering that was very difficult. So we decided that it was important to make the thing easily discoverable and that other security features that we were present would be turned on by default. Now that would have some ramifications around application compatibility. We'll talk a little bit more about that later. It's also true that patching as your only line of defense is becoming less and less of an option. The time between when exploits are available and when patch code is available is getting smaller and smaller, so it could be we're getting to the point now where there isn't enough time to patch before a system could be damaged.
So we wanted to make sure that there are other security features present in the operating system that would help reduce the damage of worms and viruses, even before a patch is installed. It is essentially all about making an attacker try to work harder. Now if you think about, say, in your neighborhood, if you protect your house, and what would you do to make an attacker, a burglar, work harder at breaking into your home?
Anne Legato: I would have an alarm system.
Steve Riley: That's true. You'd have an alarm system and in the box with the alarm system, besides the bells and the wires and the sensors and all of that, is an indicator of some kind to the attacker that you have an alarm, right?
Anne Legato: Like a barking dog.
Steve Riley: A barking dog or a sticker or a sign or something. So you put the sticker in your window and when the attacker is walking down the street looking for somewhere to break into, he sees your sticker and what do you think he might do?
Anne Legato: Pick the house without a sticker.
Steve Riley: Right. So, by putting the sticker on your window, you have decreased the security stance of all of your neighbors, which is kind of an interesting thing. But maybe you could have not bought the whole alarm system and just put the sticker on your window and accomplished the same thing. But unfortunately it doesn't work that way in the electronic world. You can't just put a picture of a firewall in front of your network and hope that the bad guys will move away. You actually have to do remediation. You have to [use] better technology with improved processes, as well. What we have realized is that relying on the network as your sole form of protection has reached the end of its useful life. The perimeter is, for all practical purposes, almost gone. Every machine is becoming its own perimeter. When you think about all of the different ways of getting into a network, wireless networks, on site consultants from vendors, mobile computers that come and go, we at Microsoft have taken the position that each individual computer must now take more responsibility for its own security. Moving the security decisions from the edge to the host, it's almost as if the host is now the edge.
Anne Legato: So, Steve, of the three scenarios that Microsoft IT found most important - blocking attacks, reducing spyware and stopping malicious code from executing - what are some of the changes and enhancements to the Windows firewall that we've added to block attacks?
Steve Riley: There's been a number of changes, actually. One thing we didn't change was the behavior of the firewall. A lot of other third-party, host-based firewalls have an outbound blocking feature. We looked at that, but what we discovered was that, in almost all instances, it served no purpose at all. Users would always answer ‘yes' whenever the firewall asked if an application wanted to talk to the Internet. Does Internet Explorer want to talk to the Internet? Well of course, yes. Does Outlook Express want to talk to the Internet? Yes. Do you want to allow Dancing Pigs.exe to talk to the Internet? Yes, okay, bam, now you have the worm. People would never make the right security decision. And then another thing we noticed in our testing was that it was extremely easy to circumvent outbound protection. If I'm going to put a worm on your machine, I'm not going to have my worm make an Internet connection. Instead I'll wait for my worm to look for Iexplore.exe to open, or mshtml to start. And when that happens, I can just ride atop the connection, which already has been given permission.
So we don't really view outbound protection as a security feature and we rely on other things in the operating system to control the execution and communication of software on the box outbound. Therefore, we decided to do two things with the firewall very well. That is: block inbound attacks, and allow the thing to be managed by group policy. So, the Windows firewall, when it is enabled, will block everything inbound except traffic that is a response to a request that left your PC. So, if you go to a Web site, then we will allow that Web site to have sent its traffic back to your computer.
There is one form of outbound blocking that we do [block] and that's spoofed traffic. The firewall will not allow your computer to generate packets with a destination address of its own IP address, which is a good thing, so that someone can't use you to spoof somebody else. Or, that someone can't spoof somebody else with you. We've also moved the firewall activation. Well, it's still present where it used to be, on the advanced tab of the network properties, but we also have a control panel for it. It's right there in the control panel as an icon. You can enable the features and control it that way. The firewall is on by default now, in upgrades and new installs. This was a difficult decision for us to make, because we felt that it might cause some compatibility problems with applications. It turns out that it isn't as big of a deal as most people think it is. Remember, since the firewall does allow all outbound traffic without prompting, that third-party application should work just fine.
The only instance of where you might have a problem is if the client side of the application needs to listen for incoming traffic; then, you would have to create an exception for that. You have to grant that application permission to listen, which is an alternative to opening a port. Statically opening a port means that the port is open for as long as the operating system is booted. When you grant an application permission, you don't need to know what the port number is. The firewall watches when the application binds to a socket, picks the port number, opens that port number only so long as the application is in memory, and when the application terminates, the firewall will close that port opening.
One thing that was important for managing the firewall was enabling what we call multiple profiles. If the computer is joined to the domain then you can have two profiles, a domain profile and a standard profile. This allows you to have a more tightly configured profile in standard mode, which is when the computer is not currently logged into the domain. This would be useful on a laptop machine that is now maybe connected to a home network or to a hotel LAN. Then there's the domain profile that you could configure to be a little bit more relaxed; for example, on this profile you would allow file and print sharing, remote desktop management, those kinds of things. Again, we found that customers wanted to make sure that, even if a firewall was running, they wanted to be able to centrally control the computer still and not have the firewall get in the way of that and the multiple profiles allows us to build a configuration that enables that customer requirement. I mentioned, a few moments ago, exceptions. This is the better way of allowing a program to listen, remember this is only for inbound communications. It will be necessary for you to be a local administrator if you want to grant a program an exception. But you can also do that through group policy, of course. The program itself, however, does not need to run as a local administrator. It can run in a lower security context as an ordinary user or as a network service. You can adjust the scope of these exceptions, you can indicate for each open port or excepted program where incoming requests should come from.
So, for example, you have three choices: "from my subnet only," which means the subnet that this computer is on; "from the entire Internet," meaning any IP address in the world, or "from a range of subnets." This is useful if your corporate network has more than one subnet, and again, that is another thing you can control through group policy. You can indicate to a program which subnets it should allow connections to come in from. In addition to group policy management of all of these features, there is also a command-line interface. This is good for those who are not using Active Directory for group policy; also for login scripts, for example, so you can manage the firewall in multiple ways. And, now, let's go back to talking a little bit about Microsoft IT a little bit more. As you were experimenting with these features and the manageability, how well did they work for Microsoft IT?
Anne Legato: Well, for the most part they worked very well and we found very few applications that we needed to work on to make them compatible with the new security features. We looked at the firewall first, and we had decided long ago that we really wanted a firewall on the desktop internally in Microsoft, [but] found it very difficult to do before XP SP2. And one of the reasons it was much easier with this product is that it's all manageable through group policy.
So that was one of our key scenarios: that we'd be able to remotely manage the firewall settings. And some of the applications that we found that the firewall affected were applications that needed to check in on the client without client interaction. So, for example, many of our applications are initiated by the user from the desktop; so, if I want to launch, oh, Outlook I would launch it from my desktop and if Outlook has a feature that goes out to the Internet, such as the Help and Support (to look for help if you're having issues with Outlook) that it initiated by the person using the program. So it's not blocked from finding those Help and Support files. Now there are some other applications that we have - Remote Assistance is one of them - and we had that configured so our call center technicians could actually ask the customer or the client [at] the desktop to accept an incoming connection, so that they could assist the user [with] issues on the machine. And what we found is that the firewall effectively blocked that communication. So we needed to find a different way to work our remote assistance. And basically the firewall works, in that outbound communications from the desktop are allowed, and then inbound communications that are not initiated by the desktop are not allowed.
So that's when it comes into opening the ports or allowing applications, like Steve mentioned. And one of the issues we also had with the firewall is if we did not allow exceptions or we did not allow the user to add in programs or settings that we would have a really big administrative nightmare, seeing that we have so many different user groups that require different applications in order to do their work. So the settings we chose for the firewall is that it would be on with group policy, but we would also allow exceptions. So we allow our users at their desktop to add in programs or settings in order to enable them to do their work. Now some of the things that we force on with group policy include some standard applications that most of our desktops run. And those are things like ActiveSync, Windows Messenger, NetMeeting and smaller applications that we use generally just to communicate with each other. Now some of the testing that we did, we chose a range of our applications that we use in our line of business, not necessarily third-party applications, not our Microsoft products, but business applications that we've developed internally, and we needed to assess how these were architected to see if the firewall would affect them or other mitigations in XP SP2, like the Internet Explorer mitigations. After we separated out our applications to determine what type of security mitigation might affect them, we then just went ahead and tested them as a general user with a firewall on and then tested them again with the firewall off. And if we had a failure in either case we then dug deeper into the application to figure out which component of the application might be affected by the different firewall settings. So it's fairly testing, we were able to turn up most of our issues pretty much immediately and understand what ports or things needed to be allowed in the firewall in order to have that application work.
Steve Riley: So let me ask you this question: when I talk to a lot of customers they're very afraid of enabling the firewall in corporate mode. They think, "Oh, I don't need it on a corporate network, the corporate network is secure; it's protected." Here we are running the firewall in the corporate network. Do you believe it's making a difference?
Anne Legato: I believe so. As we mentioned earlier, the desktop is kind of the final frontier, it's the last place of attack. It's still the easiest way to spread malicious code, spyware, etc. So we feel that protecting the desktop in that manner just adds one more layer of security, and we think it has stopped spreading issues and spyware and such internally.
Steve Riley: Good, I'm glad to hear that it's been working well.
Anne Legato: Steve, our second large scenario in XP SP2 that we looked at in Microsoft IT was around reducing spyware. And spyware is becoming a big issue on the Internet. It's very easy to propagate, it's getting more malicious as in the phishing and what types of changes in Internet Explorer would you say were the best to reduce spyware?
Steve Riley: We found that a lot of the spyware was getting delivered through weird tricks that some of these spyware authors were doing with scripts and Windows. So probably the biggest change in Internet Explorer is the restrictions now added to the Window Manager. Window Manager is the code in Windows that draws a window on the screen. It used to be, before installing Service Pack 2, that you could perform the following: entice someone with an alluring e-mail to go to some URL and when they do that, that URL is actually running a script. The script would interrogate your video adaptor to find the monitor resolution - say it's 1280 by 1024 - and would open a window, then, that's 1350 by 1100 and center that window on the screen. Now that window is bigger than the monitor and it's centered so there are certain things missing now: the title bar, the status bar, so you can't see what zone you're in. The frame of the window itself, the icon bar, all of the things that tell you you're looking at a window are missing. You're just seeing the center of it. And then the script will fill the window with interesting icons like My Computer and My Network Places and Recycle Bin. So it looks like you're right back on the desktop, very confusing to many people. Next the script will raise another window, a small one right in the center of the screen and it would say your connection to the network has been lost, please reenter your ID and password. Now 95%, and yes I'm pulling that number kind of out of the air, but I would say that about 95% of ordinary users who got hacked by that script would believe that that small window is coming from the operating system, or coming from the network when in fact it's coming from a malicious script running on a Web site somewhere. So they would enter their domain ID and password believing that they're signing back onto the network but actually revealing that information to the attacker who ran that script. So what we've done now is change the way the Window Manager behaves. We've placed a lot of restrictions on what scripts can do. A script cannot open a window that is bigger than the desktop. It cannot pop up another window on top of a first window. This keeps windows from hiding themselves behind each other. There are some other things we've done around prohibiting the kinds of things that a script could do but something that an ActiveX control is allowed to do or something that, if you were to open a window in the trusted computer zones, these kinds of automatic behaviors would still be allowed. What we're doing is blocking it in restricted sites and in Internet sites. So, because of these window restrictions, we've also been able to implement a pop-up blocker; the pop-up blocker will ignore script instructions to open windows from three different APIs, I don't remember what they are right now, but we'll give you some resources at the end of this talk so that you can look up that information, if you want to, on your own. Again, the pop-up blocker is only for use in restricted sites and Internet site zones and it's a basic pop-up blocker. It doesn't have some of the advanced things that are present in a few of the third-party products like blocking Flash and for example what we're doing is hitting most of the pop-ups that are responsible for delivering spyware with this feature. You can create exceptions for this, you can grant a domain or a particular Web site the permission to open pop-ups, even though they're not in your trusted site zones.
We've also changed the ActiveX warning. The old dialog box, while technically accurate, telling you who signed the control and indicating that you should trust this only if you trust the issuer really was meaningless to the hypothetical grandmother. There was no guidance there on whether to make that decision or what criteria to use to make that decision. So, we changed the behavior. When a Web site wants to download a control to your computer now, it will get blocked and the information bar will pop up, letting you know that this Web site was trying to download software, do you want to allow that to happen? Click on the bar for more information. Now there's less words there and I think it gives a better guidance on whether to make this decision or not. And there's also one other option now. The old dialog box only allowed you to indicate that you always wanted to trust this publisher, which is kind of like a wedding, you would always trust software from this publisher once you chose that box. Now present on the dialog box is another choice, never trust this publisher. It's a little different, though, than a wedding. It doesn't mean that you will never trust the publisher again. What it means is that you do not want to be prompted for any more controls from this publisher on this page that you're looking at. And that stops an interesting social engineering attack that we were seeing occasionally where an attacker would again compel you to go to a site by sending you an alluring email, that site would have 50 ActiveX controls on it, and the 50th one is the one that delivered all of the payload. Previously, when you would get that, you would say, "oh, no, I don't want that control," and then you'd get another dialog box for the second control. "No, no, no, no, no," and then you'd just give up and click "Yes" to make the control dialog boxes go away. Now, you can say "no, never trust this publisher," and all of the rest of the controls on that page will be ignored. You will not be prompted for those.
Finally, an important feature is the Add-on Manager. We found, in much of the research we did with Internet Explorer crashes, that the crashes were not a result of code that was bad in Internet Explorer, but it was because of an add-on that was creating a problem, whether this is a toolbar or a browser helper object or an ActiveX control. So, we've added an ability for you to indicate whether an add-on should get loaded when Internet Explorer loads. The dialog simply lists all of the Internet Explorer add-ons that are capable of being loaded or are being loaded; you can choose one, and then you can simply indicate whether that should be enabled or disabled. The feature doesn't give you the ability to uninstall the add-on, unfortunately, because Internet Explorer, of course, doesn't know how the add-on was installed. But at least we can keep the thing from loading into memory. Where this is really handy is when an add-on causes Internet Explorer to crash. At that point, we can look at a register in the CPU called the instruction pointer, which has the memory address of the next instruction that will be executed. When IE crashes, we can look at the instruction pointer and then find out where in memory that instruction was going to be executed and we know which DLL then caused the crash. So, the dialog box that lists the add-ons will appear when IE crashes and the malfunctioning DLL will already be highlighted, so you can simply indicate to disable that and then close and restart Internet Explorer and the add-on will not load in this case. So, let's go back to you, Anne, now and talk about Microsoft IT just a little bit. Did any of these changes in Internet Explorer affect our applications?
Anne Legato: Well, yes, a few of them did, Steve. We tested almost 300 applications and a few of the issues that came up were that we had unsigned controls internally. We had a few applications that use pop-ups, so some of the things that we did to fix those applications were very basic. We turned off the pop-up blocker in the intranet, which is now the default setting in XP SP2 for that zone, in order to make sure that those applications that use them were still usable. And as far as the ActiveX controls, we went through all our applications that were unsigned and made sure they went through the test passes and requirements to get signed. We really didn't have that many application issues with Internet Explorer. Our biggest one was a third-party application that we've customized for our ticketing system and that third party actually put out a patch for [its] products well before this product [was] released, in order to make it compatible with XP SP2. So, of all the applications that we tested, 76% of the breaks that we had were Web-based, but most of those were applications that needed minor fixes.
So - Microsoft internally - we decided that, even though our users are very intelligent and understand the issues with attacks and malicious code and spyware, we're also very busy. And people tend to work by habit, so habitually I - even knowing what I know - have hit "yes" sometimes to things maybe I shouldn't hit "yes" to. So, we decided that it would really be best, internally, to implement this product with as many security mitigations on as we could. And we found, through our testing, that we could deploy this internally, with all of the Internet Explorer mitigations in full effect. So, basically, we did not have to turn anything down in order to accommodate our [use of the] Internet.
So, Steve, our third scenario is stopping malicious code. And I know this is a big problem for most people; we've had it predictably through e-mail at Microsoft. Please describe some of the features in XP SP2 that help stop malicious code.
Steve Riley: We've added a number of things - some of them in Outlook Express - for those people who are using Outlook Express. A couple [are] changes to Internet Explorer that are related to this scenario, and [there are] two other things that I'll wait and talk about, in just a moment. First, in Outlook Express, we now are blocking attachments by default. You need to change the checkbox; if you don't want to block attachments, you need to tell it that you don't want to do that. Then, we've done a couple of things around HTML mail. HTML mail can be dangerous. An HTML document has two parts: a header and a body. And what differentiates them is the fact the header is contained within a header tag, and the body is contained within a body tag. Other than that there's no difference. An HTML interpreter will read both parts. The dangerous part about a header is [that] it isn't displayed. It's executed, but not displayed. So, I could deliver malicious code in an HTML header, which will never appear on your screen, but will get executed by Outlook Express or any HTML mail renderer. So, a setting we have now says to read HTML mail as "plain," which is something that I strongly encourage that all users do, when they can. Change that setting so that you're reading HTML mail as plain and then, if you know you're getting an HTML mail that is safe, like from an online magazine that you're subscribing to, you can just click "view HTML" in the menus and convert that back to the original way it was delivered to you.
The other thing around HTML mail is what we call "Web bugs." A Web bug is a one-pixel-by-one-pixel image - white foreground, white background - that is embedded as a link in your HTML mail. When Outlook Express renders the mail on the screen, if there are hrefs to images offsite, Outlook Express would, ordinarily, simply go follow those images to display the pictures on your screen. What happens is: people are embedding Web bugs in mail to use as tracking devices. Since it's a one-pixel-by-one-pixel image and it's got a white foreground and a white background, you can't see it, but when your computer renders it, it will make a connection to the Web server containing that image and so someone can tell that you have read their mail, even if you are not sending back return receipts. There are even some organizations out now that sell a service [through] which you can wrap all of your outbound mail. You would address your mail to their service. Their service will add a Web bug to the mail for you and then deliver it. This is a sneaky way of invading people's privacy, in my opinion. And so, what we are now doing, is we've added a checkbox that's present in both Outlook and Outlook Express to not follow images that are off the main domain of the Internet mail. And, again, this kind of creates an interesting user situation, you get an HTML mail, you read it and no pictures display. The indication you get is that to protect your privacy Outlook Express has blocked downloading pictures. It's a little misleading. Yes, it's stopped downloading pictures, but really what it's doing is it stopped following offsite links to stop the Web bugs from resolving.
A couple of changes to Internet Explorer, mainly [provide] more controls [over] script behavior. If an attacker were able to get malicious code on your PC, that [code] would ordinarily run in a security zone that had higher levels of permissions than a script that runs on a Web site. So, he could get the code on your computer, then have you run a script on a Web site somewhere and his script would call the code on your computer - and the code on your computer would run in the "My computer" zone. Now, we've changed Internet Explorer so that, if a script in a zone with lower security permissions attempts to call another object in a higher permission zone, the call will succeed but the object will execute as if it were in that lower security zone. So even though the script might be living on your hard drive, if it gets called from somewhere in the Internet, it will be restricted as if it were running in the Internet zone itself now. Two other things - and I mentioned these earlier and we'll now explore these a bit - that could create application compatibility problems, mostly, are data execution prevention and some RPC changes. We found, in a lot of our research with worms and viruses, that something common among almost all of them is they were following a bad software engineering practice. Which, I guess, kind of makes sense, right? We don't usually think of software engineering and worms together. There are two kinds of memory in a computer. There's memory that contains data and memory that contains executable code. It's all the same RAM. Mainly, what differentiates these two, is how they're allocated. And it's good software engineering practice to execute code only from areas of memory that have been designated as such. It is very bad to execute code from areas of memory that should only contain data, like the stack, the heap, and various kinds of memory pools that exist. What data execution prevention (DEP) does, when it is enabled, is restrain the CPU so that it will not execute code from these areas of memory that should contain only data. There is software DEP built into Windows. We can also work with CPUs that are designed to do hardware data execution prevention - [this is] sometimes called "No Execute." These would be all 64-bit CPUs and 32-bit CPUs, based on the AMD K8 architecture. But regardless of whether it's software or hardware DEP, when the feature senses that an application wants to run code from an area of memory that is protected, it will stop the application. If it's a user-mode application, it will simply stop it from running and display an error dialog that says "to protect your computer Windows has stopped this program from executing." You can, if you are a local administrator, again, or through group policy, you can grant an application an exception from this. So, if you know that you have an application that isn't a worm but has been coded in such a way that it would trigger this feature, you can add that to the list of allowed programs to run, which is the better way than to just shut the feature off completely, because, if you do that, then worms would run that ordinarily would get stopped. I do need to say one thing about kernel-mode device drivers. In 32-bit Windows - now, this is not a problem in 64-bit Windows - but in 32-bit Windows, if this feature is enabled and a kernel-mode device driver attempts to execute code from the stack, we will blue-screen the box. That was a conscious decision that we made, thinking that it is better to halt the operating system than to have this computer be the source of an infection that would spread very rapidly to other machines. Now, what does that mean in the real world? In none of our testing have we encountered a contemporary device driver that will cause this problem. Some video device drivers, especially from a couple of video card manufacturers a couple of years ago, would have caused this problem, but what we're seeing now is that drivers are being written in such a way that they're not affected by this bad coding practice and are not triggering the feature.
The final change around stopping malicious code has to do with RPC [Remote Procedure Calls]. You need to know that this code is well over a decade old. RPC was written for a different time. It was written for a time when computers were trusted objects run by trusted people connected to trusted networks. There was no Internet to speak of, there was no worldwide Web, and there was not the malicious environment that we have today. So RPC made certain assumptions about the environment and these were valid assumptions. This is an ordinary engineering process, whenever you design a product you make assumptions about the environment it will be used in, and if the environment radically changes, your product will probably have a problem. And that has happened now. The environment that we live in is very, very different than what it was ten and fifteen years ago. It's extremely hostile. It's seething with people who want to cause you harm. And that creates some problems with RPC, [which] was invented for a different time. So, one thing that we've added to RPC is this notion of authentication. There are two different registry keys that you can throw: one to require RPC authentication between applications, and one to require authentication to the port mapper. This is the way an RPC application learns what port number a service is running on. These are not enabled by default, but they are documented. We are making a lot of noise on MSDN and encouraging developers to modify their apps, so that they can work in the environment of RPC authentication, because we believe that, in the future, we will probably make this a requirement, although we haven't decided yet whether that will be so. Now, given some of these changes that we've made to IE, the DEP and RPC authentication, how have these affected Microsoft?
Anne Legato: We haven't been overly affected by these restrictions. One of our test passes that we did, regarding RPC, was to use its highest level of security and what we found with that - which is not the default - is that we broke remote debugging, so we effectively shut down some of our software testers and we did back off on that. We found that the default settings are sufficient for our environment. We had another issue with IE, where we had a few applications that we use very regularly for communications that are Internet-based applications, and we actually needed to set up a user account with that application and download some code from the app to our desktops in order to use it effectively. So, what we saw is that the user experience to set up his account was quite difficult, and took a lot of steps in order to accomplish. So, an item that [the IE team] took on, to put into the product, was something called zone mapping. And this is the ability, through group policy, to add an application that exists in one zone to another IE zone. So, what we did in that test scenario was to add this Internet-based application to our intranet zone, via group policy. This alleviated a lot of the pain that our desktop clients were getting by trying to set up their accounts with this application. For the purposes of that applic...
Amiga789