Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Comments
Heartland CEO On Why Retailers Keep Getting Breached
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
the5thHorseman
50%
50%
the5thHorseman,
User Rank: Apprentice
10/9/2014 | 1:54:32 PM
Re: NOT blaming card issuers
Your comments are insightful. You are absolutely correct when you said "It's almost as if they are calculating the risk of a breach and the outcome versus making the initial investment to prevent breaches in the first place". The only thing wrong with your statement is "almost"; it's exactly what is happening everywhere. The reason is that the people making the decisions are NOT IT people, or even CIO's in many cases. Decisions to spend this kind of money ultimately end up with a CFO, or CEO, who make the decision just like they were taught to in their Management 101 class; risk vs profit. Corporations are so greedy now, that they simply won't spend their profits on security... until they loose millions of customers sensitive data. Once it goes public, they're forced to do something to save face. But the fact is it wouldn't have happened in the first place if they CARED about protecting their customers data. The only thing that changes this... don't spend your money at their store. Money is  the only thing they care about. Personally, I don't shop in the places that have been "breached". I would rather pay a higher price now then have my identity stolen, credit wrecked and fight the banks over unauthorized charges later. Their lower prices don't offset that kind of havoc in your life. And it won't be brief either.... it will go on for a long time... Pay a little more and buy from someone with your security interests first.
markfbower
50%
50%
markfbower,
User Rank: Apprentice
10/8/2014 | 5:10:08 PM
Heartland led, others followed, but many are still vulnerable
Great to see Bob speaking out on this and encouraging others to take their lead in changing the game in protecting sensitive data. When we helped Heartland with their data-security strategy, technology adoption and E3 project, they kindly agreed to a case study which is available on our site (the comments here dont permit URL posting).

Since then, a huge number of merchants and processors have moved to this data-centric approach of encrypting card data from the instant it is read through to the processing host, followed by PAN tokenization for storage protection for post-authorization processes. This approach neutralizes sensitive data from breach risks and has proven highly effective in preventing attacks yielding anything of value to advanced malware in the POS or retail IT. Of course, organizations who suffer major breaches can also quickly adopt these technologies to avoid subsequent attacks - a fast track to recovery and remediation, exactly like Heartland who led the way several years ago. Many savvy retailers, processors and gateways have embraced the data-centric approach since that industry-changing card breach in 2009. However, those that have not are increasingly at risk of compromise, and insurance isn't a solution as Bob makes very clear.

Regards, 
Mark Bower 
VP Products 
Voltage Security
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
10/7/2014 | 2:27:53 PM
Re: NOT blaming card issuers
I think we should blame card vendors and anybody and everybody using their products without asking any security improvement. We should not be still using a card for our transaction at this day of age. They are not improving, they can easily use a chip in the cards for sure.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
10/7/2014 | 2:22:52 PM
Re: the real issue is un-authorized programming
I agree. Apple Pay is the right late direction. There will be certain vulnerabilities we need to mitigate but we have to start somewhere.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
10/7/2014 | 2:20:38 PM
Not investing and not applying
Companies may not be investing end-to-end encryption, but most importantly they do not apply the policies they put in place such as not sharing information in the email, changing passwords periodically,... and so on. They are not doing these simple things to minimize the risk. Most problems and attack start from those simple information, unfortunately.
macker490
50%
50%
macker490,
User Rank: Ninja
10/7/2014 | 7:16:58 AM
the real issue is un-authorized programming
the real issue in these hacks is un-authorized programming (hacking).  by installing a "ram scraper" (i.e. an  un-authorized program) into your Point of Sale terminal the hacker exfiltrates illegal copies of the customer card data ("dumps") *before encryption*

Apple Pay is taking the right approach on this in establishing a system whereby a 1-time payment authorization key is sent to the merchant instead of reading all the customers card data into the POS terminal

in this manner there is no usable data in the POS for the attacker to steal.   EMV should have adopted this method.

