Security Update PCI Compliance (Payment Card Industry) Jeff Uehling IBM i Security Development uehling@us.ibm.com 2012 IBM Corporation
PCI Requirements An Information only Presentation NOTE: These Slides are presented for information only! Each customer must investigate how these changes may affect their organization IBM has contacted both internal (IBM) and external PCI assessors for their interpretation of these requirements. The interpretation presented today may not reflect the views of all PCI security assessors. 2016 International Business Machines Corporation 2
PCI (Payment Card Industry) Payment Card Security Standards Council (PCI SSC) is an independent board created by major payment card brands VISA, Master Card, American Express, Discover, Japan Credit Bureau PCI SSC publishes security requirements for companies who accept, process, store or transmit credit card information. There are different requirements for: Retailers (PCI-DSS, Data Security Standard), Application Providers (PA-DSS, Payment Application) Financial (PA-PTS, Pin Transaction Security) A new requirements doc, PCI-DSS version 3.2, was published in April 2016 which will impact IBM customers 3
PCI DSS Why Security Matters The security of cardholder data affects everybody. Hackers want your cardholder data. The breach or theft of cardholder data affects the entire payment card ecosystem. Merchants and financial institutions are subject to financial liabilities. Lost confidence, so customers go to other merchants. Higher subsequent costs of compliance. Lost jobs (CISO, CIO, CEO and dependent professional positions) Termination of ability to accept payment cards https://www.pcisecuritystandards.org/pci_security/why_security_matters 4
PCI Data Security Standard PCI-DSS 3.2, 139 page.pdf containing requirements 5
PCI DSS Terminology SSL = Secure Sockets Layer (networking protocol now deemed unsecure) TLS = Transport Layer Security (networking protocol that has replaced SSL. TLS 1.0 has been deemed unsecure. TLS 1.2 is the PCI target version) PAN = Primary Account Number (credit card number) CDE = Card Holder Data Environment QSA = Qualified Security Assessor (certified assessor trained by the PCI standards Council) MFA and 2FA (Multi factor authentication, which could be more than two factors, and two factor authentication) knowledge (something you know), possession (something you have), and inherence (something you are) Encryption and Decryption (process of taking clear text data and transforming it into scrambled data and decryption reverses the process from scrambled to clear) Tokenization (is the process of substituting a sensitive data element with a nonsensitive equivalent, referred to as a token,) 6
The Requirement Changes in PCI-DSS 7
PCI DSS 3.2 Requirement: TLS1.2 TLS = Transport Layer Security the SSL (Secure Socket Layer) protocol follow-on TLS and SSL are widely used to secure data flow over a network PCI DSS 3.2 requires companies to move away from SSL (all versions) and early versions of TLS by June 2018 This requirement was originally scheduled for 6/2016 TLS 1.2 is the target usage protocol for PCI data protection All supported IBM i releases support TLS 1.2 technology Many IBM i customers are running out of support OS releases that do not support TLS 1.2 8
PCI DSS 3.2 Requirement Multi-factor Authentication PCI DSS 3.2 requires companies to secure all administrative access to the CDE (Cardholder Data Environment) using multi-factor authentication by January 2018 Multi-factor authentication can be performed Upon entry to the CDE network (recommended) Or to each CDE component Examples of multi-factor technologies include: Remote authentication and dial-in service (RADIUS) with tokens; Terminal access controller access control system (TACACS+) with tokens RSA Tokens, Biometrics, SMS, Etc. Examples of CDE components, requiring MFA, include: Servers, Firewall, IDS/IPS, Routers, Switches, Console access, Hypervisors, SAN, Tape, etc., etc., etc. For Servers, this means every client/server interface (FTP, TELNET, DRDA, ODBC, etc.) needs to support MFA 9
VISA Recommendation Network Segmentation 10
VISA Improving Security with Proper Segmentation CDE Ensure properly scoped and segmented Manage entrance & exit to/from the CDE allow only specific subnet and restrict protocols Whitelist or hybrid approach Instead of blocking or denying all threats, allow only permitted protocols and communication Principle of least privilege Provide the lowest access rights possible Zero Trust Principle Rethinking the traditional network trust https://usa.visa.com/dam/vcom/download/merchants/webinar-managing-network-segmentation.pdf 11
VISA Introduction to the Zero Trust Principle Proposed by Forrester Research Embed security into network DNA Design from the inside out with compliance in mind Inspect and log all traffic Zero Trust Verify and never trust https://usa.visa.com/dam/vcom/download/merchants/webinar-managing-network-segmentation.pdf 12
Network Segmentation The next slide is a very simple diagram of a network and is provided only to discuss segmentation as it relates to PCI 13
Network Segmentation PCI Recommendation Typical Customer Network Segmented Customer Network - limit the PCI Audit Scope Fire Wall Fire Wall Fire Wall Corporate DMZ Corporate DMZ Corporate DMZ Payment Application, Web & Email Servers CDE Payment Application Server CDE Web & Email Servers Fire Wall Fire Wall Fire Wall Corporate LAN Corporate LAN MFA Corporate LAN Power Application Server CDE Power Application Server MFA Power Application Server Power Systems Back-End DS8K DS8K CDE Power Systems Back-End MFA Required to enter CDE DS8K 14
Tokenization PCI Scope Reduction Recommendation 15
Tokenization Industry Trends Verizon 2015 PCI Compliance Report More and more organizations are adopting tokenization as a superior alternative to traditional encryption. A hosted tokenization solution, delivered as a service, provides a flexible and comprehensive solution that protects data at rest, in use and in transit. There have been significant improvements in tokenization solutions, including solutions by the card brands themselves. 16
Tokenization and PCI scope reduction Tokenization - process of replacing sensitive data with unique identification symbols that represent the PAN data without compromising its security Tokenization allows information to be reformatted in a fashion that renders it useless to outsiders. It may even replace encryption as the preferred method to protect credit card data Tokens, outside of the secure CDE, retain the Out of Scope status of the Tokenized Data Tokenization does not eliminate the need to protect the PAN data in the cardholder data vault 17
Tokenization and PCI scope reduction The following key principles relate to the use of tokenization and its relationship to PCI DSS: Tokenization solutions do not eliminate the need to maintain and validate PCI DSS compliance Tokenization may simplify a merchant s validation efforts by reducing the number of systems and components for which PCI DSS requirements apply Verifying the effectiveness of a tokenization implementation is necessary and includes confirming that only the token and not the PAN is retrievable from any system or component removed from the scope of PCI DSS 18
Tokenization vs. Encryption Encryption is a two-way reversible algorithm that transforms the PAN into cipher text Decryption reverses the cipher text back to the PAN If the encrypted PAN is compromised, the actual PAN is available to the malicious user All systems storing encrypted PAN data are in scope of PCI-DSS. Tokenization can be a one-way non-reversible value or randomly generated number associated (matched) with the PAN resulting in a alias token value If the tokenized data is compromised, only the token data is available to the malicious user Irreversible tokenized data is no longer considered to be cardholder data. 19
Examples of Token Formats PAN Associated Token Comment 3124 0059 0172 3387 7aF1Zx118523mw4cwl5x2 Token consists of alphabetic and numeric characters 4959 0059 0172 3389 729129118523184663129 Token consists of numeric characters only 5994 0059 0172 3383 599400x18523mw4cw3383 Token consists of truncated PAN (first 6, last 4 of PAN are retained) with alphabetic and numeric characters replacing middle digits. This table provides examples of token formats, but does not include all possible token formats 20
Tokenization in a Segmented Network Move Cardholder data to secure CDE network Secure communications is key QSA confirms network segmentation and CDE compliance Hosts in the Untrusted Network Stored Procedures Web Service LAN Console Hypervisor Strong Cryptography TLSv1.2 MFA* RSA Token, Radius or TACACS Server NTP, Authentication Services, Etc. CDE Card Holder Data Vault (CDV) -Encrypted- * Multi-Factor Authentication Required for Administrators PCI DSS 8.3 21
Tokenization Links PCI SSC Tokenization Docs https://www.pcisecuritystandards.org/documents/tokenization_guidelines_info_supplement.pdf https://www.pcisecuritystandards.org/documents/tokenization_product_security_guidelines.pdf https://www.pcisecuritystandards.org/documents/faqs_for_tsp_requirements_v1.pdf https://www.pcisecuritystandards.org/documents/pci_tsp_roc_reporting_template_v1.pdf Doing tokenization and cloud computing the PCI way: Rothke-Mundhenk http://www.csoonline.com/article/2985800/application-security/doing-tokenization-and-cloudcomputing-the-pci-way.html 22
Questions? 23 23
Statement of Good Security Practices: IT system security involves protecting systems and information through prevention, detection and response to improper access from within and outside your enterprise. Improper access can result in information being altered, destroyed, misappropriated or misused or can result in damage to or misuse of your systems, including for use in attacks on others. No IT system or product should be considered completely secure and no single product, service or security measure can be completely effective in preventing improper use or access. IBM systems, products and services are designed to be part of a lawful, comprehensive security approach, which will necessarily involve additional operational procedures, and may require other systems, products or services to be most effective. IBM DOES NOT WARRANT THAT ANY SYSTEMS, PRODUCTS OR SERVICES ARE IMMUNE FROM, OR WILL MAKE YOUR ENTERPRISE IMMUNE FROM, THE MALICIOUS OR ILLEGAL CONDUCT OF ANY PARTY. THANK YOU www.ibm.com/security Copyright IBM Corporation 2015. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and / or capabilities referenced in these materials may change at any time at IBM s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.