Archive for October, 2008

Oct 14 2008

Why is your company storing credit card numbers?

Published by under PCI

I don’t know where the saying comes from, but an axiom I use frequently is “They can’t steal what you don’t have”.  In other words, it is impossible for someone to steal something from you that don’t have.  This is one of the reasons many of us don’t carry any more in our wallets than absolutely necessary when traveling; if I don’t have unnecessary credit and debit cards in my wallet, I won’t lose them if my wallet is stolen or I leave it on the conveyor belt at the TSA check point. The same idea goes for credit cards on your network and in your databases:  if you don’t have the data, it can’t be stolen.

Many of the merchants I’ve dealt with keep everything and I do mean everything.  I’ve run into systems that have card numbers in their databases that date back to the first time they opened up an e-commerce site in the late 80′s.  The majority of the card numbers in these systems have long since expired, but the merchant steadfastly refuses to purge any of the data ‘just in case it might be useful some day’.  In most cases, they don’t actually use the stored credit card numbers in any way, shape or form, but they feel the need to have the data just to have the data.  After all, we all know data is valuable, and what’s more valuable than a potential customer’s credit card number?

What very few merchants have done is to actually take the time to weigh the potential value of the stored credit card numbers versus the risk they take of being compromised and the cost of properly securing the data on the network.  Have you ever asked yourself how much profit you actually make off of the credit card numbers you’re storing in that massive database in the server room?  Is the data actually being used right now or is it being stored because that’s what was done when the system was built and it’s the way you’ve always done it?  You need to evaluate how much that data’s worth to your company, decide if it’s worth what you’re paying to store it, what you’re paying to secure it and what the potential downsides will be if someone manages to worm their way into your network and steal the data.  Heck, what if a backup tape just happens to fall of the back of a DHL truck and you have to report it under one of the several dozen state laws governing data loss?

Once you know what the data’s worth to your company the decisions to keep it all, purge older data or keep nothing becomes much easier.  There may be a perfectly valid reason to keep the data, a business reason that’s directly related to profit.  More likely, old credit card numbers are useless to your company and you can minimize the amount you’re storing by purging or truncating older card numbers.  And in some cases, you really don’t need old card numbers at all and should delete them as soon as possible.  Oops, I just heard your marketing department scream when I suggested keeping no credit card data at all.  But it’s a serious point of discussion; if you’re not using the data, why are you spending the money to store and protect it in the first place?

Most companies keep credit card numbers for four reasons.  The first is that they say they need it ‘just in case’.  Things like charge backs or for customer convenience when they return to your site.  Charge backs might be a valid concern or they might not; when was the last time someone at your company talked to your acquiring bank and asked what the minimum information needed for a charge back or refund was?  I willing to bet the answer is either never or at least not in the 21st century.  And as far as customer convenience, that’s another one of the trade-off issues: are the bulk of your customers coming back to the site frequently or are they mainly one-time shoppers?  I’ve dealt with companies that stopped storing credit cards numbers for customers and used it as a selling point, explaining to customers they don’t keep credit cards for security reasons.  They were surprised at how positive the reaction was to a show of concern for the customer’s security.  If you’re customer’s only return every couple of months or never, is it worth the money to save their credit cad information? 

The second reason many businesses keep credit card numbers is for the marketing department.  This is one I just find confusing.  What can the marketing department really do with credit card numbers?  Your marketing department shouldn’t ever be viewing the credit card information directly, period.  They can use credit card data to make sales, but this is basically the same as keeping it for customer convenience on the web site.  They could be using the information for reporting purposes, but again, they should never be using live credit card numbers in reports.  I’ve heard of some companies sharing credit card information with third-party marketing companies, but you’d better have an iron clad contract with that third-party so that they take full responsibility for the security of your customer’s credit card information.  Not to mention PCI clauses in contracts with your partners is required by the PCI DSS.

