Andy s Burgers Shakes & Fries. PCI-DSS Policy

Andy s Burgers Shakes & Fries PCI-DSS Policy Reviewed May 28, 2009 Name, Title Signature

This page intentionally left blank. PCI-DSS Policy.doc Page 2 of 36

Table of Contents POLICY... 4 POLICY STATEMENT... 4 APPLICABILITY AND AVAILABILITY... 4 ADHERENCE TO STANDARDS... 5 HANDLING OF CARDHOLDER DATA... 6 ACCESS TO CARDHOLDER DATA... 7 CRITICAL EMPLOYEE-FACING TECHNOLOGIES... 8 ROLES AND RESPONSIBILITIES... 9 ANDY'S INCIDENT RESPONSE PROCEDURE... 11 INCIDENT LOG AND REPORT... 15 INCIDENT LOG... 17 INCIDENT REPORT... 18 SITE EVALUATION... 19 SITE EVALUATION LOG... 21 SITE EVALUATION SHEET... 22 LIST OF DEVICES AND AUTHORIZED EMPLOYEES... 23 PROCEDURES... 24 GENERAL BACKGROUND INFORMATION... 25 AN INTRODUCTION TO PCI DSS... 29 PCI SSC... 30 PCI DSS REQUIREMENT 6.6: WEB APPLICATION FIREWALLS AND CODE REVIEWS... 31 WEB APPLICATION FIREWALLS... 31 APPLICATION CODE REVIEWS... 31 PCI DSS REQUIREMENT 4.1: PROTECTING CARDHOLDER DATA WITH SSL AND TLS... 32 HOW SSL AND TLS WORK... 32 PCI DSS 11.3: PENETRATION TESTING REQUIREMENTS CLARIFIED... 33 RELATE NEWS ARTICLES... 34 HEARTLAND REMOVED FROM PCI COMPLIANT LIST BY VISA... 34 WHAT IT MEANS TO HEARTLAND, RBS WORLDPAY... 35 WHAT IT MEANS TO BANKING INSTITUTIONS... 35 PCI-DSS Policy.doc Page 3 of 36

May 28, 2009 Andy s Burgers Shakes & Fries Andy's PCI-DSS Policy Policy Note: Individual requirements from the PCI-DSS are denoted in parentheses. Issue Date: 5/25/2009 Reviewed: 5/28/2009 Policy Statement (12.1.1) All card processing activities and related technologies must comply with the Payment Card Industry Data Security Standard (PCI-DSS) in its entirety. Card processing activities must be conducted as described herein and in accordance with the standards and procedures listed in the Related Documents section of this Policy. No activity may be conducted nor any technology employed that might obstruct compliance with any portion of the PCI-DSS. (12.1.3) This policy shall be reviewed at least annually and updated as needed to reflect changes to business objectives or the risk environment. Applicability and Availability This policy applies to all employees. (12.1) Relevant sections of this policy apply to vendors, contractors, and business partners. The most current version of this policy is available (through the Andy's Corporate Center or at http://www.andysburgers.net/corporate/pcicompliance.html ). Policy Requirements Policy Statement Applicability and Availability Adherence to Standards Handling of Cardholder Data Access to Cardholder Data Critical Employee-facing Technologies Roles and Responsibilities Related Documents o Standards o Incident Response Plan Incident Log Site Evaluation Log o Procedures Posted in Policy PCI-DSS Policy.doc Page 4 of 36

Adherence to Standards (2.2.a) Configuration standards must be maintained for applications, network components, critical servers, and wireless access points. These standards must be consistent with industry-accepted hardening standards as defined, for example, by SysAdmin Assessment Network Security Network (SANS), National Institute of Standards Technology (NIST), and Center for Internet Security (CIS). [2.2.b should be captured in your system configuration standard; 2.2.c and 2.2.3.b should be covered in your procedure for new server set-up] Configuration standards must include: (5.2) updating of anti-virus software and definitions (6.1.b) provision for installation of all relevant new security patches within 30 days (8.5.8.b) prohibition of group and shared passwords Posted in Policy PCI-DSS Policy.doc Page 5 of 36