the trouble with Apple Pay is that it is served off a "smart phone".   load a bad app in your phone and you'll be running up charges from Peking to Berlin.   the payment card should use a separate, single purpose chip that cannot be updated: only replaced.

in the end you have to start with a secure operating system: one which accepts only signed, authenticated, and approved software updates.   you *cannot* protect a vulnerable operating system by loading security patches into the application programming.
Stratustician
100%
0%
Stratustician,
User Rank: Moderator
10/6/2014 | 4:29:57 PM
Re: NOT blaming card issuers
I think part of the issue is that companies first look at the cost of updating their systems, both from a payment processing standpoint and a security standpoint, and when the see the sticker price on what it would cost to reach a preferred security state, it's often shut down.  It's almost as if they are calculating the risk of a breach and the outcome versus making the initial investment to prevent breaches in the first place.  It's utterly the wrong way to approach security, yet it is sadly the way things remain to be for the forseeable future.  We've all seen the lack of teeth legislations like PCI really have to influence behaviour, it's only the risk of public loss of trust that actually causes some of the changes in behaviour, yet sadly it's generally going to be an afterthought since no one seems to worry until it's too late.
Sara Peters
50%
50%
Sara Peters,
User Rank: Author
10/6/2014 | 4:01:45 PM
and another thing...
He says that a forensics team (I'm assuming a third-party team) gave them a clean bill of health just days before the breach...   I wonder if there will ever be a time that forensics and pen testing companies end up getting smacked with liability lawsuits when they miss something. I'm not saying that I necessarily want it to. I'm just wondering if it will.
Sara Peters
50%
50%
Sara Peters,
User Rank: Author
10/6/2014 | 3:56:44 PM
Re: NOT blaming card issuers
@Kelly  Especially because he's still with the company. Despite gag agreements, it's a lot easier for someone who's left a company to talk frankly about how he/they screwed up. 
Kelly Jackson Higgins
50%
50%
Kelly Jackson Higgins,
User Rank: Strategist
10/6/2014 | 3:53:09 PM
Re: NOT blaming card issuers
Yep. I love his frank talk. It is very refreshing.
Page 1 / 2   >   >>


Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
Unreasonable Security Best Practices vs. Good Risk Management
Jack Freund, Director, Risk Science at RiskLens,  11/13/2019
Breaches Are Inevitable, So Embrace the Chaos
Ariel Zeitlin, Chief Technology Officer & Co-Founder, Guardicore,  11/13/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19010
PUBLISHED: 2019-11-16
Eval injection in the Math plugin of Limnoria (before 2019.11.09) and Supybot (through 2018-05-09) allows remote unprivileged attackers to disclose information or possibly have unspecified other impact via the calc and icalc IRC commands.
CVE-2019-16761
PUBLISHED: 2019-11-15
A specially crafted Bitcoin script can cause a discrepancy between the specified SLP consensus rules and the validation result of the [email protected] npm package. An attacker could create a specially crafted Bitcoin script in order to cause a hard-fork from the SLP consensus. All versions >1.0...
CVE-2019-16762
PUBLISHED: 2019-11-15
A specially crafted Bitcoin script can cause a discrepancy between the specified SLP consensus rules and the validation result of the slpjs npm package. An attacker could create a specially crafted Bitcoin script in order to cause a hard-fork from the SLP consensus. Affected users can upgrade to any...
CVE-2019-13581
PUBLISHED: 2019-11-15
An issue was discovered in Marvell 88W8688 Wi-Fi firmware before version p52, as used on Tesla Model S/X vehicles manufactured before March 2018, via the Parrot Faurecia Automotive FC6050W module. A heap-based buffer overflow allows remote attackers to cause a denial of service or execute arbitrary ...
CVE-2019-13582
PUBLISHED: 2019-11-15
An issue was discovered in Marvell 88W8688 Wi-Fi firmware before version p52, as used on Tesla Model S/X vehicles manufactured before March 2018, via the Parrot Faurecia Automotive FC6050W module. A stack overflow could lead to denial of service or arbitrary code execution.