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)

Agencies are supposed to demonstrate that they can:

• Transmit IPv6 traffic from the Internet and external peers, through the core (WAN), to the LAN.
• Transmit IPv6 traffic from the LAN, through the core (WAN), out to the Internet and external peers.
• Transmit IPv6 traffic from the LAN, through the core (WAN), to another LAN (or another node on the same LAN).

(Source: OMB IPv6 FAQs)

One year ago, the OMB reviewed the Enterprise Architecture Assessment Framework results and found that six of the twenty-four agencies were on track to achieve the June deadline. Two months ago, there was a good article by Carolyn Marsan Duffy about the status of compliance. Take a look at this article because it seemed like there was a lot of backpedaling going on about meeting the date – using phrases like “we don’t like the term mandate” and “more of a recommendation than a mandate.” At the time, only three agencies were in compliance.

Duffy just wrote an updated article, “Feds say they have aced IPv6 deadline”, and suddenly two months later, all lights seem green. As of June 24, ten of the twenty-four agencies sent emails to the OMB stating that “they have successfully transmitted IPv6 packets”. Fourteen still need to report in, but none have asked for an extension. And all of it was done through the regular tech refresh budget over the past three years. So if this is true, kudos to the feds!

Right around the time of the first not-so-rosy article, we ran a survey at FOSE, the big federal government IT show. We asked attendees if their agencies would be ready by the deadline:

• 33% said they would be ready
• 6% said they were already there
• 33% said they would NOT be ready
• About a quarter didn’t know

What was really interesting is that we asked this same question in 2007, and the audience was equally split (yes/no) on whether or not their agencies would meet the mandate – 1 in 5 (2007) instead of 1 in 3 (2008).

So what can explain these numbers? Surprisingly, out of the attendees we talked to, only 65% of them said that IPv6 is important to their operations, making it second to last on the list of IT priorities covered by the survey. Maybe the answer lies in the relative “unimportance” of the milestone – that just the network backbones (and the routers supporting them) be capable of passing IPv6 packets. The true test for government IT workers will be when actual IPv6 applications must be supported which will impact networks, systems, application and monitoring tools throughout the government.

So was this a nice checklist item for the Bush administration? This initial deadline is the only one for IPv6 mandates from the current OMB incarnation. Actually running IPv6 applications, that’s a whole ‘nother story, apparently for a new administration.

ShareThis

(Photo credit: The Tech Stop)

ScienceLogic: How long have you been involved with Interop?

Geoff Horne: Since about 1996.

ScienceLogic: How has it been changing? Does the show get more complex with new technologies or because of the constantly changing size of the show?

Geoff Horne: The technologies have changed. Every year there’s a different market environment. Since we build on customer needs, things change every year. Things like ScienceLogic for Network Monitoring, for how long have Network Management tools been completely web based? In general, it doesn’t really get any better or worse because every year we’re building it again. You don’t get the stability of a standard environment. The upside is that we’re always doing a full upgrade, a full technology refresh and not using old code.

ScienceLogic: Do those kinds of changes influence the types of vendors you look for for InteropNet?

Geoff Horne: The base categories don’t change. You always need to forward packets. You always need switches, you always need routers. We’ve tried to open it up to everyone that has products involved with networks to see if we have the time or space for it.

ScienceLogic: The kind of cooperation that you get between the vendors is what seems to be an unachievable nirvana for Enterprises. What’s the secret to getting 17 vendors to work together in such a short time? Enterprises would kill for that.

Geoff Horne: The honest answer is don’t trust the vendors. If they try and build something the way they want to, its not going to interoperate. You have to pull them out of their safety zone, make them do things that you think the product can/should do to ensure interoperability.

ScienceLogic: In a blog post prior to Interop Vegas 2008 you stated three major goals for InteropNet. They were Education, Monitoring and Statistics. How did you do against these goals?

Geoff Horne: I think we did pretty well. They’re 3 things we really didn’t have before. They’re things that just weren’t focused on the right way. For the first round of changing the focus, changing the way people look at the network (statistics rather than packets), it worked quite well, it gave people a much better idea as to what’s going on.

ScienceLogic: If we look at NY as take two for Interop 2008, are there things you are going to do differently based on lessons learned in Vegas?

Geoff Horne: We’re building more physical redundancy in the core network, geographic distribution of the infrastructure within the show. This will allow us to bring up chunks of the network independently. It isn’t something that we really thought of before. This helps us take the single point of failure (the NOC) out of the equation.

