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” tableView “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 herehere

5. Self Assessment Questionnaire (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 STRATFOR Initial 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 STRATFOR Initial 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. LEVELSLevel 1Level 2Level 3Level 4 Description Any merchant - regardless of acceptance channel - processing more than 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 identified by any card association as Level 1 1 million - 6 million Visa or MasterCard transactions per year 20,000 - 1 million Visa or MasterCard e-commerce transactions per year Less than 20,000 Visa or MasterCard e-commerce transactions per year, and all other merchants processing up to 1 million Visa or MasterCards transactions per year Solutions For Level 1 merchants, our Compliance Validation Solution (CVS) is comprehensive in scope from document collection and analysis to vulnerability scanning and penetration testing to the final production of the Report on Compliance (ROC). Our PCI DSS validation for Level 1 review includes an on-site evaluation as required by PCI DSS. For Level 2 and Level 3 merchants, PCI DSS validation includes a SAQ and vulnerability scanning through our on-demand portal, TrustKeeper. In addition, Trustwave assigns a security consultant to work with a retailer after the initial questionnaire and scan are completed. For Level 4 merchants, Trustwave's TrustKeeper provides the SAQ, vulnerability scanning, if necessary, and remediation services. Sponsored programs have access to Trustwave's Security Policy Advisor, online education and help references and Security Awareness Training. Bac k STRATFOR - 12 Month Transaction Volume (2010)

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