The report – which is offered free until the end of January – also says that companies adopting PCI-DSS compliance can save up to 45% on their costs by adopting a best practice strategy.

The study, which is billed as providing year-over-year insights into the progress that affected organizations have made in achieving and sustaining compliance with PCI-DSS , found that adopting a best-in-class approach can halve a company’s compliance costs.

On top of this, the report notes that best-in-class companies can divert the PCI-DSS compliance savings into other areas, such as sustainable programs and continuous improvement.

According to the research firm, best-in-class companies were found to have reduced their deficiencies related to PCI-DSS compliance by 7.5% on a year-over-year basis, when compared to `laggards.’

The conclusions of the security analysis show how companies can reduce the scope of their PCI-DSS compliance, as well as `map and adapt’ to better security practices.

One of the most interesting conclusions of the report is the need for managers to assign clear ownership of the PCI-DSS issues and so achieve better PCI-DSS efficiencies.

Source: Infosecurity Magazine

• Card replacement costs now averaging about $4 per item
• Compliance fines now ranging from about $5,000 to $50,000
  per event for a small merchant (III, IV)
• Cost of forensic examination averaging between $25,000 and $35,000 per event for Level III and IV merchants
• Additional fines for actual fraudulent utilization of stolen PAN varies

Case Study:

• A small carp present retailer was breached. The retailer had filled out a self assessment form and attested that the information was true and correct to the acquirer.
• The merchant was found to have stored over 2,000 credit card numbers in an accounting system for “reference” and to bill clients “if they forgot there credit card number”.
• The file was accessed and the credit card numbers were stolen when during the course of a robbery the CPU was stolen. A CPP (common point of purchase) analysis of credit cards revealed the location of the theft.

Replacement Cost                 $ 5,000

Compliance Fine                   $ 12,500

Forensic Examination            $ 25,000

Card Utilization Fines $ 74,398.47

TOTAL $116,898.47

• The merchant also sustained significant reputational cost due to adverse publicity, legal fees, loss of business and other expenses.
• The merchant filed for protection under bankruptcy
• The amounts due were assessed to the ISO by the acquirer.
• Visa fined the ISO additional fees following an examination of ISO practices as it relates to PCI adoption and plan for portfolio under VBR 07508 after the initial event.
• ISO sustained a financial loss of $189,354.45

Study: Maine Bureau of Financial Institutions January 2009

Study design: Cost of TJX and Hannaford breach borne by Maine chartered banks and credit unions

TJX

52 Institutions

64,825 Accounts

$485,000 Recovery*

Hannaford

71 Institutions

243.599 Accounts

$4,500,000 Recovery*

*Recovery cost: investigation, communication, reissuance and net fraud

Study Design: Cost of compromise to 43 companies in 2008. Each company volunteered under the condition of anonymity.

Phase I – January 1, 2008

Acquirers must not board new merchants that use known vulnerable payment applications. Furthermore, VNPs and agents must not certify new applications to their platforms that are known vulnerable payment applications. A list of vulnerable payment applications is updated quarterly and is available on Visa Online at www.us.visaonline.com/us_riskmgmt/cisp.


Phase I will deter vendors from introducing new vulnerable payment applications into the payment system, and will reinforce acquirer compliance efforts by preventing merchants from migrating from one acquirer to another in an attempt to avoid upgrading a vulnerable payment application.

Phase II – July 1, 2008

VNPs and agents must only certify new payment applications to their platforms that are PABPcompliant. A list of payment applications that have been validated against Visa’s PABP is available at www.visa.com/pabp.


Phase II promotes the use of payment applications that adhere to PABP and support merchant PCI DSS compliance. This phase will also further prevent vendors from introducing new vulnerable payment applications into the payment system.

Phase III – October 1, 2008

Acquirers must only board new Level 3 and Level 4 merchants that are PCI DSS compliant or utilize PABP-compliant applications. PABP does not apply to applications developed for inhouse use only or to hardware terminals.


Phase III mitigates acquirer risk associated with boarding new merchants that are not PCI DSS compliant or that rely on payment applications that are not PABP-compliant. Further, Phase III reinforces acquirer compliance efforts by preventing merchants from migrating from one acquirer to another in an attempt to avoid compliance requirements.

Phase IV – October 1, 2009

VNPs and agents must decertify all known vulnerable payment applications, including those published on Visa’s quarterly list of vulnerable payment applications. As future vulnerable payment applications are identified, VNPs and agents must decertify these applications within 12 months.
Phase IV is intended to eliminate the continued use of vulnerable payment applications by acquirers, merchants and agents within the payment system.

