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
PCI: Dead Man(date) Walking?
Newest First  |  Oldest First  |  Threaded View
beauwoods
50%
50%
beauwoods,
User Rank: Apprentice
5/4/2012 | 8:19:15 AM
re: PCI: Dead Man(date) Walking?
PCI-DSS isn't quite dead yet. Don't forget that one important reason the DSS probably exists is to keep government regulation away. And in that, it's done a great job so far. And PCI in all its various standards probably isn't going anywhere, even after/if all the cardbrands adopt EMV. They'll still need the PA-DSS standard and the PIN transaction standard. Especially as more and more business is done through mobile devices - what Bob Russo called "the most insecure device in the world" (http://www.americanbanker.com/....

But the DSS and the QSA program obviously have their flaws. Like the lack of quality control on assessments, beyond just making sure the documentation is in the right format. There's no accountability for QSAs who have provided ROCs for companies that turn out later to be non-compliant. To my knowledge, the PCI Council has not come out and said that just because someone is breached means they were non-compliant. I think it's only after investigation of the root cause that they determine this. But I agree, that the standards leave room for compliant organizations to get breached.

And in general, PCI auditing suffers from some of the same issues as other audits. Other audit standards (particularly the financial services industry and regulated securities) have a longer history than Infosec of audits. As I point out, we could learn something from Enron. http://beauwoods.blogspot.com/...
dmoore75001
50%
50%
dmoore75001,
User Rank: Apprentice
4/26/2012 | 8:17:32 PM
re: PCI: Dead Man(date) Walking?
This solution is helps when the card holder is present at a terminal the leverages the chip capability. What happens when you are calling in a transaction via phone? Where is the chip when you have a recurring transaction against the card? For services that pay online? Technology (EMV) is only part of the solution. The people involved and the processes that participate in transactions are also points of threat or attack.-
KCrew
50%
50%
KCrew,
User Rank: Apprentice
4/26/2012 | 12:34:42 PM
re: PCI: Dead Man(date) Walking?
Maybe I am wrong but EMV is no silver bullet and PCI is far from dead.- The chip and PIN-technology protects data at time of authentication but that's it.- Visa only waives the assessment of the merchant.- That back end database and data center-is still full of credit card information that needs to be protected.- And even if EMV encrypted all of the data and it was unreadable end to end there is still the Issuing side of this equation where someone has to store all of this information so that the card can even be used and hence PCI will still be required for that.- Additionally you will still need processors that will need to be PCI compliant, network and gateway providers, and other card related services-as well.- EMV is to help relieve the burden of PCI compliance on the small merchant and retail outlets with many end points.- EMV will-help to protect the end point and the customer-but there is-still a lot of data stored outside those end points that will need to be protected and PCI will still be there to guide companies on how to protect that data.- Sorry Mike but I disagree that PCI is going to be going away anytime soon.- Personally I think articles like this create just as much FUD and makes the security professional's job even harder.- If PCI goes away does that means you can start posting card data on the Internet?
ABARRATT000
50%
50%
ABARRATT000,
User Rank: Apprentice
4/25/2012 | 9:05:05 PM
re: PCI: Dead Man(date) Walking?
This isn't the case for Visa Europe.

http://www.visaeurope.com/en/n...-
EMV is only part of the battle, we've had it over in the UK since 2006 and its been great at helping to reduce face to face card fraud, but there are still issues that need to be addressed in the service provider community when they handle card holder data as well as in e-comm / MOTO merchants that are more actively-targeted by miscreants.
It would have been nice if the US had got on board with EMV earlier so that we could all get rid of magstripes!-
Any merchant that does multi channel sales will still require a QSA assessment annually and as multi channel integration is a major plus for retailers the TIP process will have a-diminishing-number of eligible merchants in real terms. -I personally think that Visa Inc should take a similar approach to Visa Europe - encourage EMV adoption, acknowledge that it doesn't solve all the problems, push point to point encryption (P2Pe) coupled with EMV and adjust the reporting goalposts accordingly. -

To say PCI is dead I think is a little premature. -It does need to evolve, and the delay with getting a P2Pe standard released didn't help. -P2Pe + EMV should offer significant risk reductions to those merchants that use it exclusively. -I've never seen the SSC say that "no breached entity can have been compliant". -In fact one of the discussions at a recent QSA event in the UK the SSC said they acknowledged that with 0-day exploits it is perfectly possible to have been compliant and still get breached. -As security professionals we know that the process needs to be cyclical and involve continuous improvement, which is why I am so surprised at Visa Inc and their dropping of the validation reporting (either by saq or QSA!). -Which as you rightly say will lead to a number of entities just not bothering with PCI at all. -Rather than remain a pro-active measure Visa Inc appear to be making things re-active as in the event of a breach there will no doubt be a QFI involved, and then the compliance status will need to be re-validated by a QSA. -Surely from a security-perspective we should be encouraging people to have an-independent-set of eyes review their controls. -Whilst Visa Inc are waiving the mandatory requirement to send them a RoC, -they are still expecting people to maintain compliance and are reserving the right to restart validation if they choose. This bit is of most concern "Acquirers retain full responsibility for merchantsG PCI DSS compliance, as well as-
responsibility for any fees, fines or penalties, which may be applicable in the event of a data breach"(http://usa.visa.com/download/m...-). -Can't see the acquiring community taking the hit if suddenly people stop doing PCI.. -


COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
Omdia Research Launches Page on Dark Reading
Tim Wilson, Editor in Chief, Dark Reading 7/9/2020
4 Security Tips as the July 15 Tax-Day Extension Draws Near
Shane Buckley, President & Chief Operating Officer, Gigamon,  7/10/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15105
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
CVE-2020-11061
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
CVE-2020-4042
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
CVE-2020-11081
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
CVE-2020-6114
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...