23 Jun 2008
New measures implemented in section 6.6 of the Payment Card Industry (PCI) standard, which come into force on 30 June, do nothing to address the threat of insiders, according to a database security firm.
The updates require that companies dealing with stored credit card and other consumer financial data either install firewalls around all internet-facing applications or have all customer application code reviewed for common vulnerabilities.
However, Secerno warned that, although this is a useful step in ensuring that information remains as safe as possible, its focus on the perimeter fails to provide any safety provisions against the threat of insider breaches and theft of data.
"The PCI Data Security Standard has the best intentions but, as is the case with many compliance directives, it barely addresses the most immediate and upcoming threats to consumer data," said Paul Davie, founder of Secerno.
"PCI was historically written for e-commerce rather than general retailers where breaches have actually been taking place.
"It is generally inadequate for addressing the sort of internal threat that can be exploited easily, such as by general or privileged users."
The insider threat can be anything from employees with financial or other motives to obtain and sell data, or criminals who infiltrate an organisation with the sole intention of stealing information.
"The standard says nothing about any malware other than viruses, and nothing about encrypting internal data," said Davie.
"It says nothing about protecting data on private networks and it says nothing about securing the database. Unfortunately, the internal threat is PCI's blind spot."
Davie believes that the retail industry needs to make sure that it protects data at the source in order to secure sensitive customer information against internal and external threats.
Latest stories from Web
Related articles
Related jobs
Poll
What is the most important IT priority for your company this year?
Connect with V3.co.uk
This paper focuses on a series of best practices and techniques for development teams looking to improve their software development processes
Why good data management at all levels is essential in the modern business (video, 6mins)
Principal Development Engineer Lead- London - Smart TV...
Development Engineer - London - Smart TV, Gaming, Tablets...
Principal Development Engineer - London - Smart TV, Gaming...
Test Engineer -London - Smart TV, Gaming, Tablets, PC...
Keep up to date with the latest products, services and technologies from the world's leading IT companies. IThound.com brings you over 2,000 white papers, case studies and analyst reports.
Do you agree?
Requirement 3.4
The database security firm is wrong. PCI Requierment 3.4 states: Render PAN, at minimum, unreadable anywhere it is stored (including data on portable digital media, backup media, in logs, and data received from or stored by wireless networks) by using any of the following approaches: ? Strong one-way hash functions (hashed indexes) ? Truncation ? Index tokens and pads (pads must be securely stored) ? Strong cryptography with associated key management processes and procedures. This therefore applies to databases. If you implement PCIDSS requirement 3.4 you need to encrypt data at the database level - meaning that internal access to the data is impossible unless you have the correct keys. The requirement states "Strong cryptography with associated key management processes and procedures" - this means that only the right people should have access to the keys that enable to data to be unencrypted.
Posted by: James Park 11 Sep 2008
Requirement 7
It's hilarious that people point fingers at the PCI DSS for having holes. The real holes are businesses that are trying to do the bare minimum. They'll dissect the PCI DSS and argue with QSAs, threatening to take their business elsewhere. There's QSAs that go along with it, handing out rubber stamp approvals. Does anyone find it interesting that TJX and Hannaford were both "validated" by the same company (Cybertrust)? Word on the street is that a Hannaford employee got malware. The attacker then had wide open access to the rest of the internal network and was able to get packet sniffing software on all the branch office servers. 187 servers, undetected. How sad is that? I mean, really. How do they even manage to spread that far? There must have been more gaping holes such as a possibile lack of ACLs and/or poor user account management. PCI DSS v1.1 doesn't spell out network segmentation, a basic security principal. I'm imagining that 1.2, slated for Oct release will spell it out. I'd really hope that anyone implementing something as technical as the PCI DSS would know these basic concepts. *sigh*
Posted by: Lucas 26 Jun 2008