The third reason is perhaps the silliest:  “That’s the way we’ve always done it.“  The assumption is, there was originally a reason everything was saved forever and it was a good reason, so we can’t change now.  This is one of the worst phrases you can use when dealing with sensitive information, whether it’s cardholder data or any other type of valuable information.  Challenge these assumptions!  Find out if there’s really a reason to keep the information or if it’s just being kept because ‘Joe said we needed to when the system was built’.  ‘Joe’ left the company five years ago, so why are you still following old guidelines?  An corollary to this is the engineers who set up the system kept everything, just because that’s what most engineers do; you keep everything and grep for what you need.  That’s great for log files, but not so great for cardholder data.  Do yourself a favor and ask your marketing department and web site engineers what they do with the data and if they really have a valid reason for keeping it.  You might be surprised at the answer, sometimes they’ll tell you they have no more idea why the information’s being kept than you do.

The final reason is one of the few I can’t argue with:  we need it for legal/financial reasons.  If your company has specific requirements concerning financial data, that’s the bottom line.  But you need to make sure everyone understands the real requirements and isn’t just making assumptions based on incomplete or faulty understanding of the requirements.  This is another set of assumptions that needs to be examined and analyzed to make sure there’s not another way to fulfill the same requirement, a way that doesn’t involve storing sensitive information.  Of all the reasons to keep credit card numbers, this is probably the only one that can’t be worked around, so work with your accounting and legal departments to find out what’s really the minimum amount of information needed and keep only that.

Many merchants have never examined the information they keep and why.  They just keep everything, assuming they need it.  They spend the money to secure the data when they don’t have to.  Or worse, they don’t spend the money they should and put themselves and their customers at risk.  Challenge the assumptions around your stored cardholder data, talk to your marketing department, find out who’s saving the information and why.  We’re in tough financial times and if you can save money by not saving credit card numbers and not spending the money on the safeguards that information necessitates, you can be a hero.  But you might first have to become the villain who’s pushing other departments to re-examine their assumptions.

One last thought:  consider outsourcing your credit card storage and processing, especially if you’re a small to medium business.  It might cost you slightly more to have someone else do all the work, but it can also save you money by offloading all of the responsibility of securing the data.  Chances are they have a better solution for securing the data than you do and the savings of doing it yourself were only illusionary to begin with; your saving money because you haven’t really secured the data or met the PCI requirements to begin with, not because your data is secure.  In other words, you’re only saving money because you haven’t spent the time and money to encrypt your database and implement a web app firewall, not because you can do a better job of securing the data yourself.

Update:  I was looking at the PCI Council site and found a link to a similar article from the Wall Street Journal

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

21 responses so far

Oct 13 2008

Supply chain attack on credit cards in Europe

You trust your PIN Entry Device[PED] (the thing you swipe your credit card through at the checkout stand) don’t you?  You might need to rethink that trust:  PED boxes in Europe were tampered with, either at the factory or somewhere else in the supply chain, and had additional hardware installed to capture full stripe data as well as PIN information.  The information has been getting sent back to the crime ring responsible for the compromise and is turning up in fraud cases all over the world.  The funny part is the best way to distinguish a compromised machine from an uncompromised machine is to weigh them; the attack adds 3-4 ounces to the machines thanks to the additional hardware installed in them.

To me, this is one of the scariest attacks against credit cards yet.  True, attacking a merchant like TJZ will get you millions of credit card numbers, but an attack against the supply chain could affect every merchant if it goes unnoticed long enough.  This attack is comparatively to detect, given the extra hardware that was installed.   But what if the attack had taken place one or two steps earlier in the manufacturing process and actually became part of the software in the PED boxes?  I can imagine a PED box having a little extra memory installed to log all the credit card swipes it processes oin a daily basis and calling home to upload that information on a daily or weekly basis. 

This is the sort of attack that could possibly go undetected for years, especially if the people doing it have a fair understanding of the credit card company anti-fraud mechanisms.  It’d be easy to create an algorithm that is specifically designed to choose credit card numbers from the pool and use them in such a way as to fly under the radar with a little insider knowledge.  And anyone who’s already infiltrated the manufacturing companies will have a good chance at infiltrating other aspects of the process as well.

It took nine months for the authorities to track down and report on this breach of the supply chain.  The people who pulled it off knew what they were doing and knew how to make their devices look like they’d never been tampered with.  The authorities caught on, but the next time someone pulls this off, they’ll be smarter and it’ll be even harder to catch them.

This is just one more reason you should never use your debit card anywhere other than at a bank.  When your credit card is compromised, you’re only responsible for the first $50; if your debit card is compromised, it all depends on how nice your bank decides they want to be.  Do you want to rely on your bank’s charity?  I sure as heck don’t.