Handling of Cardholder Data (9.7) Distribution, maintenance, and storage of media containing cardholder data, must be controlled, including that distributed to individuals. (9.9) Procedures must include periodic media inventories in order to validate the effectiveness of these controls. (3.1) Procedures for data retention and disposal must be maintained by each department and must include the following: legal, regulatory, and business requirements for data retention, including specific requirements for retention of cardholder data provisions for disposal of data when no longer needed for legal, regulatory, or business reasons, including disposal of cardholder data coverage for all storage of cardholder data, including database servers, mainframes, transfer directories, and bulk data copy directories used to transfer data between servers, and directories used to a programmatic (automatic) process to remove, at least on a quarterly basis, stored cardholder data that exceeds business retention requirements, or, alternatively, an audit process, conducted at least on a quarterly basis, to verify that stored cardholder data does not exceed business retention requirements (9.10) destruction of media when it is no longer needed for business or legal reasons as follows: cross-cut shred, incinerate, or pulp hardcopy materials purge, degauss, shred, or otherwise destroy electronic media such that data cannot be reconstructed [If records management is a centralized function, you may choose to offload the above section to a data retention standard and/or procedure, and then reference that procedure in the policy.] (3.3) Credit card numbers must be masked when displaying cardholder data. Those with a need to see full credit card numbers must request an exception to this policy using the exception process. (4.2.b) Unencrypted Primary Account Numbers may not be sent via email Posted in Policy PCI-DSS Policy.doc Page 6 of 36

Access to Cardholder Data (7.1) Procedures for data control must be maintained by each department and must incorporate the following: Access rights to privileged User IDs are restricted to least privileges necessary to perform job responsibilities Assignment of privileges is based on individual personnel s job classification and function Requirement for an authorization form signed by management that specifies required privileges Implementation of an automated access control system Posted in Policy PCI-DSS Policy.doc Page 7 of 36

Critical Employee-Facing Technologies (12.3) For critical employee-facing technologies, departmental procedures shall require: (12.3.1) explicit management approval to use the devices (12.3.2) that all device use is authenticated with username and password or other authentication item (for example, token) (12.3.3) a list of all devices and personnel authorized to use the devices (12.3.4) labeling of devices with owner, contact information, and purpose (12.3.8) automatic disconnect of modem sessions after a specific period of inactivity (12.3.9) activation of modems used by vendors only when needed by vendors, with immediate deactivation after use Departmental usage standards shall include: (12.3.5) acceptable uses for the technology (12.3.6) acceptable network locations for the technology (12.3.7) a list of company-approved products (12.3.10) prohibition of the storage of cardholder data onto local hard drives, floppy disks, or other external media when accessing such data remotely via modem (12.3.10) prohibition of use of cut-and-paste and print functions during remote access Posted in Policy PCI-DSS Policy.doc Page 8 of 36

Roles and Responsibilities (12.5) Chief Information Officer (or equivalent) is responsible for overseeing all aspects of information security, including but not limited to: (12.5.1) creating and distributing security policies and procedures (12.5.2) monitoring and analyzing security alerts and distributing information to appropriate information security and business unit management personnel (12.5.3) (12.9) creating and distributing security incident response and escalation procedures that include: o (12.9.1) roles, responsibilities, and communication o (12.9.1) coverage and responses for all critical system components o (12.9.1) notification, at a minimum, of credit card associations and acquirers o (12.9.1) strategy for business continuity post compromise o (12.9.1) reference or inclusion of incident response procedures from card associations o (12.9.1) analysis of legal requirements for reporting compromises (i.e., per Calif. bill 1386) o (12.9.2) annual testing o (12.9.3, 12.9.5) designation of personnel to monitor for intrusion detection, intrusion prevention, and file integrity monitoring alerts on a 24/7 basis o (12.9.4) plans for periodic training o (12.9.6) a process for evolving the incident response plan according to lessons learned and in response to industry developments o (12.6; 12.6.1.a) maintaining a formal security awareness program for all employees that provides multiple methods of communicating awareness and educating employees (for example, posters, letters, meetings) o (10.6.a) review security logs at least daily and follow-up on exceptions (12.2.a) The Chief Information Office (or equivalent) shall maintain daily administrative and technical operational security procedures that are consistent with the PCI-DSS (for example, user account maintenance procedures, and log review procedures). System and Application Administrators shall: (12.5.2) monitor and analyze security alerts and information and distribute to appropriate personnel (12.5.4) administer user accounts and manage authentication (12.5.5) monitor and control all access to data (12.10.1) maintain a list of connected entities (12.10.2) perform due diligence prior to connecting an entity, with supporting documentation (12.10.3, 12.4) verify that the entity is PCI-DSS compliant, with supporting documentation (12.10.4) establish a documented procedure for connecting and disconnecting entities (10.7.a ) retain audit logs for at least one year The Human Resources Office (or equivalent) is responsible for tracking employee participation in the security awareness program, including: (12.6.1.b) facilitating participation upon hire and at least annually (12.6.2) ensuring that employees acknowledge in writing that they have read and understand the company s information security policy (12.7) screen potential employees to minimize the risk of attacks from internal sources Internal Audit (or equivalent) is responsible for executing a (12.1.2) risk assessment process that identifies threats, vulnerabilities, and results in a formal risk assessment. General Counsel (or equivalent) will ensure that for service providers with whom cardholder information is shared: (12.8.1, 12.4) contracts require adherence to PCI-DSS by the service provider (12.8.2, 12.4) contracts include acknowledgement or responsibility for the security of cardholder data by the service provider Posted in Policy PCI-DSS Policy.doc Page 9 of 36

