BankInfoSecurity.com
HealthCareInfoSecurity.com

CLEANING CREW STEALS DOCTORS CREDIT CARD INFO STORY - http://docpay.com/pciarticle.pdf

Not PCI Compliant? Get ready for monthly fees… - http://gazebo.commonplaces.com/2009/09/not-pci-compliant-get-ready-for-monthly-fees/

Indicted Suspect Allegedly Breaks Record for Credit-Card Data Theft
http://www.cnn.com/2009/CRIME/08/17/US.computer.hacking.charges/index.html

 Big-Box Breach: The Inside Story of Wal-Mart’s Hacker Attack
http://www.wired.com/threatlevel/2009/10/walmart-hack/

 VISA Best Practices
http://corporate.visa.com/_media/best-practices.pdf

A Chronology of Data Breaches
http://www.privacyrights.org/ar/ChronDataBreaches.htm#4

Data Breach Credit Card Hackers
http://www.youtube.com/watch?v=eEnX_TzmuSk

Wireless Hack Data Breach
http://www.youtube.com/watch?v=pqCJqwkeTVo

Biggest Data Breach in History
http://www.youtube.com/watch?v=8M27V70IRGE

VeriFone addresses PCI enforcement confusion
A large part of what complicates compliance with the Payment Card Industry (PCI) standards for data, PIN entry device and payment application security is the frequent, though necessary, changing of the rules to keep up with evolving security threats.

To make things easier, the PCI Security Standards Council (PCI SSC) established specific timelines by which upgrades must be made to payment terminals. Yet, compliance is enforced by the card brands, not the PCI SSC. Furthermore, the rules can be tweaked by individual acquirers eager to ensure the compliance of their merchants and thus avoid liability for data breaches or rules violations.

Such discrepancies in the way compliance is enforced can be a source of confusion among merchants, ISOs and merchant level salespeople.

An Oct. 8, 2009, webinar put on by secure payment solutions provider VeriFone (available on VeriFone's Web site at www.verifonezone.com) addressed this and other issues relating to the PCI sunset dates and compliance generally. The webinar, hosted by Lori Breitzke, Director of Marketing for VeriFone, clarified when those sunset dates are, the differences between each one and other related issues.

Those dates
Two important sunset dates are July 2010 and December 2014, and both relate to PIN Entry Device (PED) terminals. The first date is the time by which terminals manufactured before 2004 must be swapped; the latter pertains to terminals manufactured between 2004 and 2007. Those cannot be used after 2014, but their sale has been forbidden since the end of 2007.

Meanwhile, PED terminals built after 2007 – all of which contain Triple Data Encryption Standard (DES) encryption, which is the key feature in all this – can as yet be used indefinitely.

According to Breitzke, there is "a whole lot of confusion over what the impact is" of the PCI compliance sunset dates because of some of the additional rules they have spawned. For example, Visa has required that summaries be submitted of all triple DES-compliant terminals and "attendant POS activity" by October 2009.
Visa stated further that beginning in August 2012, acquirers may be assessed fines for "fostering non-triple DES compliant merchants or agents" even though triple DES encryption won't be required of all merchants by the PCI SSC until 2014.


New fees
"We know there is one major acquirer that has come out and said they are going to be charging noncompliance fees," Breitzke said. "But we've heard that several large acquirer processors have been charging these fees, so it's really up to the ISO to communicate with the acquirer processor to figure that out.

"But I think that's going to be very likely [that acquirers in general will began levying fees for noncompliance] because the acquirer is the one that's going to be liable. So a way for them to recoup some of those costs of noncompliance or a breach would be to charge some kind of a fee."

Breitzke said that for merchants using terminals without PIN debit, there is "absolutely no compliance or security mandate to get rid of it." Nonetheless, she stressed that, for security reasons, having an updated terminal is always a good idea.

Breitzke also mentioned an omission in the PCI SSC's merchant self-assessment security questionnaire used to check various compliance points: It does not contain any questions that specifically address PED devices."We have spoken with the PCI Security Council, and they do plan to update that questionnaire," she said.


NEW requirements for securing payment applications
Recently the Payment Card Industry Security Council has transitioned payment application security procedures from the Payment Application Best Practices (PABP) to a series of requirements called the Payments Application Data Security Standards (PA DSS). These measures guide software vendors and others in developing secure payment applications that do not store prohibited data, such as full magnetic stripe, CVV2 or PIN data, and ensure their payment applications support compliance with the PCI DSS.

Summary PA DSS Requirements

• Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data.
• Protect stored cardholder data.
• Provide secure authentication features.
• Log payment application activity.
• Develop secure payment applications.
• Protect wireless transmissions.
• Test payment applications to address vulnerabilities.
• Facilitate secure network implementation.
• Cardholder data must never be stored on a server connected to the Internet.
• Facilitate secure remote software updates.
• Facilitate secure remote access to payment application.
• Encrypt sensitive traffic over public networks.
• Encrypt all non-console administrative access.
• Maintain instructional documentation and training programs for customers, resellers, and integrators.

Detailed standards and other PA DSS information are available from the PCI Security Standards Council. www.pcisecuritystandard.org

Merchant Requirements
Access, report, and validate PSI compliance

Obligations
Every merchant is assigned one of four levels based on the volume of its annual payment card activity. Merchants at each level must perform certain actions within a defined process in order to meet requirements. The definitions and obligations for each merchant level appear below:

Place Table here

Reporting
Merchants must become fully PCI compliant to prevent fines. PCI Coverage mitigates potential fines by reporting progress toward PCI compliance for Level 1, 2, and 3 merchants to MasterCard and Visa prior to each of the following dates: We will report on Level 4 merchants at our discretion.

PCI DSS Compliance Validation
To validate compliance with the PCI DSS, there are two requirements.

All merchants are required to complete:
Annual PCI DSS Self Assessment Questionnaire (SAQ) - An approved list of questions from the card associations about the security controls on a merchant's transaction network. There are four different SAQs to help scale the question set appropriately to each merchants’ environment.

Certain processing environments are also required to complete:
Quarterly Network Vulnerability Scanning - A remote scan of a merchant's transaction network (conducted by an ASV) to detect weaknesses in your external systems could be exploited by hackers or unauthorized third-parties. Merchants will receive a compliance report, created with data gathered from the questionnaire and the scan, which outlines actions required to address any vulnerabilities.

PCI Coverage merchant clients will have access to these steps for validating PCI DSS compliance through Trustwave's TrustKeeper® solution. TrustKeeper is an online compliance portal, providing access to the SAQ and vulnerability scanning for merchants approaching PCI DSS. To get started, follow these easy steps:

Please visit: https://pcicoverage.trustkeeper.net and click “Register Now”

• Complete the registration questionnaire
• Choose and complete the appropriate SAQ (TrustKeeper provides guidance on what makes sense for your environment)
• Schedule and execute vulnerability scanning

Once these steps are complete, you will receive a compliance report of your results, outlining any areas that require attention and remediation to secure your external-facing environment. Please be aware that compliance with PCI DSS is an ongoing process, not a point in time. Compliant quarterly scans and a compliant annual SAQ are required to maintain compliance.