Update:  A little more information on this attack from the Wall Street Journal.  Thanks to Richard Stiennon

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

One response so far

Oct 13 2008

Doing the math for WPA cracking

Published by under Encryption,Hacking

I’ll admit it:  Sometimes I’m lazy and sometimes I hedge my bets a little.  I didn’t have the time on Friday to look deeper into the real time requirements to hack a WPA password using Elcomsoft’s new tools.  I knew the time needed was considerable, but I didn’t realize exactly how long it’d take:  George Ou says it’d take 5793 years to crack a WPA password normally and even with a heftier computer than most of us will ever see, it’ll still take almost 6 years to break the key.  And Robert Graham backs him up, saying all it takes is lengthening your key by one character. 

I’d overestimated how much of an impact this could make on the security of a wireless network.  I thought Elcomsoft might have come up with a viable attack against WPA, but in reality, this is just a marketing gimmick.  No one’s going to devote 5+ years of computing power to hack a wireless network; first of all the information will probably be obsolete in that time frame, second, no one’s going to keep the same wireless network equipment and passwords for five years.  At least I hope they won’t.

There are any number of easier, quicker ways to break into a network than trying to brute force the WPA passphrase, everything from social engineering to just breaking in and stealing the servers.  Cracking the WPA will probably become easier as time goes by, but for now WPA is still a viable way to secure your wireless.  Unless you’re doing something stupid like using dictionary words in your passphrase. 

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

One response so far

Oct 11 2008

Looking forward to RSA Conference 2009

I really look forward to the RSA Conference in San Francisco every year.  It was fun when it was just another security conference, but since we’ve started doing the Security Blogger Meetup, it’s become one of the main conventions I look forward to. This year will be even better, since the Meetup will be bigger and better than it’s ever been before!  We’ve got a lot of big plans forming, so even if we’re only able to half of what we imagine, it’ll still be a great event.

We’ve already started planning for this year’s Meetup and I’ve been invited to write on the RSA Conference 365 site, so I’ll keep the majority of my writing and enthusiasm for the event there.  Alan, Rich, Jen and Jeanne will be writing about the Security Blogger Meetup and all the things surrounding it on the site as well, so it’ll be a good site to add to your RSS feeds.  Keep the week of April 20th through 24th free or you’ll miss one heck of an event!

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

One response so far

Oct 10 2008

Recording Notice: Security Roundtable – Blogger Ethics

Published by under Podcast

Michael Santarcangelo and I will be recording the next episode of the Security Roundtable tomorrow morning at 7:00 am PDT.  You can listen to the podcast live at http://hak5radio.com:8000/srt.mp3.m3u  We’ll be joined by our friend Jennifer Leggio to talk about blogger ethics, public relations and anything else that comes to mind.  If you can’t listen live, we’ll have the podcast up by next Wednesday.

Update:  Live stream server is down this morning, still recording, but no live stream available. 

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Oct 10 2008

Brute force attacks against WPA/WPA2 using Nvidia cards

According to The Register, Russian company Elcomsoft has made a major jump in cracking WPA and WPA2 passwords using Nvidia graphic cards to brute force the passwords.  They say that a system with two Nvidia GTX 280 video cards in it can crack the passphrase 100 times faster than anything before.

Does that mean it’s time to shut down all you’re wifi and only use your wired network?  Not really, since this requires specialized hardware and software.  Not everyone can afford $800 just for two video cards, let alone the $600 for Elcomsoft’s software and the ~$500 it costs to buy rest of the parts required to build a computer.  That’s not a trivial investment for most of us, especially right now.

If this was a piece of open source software that ran on any GPU, I’d be scared.  It’d be a real blow to wireless encryption technology.  But given the cost of the product and hardware, I doubt many people will be breaking WPA passwords in the near future.  However, the people out there who are targeting specific businesses looking looking for specific information will love this tool and use it often.  Can you say “corporate espionage”?

Don’t abandon your wifi yet, but continue to take the precautions you should be taking anyway.  Put your wireless on it’s own network, make your users VPN into the corporate network and add as many additional layers of security as your company lets you.  Issues like this are why security professionals continually use terms like ‘defense in depth’; when one layer of security fails, you need to have other protections in place to make sure you aren’t pwned like TJX.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