This page intentionally left blank. PCI-DSS Policy.doc Page 10 of 36

Andy's Incident Response Procedure VISA Police Who ya gonna call? PCI-DSS Policy.doc Page 11 of 36

This page intentionally left blank. PCI-DSS Policy.doc Page 12 of 36

Effective Date: May 25, 2009 INCIDENT RESPONSE PROCEDURE 1. If you suspect a security breach, as defined in the Information Privacy and Security Policy, has occurred, you should immediately: 1) Isolate the compromised system by unplugging its network connection cable. 2) Do not shut down, reboot, access or otherwise alter the machine. 3) Contact the Chief Information Officer at (919) 635-0902 ext. 21. 2. Upon notification of a potential security breach, the Chief Information Officer ( CIO ) will: 1) Create an incident log to document all reported facts and actions taken 2) Work with the individual reporting the breach to identify the systems and type of information affected 3) Ensure that the compromised system is properly isolated from the network and that that logs and electronic evidence are preserved on a platform suitable for analysis by a court of law 4) If using a wireless network, change the Service Set Identifier ( SSID ) on the access point and other machines that may be using this connection (with the exception of any systems believed to be compromised). If additional investigation is warranted, the CIO will notify the Chief Operations Office ( COO ) of the incident. 3. The CIO will designate an employee of IDEA Technology to work with the CIO to investigate the situation and determine the nature and scope of the incident. Where appropriate, the IDEA Technology employee shall contact database and system administrators to assist in investigation efforts. CIO and the IDEA Technology employee shall review the entire network to identify all compromised or affected systems, including e-commerce, test, development and production environments as well as VPN, modem and third-party connections. A determination shall then be made as to the: 1) Type of confidential information at risk (e.g., SSAN or credit card #'s, health information) 2) Number of individuals at risk 3) Most efficient way to bypass compromised system to ensure business continuity. If financial account information is at risk, the investigating team must establish: 1) Number of accounts at risk, identifying those stored and compromised on all test, development and production systems 2) Type of account information at risk 3) Account numbers 4) Expiration dates 5) Cardholder names 6) Cardholder addresses 7) CVV2 8) Track 1 and Track 2 data 9) If any data was exported and to where. PCI forensic investigation guidelines also require investigators to establish: 1) How the compromise occurred 2) The source of the compromise 3) The timeframe of the compromise 4) That the compromise has been contained 5) That no CVV2, Track 1 or Track 2 data is stored anywhere, whether encrypted or unencrypted. The CIO must also perform a remote vulnerability scan of Andy's Corporate Internet facing site(s). PCI-DSS Policy.doc Page 13 of 36

4. After scoping the incident, the CIO will notify Legal, CEO of IDEA Technology, and the Chief Financial Officer (CFO) to provide them with an overview of the situation. If the breach involves financial account information, the ISO will promptly convene the PCI Incident Response Team, including the CFO, Directors of Internal Audit and OIT and Legal, to determine if reporting is required under PCI standards. Incident Response Team members should appoint delegates from within their area to serve in their capacity if they are unable to attend. 5. The PCI Incident Response Team will determine if a reportable incident has occurred. In accordance with Visa standards, a reportable incident is a suspected or confirmed loss or theft of any material or records that contain cardholder data. If a reportable incident has occurred, the Incident Response Team will delegate a team member to notify: 1) Visa Fraud Control Group at (650) 432-2978; and 2) Merchant bank. Contact with the Visa Fraud Control Group must be made within 24 hours of compromise! 6. If the Visa Fraud Control Group, or in the case of non-financial information, the Incident Response Team, determines that the breach warrants law enforcement involvement, the PCI Incident Response Team will delegate a member of the team to notify local police and/or the FBI and Secret Service. 7. Individual cardholders shall be notified of the breach in accordance with Visa s instructions and only after law enforcement determines that it will not compromise the investigation. 8. The Incident Response Team will draft a notification statement to be issued to those impacted by the data loss. Notification must be timely, conspicuous, and delivered in a manner that will ensure the individual receives it. Appropriate delivery methods include: U.S. Mail Email Substitute notice (appropriate only when individuals cannot be reached by mail or email) Conspicuous posting of the notice on Andy s homepage Notification to major media. The PCI Incident Response Team will determine, based on the type of data compromised, the number of individuals at risk, and the general demographics of the individuals, the most effective method of notification. If notification is to be made by press release, the PCI Incident Response Team should seek guidance from the Director of Communications prior to notification. Notification should include: A general description of the incident; Steps individuals can take to mitigate harm, including credit report monitoring and fraud alerts as well as sources of information designed to assist the public in protecting against identity theft; A reminder to remain vigilant over the next 12 to 24 months; and A customer service number individuals can call for additional information. 9. As a final step, the ISO will convene the PCI Incident Response Team to review the steps the university will take to prevent future breaches and to address any deficiencies in the Incident Response Plan. PCI-DSS Policy.doc Page 14 of 36

