Trend Micro's Hybrid Hosted Service (RSA)

Trend Micro takes an unusual approach with its hosted ("managed"; "in-the-cloud") email security service. Rather than trying to do everything, it sticks to what a service is good at.

Trend is applying the Pareto principle (a.k.a. "80/20 rule"). The company promotes a "hybrid" approach, with the hosted service implementing only a first level of spam filtering based on reputation -- filtering roughly 80% of the inbound spam. The remaining email is passed on to spam filtering appliances on the customers' premises, to deal with the other 20%.

The on-premise appliance can therefore more easily be customized to conform to local policy. When it comes to filtering spam using content, it's best to have an understanding of the types of legitimate content that the organization sends and receives -- the obvious example is medical organizations, who may well expect to receive email about a certain blue pill who's name begins with 'V'.

Of course, organization-specific customization ''can'' be done in the cloud -- there's nothing intrinsic about it that forces it to be on-premise, but this split in responsibilities seems like it has merit.

Phishing via Instant Messaging

I just got an IM from a buddy. He told me to go to www(dot)geocities(dot)com(slash)picc_81(slash)index.htm

This appeared to be a Yahoo 360 login page. "Odd," I thought, "Why do I need to login to see a Geocities page? And anyway, aren't I already logged into Yahoo?"

Let's view the source. Oh. It sends the login credentials to a script on www2.fiberbit.net -- looks like it emails them to ggeocitiees@gmail.com

Nice job, phish boy.

I've reported it to PIRT, the Gmail guys, and the Google Safe Browsing folks.

Now to contact my buddy and give him the bad news.

Google Acquires Postini

Google announced that it has agreed to purchase Postini for $625 million in cash. Why?

Postini is best known for its managed ("hosted", "on-demand") spam filtering service, but that's not what attracted Google. Gmail and its Google Apps. cousin already have sound spam filtering technology -- they don't need help from Postini.

What Google needed was a way to round out its Google Apps. story with solutions for its customers' policy, compliance, and archiving/e-discovery needs. Google was already partnering with Postini to provide this for Google Apps. customers. Presumably the experience was a positive one and Google simply wanted to own the technology and people.

Google's statements hint that the lack of Google-owned technology in these areas has been a sales inhibitor:

Many businesses have been forced to choose between innovation on one hand, and these backoffice mandates on the other. In effect, many businesses use legacy systems not because they are the best for their users, but because they are able to support complex business rules. We agreed to acquire Postini in order to create a more complete Google Apps solution that addresses the information security and compliance issues facing businesses of all sizes.

The DHS is a Wonderful Organization

So I hear the U.S. Department of Homeland security has been having one or two problems with its computer security:

A subcommittee of the Committee on Homeland Security ... expressed "shock and disappointment" that the DHS had reported as many as 844 security incidents in fiscal years 2005 and 2006. The incidents occurred on IT networks at DHS headquarters, and those belonging to Immigration and Customs Enforcement, Customs and Border Protection (CBP) and the Federal Emergency Management Agency.

The security issues ... included one in which a password dumping utility was found on two DHS servers. In addition, Trojans and other malicious programs were found on numerous agency servers, and classified mail was found to have been sent out over insecure networks.

Trojans? Unencrypted sensitive email? Oh, big fat hairy deal. C'mon, this is nothing that you couldn't find in most organizations of that size. It's hardly DHS's fault.

Give them a break. In fact, give them all a big pay rise -- especially those nice officers who work the immigration and customs desks at America's fine airports (and the ones who sit in Canada, too). I do like them a lot, and look forward to my time chatting with them every time I visit the U.S.

They are all, without exception, wonderful people, and anyone who says otherwise is probably some sort of terrorist.

Zulfikar Ramzan is Correct About Phishing

Zully is right on in his demolition of Mikko Hypponen's idea for a ".bank" TLD.