13 responses so far

Oct 09 2008

Sequoia’s helping decide the election? God help us!

Rich and I talked about electronic voting earlier this week on the podcast and it’s something I’ve never been a big fan of.  But Wired’s story on the voting issues Palm Beach Florida had in their judicial election race quite frankly scares the snot out of me!  In nearly half a dozen recounts, Sequoia’s optical scanning machines couldn’t return the same results two times in a row.  Even when Palm Beach purchased newer optical scanners, testing showed that two machines sitting side by side even had a hard time returning the same results.  Quite frankly, electronic voting machines, whether their Sequoia’s or Diebold (whatever there name is now) or any of the other manufacuter’s, can’t be trusted.  Especially not with the Presidentail election right around the corner.

Even if you ‘ve never been interested in electronic voting, you need to take a look at Wired’s story.  These are the machines that will decide the election.  I used to be concerned with the fact that many of these machines run on Windows CE or a variation thereof and how easily they could be hacked.  But if a machine can’t even get an accurate count with the best of intentions and support, how can we trust them to count our votes? 

The worst part about this fiasco is the way all of the voting machine companies spend more time bashing the people critical of their machines than they do trying to fix the problems.  We’ve had machines in our schools for decades that will read a scantron sheet almost flawless, so why can’t Sequoia even get that part of the equation right?  Even if we don’t take the security of the machines into account, you can’t ignore the fact that the large amount of errors these machines are showing could make the Gore/Bush election look like child’s play.  Imagine how much a 1-2% error rate could swing the whole election.  Can you imagine either of the candidates just letting that go by?  I can’t and even worse would be if one of the candidates actually had a legitimate complaint and there were a large number of miscounted ballots.

There’s no doubt, we will have an all electronic election some day.  But we’re so far from ready right now; not a single one of the e-voting companies has proven their worthy of being the custodian of our votes.  They can’t count accurately, they can’t secure the machines, and they can’t be trusted.  But they will be anyways, by election officials who don’t know any better or don’t care.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

One response so far

Oct 09 2008

Cisco Ooops: drug runner music on VPN CD

Published by under Humor

Imagine popping in your Cisco VPN installation CD only to have Mexican music start playing rather than having the installer start.  That is apparently exactly what happened to Dave Fumberger yesterday.  Someone at the plant who makes the Cisco CD’s apparently burnt his or her mix tapes to the CD rather than the Cisco software that was supposed to go on it.  At least it wasn’t Barney’s Greatest Hits!

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

One response so far

Oct 09 2008

Step by step guide to the DNS vulnerability

Published by under Hacking,Security Advisories

Got a few minutes?  Actually, more than just a few to be truthful.  If you’re at all curious about the intimate details of how Dan Kaminsky’s DNS vulnerability works, then you should review Steve Friedl’s “An Illustrated Guide to the Kaminsky DNS Vulnerability“.  This is not for the faint of heart or short of time; the paper starts with the basics of DNS and works it’s way up to explaining how and why Dan’s vulnerability works and why it’s so important. It’s about 20 screens long, so get a good cup of morning coffee, sit back and get edumicated.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

2 responses so far

Oct 08 2008

NoScript protects from ClickJacking

Stop reading this and go update your NoScript plugin to get the latest version with ClearClick enabled!  And if you’re not already using Firefox with NoScript, there’s nothing I can do to help you.  :-)

Seriously, with all the talk about clickjacking over the last couple of weeks and proof of concept code being released yesterday, you do need to do something to protect yourself.  One option is to follow Adobe’s suggestions for disabling the camera and microphone by default, but that’s only a stop-gap measure and only addresses a small part of the issue.  NoScript in Firefox offers protection from clickjacking along with a host of other script-related issues.  If you’re a security professional and you’re not already using this combo, I’m curious as to why.  Really.

Clickjacking isn’t the end of the world, but it does add a new, set of vulnerabilities and concerns that the average user can’t be bothered to understand.  It won’t open the Internet to the Apocolypse, but it will give the bad guys one more weapon to use in the malware wars.  And one more thing we have to make sure to protect against.  <big sigh>

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

« Prev - Next »