PCI DSS

1. PCI DSS • The Payment Card Industry (PCI) Data Security Standard (DSS) was developed by the PCI Security Standards Council to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. • Applies to all entities involved in payment card processing including merchants, processors, acquirers, issuers, service providers, as well as all other entities that store, process or transmit cardholder data. • Abstract: • While the PCI DSS in its current state should be considered mature, it is by no means immutable - as technology changes and new security breaches occur, this standard can and will change. STRATFOR should keep this in mind when weighing options towards a sustainable solution. As with most “best practices” this should be considered more in the light of the “spirit of the law” than seeking out short-cuts or loop holes. • Also of note, US states are beginning to legislate PCI compliance; Texas initiated a bill in 2007 but it is unclear to us at what level of ratification it now holds.

2. PCI “Quick Take” • PCI compliance is not a federal mandate, but is considered routine, best practice and the superlative first-step to cardholder account security. State laws are beginning to mandate PCI compliance, starting with Minnesota in 2006. • Breach Consequences - Even if a company is 100% PCI compliant and validated, a breach in cardholder data may still occur. Cardholder Breaches can result in the following losses for a merchant. • $50-$90 fine per cardholder data compromised • Suspension of credit card acceptance by a merchant’s credit card account provider • Loss of reputation with customers, suppliers, and partners which effects future sales • Possible civil litigation from breached customers

3. Factors: “Level” • Payment brands define merchant levels for PCI compliance based on volume of transactions over a 12-month period. View “Levels” table • STRATFOR qualifies as a Level 3 (2000% Visa transaction growth would increase us to Level 2) • Periodic Requirements • Annual Self Assessment Questionnaire (SAQ) • Quarterly vulnerability scan • Merchant’s “processor” (Payment Planet) may require annual attestation of PCI compliance

4. Factors: “Type” • Types A through D; “A” requires the least initial and periodic curation and indicates the lowest risk factor. • STRATFOR currently uses a manual card number entry device in the form of a keypad (forces at best Type D) • STRATFOR currently collects and stores sensitive card holder data (forces at best Type C-VT) • See more info on Choosing Your Type here

5. Self AssessmentQuestionnaire (SAQ) • Informal self assessment has shown STRATFOR to fail in well over 50% of the arenas addressed. • Initial poor practice causes us to inherit additional areas of concern. • In STRATFOR’s annual attestation of compliance the SAQ must be re-assessed; by adjusting our “Type” towards “A”, our questionnaire, and thus our risks become greatly minimized.

6. Fixing STRATFORInitial Discussions • Segmenting customer service representative (CSR) offices to a separate (sub) network and following a “no wireless” policy for CSRs is advised. • Removing the manual entry hardware/keypad from the setup is advised. • Converting to a “tokenized” system is advised. [more detail on following page]

7. Fixing STRATFORInitial Discussions: Tokenization • Tokenization is the process of replacing sensitive data with unique identification string. Most merchant processors offer this service at a low cost (eg. Payment Planet ~$25/mo). • After initial acquisition, this “token” is passed to the credit card merchant processor (eg. Payment Planet) instead of sensitive data; the merchant processor is considered PCI compliant and is held to the highest standards and requirements. • In the unlikely case of a cardholder data breach, the merchant processor will be the offending party as only they hold the customer data in their “vault”. • All existing data can be converted/back-populated into “token” data in a secure batch procedure to initiate this policy.

8. Expired - these are “modified” prior to initial batch run • AmEx Soft Decline - these are re-entered via the hardware terminal keypad • Soft Decline/N7 - these types are manually handled through the IPAY Portal tools • Unfixable - these are due to insufficient funds, invalid account or credit car number does not exist based on estimated data

9. END

10. STRATFOR - 12 Month Transaction Volume (2010) Back

11. Choosing Your PCI DSS SAQ • SAQ A: Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants. • SAQ B: Imprint-only merchants with no electronic cardholder data storage, or standalone, dial-out terminal merchants with no electronic cardholder data storage. • SAQ C-VT: Merchants using only web-based virtual terminals, no electronic cardholder data storage. • SAQ C: Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. • SAQ D: All other merchants not included in descriptions for SAQ types A through C above, and all service providers defined by a payment brand as eligible to complete an SAQ. Back