Incident Log and Report Incident Report Date: Who are ya: Time: What Happened? Then What? Anything Else? Who'd ya tell? PCI-DSS Policy.doc Page 15 of 36

This page intentionally left blank. PCI-DSS Policy.doc Page 16 of 36

Incident Log Date Location Issue Corrective Action Incident Log PCI-DSS Policy.doc Page 17 of 36

Incident Report Location Description of current issue: Date: Time: Unusual Activity: Corrective Action: Operator's Name: Person Contacted: Site Evaluation Performed: Yes or No Notes: System Secure Name Signature Date Incident Report PCI-DSS Policy.doc Page 18 of 36

Site Evaluation PCI-DSS Policy.doc Page 19 of 36

This page intentionally left blank. PCI-DSS Policy.doc Page 20 of 36

Site Evaluation Log Store Location Date Scheduled Date Due Notes Site Evaluation Log PCI-DSS Policy.doc Page 21 of 36

Site Evaluation Sheet Location Date Number of Registers: Register 1 Serial Number Register 2 Serial Number Other Equipment: Receipt Printer Side Terminal Switch (Check all that apply) Office Printer Router Router DSL Modem Wireless Router Fax Surveillance Camera Other: Operating System updates current? Firewall program is up to date? Antivirus is up to date? Is Wireless available? Is the Wireless secure? Wireless password: Ultra VNC Password: Yes or No Yes or No Yes or No Yes or No Yes or No Notes: changed to changed to Site Certification Scan completed? Date of last scan: Current Issues: Site Evaluated by: Signature Site Evaluation Report PCI-DSS Policy.doc Page 22 of 36

List of Devices and Authorized Employees The following represents a list of employees who have remote access to the store register systems, above the level required by store employees or managers. Locations Name User ID Password Notes All Dave Thompson CIO All Jamie Lucas IDEA Technologies All Bob Bland Total Touch All John Biba Total Touch All Vince Becker Total Touch Corporate Amy Lancaster Office Administrator Corporate Wendel Campbell Financial Services Corporate Judy Mozingo Financial Services Corporate Amber Lambert Financial Services Corporate Jaclyn Smith Financial Services The above represents explicit management approval to use the devices iaw (12.3.1) POS Terminals Receipt Printers Office Printers Side Terminals Modems Switches Routers Wireless Routers Fax Machine Corporate Employees Store Operators Waitstaff Cashiers Cooks Labeling The above represents a list of all devices and personnel authorized to use the devices iaw (12.3.3). IDEA Technologies A division of Belle Foods & Andy's Burgers Shakes & Fries (919) 635-0902 This equipment is used exclusively for the daily operations of this restaurant. No other use of this equipment is authorized. Labeling of devices iaw (12.3.4) PCI-DSS Policy.doc Page 23 of 36

Procedures What equipment do the stores have? Each location has either one or two POS terminal(s), Receipt Printer(s), office printer, Modem (DSL, cable, or Verizon wireless), some stores have a wireless router or Netgear switch. Some store use a side terminal to accept credit card transactions. How is the equipment used? To ring sales, accept credit card sales, record and monitor sales, employee hours, and produce reports. Explain how we take credit cards? Cashier/waitstaff rings up customer sale in the register, select credit, swipe the card, wait for approval, add the tip, and finalize the sale. What if we must take cards by hand? (i.e. DSL is down) Record the sale with a card slide machine. Keep all receipt with credit card information locked and secured. When Internet is back up, manually key in sale and credit card information. How do we handle securing the paperwork? Shred credit card receipt. Keep no paper copy of credit card information. Who has access to Credit Card information? We do no store credit card information anywhere. Only card number and expiration date are kept through the day and deleted upon Close Day. What do we do in the case of a security breach? Isolate the terminal from the Internet. Secure terminal from access by anyone until investigated. Who is notified? Contact Andy's CIO. What is currently in place to prevent a security breach? Andy's PCI-DSS Policy Total Touch PCI-DSS Policy PCI-DSS Policy.doc Page 24 of 36

General Background Information PCI-DSS Policy.doc Page 25 of 36

This page intentionally left blank. PCI-DSS Policy.doc Page 26 of 36

