Someone on the IE security team forwarded me a document that had additional details. So here, for your enjoyment, is a chart listing the default settings for each security level. To answer the newsgroup poster, "medium" and "medium-high" aren't the same.

About the formatting: to get it to fit within the width of the blog's text section, I've made some abbreviations.

In a few cases, the table shows a number rather than D or E or P; below the table is a description of each such entry.

At the very bottom of this post I've included the settings from the privacy tab, too.

Note: these settings reflect those for Internet Explorer 7 on Vista SP1. Please see the MDSN link above for differences between IE 6 and IE 7.

.NET Framework

.NET Framework-reliant components

     1 = High safety

ActiveX controls and plug-ins

Downloads

Enable .NET Framework setup

Miscellaneous

     1 = Prohibit downloads from software update channels
     2 = Cache content downloaded from software update channels
     3 = Automatically install software updates

Scripting

User authentication

     1 = Prompt the user for name and password
     2 = Automatic logon only in intranet zone
     3 = Automatic logon with current user name and password

Privacy settings (on the "Privacy" tab)

Fourth US airline to go Wi-Fi: Aircell says they have a fourth airline--after American, Delta, and Virgin America--on board for its in-flight Wi-Fi service. The aerial broadband provider's latest partner will be announced soon. Aircell's service went live in 15 American Airlines planes two weeks ago, and there's been a surprising lack of reporting from regular travelers or journalists since the big splash at the launch.

Microsoft, two universities research methods for better Wi-Fi handoff for vehicles: The researchers developed a method they call Vi-Fi, writes the Seattle Post-Intelligencer's Todd Bishop, which allows a system to maintain connections with several base stations at once, using a primary access point for traffic until a discontinuity is predicted or encountered. This allows seamless handoffs and continuous voice conversations.

Speaking of autos and Wi-Fi, concerns raised about Chrysler's in-car Wi-Fi option: Randall Stross wrote nearly two weeks ago in The New York Times about the problem of distraction. With the Internet at your fingertips, can you restrain yourself? The only problem with the humorous and accurate analysis is that millions of business travelers have 3G access via laptop cards already, so you'd think we'd already be seeing the bad effects of automotive area networks.

A Wi-Fi booster can't post availability signs on highway: The Nebraska town of Louisville has free Wi-Fi downtown, and wanted to post "Visitor Wi-Fi" on a highway sign as another amenity. The state highway department has a policy that doesn't allow the promotion of Wi-Fi, because they believe they'd be inundated. A resident who runs a local Internet firm installed his own signs on the highway; the roads department removed them; he remounted them; they were removed again. The idea of zoning and mounting a billboard apparently hasn't come to the city officials' minds (or perhaps they're prohibited).

The folks spreading misinformation about Wi-Fi health effects cause Ulster school to disable network: I can understand why non-technical folks might think that Wi-Fi has been proven to be unsafe, given the kind of information that's available on the Internet about wireless safety. While there are ongoing studies about the safety of cellular signals--and I'm convinced at this point there's no increased risk to an adult's health by using a cell phone--there is no specific and credible research linked to Wi-Fi, which broadcasts signals at a far lower level than a cell phone, most of the time in most uses.

Washington state shuts down rest-area Wi-Fi: The $3 for 15 minutes, $7 per day, or $30 per month Wi-Fi service at 28 of Washington's 42 rest areas has been turned off after a year for lack of use. Figures. The fees charged by Parsons and Road Connect aren't unreasonable for a nationally scoped plan, but are ridiculous for limited use. States should either bite the bullet and offer these service for free, partner with national roaming operators who can resell service into large networks of business travelers, or use ads to support the service. Highways in remote areas can typically pick up cell data networks, and ongoing costs should be minimal to operate such networks.

IEEE approves fast-roaming standard, 802.11r: This new standard is designed to improve the handoff of devices between base stations. This is accomplished in part by allowing base stations to communicate security and quality of service information so that a VoIP over WLAN phone can immediately reassociate without the delay of authentication and other handshaking.

Denver airport sees 7,000 connections on a single day last week due to Democratic National Convention: FreeFi released the usage figures recently to show how their service is operating. The network started with about 600 daily users when the switchover from fee to free happened 10 months ago, and now carries about 3,500 daily connections.

Coffee Bean & Tea Leaf goes free: The chain of about 700 cafes will have free Wi-Fi installed by now in all its company-owned stores (about 300).

Changing Behavior

1. Educate yourself.
At least every 6 to 12 months, surfers should browse the educational information provided by their operating system and security vendors and subscribe to any security-related newsletters they might offer. According to David Perry, familiarity with the latest threats, dangers, and recommended safety tips will allow surfers to make safe choices. “Until you know what’s out there, you’re just flying blind. Without an education, you’re wide open”.
2. Avoid suspect sites.
While criminals can infect even mainstream Web sites, sites such as gambling sites, adult Internet sites, and illegal file-sharing sites are far more likely to carry malicious code. Web sites that offer “something for nothing” frequently recoup their losses by infecting visitors’ PCs.
3. Lose Your Comfort Zone.

Recommended Technology

