1. Visa Cemea Account Information Security (AIS) Programme

2. Content Overview Payment Card Industry Data Security Standard (PCI DSS
Visa’s AIS Programme
Benefits of the AIS Programme
Compliance Validation Requirements and process
Security Breaches and Vulnerability Experiences
AIS Programme | January 2007

3. Overview of PCI DSS Standard

4. PCI Data Security Standard (PCI DSS)
Original published as the Visa Account Information Security Standard in 2000 and globally mandated in 2001
Growing pressure from the industry to create a single aligned global standard resulted in the alignment of standard with other payment schemes.
Payment Card Industry Data Security Standard published in Jan 2005 as the globally aligned standard supported by the payment schemes participating in the PCI initiative.
AIS Programme | January 2007

5. PCI Participants GLOBAL
This picture shows the different card associations and how they relate to PCI. It is a global standard that Visa and MasterCard have agreed on and other brands have begun accepting. This combined set of requirements, definitions, levels, and procedures is the combined effort of the card associations work to create a single standard.
AIS Programme | January 2007

6. PCI DSS Objectives
The main objective of PCI DSS is to improve the overall level of security for payments globally by:
Promoting a secure environment for cardholder data
Reducing inter-scheme redundancies and inconsistencies in requirements.
Streamlining processes and reducing expenses
Single validation to satisfy the requirements of all participating schemes.
Prior to the creation of the PCI DSS, each card association brand had their own security requirements and their merchant, service provider and member population struggled to meet the requirements of each program.
AIS Programme | January 2007

7. Elements of PCI DSS Alignment
Aligned Standards and Validation Tools
PCI Data Security Standard (DSS)
PCI Security Audit Procedures
PCI Self-Assessment Questionnaire
PCI Network Security Scan Requirements
Future Alignment
Payment Application Best Practices  PCI Payment Application Security Standard
PCI alignment focuses on ensuring a common demonstration of security and clear transparency in practices.
Standardized Security Requirements
Consistent validation requirements and protocols
Common evaluator credentials and approvals
Clear procedures for review and reassessment
Visa and MasterCard are the only two brands that have aligned their requirements but the PCI DSS is accepted by the other brands. For example, Discover has an independent data security program but will accept compliance with PCI as fulfillment in lieu their requirements.
AIS Programme | January 2007

8. PCI Security Standard Council
To manage the aligned standard, validation tools and centrally manage the process of approving security assessors, the participants of PCI formed Payment Card Industry Security Standard Council (PCI SSC) in Sept 06
PCI SSC is responsible for
Managing and maintaining the aligned standards including future updates.
Approving on-site security assessors
Approving network scan vendors
PCI SSC is a global forum
Prior to PCI SSC Visa regions were responsible for approving QSAs and Mastercard was responsible for approving scan vendors.
Any payment processing entity can be a member of the council including banks, merchants, TPP, device/application vendors
AIS Programme | January 2007

9. Overview of PCI DSS
Consists of twelve basic requirements supported by more detailed sub requirements:
Build and maintain a secure network
Requirement 1. Install and maintain a firewall configuration to protect data
Requirement 2. Do not use vendor-supplied defaults for system passwords and other security parameters
Protect cardholder data
Requirement 3. Protect stored data
Requirement 4. Encrypt transmission of cardholder data and sensitive information across public networks
Maintain a vulnerability management program
Requirement 5. Use and regularly update anti-virus software
Requirement 6. Develop and maintain secure systems and applications
Build and maintain a secure network
Firewalls are computer devices that control computer traffic allowed into a company’s network from outside, as well as traffic into more sensitive areas within a company’s internal network. All systems need to be protected from unauthorized access from the Internet, whether for e-commerce, employees’ Internet-based access via desktop browsers, or employees’ access. Often, seemingly insignificant paths to and from the Internet can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.
Hackers (external and internal to a company) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known in hacker communities and easily determined via public information.
Protect cardholder data
Encryption is the ultimate protection mechanism because even if someone breaks through all other protection mechanisms and gains access to encrypted data, they will not be able to read the data without further breaking the encryption. This is an illustration of the defense in depth principle.
Sensitive information must be encrypted during transmission over the Internet, because it is easy and common for a hacker to intercept and/or divert data while in transit.
Maintain a vulnerability management program
Many vulnerabilities and malicious viruses enter the network via employees’ activities. Anti-virus software must be used on all systems and desktops to protect systems from malicious software.
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed via vendor security patches, and all systems should have current software patches to protect against exploitation by employees, external hackers, and viruses. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.
AIS Programme | January 2007

10. Overview of PCI DSS…cont
Implement strong access control measures
Requirement 7. Restrict access to data by business need-to-know
Requirement 8. Assign a unique ID to each person with computer access
Requirement 9. Restrict physical access to cardholder data
Regularly monitor and test networks
Requirement 10. Track and monitor all access to network resources and cardholder data
Requirement 11. Regularly test security systems and processes
Maintain an information security policy
Requirement 12. Maintain a policy that addresses information security
Implement strong access control measures
This ensures critical data can only be accessed in an authorized manner and actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.
Any physical access to data or systems that house cardholder data allows the opportunity to access devices or data, and remove systems or hardcopies, and should be appropriately restricted.
Regularly monitor and test networks
Logging mechanisms and the ability to track user activities are critical. The presence of logs in all environments allows thorough tracking and analysis when something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.
Vulnerabilities are continually being discovered by hackers/researchers and introduced by new software. Systems, processes, and custom software should be tested frequently to ensure security is maintained over time and through changes.
Maintain an information security policy
A strong security policy sets the security tone for the whole company, and lets employees know what is expected of them. All employees should be aware of the sensitivity of data and their responsibilities for protecting it.
AIS Programme | January 2007

11. Storing Cardholder Data
What is allowed to be stored, transmitted, or processed?
PAN, and expiration date.
How should the PAN be protected when stored?
Encrypted, hashed, or truncated
What MUST NOT be stored post-authorization?
Full track data (Track 1 or 2)
CVV2
PIN block/ Clear PIN
AIS Programme | January 2007

12. Storing Track Data For Troubleshooting Purposes
Sometimes track data must be stored (temporarily) for troubleshooting purposes
Why? Track misreads, network errors, encryption issues, etc.
Procedures should be defined around this issue:
- Retention period
- Destruction procedure
- Limits to number cardholder data stored
AIS Programme | January 2007

13. Visa’s AIS Programme

14. Visa’s AIS Programme
Due to the different business models and legal liabilities, all participants of PCI agreed that each scheme maintain, manage and enforce its own compliance program.
In Visa PCI DSS is validated via the regional Account Information Security Programme.
The programme is known as AIS Programme in all Visa regions, except in US where it is called Cardholder Information Security Programme (CISP)
The membership structure of the various schemes were not aligned with each other. Also the business model of each scheme differed from one-another. Hence a globally aligned programme was not feasible.
AIS Programme | January 2007

15. Visa’s responsibilities
Enforce compliance via regional AIS programme
Manages communications, education, and support for Members, Merchants, and Service Providers.
Review and sign-off Report of Compliance for members, merchants and service providers.
Works with Visa Members to ensure compliance of their merchants and service providers.
The approach of reviewing and signing off ROC is not the approach all Visa regions have taken. Only VE and Cemea has adopted this approach. All other regions do a selective review or none at all. Compliance is asserted jointly by the QSA and validating entity to Visa and other schemes.
AIS Programme | January 2007

16. Member’s responsibilities
All Members must comply with the PCI Data Security Standard
Members are responsible for ensuring the compliance of their merchants, service providers and other agents who store, process, or transmit cardholder data
Ensure their merchants, service providers or other agents do not store track data post authorization.
Report any data breach to Visa and take the appropriate action to mitigate further damage to the business and the Visa brand
Undergo compliance validation as outlined within the regional AIS programme from Jan 2008
AIS Programme | January 2007

17. Benefits of the AIS Programme

18. Benefits of the AIS Programme
Limits risk associated with data compromise and fraud
Improves confidence in the payment industry
Protects reputation
Promote brand Integrity
Boost consumer confidence
Provides competitive edge
AIS Programme | January 2007

19. Compliance Validation, Requirements and process

20. Compliance Validation, Requirements and process
Merchant Levels Defined
Cemea VBV Mandate
Acquirer responsibilities
Service Provider Levels Defined
Member levels Defined
Compliance Validation Cycle
Compliance validation process
Who can validate compliance
We will talk about both merchant and service provider levels, about the current ones and those being proposed and discussed right now between Visa and MasterCard.
For compliance validation, we will talk about the required documentation for each level, the timeframes, and some recommendations for how an Acquirer can manage their merchants.
Lastly we will talk about penalties.
AIS Programme | January 2007

21. Merchant Levels Defined
Description
Validation required
Deadline 1
Any merchant regardless of acceptance channel processing over 6,000,000 Visa transactions per year. Any merchant that has suffered a hack or an attack that resulted in an account data compromise. Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimise risk to the Visa system. Any merchant identified by any other payment card brand as Level 1.
(1) Annual on-site audit
(2) Quarterly network scan
31st Dec 2006 2
Any merchant, regardless of acceptance channel, processing up to 6,000,000 Visa transactions per year.
(1) Annual self assessment questionnaire
Only merchants who have the ability to store, process or transmit data
need to be validated
Acquirers are responsible for ensuring that all of their merchants comply with the PCI Data Security Requirements, however, merchant compliance validation has been prioritized based on:
Volume of transactions
Potential risk
Exposure
Level 1 Merchant
Any merchant-regardless of acceptance channel-processing over 6,000,000 Visa transactions per year.
Any merchant that has suffered a hack or an attack that resulted in an account data compromise.
Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system.
Any merchant identified by any other payment card brand as Level 1.
Level 2 & 3 Merchants
E-commerce merchants with between 150,000-6m and 20, ,000 Visa transactions respectively.
E-commerce merchant – online, card-not-present transactions using digital communications through a public or private networks between consumer purchasing goods or services and business accepting payment. This does not include card-present transactions, even if reservations are made online or a card-present transaction is transmitted over the Internet.
Level 4 Merchants
This is all other merchants, including brick-n-mortar merchant with less than 6m Visa transactions a year. We require that all merchants are compliant, for validation for these level 4 merchants is recommended only, not required.
AIS Programme | January 2007

22. VBV Mandate
E-commerce merchants are not allowed to store data in Cemea region.
Exceptions are granted to certain type of e-commerce merchants on a case by case basis.
Acquirers need to seek approval from Visa’s senior management prior to allowing merchants to store data.
AIS Programme | January 2007

23. Acquirer responsibilities
Visa Acquirers are responsible for:
Ensuring their merchants are PCI DSS compliant
Managing merchant communications
Working with their Merchants until full compliance has been validated
Merchants are not compliant until all requirements have been met and validated.
Acquirer is responsible for providing Visa their merchants’ compliance status.
Any liability that may occur as a result of non-compliance with PCI DSS
A merchant or service provider is not considered compliant until they have competed all requirements and remediation activities and the report has been reviewed and accepted by Visa.
AIS Programme | January 2007

24. Service Provider Levels Defined
Description
Validation required
Deadline 1
All VisaNet processors (member and non-member)+ and all payment gateways*
(1) Annual on-site audit
(2) Quarterly network scan
31 Dec 2006 2
Any service provider that is not in Level 1 and stores, processes, or transmits more than 1,000,000 Visa accounts/transactions annually. 3
Any service provider that is not in Level 1 and stores, processes, or transmits fewer than 1,000,000 Visa accounts/transactions annually.
(1) Annual Self assessment Questionnaire +
Here are the proposed levels:
Due to much confusion about the payment gateway definition, and also some concern about payment gateways that are very small and have to do an onsite review, Visa is considering changes to the levels. We are also trying to align with MasterCard on these levels if we can.
AIS Programme | January 2007

25. Members responsibilities
Members must use, and are responsible for ensuring that their merchants use service providers that are PCI DSS compliant.
Visa Members are responsible for any liability that may occur as a result of non-compliance of service providers with PCI DSS
Acquirers must identify service providers handling cardholder data on their merchant’s behalf. Visa will then work with Acquirers to ensure that these service providers validate compliance with AIS
AIS Programme | January 2007

26. Members Levels Defined
Threshold
Validation Requirement 1
Members who process, store or transmit 600,000 or more transactions per year
Annual on-site validation
Quarterly vulnerability scan 2
Members who process, store or transmit 120,000 up to 600,000 transactions per year
Annual self assessment 3
Members who process, store or transmit 120,000 or less
We will talk about both merchant and service provider levels, about the current ones and those being proposed and discussed right now between Visa and MasterCard.
For compliance validation, we will talk about the required documentation for each level, the timeframes, and some recommendations for how an Acquirer can manage their merchants.
Lastly we will talk about penalties.
Compliance validation to commence on Jan 2008
AIS Programme | January 2007

27. All entities must validate compliance on an annual basis.
Validation Cycle
All entities must validate compliance on an annual basis.
Annual revalidation is required within 12 months from date of previous Report of Compliance was accepted
Quarterly scans must be performed at every three months interval.
AIS Programme | January 2007

28. Compliance Validation Process - Merchants
Acquirers are responsible for managing the compliance validation of their merchants as outlined within the merchant validation thresholds.
Where a Level 1 Merchant is identified, Acquirers must provide information regarding the Level 1 merchant to Visa.
Once the appropriate validation has been completed, the acquirer must provide Visa a Assertion Of Compliance letter indicating
Name of merchant and type of validation completed
Every requirement is met (including those met via compensating controls)
All remediation is complete and revalidated
Terminology used must reflect compliance
The PCI Security Audit Procedures were followed if an on-site review was performed.
All findings are accurate
No evidence of magnetic stripe data or CVV2 data storage
AIS Programme | January 2007

29. Compliance Validation Process – Service Providers
Service Providers are required to undertake compliance validation independently by contracting the appropriate security vendor
Once the validation is completed, the QSA and Service Providers must sign a Assertion Of Compliance letter indicating
What validation task was completed
Every requirement is marked “In Place” (including those met via compensating controls)
Terminology used must reflect compliance
All remediation is complete and revalidated
The PCI Security Audit Procedures were followed if an on-site was performed
All findings are accurate
No evidence of magnetic stripe data or CVV2 data storage
Where an on-site is performed, a copy of the Compliance
Report must be submitted to Visa for sign off prior to submitting
the letter of assertion
AIS Programme | January 2007

30. Who can validate compliance
On-site review must be performed by a PCI SSC approved Qualified Security Assessor (QSA)
Self assessment – Ideally must be performed by an internal IT auditor or a QSA to ensure impartiality and accuracy.
Vulnerability scanning must be performed by a PCI SSC approved Scan Vendor (ASV)
AIS Programme | January 2007

31. Other related requirements
PCI PIN Security Standard
Clear PIN and PIN Block must not be stored in transaction journal or logs post authorisation.
International Member Letter 14/04
Effective 1st April 2007, PAN must be truncated in cardholder copy of receipt.
Effective 1st April 2005, all newly deployed devices must have the capability to truncate PAN
AIS Programme | January 2007

32. Security Breaches and Vulnerability Experiences

33. Security Breaches Overview
Payment Card Industry Experience
Security Breaches
Hacker Focus
Impact of Data Compromises
Incident Response Procedures
AIS Programme | January 2007

34. Payment Card Industry Experience
Increased regulatory pressure to address security risk
Risk of consumer loss of confidence in brand and payment system
Globally organized criminals increasingly involved in hacks
Data compromises result in fraud losses
-With recent news of a Processor compromise, there is a heightened interest from regulators on cardholder security. For your info, fraud is at an all time low of five cents for every $100 worth of transactions. Regardless, when news of a security breach is made public, there is negative impact to the payment industry. Visa has not taken a position on a specific legislation; however, if any federal policies were to be enacted, it must be consistently applied to avoid issues.
-When an account number is hacked, it impacts everyone in the payment industry (especially the consumer). If a consumer is afraid to use their credit card, what does that do to the payment industry?
-Organized crimes are increasingly involved in these hacks and they are very good at what they do. In the next few slides, I will discuss some of those organized crime ring.
-When a hacker obtains account number and exp date only, yes, they could still perpretrate fraud; however, if they get the full track (including cvv), the fraud dollar losses increases. Because this means, somebody has been able to make a mirror-image of the credit card and use it to their advantage.
AIS Programme | January 2007

35. Security Breaches System Vulnerabilities
No segmentation and/or firewall
Un-patched systems and/or default configuration
No logging
No encryption or authentication on wireless access points
Default passwords
No intrusion monitoring
Unsecured point of sale technology
System Vulnerabilities
These are some of the most common vulnerabilities as part of forensic investigation of recent data breaches. Most of it relates to basic network configuration.
-No segmentation: Entities do not apply a layered approach to their network. Probably the biggest mistake companies make when they start processing transaction is using the same old security methods they used before. The security measures you had in place will not suffice when you start deploying application and database servers to process transactions.
-Unpatched systems and default configuration. As a security person, I am sure you would agree that patching is a critical component on a company’s security program. The challenging part for merchants is when they have a decentralized environment, like retail.
-Default configuration is another issue. Take for example a firewall configuration. On certain compromise situation, the firewall configuration was set appropriately for inbound traffic; however, we see time and time again that entities fail to address outbound traffic.
-No intrusion monitoring. There is never any kind of monitoring on the network. There’s not even any logs to help with forensic analysis. Even if logs were available, entities do not review the logs. In certain cases, we found that the compromised entity was hacked six months prior to forensic investigation.
-Unsecured point of sale technology – We could have a whole day session just talking about payment applications. Some examples of issues: Track data and PIN block retention, use of insecure protocols (file sharing, etc), use of default password to communicate (SA).
AIS Programme | January 2007

36. Hacker Focus Hackers are attacking: Hackers looking for:
Brick-and-mortar merchants
E-commerce merchants
Third-party entities in the payment system
In-house processed banks
Hackers looking for:
Software that stores sensitive cardholder data
Personal information
Corporate intellectual property
Track data and payment account numbers
Hackers are attacking retail, ecommerce and service providers in the payment system. As previously depicted, there are a lot of players when the cardholder data is transmitted in the payment system. In some cases a merchant may have 2 or 3 service provider hops before the cardholder data is ultimately processed. Imagine, all of these entities retain cardholder data and, unfortunately, we have no idea who the 2 or 3 service providers are until there is a compromise. Attacks are not limited to just e-commerce environment as hackers are also targeting brick and mortar merchants.
AIS Programme | January 2007

37. Impact of Data Compromises
Notification/disclosure
Brand/reputation
Loss of business/consumer confidence
Financial liabilities
Compromised Entity
Visa Member
Litigation
Government intervention/legislation
-Notification/disclosures –Notification to Visa may come from Members, merchants and sometimes public news. If the Member fails to notify Visa, they could be subject to penalty.
-Brand and reputation – For Visa, this is critical. A compromise of a Visa number tarnishes our brand
-Loss of consumer confidence
-Financial Liabilities – From a Visa perspective, the Member responsible for the entity is subject to Visa fines.
-Government intervention/legislation – We are bracing themselves for a possible onslaught of regulations and legislations concerning data security breach. Highly publicized data intrusion cases involving card numbers have since created a lawmaking and regulation frenzy at the state and federal levels that will likely have an impact on the payment industry in the future.
AIS Programme | January 2007

38. Incident Response Procedures
Contain and limit exposure
Understand entity’s environment
Identify how compromise occurred
Identify if full magnetic stripe data retained
Engage forensic team immediately
Action Items
Contract with qualified forensic team to determine findings
Validate full track has been removed
Bring environment into PCI DSS compliance
Members must take immediate action to investigate the incident, limit the exposure of cardholder data, notify Visa, and report investigation findings.
At Visa’s discretion, Members must engage an independent security assessor to conduct a forensic investigation.
Members are subject to fines for any merchant or service provider that is compromised and not AIS-compliant at the time of the incident.
Members may receive protection for fines for merchants or service providers that have been compromised but are found to be AISP-compliant at the time of the incident.
AIS Programme | January 2007

39. Useful contacts Standard, validation tools and approved vendors.
Information Visa Cemea’s AIS Programme
Reporting data breach
Visa Regional Risk Head
AIS Programme | January 2007