Visual representation of the credit card processing hierarchy. PCI-DSS Policy.doc Page 27 of 36

Generic set-up of Andy's restaurant register systems. PCI-DSS Policy.doc Page 28 of 36

An Introduction to PCI DSS By now, one might expect that most people even remotely involved with credit card processing would have a passing familiarity with the Payment Card Industry Data Security Standard (PCI DSS). Unfortunately, this is not the case. Many merchants (primarily Level 4) remain unaware of the obligations introduced by the card brands security programs, each of which centers on the standard. Even for those versed in PCI DSS, there are benefits to understanding its origins. The roles and responsibilities that fall to various parties, as well as the appropriate use of the instruments involved in validating compliance, are intertwined with the origins of the standard. The Inception In 1999, Visa introduced its data security program, which was formally named the Cardholder Information Security Program, or CISP. The program was intended to enhance the protection of cardholder information and detailed twelve areas of focus, known as the digital dozen: 1. Install and maintain a working firewall to protect data. 2. Keep security patches up-to-date. 3. Protect stored data. 4. Encrypt transmission of cardholder and sensitive information across public networks. 5. Use and regularly update anti-virus software or programs. 6. Restrict access to data by business need-to-know. 7. Assign a unique ID to each person with computer access. 8. Do not use vendor-supplied defaults for system passwords and other security 9. Track all access to data by unique ID 10. Regularly test security systems and processes. 11. Maintain a policy that addresses information security for employees and contractors. 12. Restrict physical access to cardholder information. Upon comparing the twelve requirements of PCI DSS, it is clear that the standard is simply the digital dozen reordered and expounded upon. Nevertheless, much like the Dude, CISP abides. That is, it is not a defunct compliance initiative: it still exists and still pertains to all Visa transactions. What has changed is that CISP now references PCI DSS as the standard to which Visa s member banks must hold their merchant clients. Implications That s an important distinction: PCI DSS does not require adherence of Visa merchants to specific behaviors and standards. Rather, CISP obligates Visa s member banks to require their merchants to adhere to the standard.* Similarly, the security programs governing the transactions of the other card brands now reference PCI DSS, including those maintained by Master Card (the Site Data Protection program or SDP), American Express (the Data Security Operating Policies or DSOP), and Discover (Discover Information Security and Compliance program or DISC).** Partnering Visa and Master Card were the first to transition from separate, differently focused standards to a common approach. That such antagonistic competitors would do so is a testament to the persuasiveness and vision of Bob Russo (currently the General Manager for the PCI Security Standards Council) and an indictment of the state of credit card security at the time. It is said that Russo, among others, convinced the associations that a unified approach to data security was in their best interest. As a result, in a move to avoid external regulation and to shore up consumer confidence, version 1.0 of the standard was published in December of 2004 with an original compliance deadline of June 30, 2005. PCI-DSS Policy.doc Page 29 of 36

PCI SSC At this time, the groundwork was laid for the Payment Card Industry Security Standard Council, LLC. By handing the standard over to a separate corporate entity, the brands insulated themselves from any appearance of collusion that might have antitrust implications. When the first update to the standard was published in September of 2006, the council (PCI SSC) officially assumed ownership and maintenance of the PCI DSS and the associated compliance validation instruments (Self Assessment Questionnaires or SAQs). In the two years since its inception, the PCI SSC has added the PIN Entry Device Standard (PED), the Payment Application Data Security Standard (PA DSS), and the certification programs for compliance assessors and scan vendors to their list of charges. They have also continued to develop the standard, with version 1.2 due out in the coming months. The associations payment brands dictate validation requirements through these programs based upon the number of transactions you conduct for their card brand. *The Payment Application Data Security Standard (PA DSS) goes one step further: the associations require member banks to require merchants to require vendors to observe PA DSS. **American Express and Discover are note card associations, and have direct contractual relationships with merchants who process their cards. PCI-DSS Policy.doc Page 30 of 36