Phase V – July 1, 2010

Acquirers must ensure their merchants and agents use only PABP-compliant applications. A list of payment applications that have been validated against Visa’s PABP is available at www.visa.com/pabp.


Phase V mandates the use of payment applications that support PCI DSS compliance, requiring acquirers, merchants and agents to use only those payment applications that can be validated as  PABP-compliant. It is important to note that the deadline for Phase V is aligned with the Triple Data Encryption Standard (TDES) usage mandate for all point-of-sale (POS) PIN-entry devices (PEDs) to be using TDES to protect PINs. Additionally, all attended POS PEDs must be evaluated by a Visa-recognized laboratory and approved by Visa prior to this same date.

Vulnerable Payment Applications

As a result of an increasing number of merchant compromises, Visa has identified that certain payment applications are designed to store prohibited data, including full magnetic-stripe, CVV2 or PIN data, subsequent to transaction authorization. Storage of these data elements is in violation of the PCI DSS and Visa U.S.A. Inc. Operating Regulations. Hackers are targeting merchants and agents using vulnerable payment applications and exploiting vulnerabilities to find this data. It is critical for acquirers to ensure that their merchants and agents do not use payment applications known to retain prohibited data elements and to take corrective actions to address any identified deficiencies. Acquirers, merchants and agents should ask all of their payment application vendors, resellers or system integrators to confirm that software versions used do not store magnetic-stripe, CVV2 or PIN data.


Recently, Visa alerted acquirers of an updated list of vulnerable payment applications that retain prohibited data. Visa will continue to proactively alert acquirers as vulnerable payment applications are identified. The vulnerable payment application list is available on Visa Online at www.us.visaonline.com/us_riskmgmt/cisp.

Summary

To enforce the payment application security mandates, Visa will continue to identify payment applications used by Level 1 and 2 merchants through the PCI Compliance Acceleration Program, monitor acquirers’ Level 4 merchant compliance plans and determine payment applications certified by VNPs. Visa may also consider a compromised entity’s use of vulnerable payment applications or PABP-validated applications in fine and ADCR determinations.


Visa will continue to work with all key stakeholders — acquirers, processors, merchants, agents and payment application vendors — to raise security awareness and promote the use of payment  applications validated against the PABP. In many cases, acquirers, processors and agents have indicated that they already have more aggressive plans in place to support these mandates. It is critical for acquirers and processors to begin integrating these mandates into their processes. Acquirers should also revisit their Level 4 merchant compliance plans and adjust accordingly to support these  candates. In an effort to mitigate the risk of compromise, acquirers must take prompt action to ensure that merchants and agents discontinue use of vulnerable payment applications and begin moving merchants and agents toward using only PABP-compliant applications.


For more information on Visa’s PABP, please visit http://www.visa.com/pabp. Questions about this bulletin may be directed to CISP@visa.com. For the complete VBR, Visa acquirers may refer to the Visa Business Review article, “Visa Announces New Payment Application Security Mandates,” October 2007; Issue 07100902.


© 2007 Visa Inc., all rights reserved.


CISP BULLETIN – 102307

Listed below are Visa
key dates including data security mandates and reporting deadlines.

*Note: this timeframe
applies to newly identified Level 1 and Level 2 merchants late 2007
and early 2008

**Note: this timeframe applies to newly identified Level 1 and Level
2 merchants late 2008 and early 2009

Source: http://usa.visa.com/merchants/risk_management/cisp_key_dates.html

MYTH 1: I DO NOT HAVE TO BE COMPLIANT

This is untrue. Every merchant who in any manner accepts, handles, stores or transmits credit card information must be compliant. This extends to all merchants regardless of the type of credit card environment they are in. There are no exceptions for merchants who are in the card present environment.

MYTH 2: IF I HAVE PENETRATION SCANS I AM COMPLIANT

This is untrue. Penetration scans or vulnerability scans represent a small fraction of the requirements. Having penetration scans done is important but it is not all that is required. The merchant must complete the 75 questions that make up the annual self-assessment questionnaire (SAQ).

MYTH 3: FOR THE SAQ I CAN JUST ANSWER YES TO PASS.

This is untrue. You should only answer yes if you both understand the question and have the documented evidence that the answer should be yes. Fabricating yes answers is both inappropriate and opens the merchant to severe penalties including loss of credit card privileges.

MYTH 4: NO ONE WILL EVER LOOK AT MY ANSWERS TO THE SELF-ASSESSMENT QUESTIONAIRE