Writing on Symantec's Security Response weblog, he basically urinates all over Mikko's plan (although he's a lot more diplomatic than that). Some choice cuts:

Phishers don’t have to use the .bank extension and most users will fail to notice ... if you look at almost every phishing site these days, the URL itself is a blatant giveaway that you’re not at an authentic site
...
The proposal will also lull users into a false sense of security for a number of reasons ... The bad guys may still be able to get .bank domains ... won’t stop phishing attacks that exploit cross-site scripting vulnerabilities ... Browsers are sometimes susceptible to address-bar overlay vulnerabilities. [read more]

Or, to put it another way, the problem with this proposal is that roughly half the population have below-average intelligence (hat tip: APHC).

Sure, it's easy to be a critic, but such ideas just waste energy that could be ploughed into useful furrows, such as DKIM and domain-level reputation.

See also: BofA Sitekey, Yahoo! Signin Seal, etc., etc.

Locally-Maintained Reputation

In response to yesterday's blog post, Cisco DE Jim Fenton* wrote:

reputation can be locally-maintained. Local reputation is not as powerful as shared reputation services, but does provide benefit in the short term.

Yes, that's right. Local domain reputation is often expressed in terms of whitelists and blacklists. Without sender authentication, these are notoriously unreliable.

It nicely illustrates one of the benefits of authentication.

For example, users of anti-spam filters sometimes find their colleagues' email in the quarantine, so they add a wildcard whitelist entry for their domain. They soon discover that a significant chunk of spam will have their domain forged into the sender address. Without sender authentication, there's not a lot can be done about this.

However, with sender authentication, you can have a whitelisted domain entry that only allows the message a free pass if the authentication passes -- otherwise the normal spam filtering rules apply.

You could even impose a local policy that says if a message "from" our domain fails authentication, we'll reject it as spam, but this is probably too risky, at least in the early stages of deployment.

* - well, they claimed to be "Jim Fenton" and I assume it's that Jim, but perhaps it was a dog

CNET's Error Explaining DKIM

Declan McCullagh, writing in CNET, makes the standard schoolboy error of assuming that email sender authentication technologies are "antispam techniques."

They're not.

DomainKeys Identified Mail (DKIM) and other sender authentication technologies are simply ways to detect forgeries. At best, they give a partial indication whether a message is spam or not, but their main use is to allow recipients to look up the reputation of the sending domain.

Detecting phishing attacks via sender authentication depends on legitimate senders, such as PayPal, publishing information in the DNS. An email that purports to come from paypal.com can then be verified against that published information.

Of course, this doesn’t stop phishers from using similar domains, such as verify-paypal.com. Many users won't notice the difference. A DKIM test will "pass" because the bad actors own the fraudulent domain.

In other words, DKIM alone is almost useless. That's why we also need domain-level reputation services.

For several years, spam and virus control has been assisted by the use of DNS blacklists (DNSBLs). These list rogue IP addresses and address ranges that have been observed sending spam, viruses, or other undesirable content. The lists are interrogated in real time, usually via a DNS query. Several spam control vendors use a form of DNSBL, known as a reputation service. These provide a professionally run service that rates the reputations of IP addresses—good, bad, or unknown.

So today, we have IP address based reputation services, but not the ability to track and report the reputation of a sending domain. In the future, reputation services will be able to track the reputation of sending domains, as well as of IP addresses. This is not possible today, as the purported sender of a message is too easy to forge.

Email sender authentication techniques such as DKIM thus provide the missing piece of the puzzle, by allowing services to track the reputation of a domain. So, as the use of sender authentication becomes more widespread, reputation services will become more useful.

And with sender authentication becoming more popular, trusted authorities need a standard mechanism to vouch for a domain name. For example, a receiving mail system may be able to use SPF/SIDF or DKIM to verify that an incoming message was sent by example.com, but it currently has no standard way of deciding if it wants to receive email from that company.

The Domain Assurance Council (DAC) plans to solve that problem by publishing reputation or accreditation data about a domain name in a standard form. This standard, called Vouch By Reference (VBR), will create a market for organizations that vouch for domains, allowing its members to compete with minimum friction.

By the way, according to his Politech bio, Declan McCullagh is CNET's chief political correspondent, as well as being a rather good photojournalist.