Windows Vista Security

We Have Moved

windowsvistasecurity — Thu, 11 Dec 2008 22:23:00 GMT

Good day, Paul Cooke here.

The Windows Vista Security blog has been a great avenue for us to talk with you about what has made Windows Vista the most secure client operating system Microsoft has ever delivered. However, hindsight is always 20/20 and it is clear that while we started with a good cadence of posts, our volume and insights definitely fell off over time. This is unfortunate, for there are a lot of things to talk about when it comes to the security of Windows. Now, as we start talking about Windows 7, and look for opportunities to discuss relevant security topics in a broader sense, we felt it was a good time to revamp the blog.

As a result, we are re-launching and moving this blog as simply the Windows Security Blog. The renewed purpose of this blog is to make you aware of all the things that go into having a secure Windows environment. This will cover the gamut from Windows XP all the way through the upcoming Windows 7. I plan to post updates regularly and add some variety with guest posters throughout the security space here at Microsoft.

Thanks for all of you that have followed this blog for the last few years and I hope you follow us to our new location!

Windows Security Blog | RSS Feed

Microsoft SIRv5 Released

windowsvistasecurity — Mon, 03 Nov 2008 13:44:00 GMT

Good day, Paul Cooke here.

The Microsoft Malware Protection Center has published volume five of the Microsoft Security Intelligence Report. If you have not taken a look at this report before, I urge you to go download it from http://www.microsoft.com/sir. It provides a thorough view of the current threat landscape and is filled with a number of great data points. In my first scanning of the document, the following items immediately jumped out at me:

· Microsoft vulnerabilities accounted for 42% of the total vulnerabilities on Windows XP for browser based attacks; however, on Windows Vista-based machines the proportion of vulnerabilities attacked in Microsoft software dropped to just 6% of the total. This highlights our not only our continued security investments in the browser but also that attackers are focusing more and more on the applications that run in the browser.

· The infection rate for Windows Vista is significantly lower than Windows XP, regardless of service pack levels. In addition, 64-bit versions of XP and Vista have lower infection rates than their 32-bit counterparts.

· The higher the level of service pack a machine runs, the lower the rate of infection. This is consistent across client and server platforms, across all versions. Clearly, keeping up to date with the latest service pack levels and security patches is beneficial from a security perspective. While we have always thought this to be true, having a data point to prove it is great.

This is just a taste of some of the findings in this latest report. I’ll be scouring this report in detail and come back in the next week or so with a comprehensive look at how Windows Vista has fared from a security perspective since its release!

Posting is provided "AS IS" with no warranties, and confers no rights.

TechED - EMEA

windowsvistasecurity — Mon, 03 Nov 2008 13:38:00 GMT

Good day, Paul Cooke here.

I am in Barcelona getting set up for some sessions at TechEd-EMEA in Barcelona. The weather was a bit dicey for parts of yesterday but today is clear and beautiful. I've got two full sessions and a bit part in a third where I will be talking about Windows 7 security features. If you are in Barcelona and have a passion for security, come to one of my sessions or find me on the exhibition hall floor, I would love to chat.

Posting is provided "AS IS" with no warranties, and confers no rights.

Windows Vista Security Stories @ TechEd - Recap

windowsvistasecurity — Fri, 18 Jul 2008 20:00:00 GMT

Good day! Paul Cooke, Director of Enterprise Security, here.

Orlando entertained close to 9,500 customers, partners, and staff at the first Microsoft Tech·Ed for IT Professionals. For four days, IT Professionals from around the world experienced in-depth technical learning with more than 770 Breakout Sessions, Hands-on Labs, and Instructor-led Labs; they also networked and shared information with Microsoft partners and industry peers. It was great to to discuss security topics with both old friends and new.

This year we tried something a little new for us: we went searching for Windows Vista Security Stories and wanted to get them on camera, so that our engineers could hear from you directly. We figured we would get some complaints and some kudos from the participants, but what we were really hoping for is an honest assessment of what you thought about Windows Vista Security! The participation from attendees was great and the candid feedback was exactly what we were looking for….