This is untrue. As part of the requirements for PCI compliance each merchant must file the SAQ with his or her acquirer. If a merchant is compromised, risk rated, randomly audited or for other reasons the response to the SAQ will be examined.

MYTH 5: ALL I NEED TO DO IS TO GET MY PENETRATION SCAN COMPLETED.

This is untrue.  It is vitally important to examine the results of the penetration scans and note findings. Each abnormal finding must be addressed regardless of which of the four levels from informational to severe is listed. Severe findings must be remediate within 30 days.

MYTH 6: IF MY SOFTWARE OR TERMINAL IS COMPLIANT THAN I AM COMPLIANT.

This is untrue. Every merchant to answer the questions of the SAQ correctly and honestly must have written policies, procedures and auditable logs. There are significant physical security requirements that are required as well which must be met. Compliant software and terminals arecritical but not the entire answer.

MYTH 7: IT CAN’T HAPPEN TO ME.

This is untrue security breaches happen everywhere and can happen to anyone at anytime.

MYTH 8: ALL SECURITY BREACHES OCCUR FROM EXTERNAL SOURCES.

This is untrue over 90% of security breaches occur because of employees are others with internal access to the merchant.

MYTH 9: MY PROCESSOR IS RESPONSIBLE FOR THE FINES SO WHY SHOULD I CARE.

This is untrue. The merchant is ultimately responsible for all financial fines and penalties. This can be up to $25,000 per month per event.

MYTH 10: I CAN DO THE SAQ MYSELF

This is true but no one should. The 75 questions on the SAQ are complicated and complex to answer them requires a detailed understanding of the meaning and intent of each of the questions.

With the above said it is incumbent for the MLS and or ISO to have a detailed understanding of PCI. The fact needs to be strongly emphasized to each merchant that they must comply with the PCI. Failure to do this can lead to civil penalties, criminal prosecution and loss of credit card accepting privileges.

The payment brands have spent considerable sums attempting to educate the merchant population. A number of resources are available to assist you in helping the merchant achieve compliance. The Green Sheet has published a number of articles addressing these issues. In addition each of the payment brands have information on their web sites defining the requirements and the various categories of merchants.

We strongly recommend that each merchant obtain qualified assistance in achieving PCI DSS compliance. Knowledge of PCI and what it really takes to be compliant will help you the ISO or MLS maintain, retain and obtain merchants.

“No organization that has been completely compliant with PCI has been compromised”.
A. Bryan Sartin, Cybertrust
Chief, Forensic Investigator
May 2007

CSRSI EXPERIENCE

1. Engagements with multiple grocers
2. Not a single grocer examined was compliant with PCI DSS
3. Aware of dozens of security breaches within the industry
4. Significant misconceptions
5. Grocers are extremely vulnerable

Recent major Wall Street Journal Articles
“How Credit Card Data Went Out Wireless Door” WSJ; May 4, 2007 A1
“Retailers Whose Slips Show Too Much Attract Lawsuits” WSJ; April 28, 2007 B1
“Card Companies Crack Down on Restaurants Personal Data Protection” WSJ; March 24, 2007 A1

Articles by Ross Federgreen in Grocery Headquarters
“Electronic Payment Card Handling in the Grocery Store- An Observational Study of Risk”; in press 2007
“Security Alert”; May, 2007
“Critical Choices in eCommerce”; September, 2006
“Telltale Patterns of Change”; March, 2006

The PCI TOOLKIT is the first and only integrated system, which leads the merchant through all of the steps necessary to comply with the MANDATED Payment Card Industry Data Security Standard.

PCI DSS v 1.1 (September 2006)

PCI DSS v 1.1 is in line with the current best practice security recommendations of International Standards Code of Practice for Information Security Management (ISO 17799)

Federal Privacy and Security Data Legislation which corresponds with PCI DSS

• HIPAA (Hospital Insurance Portability and Accountability Act) of 1996 TITLE II SECURITY
• GRAHAM LEACH BLILEY ACT of 1999
• SARBANES OXLEY ACT of 2002
• FACTA (The Fair and Accurate Transaction Act) of 2003

HIPAA TITLE II SECURITY

• Administered by the Office of Civil Rights (OCR)*, HHS  *www.hhs.gov/ocr/privacy/enforcement/
• Aggressive view to pharmacy operations in grocery operations.
• 153 referrals to the Center for Medicare and Medicaid Services  (CMS) for potential violations of the HIPAA Privacy and  Security Rules
• 393 referrals to the Department of Justice (DOJ) for criminal  investigations with a significant number of convictions**  Criminal sanctions are up to ten years in jail and a $250,000 fine per event.
• LEAHY-SPECTER (S 495) PENDING “PERSONAL DATA PRIVACY and SECURITY ACT of 2007