PCI DSS Requirement 6.6: Web Application Firewalls and Code Reviews On June 30, 2008, PCI DSS requirement 6.6 takes effect, requiring that all merchants who operate public websites implement at least one of two controls: Install a web application firewall Perform application code reviews Until recently, the meaning of these requirements has been quite unclear and subject to interpretation. However, with the recent release of an information supplement, the PCI Security Standards Council clarified the requirements and laid out a clear path to compliance for merchants. Let s take a brief look at each of the two options. Web Application Firewalls The supplement defines application firewalls as security policy enforcement point(s) positioned between a web application and the client endpoint. They further go on to say that the firewall may be implemented in either software or hardware, may be a standalone appliance, a server or a component of another device. That description certainly opens a wide range of possibilities, and it s designed to do so. You can meet the intent of this requirement with any of a number of commercial and open source products. The most obvious (and most expensive!) option is to install a dedicated web application firewall, such as the Barracuda Web Site Firewall. If you re using an application proxy firewall, such as the Secure Computing Sidewinder G2 firewall, you can configure Application Defenses to monitor HTTP traffic and block malicious traffic from reaching your web servers. If you do decide to go this route, consider using the Web Application Firewall Evaluation Criteria to guide your selection process. That said, you should read the last four pages of the information supplement before going this route. They outline a long list of criteria for web application firewalls but then use weasel words to introduce them, stating that a web application firewall should be able to What does that mean? I guess we won t find out for sure until someone gets audited and has a fine assessed for not having a proper web application firewall. Application Code Reviews The alternative to purchasing a web application firewall is to conduct a code review of your Internet-facing web applications. At first glance, that might sound very daunting, until you read a line in the information supplement: The application code review option does not necessarily require a manual review of source code. In fact, there are four options presented that fully meet the requirement: 1. Manually reviewing the source code (avoid this at all costs!) 2. Proper use of automated application source code analyzer (scanning) tools (that s a possibility, if you re writing your own code and have developers willing to work with those tools) 3. Manual web application security vulnerability assessment (that s quite difficult and time-consuming) 4. Proper use of automated web application security vulnerability assessment (scanning) tools. (there s the money option!) Option 4 allows you to have a qualified security professional (an internal employee is fine, as long as it s someone who understands the proper use of the tools), perform a web application scan with the assistance of an automated tool, such as HP s WebInspect, Cenzic s HailStorm or IBM s AppScan. I ve been using WebInspect for a couple of years and have no major complaints. Personally, I m advising the merchants I work with to go the code review route and work with an automated tool. It s the more clearly defined of the two options and, given the complexity of properly configuring a web application firewall, is probably the path of least resistance. PCI-DSS Policy.doc Page 31 of 36

PCI DSS Requirement 4.1: Protecting Cardholder Data with SSL and TLS PCI DSS requirement 4.1 requires the use of secure sockets layer (SSL) or other strong cryptography to protect cardholder data while in transit over public networks. Specifically, the standard requires that: Use strong cryptography and security protocols such as secure sockets layer (SSL) / transport layer security (TLS) and Internet protocol security (IPSEC) to safeguard sensitive cardholder data during transmission over open, public networks. In this article, we take a look at what this means for you as a PCI DSS professional. We begin with an overview of how the Secure Sockets Layer (SSL) works, define an open, public network and then explore what you need to do to validate your PCI DSS compliance in this area. How SSL and TLS Work The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are similar protocols, both designed to encrypt information in transit over the Internet. They are extremely similar in functionality and, for the purposes of our discussion, may be considered equivalent. You can use SSL/TLS to secure almost any type of Internet transmission, but the most common use is to encrypt web communications using the HTTPS protocol. SSL and TLS communications begin with a handshaking process between the two communicating systems. The system initiating the connection (in the case of the web, this is the end user) contacts the server and requests an SSL/TLS connection. With that request, the user s computer sends a list of encryption algorithms that it can support. The server then analyzes that list and compares it to its own list of supported algorithms, selecting the most secure algorithm that both systems share in common. The server then notifies the client of its selection and provides the client with a digital certificate that includes the server s public key. The client then verifies the validity of the server s certificate (ensuring that the server is what it claims to be) and uses the public key contained in the certificate to encrypt a shared session key that it transmits back to the server. Now that both systems have the same session key, they use it to encrypt all of their communications from that point forward. What Is An Open, Public Network? The phrase open, public network caused much confusion in the early days of PCI DSS. Fortunately, the PCI council recently clarified their intent with the following statement: Examples of open, public networks that are in scope of the PCI DSS are the Internet, WiFi (IEEE 802.11x), global system for mobile communications (GSM) and general packet radio service (GPRS) The bottom line is that you must use SSL or TLS to encrypt communications containing cardholder data that take place over any network that doesn t belong to your organization. This includes the Internet, cell phone data networks and any other type of network outside of your control. It also includes any wireless (WiFi) network, even if it belongs to your organization. How Do I Implement SSL? To implement SSL, you need to follow several steps: 1. Obtain an SSL certificate. The cheapest way to do this is to purchase one through the Go Daddy $14.99 SSL Sale! 2. Install the certificate on your server. If you use a web hosting service, chances are that they ll be able to install this certificate for you. Otherwise, you ll need assistance from your technical staff. 3. Disable non-encrypted communications, if desired. You may wish to continue to allow unencrypted web traffic (standard HTTP) on your server if you have many pages that do not process cardholder data. If you do this, be sure that you configure the server so that pages that do process credit cards are only available over the HTTPS connection. 4. When choosing the version of SSL that you wish to implement, it s critical that you not choose a version earlier than SSL v3.0. The Navigating PCI DSS: Understanding the Intent of the Requirements document states: Note that SSL versions prior to v3.0 contain documented vulnerabilities, such as buffer overflows, that an attacker can use to gain control of the affected system. That s about all there is to it. SSL and TLS are basic technologies that enable you to secure cardholder data in transit over the Internet. They re fairly straightforward to configure and their use is clearly mandated by PCI DSS. PCI-DSS Policy.doc Page 32 of 36