Well, it’s been just over a month and we have finally finished combing through the hours of video and selected our favorite stories! So without further ado, I would like to congratulate the following story tellers and let you know what you won:

Xbox 360

Zune

· Russ Alexander

· Stephen Dietz

· Joseph Eckhout

· Raymond Comvalius

· Glenn Milles

· Nathaniel Avery

· James Melton

· Cody Jones

· Andreas Hofmann

· Matthew Baker

We have the prizes on order and will be reaching out to you in the next week or so to confirm where you want your prize delivered!

We really want to thank all of you that participated. It was a lot of fun talking with all of you and we hope to see you again next year!

Windows Vista and Malware

windowsvistasecurity — Fri, 09 May 2008 23:41:00 GMT

Hi, Austin Wilson here. Recently there have been some questions raised about the susceptibility of Windows Vista to malware – specifically, that it’s more susceptible to malware than Windows 2000. I’d like to show why we reject that claim. We study the malware space very carefully and publish our results twice a year in the Security Intelligence Report. This report is compiled from statistics on malware infections based on over 450 million executions of the Malicious Software Removal Tool (MSRT) every month. Microsoft is a member of AMTSO (Anti Malware Testing Standards Organization) and its charter includes defining test methodology so that there is a minimum quality bar to all testing of this type.

Our results published in the April 2008 version of the Security Intelligence Report show that Windows Vista is significantly less susceptible to malware than older operating systems. In fact, from June – December 2007, using proportionate numbers, the MSRT found and cleaned malware from 60.5% fewer Windows Vista-based computers than from computers running Windows XP with Service Pack 2 installed. How about Windows 2000? Using proportionate numbers, MSRT found and cleaned malware from 44% fewer Windows Vista-based computers than Windows 2000 SP4 computers and 77% fewer than from computers running Windows 2000 SP3. Note that the Windows 2000 numbers include both Windows 2000 client AND server versions, while the Windows XP numbers of course are only clients. Servers tend to be less likely to get infected with malware as many of them are in data centers and aren’t used for general web surfing or other day to day tasks.

Does this mean that anti-malware software isn’t necessary? Absolutely not. No software is perfect. While we have many defense-in-depth improvements in Windows Vista, it’s critical for consumers to follow the Protect Your PC guidance of keeping the firewall turned on, keeping the operating system up to date, and having up to date anti-virus and anti-spyware software.

It’s worth mentioning just a few of the defense-in-depth improvements and features that are in Windows Vista that aren’t included in Windows 2000: DEP, ASLR, firewall on by default, Windows Defender, IE hardening, User Account Control, Windows Security Center, parental controls etc…

We’re always looking for ways to improve our studies, so please feel free to make suggestions on what you’d like to see. For feedback on the Security Intelligence Report, send email to sirfb@microsoft.com. Likewise, we welcome and encourage feedback from the community to make our products better, so comment on this blog entry if you have suggestions.

- Austin

Disk encryption: Balancing security, usability and risk assessment

windowsvistasecurity — Sat, 23 Feb 2008 00:12:00 GMT

Hi: Russ Humphries here. There’s been a lot of attention this week paid to memory attacks against disk encryption technologies and I wanted to provide some commentary and thoughts. The focus of these conversations is centering on investigating the contents of a computer’s memory – if it’s running or shortly after it has been recently powered down; where ‘recently’ could be seconds to perhaps minutes. The concept that memory retains a ‘ghost image’ of what was last stored on it has been well documented and is an industry-wide issue.

However, the current debate has an interesting angle to it - specifically a method has been detailed in which an application might be able to reconstruct an encryption key, which might have been used for almost any security purpose, from these ghost images.

