By Rich
Like many of you, for a long time I really couldn't see the use of those URL shortener service thingies. Sure, when I was designing sites I tried to avoid long, ugly URLs, but I never saw slapping some random characters after a common base URL as being any more useful. I considered my awareness of the existence of these obscure services as an aberration induced by my geek genes, rather than validation of their existence or popularity.
Then came Twitter, and the world of URLs was never the same.
Twitter firmly swapped URL shorteners out of the occasionally useful into the pretty darn essential column. That magical 140 character limit, combined with the propensity of major sites to use URLs nearly as long as their software user agreements, thrust shorteners in front of millions of new eyeballs.
One issue, pointed out by more than a few security pundits and rickrolling victims, is that these shorteners completely obscure the underlying URL. It's trivial for a malicious attacker to hide a link and redirect a user to any sort of malicious site. It didn't take long for phishers and drive-by malware attacks to take advantage of the growing popularity of these obfuscation services.
Some of the more popular Twitter clients, like Tweetie, added optional URL previews to show users the full link before clicking through to the site. In part, this was enabled by shorteners like bit.ly enabling previews through their APIs. A nice feature, but it's not one that most users enable, and it isn't available in most web interfaces or even all standalone Twitter clients.
Bit.ly announced today that they are taking things one major step further and will soon be scanning all links, in real time, using multiple security services. Bit.ly will be using a collection of databases and scanning services to check both new and existing links as users access them. Websense's cloud-based scanner is one of the services (the one that pre-briefed me), and bit.ly will use at least one other commercial service as well as some free/open databases.
Update: according to the bit.ly blog, VeriSign and Sophos are the other scanning/database engines.
In the case of Websense, bit.ly will tie directly into their content scanning service to check links in real time as they are added to the bit.ly database. Websense uses a mix of real time scans (for things like malware and certain phishing techniques) and their database of known bad sites. The system won't rely only on the database of previously-detected bad sites, but will also check them at access time.
If a link is suspected of being malicious, Websense marks it and bit.ly will redirect users to a warning page instead of directly to the site. Users can still click through, and I'm sure plenty will, but at least those of us with a little common sense are less likely to be exploited.
Bit.ly won't only be scanning new links added to the database, but will be checking existing links in case they've become compromised. This also reduces the chances of the bad guys gaming the system by adding a clean version of their site for an initial scan, then sneaking in malware for future visits.
I like bit.ly's approach of checking existing links in case they get compromised, rather than only scanning new links as they are added. This will make it harder for bad guys to game the system. This solution is a lot better than the anti-phishing built into browsers and some search engines, since those rely only on databases of previously-discovered known bad sites.
It's also a two-way system, and although Websense is being paid for the scanning, they gain the additional benefit of now leveraging the results once millions of new (and old) links start flowing through their service. Every bad website Wensense finds when a user submits a link to bit.ly is added to the database used by all their other products.
Finally, there's nothing that says we're only allowed to use bit.ly for Twitter. The entire Internet now gains a real-time security scanning service... for free. Have a questionable link? Shorten it through bit.ly and it's scanned by Websense and at least one other commercial service, as well as all the free/open/cheap databases bit.ly uses (sorry, I don't know what they are).
This isn't to say that any of the individual scans, or all of them together, can identify every malicious link they encounter, but this is a significant advance in web services security. It's a perfect example of cloud computing enhancing security, rather than creating new risks. Links sent through bit.ly will now be safer than the original links viewed directly.
This isn't live yet, but should be by the end of the year.
–Rich
By Adrian Lane
During the week of Black Hat/Defcon, McAfee acquired MX Logic for about $140M plus incentives, adding additional email security and web filtering services to their product line. I had kind of forgotten about McAfee and email security, and not just because of the conferences. Seriously, they were almost an afterthought in this space. Despite their anti-virus being widely used in mail security products, and the vast customer base, their own email & web products have not been dominant. Because they're one of the biggest security firms in the industry it's difficult to discount their presence, but honestly, I thought McAfee would have made an acquisition last year because their email security offering was seriously lacking. In the same vein, MX Logic is not the first name that comes to mind with email security either, but not because of product quality issues -- they simply focus on reselling through managed service providers and have not gotten the same degree of attention as many of the other vendors.
So what's good about this? Going back to my post on acquisitions and strategy, this purchase is strategic in that it solidifies and modernizes McAfee's own position in email and web filtering SaaS capabilities, but it also opens up new relationships with the MSPs. The acquisition gives McAfee a more enticing SaaS offering to complement their appliances, and should more naturally bundle with other web services and content filtering, reducing head-to-head competitive issues. The more I think about it, the more it looks like the managed service provider relationships are a big piece of the puzzle. McAfee just added 1,800 new channel partners, and has the opportunity to leverage those channels' relationships into new accounts, who tend to hold sway over their customers' buying decisions. And unlike Tumbleweed, which was purchased for a similar amount of $143M on falling revenues and no recognizable SaaS offering, this appears to be a much more compelling purchase that fits on several different levels.
I estimated McAfee's revenue attributable to email security was in the $55M range for 2008, which was a guess on my part because I have trouble deciphering balance sheets, but backed up by another analyst as well as a former McAfee employee who said I was in the ballpark. If we add another $30M to $35M (optimistically) of revenue to that total, it puts McAfee a lot closer to the leaders in the space in terms of revenue and functionality. We can hypothesize about whether Websense or Proofpoint would have made a better choice, as both offer what I consider more mature and higher-quality products, but their higher revenue and larger installed bases would have cost significantly more, overlapping more with what McAfee already has in place. This accomplished some of the same goals for less money. All in all, this is a good deal for existing McAfee customers, fills in a big missing piece of their SaaS puzzle, and I am betting will help foster revenue growth in excess of the purchase price.
–Adrian Lane
By Rich
Word is slowly coming through industry channels that the attackers in the Heartland breach exfiltrated sniffed data via an outbound network connection. While not surprising, I did hear that the connection wasn't encrypted- the bad guys sent the data out in cleartext (I'll leave it to the person who passed this on to identify themselves if they want). Rumor from 2 independent sources is the bad guys are an organized group out of St. Petersburg (yes, Russia, as cliche as that is).
This is similar to a whole host of breaches- including (probably) TJX. While I'm not so naive as to think you can stop all malicious outbound connections, I do think there's a lot we can do to make life harder on the bad guys. 
First, you need to lock down your outbound connections using a combination of current and next-generation firewalls. You should isolate out your transaction network to enforce tighter controls on it than on the rest of your business network. Traditional firewalls can lock down most outbound port/protocols, but struggle with nested/stealth channels or all the stuff shoveled over port 80. Next-gen firewalls and web gateways (I hate the name, but don't have a better one) like Palo Alto Networks or Mi5 Networks can help. Regular web gateways (Websense and McAfee/Secure Computing) are also good, but vary more on their outbound control capabilities and tend to be more focused on malware prevention (not counting their DLP products, which we'll talk about in a second).
The web gateway and next gen firewalls will focus on your overall network, while you can lock of the transaction side with tighter traditional firewall rules and segmenting that thing off.
Next, use DLP to sniff for outbound cardholder data. The bad guys don't seem to be encrypting, and DLP will alert on that in a heartbeat (and maybe block it, depending on the channel). You'll want to proxy with your web gateway to sniff SSL (and only some web gateways can do this) and set the DLP to alert on unauthorized encryption usage. That might be a real pain in the ass, if you have a lot of unmanaged encryption outside of SSL. Also, to do the outbound SSL proxy you need to roll out a gateway certificate to all your endpoints and suppress browser alerts via group policies.
I also recommend DLP content discovery to reduce where you have unencrypted stored data (yes, you do have it, even if you think you don't).
As you've probably figured out by now, if you are starting from scratch some of this will be very difficult to implement on an existing network, especially one that hasn't been managed tightly. Thus I suggest you focus on any of your processing/transaction paths and start walling those off first. In the long run, that will reduce both your risks and your compliance and audit costs.
–Rich
