Prevention eventually fails. What's your plan?

A recent study conducted by British Telecom claims that 94% of the companies they polled expected to suffer a compromise sometime in 2009.

I guess companies are finally acknowledging one of Information Security's most sacred truths:  Prevention eventually fails.  I first heard this truism while reading Richard Bejtlich's fantastic book The Tao of Network Security Monitoring.  In it, he claims that preventive controls are doomed to eventual failure due to 2 factors: Some intruders are smarter than the people securing the systems, and intruders are unpredictable.

These sobering facts recently prompted InfoSec pioneer Dan Greer to comment in an interview:

[...]the world we live in now is one where the rate of change is so great it is hard to develop a skilled craft because by the time you do, the problem set has moved on.

I think information security is quite possibly the most intellectually challenging profession on the planet. For that reason that what was true yesterday may not be tomorrow. In information security in particular, the rising fraction of R & D that is done by the opposition, and is funded by the opposition by its own revenue, is quite fascinating and makes things very difficult. At the same time, have we made progress? Sure. But the challenging aspect to this continues to be this rate of change and the degree to which you need to be on your toes all the time.

So, given that you will, eventually, suffer a breach, what's your plan?  You *do* have an incident response plan, don't you?  If you thought you had a 94% chance of getting into a car accident, you'd plan for that eventuality, wouldn't you?

If you don't have an Incident Response Plan, NIST's 800-61 publication, originally published in 2004 and refreshed last year, is a great place to start, and considered required reading by most InfoSec practitioners who have accepted the reality that prevention eventually fails.

Dirty URL Tricks

I've preached for years the need for users to scrutinize heavily any URLs in emails they receive, especially in emails from financial institutions.  As applications and operating systems get more and more secure, hackers are increasingly relying on tricking the end users into clicking on a hostile link or otherwise actively enable the compromise of their own system.

Traditionally, one of the mechanisms you can use to determine that an email is a phishing attempt is to scrutinize the link or button the email wants you to click.

For instance, you can hover your mouse over this http://www.Visa.com link, and determine pretty easily that it actually takes you to www.ClickHereToGetOwned.com.  Right?  Just say "Right!" for me.

But what if the link looks like this? tinyurl.com/ozn4lm.  Clicking that link will also take you to the Click-Here-To-Get-Owned site, but it passes our usual sniff test because the redirection to the malicious site happens on TinyURL's end.

For those unfamiliar with TinyURL (go ahead and click, it's OK), it's a free service that allows anyone to shrink an obnoxiously-long link to something shorter so that it survives emails and other communication mechanisms that do unkind things to links that exceed one line in length.  The explosion of Twitter, which has a hard cap on the number of characters you can send in a single message, has dramatically increased the use of URL shrinkers.

But it also enables a phisher to obfuscate the true destination of a given link in a way that is not mitigated by the guidance we've been giving people for years.  The popularity of TinyURL, in particular,  has become nearly ubiquitous, leading to complacency when a potentially hostile TinyURL link arrives in email or Twitter.

Thankfully, TinyURL does allow users to preview the location of a given URL to allow users to see where they will end up if they click it.  If you allow cookies, you can even set TinyURL to *always* bring up the preview of the URL before it takes you to the destination.  Good on them.

But there are other URL shrinking services that don't offer such protections.

Besides, what if your URL looks like this:

Don't laugh, it's a URL in the style of an Aztec barcode, and if you have a handheld device, like an iPhone, chances are you can consume it using your device's camera and send your device's browser to only-god-knows-where (in this case, the Wikipedia page for Aztec barcodes).  Airlines are using them increasingly to send check-in information to airline passengers' mobile phones.

Or how about this one:

This is a format currently being pushed by Microsoft, called HCCB, or Microsoft Tag.

As URLs continue the trend towards machine-readible, and away from human-readible, their potential for abuse by phishers and other malicious actors will only increase.  It's up to the users to scrutinze inbound communications they receive, including the context, and only click on URLs that they can realisticaly trust.