There are no silver bullets for phishing. But there are plenty of silver hooks. Here are some pragmatic ones that we could quickly adopt in whole or part assuming we’re willing accept some ill effects. Unfortunately I don’t see that happening in the near future, which is just another way of saying that our phishing pain hasn’t yet exceeded our gain.

Gain you say? Sure. Somehow we’ve completely lost sight of the fact that phishing is fueled by the exact same features (not bugs) that fuel online merchant marketing: HTML email with embedded anchor tags. Click here and buy something there.

Here are some of those silver hooks:

MTA Methods:

• Black hole HTML email. This will undo one of the biggest technology mistakes ever made.
• Strip anchor tags from HTML email
• Neuter anchor tags by adding invalid characters inside the HREF attribute
• Replace anchor tags with “[URL REMOVED FOR YOUR OWN GOOD]“

Email Reader Methods:

• Same as MTA Methods
• Present a mouseover warning (independent of javacript) that warns the user to be cautious
• Present a mouseover warning that dissects the URL into smaller components that the user can hopefully understand

Merchant Methods:

• Find alternative marketing means
• Replace the message in anti-phishing collateral from “how to recognize a phish” to “never click on embedded links in email.”

By Jim Reavis

The people who own corporate information security programs have spent the last few years playing a game of regulatory catch up, while for the most part spinning their wheels when it comes to implementing new and actually useful concepts to mitigate evolving threats and justifying their existence.  Meanwhile, exploiting information security vulnerabilities for financial gain has never been easier and is now big business, with sophisticated tools, mature distribution channels, stable malware pricing and even some slick marketing.  The gap between good and evil is as wide as I can recall in my years in the business, and if it turns out that the recent Estonia bashing business was actually coordinated in part by the Russian government, well, it ain’t getting prettier.  Yet, with all the bad news, you do hear about a lot of good ideas being bandied about to make changes in the way we protect information assets.  Ok, I am also hearing a few bad ideas as well, but at this point I think change for change’s sake isn’t necessarily the worst thing to do.  Here, in no particular order, is my list of Ten Ascendant Trends for the Next Chapter of Information Security:     

Continue Reading »

By Ira Winkler

There is a current article from Fortune describing some more accusations of “Pretexting” against HP. HP’s response is that they did not perform any pretexting. Sadly the reporter either didn’t question any further or didn’t have the opportunity to ask more questions. Nobody said that direct HP employees performed illegal pretexting themselves. The fact is that they paid to have the crimes committed.

The whole plausible deniability excuse is ridiculous. The HP Executives knew exactly what was going to be done, and they paid to have it done. Just as paying someone to commit a murder makes a person an integral part of a crime, knowingly paying someone to commit a criminal act is makes that person equally responsible for the crime. It is time that reporters and the criminal justice system started to treat things that way. Just because it is HP’s policy not to perform pretexting, it doesn’t mean that they are off the hook when they pay others to do it for them.

By Ira Winkler

In my new book, Zen and the Art of Information Security, I have a chapter titled, If You Have to Ask, You Shouldn’t Be Asking. The catalyst for this chapter was that someone once attended a presentation that I gave on penetration testing, and then contacted me a year later with an e-mail that basically said, “I finally talked a client into letting me perform a pen test. I don’t know what to do, how to do it, what to charge, or any special legal language that should be in the contract.” My response was basically, “You shouldn’t do the work.”

Today, I was hit with another e-mail message that wreaked of the same problem. In today’s message, a consultant from a very large integration firm sent out a message saying that one of their clients wants to scope out integration of a NOC/SOC. He gave a very wide variety of requirements for the facility, and then wanted feedback from a wide variety of people not associated with his company. While I am normally all for helping out a colleague, this person should have either sought this info inside his own organization, which has access to such experts, or just told the client he doesn’t have a clue and to go elsewhere.

Continue Reading »

By Jim Reavis

 I was interviewed by PGP Corp, where I am a Business Advisory Board member, about Enterprise Data Protection (EDP) - defining the term, looking at what is coming down the road, sharing best practices, etc.  It is an educational piece, you can listen to it by clicking here for the MP3.  It isn’t a sales job, I need to get better at that :)

