I'm back from BlackHat 2008 and had a great time. This year, most of the press coverage was on Dan Kaminsky's DNS vulnerability. Dan is smart, clever, and will always go out of his way to recognize other people's good work - gotta love it.

This weakness in DNS has been seen by some as over exaggerated and by other as one of the deadliest the Internet has seen in years. No matter where you stand on the issue, the problem is what this weakness makes feasible and not the weakness itself.

Although the discussion is about DNS, your countermeasures should focus on man-in-the-middle (MiTM) attack scenarios - this is where the game is played. This weakness when exploited makes many MiTM attacks extremely feasible and difficult to detect by the victim at the time of the incident. If the attacker is able to get in the middle of the applications you are using directly (your web browsing, file transfers, etc) or ones that you use indirectly (auto-updating of software packages, automated agents including email MUA/MTA), you better hope there is proper cryptographic methods to protect the data and validate the other-end of the connection. Not only are most applications in bad shape but studies have shown that if you warn a user about this type compromise during their session, they will likely just click-through the warnings because remember, they are busy and need to get their work done. More about this behavior later.

Now before you start blaming the big bad Internet for being so insecure, when did someone say it was ok to start trusting services like DNS anyway? Some of the very first requirements for the Internet was that "the host shall never trust the network, and the network shall never trust the host". The sooner we all stop trusting insecure protocols, the better. I'm not saying stop using them, I'm saying use them but know their limits and be accountable for the risks within your design.

Why do people take shortcuts in their designs, cheat when they don't think they will get caught, and generally pick the "easy" route? Because we are creatures that favor convenience and the Internet and its protocols are dangerously convenient. We like all other living organisms fundamentally are wired to conserve energy. We will always try to find the most efficient path to our goals and in turn do so at some risk. We are quick to understand the benefits of an action but not always quick to evaluate at what future cost.

The Internet and its protocols are dangerously convenient. Can we not design systems that are both convenient and secure? The correct but not so useful answer here is "It Depends". My point in all of this was that these social biases point toward a much more fundamental security issue than any line of code. We must never forget that we are not designing system for arbitrary faults, we must design knowing there is an active opponent out there trying to get at something of ours that has a high utility to them and when they have taken it from us, we still have it.

In Nassim Nicholas Taleb's book "The Black Swan", he explains a type of ingratitude that I think the security professional knows all too well. It goes something like this: Who gets rewarded by society, the person who nearly kills himself trying to avoid a huge problem or the person who corrects a bad situation after it is already in progress? History will show time and time again that it is the latter. He says "Everyone knows that you need more prevention than treatment, but few reward acts of prevention."

The other day, someone asked me "If this DNS Vulnerability was such a big deal, then why did we not see horrible things happen on the Internet?" We as humans find it difficult to value that which we don't know or have not directly experienced. There were many people working their tails off once they were notified of this DNS bug so that the highest level of preventative steps could be taken. I salute those who listened to what Dan had to say and took action.

The administrator that worked over the weekend to remediate an unruly set vulnerabilities will not be rewarded on Monday the same way that he would if problems happened over the weekend and he fixed it before doors opened on Monday. We prioritize our preventative measures on likelihood and impact and that is an entirely different topic for another blog entry.

The same pattern can be seen at the personal level where until you have a bout with death, preventative tasks just don't get the priority they deserve. IMHO, it comes down to an individual being able to experience the bad situation that is to be avoided so that when asked to spend time, energy, or money on the preventative action, the avoidance is self-evident.

If you follow me so far, you would come to a sociological theory of information security that says that in order for your community to understand the value of preventative measures, they must have had to experience that which is trying to be prevented on a personal level. Don't take this like I am trying to make everyone into a communicator of fear, not at all. All I am trying to do is to present the biases that we have as a society so that we can leverage them when it is appropriate to do so and we can avoid them when they get in the way of good decision making.