ScienceLogic: Are there any lessons learned from Interop that you think would help enterprises?

Geoff Horne: Visibility is key. Your network is significantly more functional when more people can see what’s going on. If the only guy that can see what’s going on is the guy with his fingers on the terminal, no one can make good decisions. You have to make people loosen up their control so that everyone can see and therefore make educated decisions.

ShareThis

Well, can we have IDS? How about IPS? Can we really "prevent intrusions?" Can we really "control access to our networks?"

The answer to "can we have DLP?" is actually pretty simple: if you think "DLP = box that prevents all data leaks" (and you also think that deploying IPS will "prevent intrusions"), then we can't. Forget it.

But blame the idiots who called it "leak prevention" - if you think that "DLP will prevent all leaks" - sorry, but you are one of them! :-) If you treat "L" not as "leak" but as "loss" and hope that "DLP will prevent all data loss, whether intentional or not," you are an even BIGGER one.

So rambling about "Can DLP Really Stop All Leaks" is pretty silly. No, it can't. Pondering "Is DLP Possible"  is just as silly. No, complete prevention of all leaks is impossible, with OR without DLP technology. Go read Mike R instead :-)

Why seemingly smart people behave in such childish manner? I dunno. Scratch all that. Instead ask:

Is today's cutting-edge DLP technologies USEFUL?

And the answer is "Hell yeah!"

If you see how much "fun" sensitive content goes over email (corp and personal web-based), gets uploaded to forums, channeled over IM file transfers, FTP'ed somewhere, you'd scream for one of these boxes. Accidental leaks, email address typos, non-malicious leaks, blatant disregard of security policy for the sake of "productivity", even phishing, "wholesale data theft" and amateur "employee hackers" probably account for 10x (100x?)  more damage (in direct losses, brand damage, embarrassment and - yes! - non-compliance fines AND loss frequency) than "uber-hackers" (who might indeed go thru your DLP box like hot knife thru butter.) And if an advanced DLP box does one day stop some determined insider theft, that's just icing on the cake.

That is why smart people don't call it "DLP" - they call it "content monitoring and filtering." This sounds much less sexy, but much more useful. The boxes that will show up on your doorstep will still have "DLP" labels, but what they will do for you is really content monitoring and filtering.  And even though it will not stop all data theft, DLP box will likely prove useful more than once...

Finally, all rants about any preventative AND monitoring technologies should really end the same: go refresh your incident response plans.

Possibly related posts:

• "In Passing on DLP"

The paper even had the following picture, which is presented here to illustrate the point:

(source: Forrester paper named above)

The paper clarifies: "With people and contexts defined, protective controls in place, and policies outlined, the
fourth set of questions [i.e. regarding the audit] includes: “What happened?”, “What is happening?” or, especially, “Is
it working?”

However, is this really so? Or, is this always so? First, when reality collided with plans,  many of the organizations that followed that wisdom got mired in one phase (e.g. in trying to get authentication under control) and ended up having no audit whatsoever: in other words, they are flying blind while implementing controls!  Second, in some cases controls (authentication, authorization, administration) will actually be impossible to implement, while audit will be possible. Imagine retrofitting a legacy application for granular authorization? Third, in some cases implementing prevention/control will be much more complicated, compared to implementing audit: thus, people will face a choice between a half-baked control to a full-blown audit capability? An example will be managing which file each user can access vs monitoring/auditing which file each user have accessed. The latter is doable, while the former is next to impossible. Another way to phrase it is "reactive but possible" vs "proactive but impossible" (hint: pick the former :-))

I think the idea of putting audit first in some cases is the way we'd need to progress. "Wow, what a blasphemy!", some might say ...  After all, if you have not defined controls, what are you going to audit? But remember that audit is meant broadly in this context and thus the opposite question is very relevant: what are you going to control if you have no idea what is going on? People sometimes define a security policy based on how things should be (and then WSJ happens :-) - refresh your memory of the "WSJ saga" here), but then spent years trying to bring policy and reality together (and end up with an environment which is "half-controlled") Won't it be better to audit first, then control?

Obviously, "do IDS before IPS" falls under the same principle: monitor first, [try to] control second. Here is another example: implement log management before identity management. Looking at logs will tell you what privileges the users actually use for doing their daily jobs. Then you can mix it up with what the idea access policy will be.

So, think about it! Questioning the common wisdom does often bring interesting insights.