Perimeter
Guest Blog // Selected Security Content Provided By Sophos
What's This?
10/30/2012
11:10 AM
Dark Reading
Dark Reading
Security Insights
Connect Directly
RSS
E-Mail
50%
50%

Is A Greater Risk Of Data Loss The Trade-Off For Convenience?

Ease of use aside, protecting customer data is never an afterthought

Interviewed by the Chicago Sun Times in the days following the recent Barnes & Noble PIN pad data breach Jacob Furst, a professor at DePaul University, specializing in information security, offered up at least one defense against data breaches―pay cash.

OK, that’s one way to stop data theft, but in the real world, especially online, that outcome just isn’t practical.

Then there’s this observation (delivered, apparently, without tongue firmly in cheek), “Generally, the more convenient something is, the less secure it is.”

For those hearing about the breach for the first time, customers using credit and debit card devices at 63 Barnes & Noble locations nationwide learned that at least one “PIN pad” in each store had been compromised (e.g., tampered with) by hackers. As a result, the bookseller warned its customers to check for unauthorized transactions and to change their PINs to defend against data loss or identity theft. Fair enough. Good advice.

As a security professional, however, I’m not so sure about Mr. Furst’s suggestion that just because something is convenient (e.g., a single-click or swipe), it’s somehow less secure. And you should just get used to it. You know, expect to get hacked. Have your credit card numbers stolen. And have the offender offer you free monitoring services for a year. And watch for irregularities in your monthly bank statement (e.g., when was I in Uruguay and why would I rent a fishing charter when I was there?).

Not so. Not even close.

That mindset suggests that whether you slide your train pass through the reader to enter a subway station, swipe your debit card to pay a tab, or even provide your credit card number online to buy something that someone, somewhere hasn’t thought of first protecting your data before you do.

Allow me to present evidence to the contrary.

Let’s work backward, just a bit. In a former life I worked as a security scribe for a payments processor which exclusively supported card-not-present (e.g. e-tailers) businesses. It was there that I first became acquainted with the PCI Security Standards Council PCI which is responsible for the development of the PCI Security standards including the Data Security Standard (PCI DSS) and PIN Transaction Security (PTS) requirements.

These standards, to which merchants, banks and other institutions must adhere if they want to continue to accept credit cards, aren’t a step you can simply overlook, opt out of or decline to participate in if it’s not convenient. Each of the credit card companies (including AMEX, Discover, Visa and MasterCard) require you, as a merchant, to comply in full with its 12-step standards. And they’ll even take the step of sending out auditors, in this case known as QAS (or Qualified Security Assessors) to make sure you do.

In the case of point-of-sale (POS) PIN pads, the information is encrypted as it’s transmitted. This is also true of card-not-present retailers leveraging tokenization solutions, where the primary account number (PAN) is replaced with a surrogate value called a token. Storing tokens instead of PANs is one alternative that can help to reduce the amount of cardholder data in the environment, potentially reducing the merchant’s effort to implement PCI DSS requirements. And, parenthetically of course, if a cardholder’s card number is masked (or tokenized), it also substantially reduces the amount of risk to a cardholder at a POS PIN pad or use of a credit card online.

By the way, all of the media takes on the B&N breach suggest that customer personal identification number information remained encrypted on the PIN pad, which is one reason the bookseller did not have to publicly announce the breach immediately, but instead share it with authorities to track down the hackers responsible.

Or, how about something closer to home, like transit? Here in Boston according to the Massachusetts Bay Transit Authority (MBTA), the subway’s commuter and rail pass program – the “CharlieCard” – incorporates a tiny chip implanted into every card. If it’s ever lost or stolen, the card can be blocked from further use and the remaining balance transferred to a new card.

On more familiar ground there’s also smartphone remote wipe technology that lets you (or an IT employee) remotely erase the handheld’s data in case it’s lost or stolen.

So what do these examples prove?

Well, with complete deference to Professor Furst’s position on this, I must disagree with his premise because it presupposes that convenience will always trump security when, at least in my world (likely yours as well), nothing could be further from the truth.

Are there exceptions to the rule? As the good professor will tell you and as common sense dictates, of course. Sometimes hackers find their way round an encryption solution in order to have their way with your personal information. After all, no security solution is ever 100% impermeable. Bad actors and cyber crooks make their way through that usually resilient membrane with astounding regularity. And most of the time when they do, as in the Barnes & Noble breach, it makes the papers. And most of the time if the security measures work, they come away empty-handed (as we hope they do in this case).

However, the examples I’ve shared (and I’m confident there are others) demonstrate overwhelmingly that when it comes to virtually turning over your personal information to someone or some organization in return for a product or service, your information is not at any more risk than it would be if you personally handed over your hard-earned money to a merchant in a typical brick and mortar big box store.

In other words, (and to take the contrarian view of Professor Furst), just because it’s convenient does not make it insecure.

Brian Royer, a security subject matter expert, Sophos U.S., is partnering with SophosLabs to research and report on the latest trends in malware, web threats, endpoint and data protection, mobile security, cloud computing and data center virtualization.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
kfred454
50%
50%
kfred454,
User Rank: Apprentice
11/3/2012 | 1:30:54 AM
re: Is A Greater Risk Of Data Loss The Trade-Off For Convenience?
I take exception to the statement "...These standards, to which merchants, banks and other institutions must adhere if they want to continue to accept credit cards,..."-á This is not true - previously I worked for an unnamed company that were (are still?) NOT PCI compliant and were / are perfectly at ease with the position of "Risk Acceptance" and paying the monthly FINES rather than the expense of making their legacy, Windows 2000-embedded POS environment compliant.-á "Must" and "Always" statements should be used judiciously...
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.