PCI DSS 11.3: Penetration Testing Requirements Clarified There s a lot of talk about section 11.3 of the Payment Card Industry Data Security Standard (PCI DSS), requiring organizations to conduct penetration tests. The language in this section of the standard reads: 11.3 Perform penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment). These penetration tests must include the following: 11.3.1 Network-layer penetration tests 11.3.2 Application-layer penetration tests When the standard first came out, the vagueness of this requirement caused quite a bit of confusion among compliance professionals attempting to understand how they ll be held accountable by their merchant banks. Hearing this confusion from the industry, the PCI Council recently released an information supplement providing additional information on the penetration testing requirement. This supplement clarifies requirement 11.3 in a number of important areas. Technical Requirements PCI DSS Requirement 11.3 requires that organizations perform annual penetration tests that: Evaluate both the network and application layers Include both internal and external testing What s Included in the penetration test s scope? The scope of PCI-required penetration tests includes all systems and networks within the cardholder data environment. This is where network segmentation is key. If you ve followed the advice of PCI DSS experts and narrowly defined the scope of your cardholder data environment, you re going to be in good shape when it comes time to perform your penetration test. Who can perform the penetration test? Contrary to popular belief, you do not need to use a Qualified Security Assessor (QSA) or Approved Scanning Vendor (ASV) to perform your penetration tests. In fact, you don t even need to hire someone to perform the tests it s perfectly acceptable to use internal resources. The key is that you must use experienced penetration testers (i.e. someone who has performed penetration tests professionally in the past). Furthermore, they must be organizationally separate from those individuals managing the cardholder environment. What s the bottom line here? If your information security staff is actively invovled in the management of the cardholder network (e.g. managing the firewall, intrusion detection system, or participating in the design of the architecture), they re disqualified from performing the penetration tests. If your organization has an internal audit staff that is qualified and willing to take on the assignment, they re a great place to turn, as they naturally have the required independence. How often should penetration tests be performed? PCI DSS requires that you perform penetration tests on at least an annual basis. You also must perform tests anytime you make a significant change to the environment. The definition of significant is left up to the discretion of the individual interpreting the standard. For example, it s a safe bet that adding a user account is not a significant change, while adding a new web server would clearly merit penetration testing. This is still one of the grey areas of PCI DSS and it s always safe to err on the side of performing additional tests. PCI-DSS Policy.doc Page 33 of 36

Relate News Articles Heartland Removed from PCI compliant list by VISA March 16, 2009 Both Heartland and RBS Worldpay have been removed from the list of PCI Complaint vendors by VISA. In an article on the bankinfosecurity website it states that Heartland and RBS Worldpay are both on probation and have to recertify their PCI-DSS compliance with a QSA (Qualified Security Assessor). During the probation, they will both be able to continue to process Visa transactions. This shows that VISA is standing behind the PCI-DSS. Actions similar to this have only been taken before. The last large one was CardSystems in 2005 which ultimately went out of business. Card issuers have until May 19, 2009 to submit claims to be reimbursed for consumer fraud and other expenses sourced from the breach. Heartland Payment Systems (HPY) has been removed from Visa's list of compliant service providers, and banking institutions affected by the Heartland data breach have until May 19 to file their fraud claims with Visa. This news emerged late last week from a public statement by Visa, as well as from a letter sent by the credit card company to card-issuing banking institutions. In the statement, Visa confirmed that both Heartland and RBS WorldPay as a result of their recent data breaches, have been removed from the company's Payment Card Industry Data Security Standard (PCI DSS) Compliant Service Providers list. This list represents the service providers that Visa has validated as being PCI DSS compliant for merchants and other businesses to run their credit card transactions. Heartland is now considered to be "on probation," and can apply to be relisted once they revalidate PCI DSS compliance and meet other security stipulations. RBS has been removed from compliant service providers list and is now undergoing PCI recertification, according to an RBS spokesperson. Heartland, according to spokesperson Jason Maloni, can still process Visa transactions during this probationary period. In the letter about Heartland to banking institutions (a copy of the letter was obtained by Information Security Media Group, and its contents confirmed by recipients), Visa says: Heartland is now "in a probationary period" and subject to several risk conditions, including "more stringent security assessments, monitoring and reporting." Heartland's sponsoring banks will be assessed undisclosed fines as a result of the data breach. Card issuers can recover an unspecified portion of losses connected to the Heartland breach, but they face a May 19 deadline to file their claims with Visa. So far, neither MasterCard nor any other credit card company has issued similar statements about Heartland's status or how/if institutions can recover money losses from the breach. PCI-DSS Policy.doc Page 34 of 36