Key Points

• SAFE HARBOR for COMPLIANCE [Title III section 301 (d)]
• Increased civil and criminal penalties for concealment of security breaches (Title I section 102)*
• Definition of sensitive personally identifiable information “A unique account identifier, electronic identification number, user name,or routing code in combination with any associated security code, access code or password that is required for an individual to obtain money, goods, services or any other thing of value” [Section 3 (11) (a) (iv)]  *Up to 5 years in prison and up to $500,000 per event

Business Case for PCI DSS Compliance

• Mandated
• Maintain positive image
• Enhance consumer confidence
• Improve bottom line
• Reduce exposure to fraud losses

LEVEL 3*

• Any merchant processing 20,000 to 1,000,000 Visa e-commerce transactions per year per MID**.

LEVEL 4*

• Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants-regardless of acceptance channel-processing up to 1,000,000 Visa transactions per year per MID**.

*Definitions July 18, 2006 PCI Security Standards Council
**MID Merchant Identification Number

LEVEL 3 AND 4 MERCHANT REQUIREMENTS

• Annual PCI Self-Assessment Questionnaire
• Quarterly Network Scan – MUST BE PERFORMED BY APPROVED SCANNING VENDOR (ASV)

COMPLIANCE DUE DATES

• LEVEL 3 Merchants JUNE 30, 2005
• LEVEL 4 MERCHANTS Acquirer*

*All major financial institutions require level 4 merchants to file the annual self assessment questionnaire and many require filing of quarterly penetration scans.
IF THERE IS A COMPROMISE ALL MERCHANTS ARE NOW SUBJECT TO NON-COMPLIANCE PENALITIES FOR FAILURE TO BE PCI COMPLIANT AT TIME OF COMPROMISE

Fines and Penalties

• Restriction on processing
• Permanent prohibition from processing
• Financial fines
• Violation of applicable federal and state laws
• Fraud losses perpetrated using the account numbers compromised
• (Ongoing financial as well as security and replacement cost)

FINANCIAL PENALTIES FOR NON-COMPLIANCE
$500,000 per incident – Compromise resulting in loss or theft of cardholder information and the merchant was found to be noncompliant at the time of the compromise.
$100,000 per incident  – Failure to immediately (24 hours) notify credit card companies of suspected or confirmed loss or theft of transaction information.

FINANCIAL PENALTIES LEVIED
VISA fined Category 1 merchants 4.6 million dollars from January 1, 2006 to September 30, 2006*.
Visa fined Category 1 merchants 3.4 million dollars from January 1, 2005 to December 31, 2005*.
System fines expected in 2007 for all merchant categories is expected to exceed 25 million dollars.
*VISA CISP BULLETIN December 12, 2006

ALL MERCHANTS SUBJECT TO NON-COMPLIANCE PENALTIES FOR FAILURE TO BE PCI COMPLIANT IF COMPROMISED!

• Do not depend upon your software vendor to provide you with the compliance that you must have.
• StoreNext®, (May 2007) “With a “PCI Isolated” POS and Connected Payments, no card data remains in the store,  removing the store from all requirements with the exception of the audit questionnaire.”

N.G.A./CSR PCI TOOLKIT

• The PCI TOOLKIT enables level II, III and IV merchants to comply with all the requirements of PCI DSS.
• The PCI TOOLKIT provide the merchant a fully integrated step-by-step solution
• The PCI TOOLKIT is fully supported by the experience and resources of CSRSI.

The PCI TOOLKIT consists of everything you need:

1. Customized Written Policies
2. Customized Written Procedures
3. Customized Written Employee Handouts
4. Training Aids
5. Detailed Assistance with the Self Assessment Questionnaire
6. Quarterly Penetration Scanning
7. Industry Specific Information
8. Detailed Glossary
9. Breach Insurance upon completion

CSRSI GUARANTEES SUCCESS:

• If you successfully complete each of the elements of the PCI TOOLKIT and you are unable to become PCI compliant CSRSI will provide you with a 100% refund.

CSRSI PROTECTS YOU:

• Once you successfully complete each of the elements of the PCI TOOLKIT you are added to a master policy held by CSRSI and underwritten by Great American Insurance Group in the amount of $25,000 with a zero dollar deductible to protect you against the costs associated with a data breach!

• The policy is a specific Compromised Data Expense Reimbursement Contractual Liability Insurance Policy*