4. Use an updated virus scanning suite.
The most important component of any threat mitigation system is a virus scanning suite. In addition to detecting and removing known viruses and malware, modern virus scanning suites provide additional protections against new attacks by disabling their known protocols. For example, Trend Micro™ Internet Security encrypts keyboard traffic, protecting personal data from keyboard logging programs that might go unnoticed. Users should update their scanner and virus definitions as frequently as possible to ensure the best possible coverage.
5. Upgrade your OS and browser.
In addition to offering more features, Microsoft’s Internet Explorer version 7 and the latest Mozilla Firefox are both substantially more secure than previous-generation browsers. Users of older browsers should upgrade immediately to take advantage of increased security. Similarly, Windows Vista and Mac OS X are more secure than their predecessors, and users of older operating systems should consider upgrading, as well.
6. Disable scripting and “widgets.”
Many Web-based attacks use various scripting languages to run infectious programs in a browser or use downloadable “widgets” to execute infections locally. By disabling scripting and avoiding downloadable widgets wherever possible, surfers disable these common attack vectors.
7. Rate your Web pages.
Some available services rate the risk of Web pages in search results, allowing surfers to avoid unwanted content and hidden threats before viewing the pages. Rating applications (e.g., Trend Micro TrendProtect™) consume few system resources and run unobtrusively, so they are suitable for any Web-enabled personal computer.
8. Ask your provider.
Commerce companies, banks, and credit card associations are all interested in computer security, and many offer additional features. For example, Visa’s Verified By Visa program requires cardholders to enter a second password to identify themselves during a transaction, while businesses in Poland require cell-phone confirmation of credit card purchases. While nothing will be 100 percent effective, any additional security measure provided by a trusted source will increase protection, and surfers should adopt as many as possible.

This article provided for your reading pleasure by Trend Micro.

Your first real lesson about locking down a host was how to reduce its attack surface. You learned how to disable services using /etc/inetd.conf. Then you learned about rc.d and how to prevent unnecessary services from being launched at startup. Next, maybe you configured the Xserver to disallow remote connections or moved on to removing setuid permissions from files. As you worked, you’d periodically re-scan the box to gauge progress, asking yourself “have I removed everything I don’t need?” The underlying motivation, of course, is that an attacker can’t hack something that isn’t there.

You learned how to extend those concepts to the network — configuring firewall rules, router ACLs, VLANs, etc. Segmenting the network. Creating a DMZ. No need to dwell on this, you get the idea.

Eventually, people realized that applications had an attack surface too. Web servers and application servers got a lot of attention, followed closely by custom web applications. “What do you mean you can execute SQL queries against my database? That’s impossible, I have a firewall!”

Some companies, the ones who could afford it anyway, started to build security into their development cycle. Doing threat modeling during the design phase made sense, because hey, it’s much cheaper to fix security holes in a whiteboard drawing than it is to rewrite your authorization module from scratch after it’s in production.

Let’s talk strictly about custom web applications now. What I’ve observed is that most development groups, even the ones who actively engage in threat modeling, do not understand their web application’s attack surface. The lead architect can whiteboard a high-level diagram of all the major components and how they interact. Individual developers can go a bit deeper, telling you which files they touch, what database permissions they need, or how various pieces of data are encrypted in storage. At the end of this exercise you have a complete picture of the processes, data flows, protocols, privilege boundaries, external entities, and so on, and you’re well on your way to understanding all of the potential attack vectors.

Or are you?

What often gets overlooked or glossed over is the impact of external libraries or packages. Nobody writes everything from scratch. A typical list of third-party libraries for a Java-based Web 2.0 application might include DWR, GWT, Axis, and Dojo, plus about 30 other libraries to do everything from logging to parsing to image manipulation. Nine out of ten times, the libraries will be installed in full, using the default configuration from page one of the README file.

Why is this relevant? Because just as those old Unix boxes exposed unnecessary services, libraries expose unnecessary code. Let’s say you installed Dojo to simplify the process of creating an HTML table with rows and columns that can be sorted on demand. Did you remember to remove all the .js files you didn’t need? Or maybe you installed Axis or DWR or anything else that has its own Servlet(s) for processing requests. Have you compared what that Servlet can do against what you need it to do?

A fictitious example may help illustrate further. Imagine you just downloaded a new library called WhizBang. You follow the installation instructions to define and map two servlets in your web.xml file, WhizServlet and BangServlet, and you configure it to integrate with your web app. After a bit of trial and error, it’s functional. Yay! This is where most developers stop.

Nobody asks, “how much of this do I actually need?” Case in point, what if your application only uses WhizServlet? BangServlet is still exposed, and you don’t even use it! Similarly, what if WhizServlet takes an “action” parameter which can be either “view”, “edit”, or “delete”, and your application only uses “view”? You’re still exposing the other actions to anybody who knows the URL syntax (pretty trivial if it’s open source). You wouldn’t expose large chunks of your own code that you weren’t using, so why should it be any different with libraries?

This post is getting kind of long so I’m going to split it up. In the next post, I’ll continue the discussion of attack surface minimization, as well as some of the tradeoffs that go along with this approach.