When you look at the industry predictions for the crazy amount of storage growth, particularly at the enterprise, the equally insane amount of installations of Citrix, VMWare, Sharepoint, etc., you can see that the CIOs are going to be reasserting controls and will be looking to centralize data.  We used to have to choose between high bandwidth and mobility - now we have both, so you can have better luck at providing data collaboration to your users while at the same time controlling what goes on the mobile devices.  The point here is that the EDP strategy needs to not just look at encrypting laptops, but protecting shared storage and enterprise applications from an increasingly compromised internal network.  You need a strategy for doing this without multiple access methods, redundant keys and other hoops for the users.

I give a Top Ten list of key considerations at the end and hopefully a few interesting nuggets you can put to use.  Enjoy!

By Ira Winkler

I was reading about the plans for the IRS to want Internet sites to collect information on people who collect more than $5,000 in more than 100 transactions. I can technically see why, as the IRS potentially wants to crackdown on people who are making a lot of money on eBay and other sites. However the criteria in this case is ridiculous. For example, what about someone who sells 30 cars on eBay for $20,000 each? They wouldn’t have to report, while someone making many small transactions would.

Most importantly, it puts people’s Social Security Numbers in danger as the sites would have to collect SSNs to fulfill their requirements. Then they would have to store the info. More importantly, the sites don’t see the final transactions. If a deal is cancelled, or fraud is involved, the sites might not see it. The IRS would have a much more effective contention for getting credit card companies to report all companies with the same criteria. The credit card companies already need the SSNs and Tax ID numbers already, so it wouldn’t be any more of a security risk than it already is. That is accept of course for the possibility that the information would be stolen from the government.

Editor: I’m reminded of the book “Snow Crash,” more specifically the part surrounding the US government’s collapse after they lost the ability to collect taxes due to electronic currencies and other non taxable forms of commerce. The good news is you can always tax real estate, hard to hide that stuff.

Yesterday’s front-page Wall St. Journal article about TJX (”How Credit Card Data Went Out Wireless Door”, May 4, 2007) takes a disappointing, though expected, turn at the end. Referring to proposed credit card security legislation, they write: “One bill in Massachusetts would impose full financial responsibility for any fraud-related losses, including costs of reissuing of cards, on companies whose security systems are breached.” The context suggests that by companies, they mean companies that aren’t card-issuing banks, namely downstream entities like merchants (e.g. TJX) and payment processors (e.g. CardSystems).

This sounds great on paper, particularly to an audience whose demographic I’m guessing includes everyone with a vested interest in the banking industry. Who doesn’t get warm fuzzies when they read about financial slackers being legislated into good behavior?

But who exactly are the credit card security slackers? I’d bet my bottom blue chip dollar that it’s the same slackers who slack in other crucial parts of their business. Some merchants slack. Some payment processors slack. (For instance, those who in 2004 themselves didn’t comply with PCI/DSS, at the same time they were enforcing compliance upon their downstream merchants.) And, in breaking news, some banks slack.

None of this is about security. It’s about pushing liability for credit card fraud as far downstream as possible. Card issuers have been pining to do that for decades, and they’re using PCI/DSS as political means to do it. In a crafty move, they’ve even created a new downstream tributary: PCI/DSS auditors. Auditors see it coming.

Card issuers ought be more careful about this. For one, nobody has secure technology. (For the zillionth time, security is an abstract concept; all tangible technology can be penetrated.) When enough issuers have been penetrated, the very integrity of PCI/DSS will be undermined. That means liability shifts upstream again. For two, merchants - the majority of whom are not slackers - already shoulder huge fraud burden. If they’re forced to carry a lot more, they’ll have no choice but to also start shoving downstream. And the only thing downstream from merchants is card holders.

Don’t get me wrong. Liable parties should be held accountable. PCI/DSS should exist. It’s a great standard, simultaneously pragmatic and lofty, as I can attest from driving compliance efforts at Amazon.com.

The truth of the matter is, there are really good ways to fix the weakest links in credit card security. And the card issuers have got to be losing sleep over it, since some of them are downright simple and affordable relative to complying with PCI/DSS. Problem is, those solutions transfer virtually all of the liability off merchants and onto themselves.

Smart merchants will eventually figure some of these solutions out, band together, and do something about it. Merchants, here’s a hint: you don’t really need to know my credit card number.