What it Means to Heartland, RBS WorldPay Visa's action comes less than two months after Heartland announced on January 20 that its payment processing network had been breached by hackers in 2008. To date more than 600 financial institutions in the U.S. and Canada, Guam, and Bermuda have come forward to say their customers' debit and credit cards were compromised as a result of the breach. RBS WorldPay, another U.S.-based payment processor, revealed last December that 1.5 million customer accounts were compromised in a breach that happened earlier in 2008. The RBS WorldPay breach was discovered after daring, wellorchestrated ATM robberies of $9 million occurred at locations around the globe on November 8. Prior to this announcement, the last large payment processor removed from the list of compliant service providers was CardSystems, observes David Taylor, Founder of the PCI Knowledge Base, an independent PCI security organization. CardSystems Solutions was a payments processor that was breached in 2005, and subsequently Visa, MasterCard and other credit card companies stopped using it as a service provider. The company that subsequently bought CardSystems went out of business in early 2008. "My first question is: While Visa still is allowing Heartland to process transactions during the probation period, what price will be inflicted upon them in terms of higher process transaction fees?" Taylor says. Visa's statement did not reveal the details of the terms of probation. Visa's statement notes that both "Heartland and RBS WorldPay are actively working on revalidation of PCI DSS compliance using a Qualified Security Assessor." Visa adds it will consider relisting both organizations following their submissions of their PCI DSS reports on compliance. Heartland Payment Systems spokesman Jason Maloni says Heartland is "cooperating fully with Visa and other card brands, and we are committed to having a safe and secure processing environment." Maloni says Heartland, which was certified as PCI DSS compliant in April 2008, "expects to continue to be assessed as PCI DSS compliant in the future." Maloni confirmed that Heartland is currently undergoing its 2009 PCI DSS assessment. "Heartland believes [the assessment] will be complete no later than May 2009 and will result in Heartland, once again, being assessed as PCI DSS compliant," says Maloni. Visa's action evoked this statement from RBS WorldPay: "RBS WorldPay received its Payment Card Industry (PCI) Report on Compliance (ROC) in June of 2008 by a qualified assessor. Visa has asked us to obtain a new certification of PCI compliance because of the recent data-security compromise. Visa has removed us from its list of approved PCI-compliant processors until the new certification is complete. Our goal is to have a new ROC by the end of April. "There have been no material system changes that would have negatively altered this certification and we have in fact enhanced the security of our systems in the interim. Because of the criminal intrusion, we need to be recertified earlier than the normal schedule." What it Means to Banking Institutions In its March 12 letter, attributed to Chief Enterprise Risk Officer Ellen Richey, Visa takes the opportunity to underscore its support for PCI DSS. "These standards continue to serve as a robust and critical foundation to protect cardholder data and, when implemented properly, have proven to be highly effective in preventing and mitigating the impact of data compromises," the letter states. "Compromise events are a reminder of the importance for all parties in the payment system to maintain ongoing vigilance when it comes to protecting cardholder data. Each stakeholder in the Visa system has a critical role in our collective fight against the criminals that perpetuate card fraud." Ever since the data breach was first announced, banking institutions have been outspoken in their outrage at once again (after the TJX and Hannaford breaches) having to replace cards and placate unhappy customers for fraud resulting from a vendor's security flaws. Visa addresses these concerns by declaring the Heartland breach eligible for the Account Data Compromise Recovery (ADCR) program, which allows issuers to recover "a portion of their losses" related to the compromised accounts. Issuers have roughly two months, until May 19th, to report any fraud losses related to Heartland. Specific recovery amounts will not be determined until after that reporting deadline. Visa's information on compromised cards and the steps to take is in Visa's "What To Do If Compromised". Page 12 of this Visa document outlines the steps for acquirer and issuers to take in the event of a security breach. Institutions should contact their regional Visa representative for information on filing their loss claims. *Heartland Data Breach: Visa Sets Deadline for Issuers to File Fraud Claims Heartland, RBS WorldPay Removed from Visa's Compliant Service Providers List March 16, 2009 - Linda McGlasson, Managing Editor PCI-DSS Policy.doc Page 35 of 36

This page intentionally left blank. PCI-DSS Policy.doc Page 36 of 36