Since disk encryption is a topic that gains headlines perhaps it was inevitable that the practical demonstration of this key-reconstruction would be to investigate a computer’s memory to ‘break disk encryption products’ and potentially access data stored on the hard drive.

The thing to keep in mind here is the old adage of balancing security, usability and risk. For example BitLocker provides several options that allow for a user (or more likely Administrator) to increase their security protections but at the cost of somewhat lowering ease-of-use. BitLocker supports options that will not allow a machine to boot – or resume from hibernate – until the user can:

· Enter a PIN

· Insert a USB stick that contains a secret Key

· … and as of Windows Vista SP1 both enter a PIN and insert the USB stick!

We provide best practice guidance in the Data Encryption Toolkit (http://www.microsoft.com/technet/security/guidance/clientsecurity/dataencryption/analysis/4e6ce820-fcac-495a-9f23-73d65d846638.mspx ) that describes the various manners in which the above choices can be made and also provides advice to help improve security, such as disabling ‘sleep mode’ – forcing a user to hibernate and thus allowing memory to lose the ghost images discussed. These power management settings can all be configured centrally using Group Policy Objects.

Now with the above context in mind, I’d like to take a step back and, from a BitLocker perspective, detail some of the assumptions that have to be made for this attack to be successful:

· Physical access to the machine

· The user’s laptop would likely have to be in sleep mode, rather than hibernate mode or powered off

· The user would have chosen not to implement multi-factor pre-boot authentication

· The person who finds/steals the laptop must be knowledgeable and interested enough to execute this attack on the laptop they just stole

I would posit that the opportunistic laptop thief is somewhat unlikely to carry a separate laptop on which they will have installed tools that allow them to reconstruct cryptographic keys – or for that matter have a can of compressed air handy.

Targeted theft is, of course, an entirely different threat model!

Let me also point out that BitLocker allows an administrator to, quite easily, change the protection method for a laptop, even remotely [but assuming some form of connectivity], by having a script execute. Thanks to BitLocker’s design, which implements key abstraction, a script can be executed that adds pre-boot protection mechanisms without requiring the re-encryption of the hard disk. This script can therefore execute very quickly.

Let me close by clearly stating that quality security research helps our customers and the industry in general raise the security bar, and I applaud it; but let’s also keep in mind that technologies like BitLocker provide a very valuable service to users and helps them protect data on their PCs. BitLocker’s range of deployment options, ranging from single-factor authentication with sleep mode to TPM+PIN+USB with hibernation only, allow customers to find the right balance of security and convenience for their data; the documentation of one attack method, that can be mitigated through these policy choices, does not equate to a class of data protection products being rendered ‘useless’ as has been reported in some circles.

-Russ

Windows Vista Security One Year Later

windowsvistasecurity — Wed, 23 Jan 2008 17:53:00 GMT

Hi, Austin Wilson here. Now that Windows Vista has been available to business customers for more than a year, it’s a good time to go back and look at how it’s holding up from a security perspective. I think that it’s fair to say that Windows Vista is proving to be the most secure version of the Windows to date. Our investments in the SDL and our defense in depth approach to building Windows Vista seem to be paying off. Let’s take a look at some areas that we’ve made progress in: the impact of defense-in-depth; Internet Explorer 7’s protection of personal information; vulnerabilities and infections; and cost savings.

First, let’s look at the impact of defense-in-depth features like User Account Control and Internet Explorer Protected Mode. These features have helped reduce both the risk and severity of security bulletins, giving enterprises more time to deploy patches:

• Running as standard user, which is the recommended configuration and made easier in Windows Vista thanks to User Account Control, helps reduce the impact of any particular vulnerability. Of the 23 security bulletins that have been released for Windows Vista through January 2008, 12 specifically call out a lower impact for those running without administrative privileges: MS07-033, 034, 040, 042, 045, 047, 048, 050, 057, 064, 068, and 069. This is a great illustration of the importance of User Account Control and why we included it in the product. It’s also the reason I personally run as a standard user on every machine I use.

• Because of IE Protected Mode, the MS07-056 bulletin from October ’07 was rated important on Windows Vista and critical on Windows XP. The bulletin rating helps organizations determine the urgency with which they need to deploy the update. Fewer critical updates help organizations maintain regular processes around patch management.

Internet Explorer 7, which is the default browser in Windows Vista, also helps protect the personal information of end users. We’re seeing almost 1 million phishing attempts blocked per week, representing a large number of potential cases of identity theft or credit card fraud that were stopped. In addition, there are over 3500 sites with Extended Validation SSL Certificates (EV SSL) representing an improved level of authentication for securing transactions on these sites. Internet Explorer 7 is the first browser to fully support EV SSL. It turns the address bar green for EV SSL sites and notifies users about the available identity information so they can make better trust decisions when entering sensitive personal information while online.

Next, let’s look at patch events, vulnerabilities and infections. We’re showing steady positive progress in this area. When looking at Windows Vista compared to Windows XP, we’ve seen:

• An important metric for IT professionals is the concept of patch events, which is discussed in the One Year Vulnerability Report released today by Microsoft’s Jeff Jones. During Windows XP’s first year, updates were released on 26 separate days. Through a combination of the move to a predictable monthly release schedule, and decreased vulnerabilities, Windows Vista had updates released on just nine days in its first year. To the average security professional, this is one of the most relevant metrics: how many times did I have to activate my internal patch management process due to vendor update releases over the course of a year? Nine times is much more attractive, and cost effective, than 26 times. Jeff Jones’ one year report goes into this in area in more detail, and the graph below from his report shows the patch events during the first year of Windows Vista and Windows XP:

• Fewer vulnerabilities: Also from the One Year Vulnerability Report, we see that Windows Vista in its first year had significantly fewer fixed and unfixed vulnerabilities than Windows XP in its first year: 36 fixed/30 unfixed for Windows Vista vs. 68 fixed/54 unfixed for Windows XP. The chart below gives you an idea of the progress we’ve made:

• Fewer months with updates: Building on the concept of patch events, since Windows Vista was released, there were three months in which Windows XP had updates and Windows Vista did not (December ’06, January ’07, and November ’07). This means that an organization running all Windows Vista clients would have had three months in which they wouldn’t have had to deploy an OS update to their clients at all.

Fewer infections: From January – June 2007, there were 60% fewer malware infections and 2.8 times less potentially unwanted software on Windows Vista than on Windows XP SP2, according to the Microsoft Security Intelligence Report from 10/07. This illustrates how the defense in depth features built in to Windows Vista help prevent machines from getting infected by malicious and potentially unwanted software.

Finally, what does Windows Vista do to help organizations reduce costs? A recent Microsoft commissioned report from GCR on cost savings for mobile PCs shows $251/machine per year in cost savings for Windows Vista, of which $55/machine per year was attributed to security and data protection features such as User Account Control and BitLocker Drive Encryption.

We’ve said it before, but it bears repeating: our job with security is never finished. But, the focus we put on engineering for security, the backing of the world-class security response process delivered by the Microsoft Security Response Center, and the defense in depth approach of Windows Vista are showing real-world benefits for customers and that’ something I take pride in.

- Austin

Extended Validation SSL Update

windowsvistasecurity — Wed, 19 Dec 2007 01:51:00 GMT

I am Craig Spiezle, Director of Online Security and Safety for Microsoft Internet Explorer. While I am new to this role, I’ve been at Microsoft for over 10 years, and very involved on usability and online safety, helping users realize their potential, while being confident that their data and privacy are maintained. In response to mounting online threats, Microsoft recently launched a $250,000 Sweepstakes communication to show users how Internet Explorer and innovative technologies can enhance online trust and confidence. Leveraging the stop light metaphor of red for stop and green for go, the interactive site demonstrates this to users, while providing them chances to win one of 25, $10,000 shopping sprees with PayPal. Visit the site today, download Internet Explorer 7 and enter to win. www.microsoft.com/ie/confidence Hurry entries must be received by January 31, 2008.

Internet Explorer integrates dynamic Phishing protection and support of the emerging Extended Validation SSL Certificate program, as just two of several investments to help of protect users, their data, their PC and their privacy.

The Microsoft Phishing Filter provides dynamic protection from known phishing sites and blocking nearly 1 million exploits each and every week. This is an opt-in service that operates in the background and provides an early warning system to notify users of both suspicious websites that could be engaging in identity and data theft, as well as those confirmed to be phishing sites. By design, user privacy has been at the forefront of this service and verified by third party audits that no personal information is collected by Microsoft or any third party.[1] http://www.jeffersonwells.com/client_audit_reports/Microsoft_PF_IE7_IEToolbarFeature_Privacy_Audit_20060728.pdf It relies on browser-based heuristics to analyze Web pages in real time and warn users about suspicious characteristics as they browse. This client-side technology is combined with dynamically updated information that helps prevent users from interacting with confirmed phishing sites reported to Microsoft by a network of third-party data-provider partners and a community of users who help provide information on potential and confirmed phishing sites.

However, phishers have also been able to obtain ‘valid’ SSL certificates for their spoofed sites. Looking for that gold padlock icon is important, but without the identity information users can end up sending their personal information to the wrong website. Historically one way users used to help answer that question was the SSL padlock (the gold lock), which was the only indication of any security whatsoever. While helpful, SSL only means that I have an encrypted connection to someone. So someone with malicious intent could set up a site that closely copied the look and URL of a legitimate business, get a SSL cert, and try to fool users into giving them sensitive personal information via a phishing or social engineering attack.

Responding to these threats, the CA/ Browser Forum has developed the new Extended Validation SSL Certificates or EV SSL. EV SSL leverages proven SSL technology, and adds a new process for vetting the identity of the business that is requesting the certificate, offering an improved level of authentication for securing transactions on their Web sites. Given the standardization and rigorousness of the process used, users can realize a higher level of online trust and confidence.

Internet Explorer 7 is the first browser to fully support EV SSL, and here’s what that looks like (in this instance when visiting http://login.live.com). You will notice that the address bar turns green, to notify users about the available identity information, and the name and country of the business are shown right there on the address bar (here “Microsoft Corporation [US]”). If a user wants to see more information about the company behind a website, he can simply click on the name of the company – the identification popup immediately shows the name and address of said company.

This is great news for Internet users: they now have an easy and reliable way to verify that they are on the correct site, and they don’t have to worry as much about phishing attacks or deceptive website, as long as EV SSL is used. Furthermore, when they are transacting with a new website that uses EV SSL (say one they found through shopping.msn.com), they can easily identify the company behind the website, which helps them legally pursue their claim if the site doesn’t deliver as promised, helping add an element of accountability to the web. Remember that most sites will use a secure connection (https://, that will show you the green bar if they are using EV SSL), only when you are about to exchange with the sensitive information, such as when you login, or are about to check out your cart. If you wonder about the different colors of the address bar and how to use them in making trust decision, you will find this description of the Internet Explorer 7 Security Status Bar helpful.

Today there are nearly 3,500 sites are now protecting their customers with EV SSLs, including Alaska Airlines, AutoZone, British Airways, eBay, FedEx, PayPal, Microsoft, Royal Doulton, The Body Shop UK, and Travelocity. In addition leading financial services have been quickly adopting worldwide including the Banque National du Canada, Charles Schwab, Deutsche Bank, SunLife, Sovereign Bank, UBS, and Vanguard. While the Microsoft Phishing Filter and EV SSLs alone will not solve all of the internet’s ills, combined they are important step to protect brands and consumers alike.

Craig Spiezle

Director Safety & Security

Windows Internet Explorer Product Management

[1] Third Party audit preformed by Jefferson Wells. More information is available at www.microsoft.com/safety/antiphishing

(Driver Signing <> Kernel Patch Protection) AND (KPP <> Driver Signing)

windowsvistasecurity — Thu, 16 Aug 2007 03:04:00 GMT

So I am reading a lot of stories that seem to have confused, or incorrectly aligned, Windows Vista driver signing and Kernel Patch Protection technologies. Whilst driver signing and KPP are complimentary, they are not conjoined.

Driver signing provides a method to better identify the author/creator of a piece of software or code so that the author/creator can be approached in the event a reliability issue, vulnerability, or malware is discovered. Signing is not designed to confirm the “intent” of signed code (i.e. good or bad), or whether exploitable bugs or malicious code is present. Malicious or exploitable kernel drivers can lead to system compromise beyond disabling of code signing controls, since kernel driver code has access to hardware as well as all programs running as the user.

Kernel Patch Protection (KPP) helps protect code and critical structures in the Windows kernel from modification. Microsoft updates KPP periodically, based on internal and external research. You can read more about KPP here:

http://blogs.msdn.com/windowsvistasecurity/archive/2006/08/11/695993.aspx

http://www.microsoft.com/whdc/driver/kernel/64bitpatching.mspx

Perhaps the mix up is due to a confluence of events, or – put another way – the fact that we released an update to KPP at the same time that news about an ATI Driver issue appeared. The update to KPP has no relationship to the ATI driver issue or recent topics related to code signing.

These are unrelated events!

1: Microsoft issued a non-security update for Kernel Patch Protection (KPP), and an accompanying security advisory: Microsoft Security Advisory (932596)

2: Microsoft was made aware of an issue reported in an ATI driver that is potentially vulnerable. Microsoft was in contact with ATI to help address this issue and ATI have posted a fix in the v7.8 Catalyst Package that can be found here:

http://ati.amd.com/support/drivers/vista64/common-vista64.html,

http://ati.amd.com/support/drivers/vista32/common-vista32.html

I would like to highlight that the driver in question was not shipped ‘in-box’.

Russ Humphries

FAQ: Why can’t I bypass the UAC prompt?

User Account Control Team — Fri, 10 Aug 2007 06:44:00 GMT

[This item was authored by Aaron Margosis and originally appeared on his Non-Admin Blog.]

The frequently asked question, "Why can't I bypass the UAC prompt?" is often accompanied by statements like one or more of the following:

"We want our application to run elevated automatically without prompting the user."
"I don't get why I can't authorize an application ONCE and be done with it."
"Unix has setuid root which lets you run privileged programs securely."

The designers of Windows Vista's User Account Control expressly decided not to incorporate functionality like setuid/suid or sudo found in Unix and Unix-like OSes such as Mac OS X. I think they made the right decision.

As I'm sure everyone knows, large parts of the Windows ecosystem have a long legacy of assuming that the end user has administrative permissions, and consequently a lot of programs work correctly only when run that way. (I'm not going to delve into that history here, nor will I entertain any finger-pointing on the topic at this time. One of these days I'll post my thoughts on that subject.) As computer security has become increasingly important, breaking that cycle became absolutely imperative. It is with the release of Windows Vista that the first major move in that direction is achieved. Indeed, the primary purpose of the technologies that comprise UAC is to enable "standard user" to be the default for Windows, encouraging software developers to create applications that do not require admin. The move to standard user is a new paradigm and creates the need for software developers to write applications that do not require admin privileges. Creating a shift in the ecosystem will take a long time due to the large deployed base of legacy applications, and UAC is a good first step.

Pre-approving code to run with elevated permissions without going through an elevation prompt, as described in the bulleted scenarios above, seems at first glance to be both useful and convenient. However, the negatives far outweigh those benefits. In particular:

The "standard user by default" vision would become impossible and ultimately never happen;
Elevation of privilege (EoP) would be trivial – any compromise could lead to full system compromise.

If it were possible to mark an application to run with silently-elevated privileges, what would become of all those apps out there with LUA bugs? Answer: they'd all be marked to silently elevate. How would future software for Windows be written? Answer: To silently elevate. Nobody would actually fix their apps, and end-user applications will continue to require and run with full administrative permissions unnecessarily.

What if the application could not mark itself for silent elevation but instead had to be marked by the consumer or enterprise administrator installing the application? Answer: the developer of the installation program (which necessarily runs with admin/system permissions in order to install machine-wide) would figure out where the setting lived, and set it. (Several major ISVs told us directly that they would in fact do exactly that.) There would be no real way to protect that setting from anything running as admin. This would be especially true if it were settable via Group Policy (which would be expected, if not demanded).

"Well, so what? We're only talking about applications I approved!" OK, let's say that's true, but how do you ensure that a malicious user cannot use the application for purposes other than those for which it was intended? And at least as important – how do you ensure that malware that has infected the user's session cannot drive a setuid application programmatically to take over the system? Ensuring strict behavioral boundaries for complex software running with elevated privileges is (at best) incredibly difficult. And ensuring that it is free of exploitable design and implementation bugs is far beyond the capabilities of software engineering today. The complexity and risk compounds when you consider how many apps have extensibility points that load code that you or your IT admin may not be aware of, or that can load code or consume data from user-writable areas with minimal if any validation.

Privilege escalation due to setuid and sudo has plagued Unix-like systems for many years, and continues to do so. In fact, several of the bugs in the recent Month of Apple Bugs fell into this category. Follow these links for lots more references: (*)

In the past, elevation of privilege has tended not to be noticed in Windows – there is no real "elevation" if you're already running as admin. (**) With the Vista shift toward "standard user", EoP threats become much more important, and it is vital that Windows do as much as practical to mitigate them. That is also why Windows services are no longer able to interact with the user desktop. Taking on the setuid headaches that *nix has had to live with does not seem like a profitable deal.

We expect that in ordinary day-to-day usage, users should rarely, if ever, see elevation prompts, since most should rarely, if ever, have to perform administrative tasks – and never in a well-managed enterprise. Elevation prompts are to be expected when setting up a new system or installing new software. Beyond that, they should be infrequent enough that they catch your attention when they occur, and not simply trigger a reflexive approval response. This will increasingly be the case as more software conforms to least-privilege norms, and as improvements in the Windows user experience reduces prompting further.

Having said all that, there is a Local Security Policy option to change the behavior of the elevation prompt for Administrators to "elevate without prompting". With this option selected, anything that requests elevation gets elevated without prompting the user. (The default setting is "prompt for consent"; the third option is "prompt for credentials". Note that "elevate without prompting" is available only for members of the Administrators group. The options for standard users are "prompt for credentials" and "automatically deny elevation requests".) While "elevate without prompting" may be useful in well-constrained, secure environments for automated testing and possibly for initial system setup, having this option selected otherwise is very risky and strongly discouraged. (Note also that Vista's Home SKUs do not include the policy editor.)

Nitpicker's corner (***)

(*) Pointing out the obvious: local privilege escalation by definition means that the bad actor is already on your system. However, there's a huge difference between malware running as you (non-admin) and malware running with root privileges. If there weren't, there would be no point (from a security point of view) in running with least privilege.

(**) "Elevation of privilege" in this context means "unauthorized elevation of privilege". Technically, yes, Administrator is not as powerful as System (in that there are operations that Administrator will get Access Denied where System will succeed), and System is not as powerful as kernel-mode code (in that there are operations that fail for user-mode code running as System that succeed when called from kernel code). However, two of the things that Administrator is authorized to do include: 1) configuring arbitrary code to run as System, and running it; and 2) loading arbitrary code into the kernel, and running it. Hence, if code is running as admin, there is nothing it is not authorized to do.

(***) "Nitpicker's corner" might be a trademark of The Old New Thing.