*Please see the insurance policy declaration page for details.

SELF ASSESSMENT QUESTIONAIRE (SAQ)

• The SAQ consists of 75 questions all of which must be answered yes to pass.
• To answer the SAQ written policies, procedures, employee training aids and handouts are required.
• The SAQ must be filed with your merchant bank.
• Answering the SAQ in a false or uninformed manner will lead to civil and potential criminal penalty including the loss of credit card acceptance
• The SAQ remains on file as long as you process

Each of the 75 SAQ questions are fully explained to assist you

EXAMPLE OF SAQ QUESTION with EXPLANATION:

Requirement 7: Restrict access to data by business need-to-know.

7.1 Is access to the payment account numbers restricted for users on a need-to-know basis?

ANSWER CHECKLIST:

1. Access to cardholder data must be restricted on a job driven need to know basis.
2. Access must be restricted to the least privileges necessary to perform job function.
3. The access control system must be set to deny all access unless specific permission is granted.
4. A policy must be in place to address the issue of access to payment account numbers and information. (SEE POLICY)

Written Policies that are required by the SAQ include:

• SECURITY STANDARD POLICY
• AUDIT LOG POLICY
• SOFTWARE APPLICATION DEVELOPMENT POLICY
• PASSWORD POLICY
• INFORMATION SECURITY POLICY
• INFORMATION SECURITY TRAINING PROGRAM POLICY
• SECURITY INCIDENT RESPONSE POLICY

PASSWORD POLICY EXAMPLE
VII. Password Policy

1. Purpose
1.1. Passwords are an important aspect of computer security. They are the front line of protection for user accounts. A poorly chosen password may result in the compromise of Ubetchalife, Inc’s entire corporate network.

1.2. The purpose of this policy is to establish a standard for creation of strong passwords, the protection of those passwords, and the frequency of change.

2. Scope and Responsibility
2.1. This policy is applicable to any computer system or environment that records or stores Credit Card Primary Account Numbers (PAN’s).

2.2. The scope of this policy includes all personnel who have or are responsible for an account (or any form of access that supports or requires a password) on any system that resides at any betchalife, Inc facility, that has access to the Ubetchalife, Inc network, and stores any PAN Data.

2.3. Managers responsible for Human Resources and Information Technology are required to implement this policy via Procedure VII, ‘Password Procedure and Guideline.’

3. Policy
3.1. General

3.1.1. All system-level passwords shall be changed on at least a quarterly basis.

3.1.2. All production system level passwords shall be recorded in a password management database or log.

3.1.3. All user-level passwords shall be changed at least every six months. The recommended change interval is every four months.

3.1.4. User accounts that have system level privileges granted through group memberships or programs shall have a unique password from all other accounts held by that user.

3.1.5. Passwords shall not be inserted into email messages or other forms of electronic communication.

3.1.6. Use of vendor supplied or standard default login passwords shall be changed on new Network or Internet accounts that can access PAN data.

3.1.7. All user-level and system-level passwords shall conform to the Password Procedure and Guideline.

3.1.8. Any employee found to have violated this policy might be subject to disciplinary action, up to and including termination of employment.

4. References and Cites
4.1. Payment Card Industry Data Security Standard v1.1 Self Assessment Questionnaire Requirements; Section 8, ‘Assign a unique ID to each person with computer access.’

5. Records
5.1. Ubetchalife, Inc. Procedure VII Password Procedure and Guideline, Appendix A.

6. Definitions
6.1. Application Administration Account – Any account that is for the administration of an application (e.g., Oracle database administrator, ISSU administrator).

6.2. Strong Password – Passwords that are at least 8 Characters long and use a combination of letters and numbers or special characters eg. *^%#. An example of a strong password is: I81@joe_s.

6.3. Primary Account Number (PAN) – A primary account number is the number that is embossed on a credit card.

6.4. Production System Level Password – A password that can access administrative functions and data on a computer system that is used in the normal course of business by many users. Sometimes called an Administrative Password.

IMPORTANT POINTS

• PCI is a business issue not an IT issue.
• The bank is not responsible for PCI compliance you are.
• Greater than 90% of breaches are local— they occur everywhere.
• I can do PCI myself. As the saying goes,“Only a fool has himself for a lawyer!”
• “PCI is getting easier”. False! It is becoming much more complicated.
• “PCI compliance is too expensive.” False! PCI non compliance is expensive.

]]> http://www.pcitoolkit.com/2009/10/28/pci-is-a-business-issue/feed/ 0