©2012 IBM Corporation

Security Update – PCI Compliance(Payment Card Industry)

Jeff Uehling

IBM i Security Development

uehling@us.ibm.com

© 2016 International Business Machines 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

2

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.

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

5

PCI Data Security Standard

PCI-DSS 3.2, 139 page .pdf containing requirements

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 non-sensitive equivalent, referred to as a token,) 6

7

The Requirement Changes in PCI-DSS

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

10

VISA Recommendation – Network 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

VISA – Improving Security with Proper Segmentation

https://usa.visa.com/dam/VCOM/download/merchants/webinar-managing-network-segmentation.pdf

11

� 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”

VISA – Introduction to the Zero Trust Principle

https://usa.visa.com/dam/VCOM/download/merchants/webinar-managing-network-segmentation.pdf

12

13

The next slide is a very simple diagram of a network and is provided only to discuss segmentation as it relates to PCI

Network Segmentation

Network Segmentation – PCI Recommendation

Typical Customer Network

Payment Application, Web & Email Servers

Corporate DMZ

Fire Wall

Power Application Server

Fire Wall

Power Systems

Back-End

Corporate LAN

DS8K

CDE

CDE

Fire Wall

Web & Email Servers

Corporate DMZ

Fire Wall

Corporate LAN

Power Application Server

Power Systems

Back-End

DS8K

Segmented Customer Network -limit the PCI Audit Scope

Payment Application Server

Corporate DMZ

Fire Wall

Corporate LAN

Power Application Server

DS8K

Fire Wall

CDE

CDE

MFA

MFA

MFA Required to enter CDE 14

15

Tokenization – PCI Scope Reduction Recommendation

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

• 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.

Tokenization vs. Encryption

19

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.

Examples of Token Formats

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

CDE

Hostsin theUntrustedNetwork Card

HolderData Vault

(CDV)

-Encrypted-

Web Service

StoredProcedures

Strong Cryptography – TLSv1.2

* Multi-Factor Authentication Required for Administrators – PCI DSS 8.3

RSA Token,

Radius orTACACSServer

MFA*

LAN

ConsoleHypervisor

NTP,

AuthenticationServices,Etc.

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-cloud-computing-the-pci-way.html

22

23

Questions?

23

© 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.

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 YOUwww.ibm.com/security