1. science
2. computer science
3. cryptography

PCI Compliance Without
Compensating Controls – How to Take
Your Mainframe Out of Scope
Ulf Mattsson
CTO Protegrity
August 8, 2011
Session 9353
Ulf Mattsson
• 20 years with IBM Software Development
• Received US Green Card ‘EB 11 – Individual of Extraordinary Ability’
endorsed by IBM Research
• Inventor of 21 Patents
• Encryption Key Management, Policy Driven Data Encryption, Distributed
Tokenization and Intrusion Prevention
• Research member of the International Federation for Information
Processing (IFIP) WG 11.3 Data and Application Security
• Created the Architecture of the Protegrity Database Security
Technology
• Received Industry's 2008 Most Valuable Performers (MVP) award
together with technology leaders from IBM, Google, Cisco, Ingres and
other leading companies
2
Session 9353
03
4
Best Source of Incident Data
“It is fascinating that the top threat events
in both 2010 and 2011 are the same
and involve external agents hacking and installing malware
to compromise the confidentiality and integrity of servers.”
Source: 2011 Data Breach Investigations Report, Verizon Business RISK team
5
Session 9353
Compromised Data Types - # Records
Payment card data
Personal information
Usernames, passwords
Intellectual property
Bank account data
Medical records
Classified information
System information
Sensitive organizational data
0
20
40
60
Source: 2011 Data Breach Investigations Report, Verizon Business RISK team and USSS
6
Session 9353
80
100
% 120
Attacks at Different System Layers
Data Entry
Authorized/
Un-authorized
Users
“The perimeter is gone – need for new security
approaches”
Application
HW Service
Contractors
Vendors
Database Admin
Database
7
SQL INJECTION
MALWARE / TROJAN
DATABASE ATTACK
File System
Storage
System Admin
B
SNIFFER ATTACK
Backup
Session 9353
FILE ATTACK
MEDIA ATTACK
0
PCI DSS - Payment Card Industry Data
Security Standard
• Applies to all organizations that hold, process, or
exchange cardholder information
• A worldwide information security standard defined by the
Payment Card Industry Security Standards Council
(formed in 2004)
• Began as five different programs:
• Visa Card Information Security Program, MasterCard Site Data
Protection, American Express Data Security Operating Policy,
Discover Information and Compliance, and the JCB Data Security
Program.
• 12 requirements for compliance, organized into six
logically related groups, which are called "control
objectives."
8
Session 9353
PCI DSS # 3, 6, 7, 10 & 12
Build and maintain a secure network.
1.
2.
Protect cardholder data.
3.
4.
Protect stored data
Encrypt transmission of cardholder data and
sensitive information across public networks
Maintain a vulnerability management
program.
5.
6.
Use and regularly update anti-virus software
Develop and maintain secure systems and
applications
Implement strong access control
measures.
7.
8.
Restrict access to data by business need-to-know
Assign a unique ID to each person with computer
access
Restrict physical access to cardholder data
9.
9
Install and maintain a firewall configuration to
protect data
Do not use vendor-supplied defaults for system
passwords and other security parameters
Regularly monitor and test networks.
10. Track and monitor all access to network resources
and cardholder data
11. Regularly test security systems and processes
Maintain an information security
policy.
12. Maintain a policy that addresses information security
Session 9353
PCI DSS #3 & 4 – Protect Cardholder Data
• 3.4 Render PAN, at minimum, unreadable anywhere it is
stored by using any of the following approaches:
•
•
•
•
One-way hashes based on strong cryptography
Truncation
Index tokens and pads (pads must be securely stored)
Strong cryptography with associated key-management processes and
procedures
• 4.1 Use strong cryptography to safeguard sensitive
cardholder data during transmission over open, public
networks.
• Comments – Cost effective compliance
• Encrypted PAN is always “in PCI scope”
• Tokens can be “out of PCI scope”
10
Session 9353
PCI DSS - Appendix B: Compensating
Controls
• Compensating controls may be considered for most PCI DSS requirements
when an entity cannot meet a requirement explicitly as stated, due to
legitimate technical or documented business constraints, but has sufficiently
mitigated the risk associated with the requirement through implementation of
other, or compensating, controls.
• Compensating controls must satisfy the following criteria:
• Meet the intent and rigor of the original PCI DSS requirement.
• Provide a similar level of defense as the original PCI DSS requirement, such that the
compensating control sufficiently offsets the risk that the original PCI DSS
requirement was designed to defend against.
• Be “above and beyond” other PCI DSS requirements. (Simply being in compliance
with other PCI DSS requirements is not a compensating control.)
11
Session 9353
PCI DSS - Network Segmentation
• Network segmentation of, or isolating (segmenting), the cardholder
data environment from the remainder of an entity’s network is not a
PCI DSS requirement.
• However, it is strongly recommended as a method that may reduce:
•
•
•
•
12
The scope of the PCI DSS assessment
The cost of the PCI DSS assessment
The cost and difficulty of implementing and maintaining PCI DSS controls
The risk to an organization (reduced by consolidating cardholder data into
fewer, more controlled locations)
Session 9353
Speed of Different Protection Methods
Transactions per second (16 digits)*
10 000 000 1 000 000 100 000 10 000 1 000 100 I
I
I
I
I
Traditional
Format
Data
AES CBC
Memory
Data
Preserving
Type
Encryption
Data
Tokenization
Encryption
Preservation
Standard
Tokenization
Encryption
*: Speed will depend on the configuration
13
Session 9353
Security of Different Protection Methods
Security Level
High -
Low -
I
I
I
I
I
Traditional
Format
Data
AES CBC
Memory
Data
Preserving
Type
Encryption
Data
Tokenization
Encryption
Preservation
Standard
Tokenization
Encryption
14
Session 9353
Speed and Security
Transactions per second (16 digits)
Security
10 000 000 Speed*
1 000 000 -
Level
High
100 000 Security
10 000 -
Low
1 000 100 I
I
I
I
I
Traditional
Format
Data
AES CBC
Memory
Data
Preserving
Type
Encryption
Data
Tokenization
Encryption
Preservation
Standard
Tokenization
*: Speed will depend on the configuration
15
Encryption
Session 9353
Different Approaches for Tokenization
• Traditional Tokenization
• Dynamic Model or Pre-Generated Model
• 5 tokens per second - 5000 tokenizations per second
• Next Generation Tokenization
• Memory-tokenization
• 200,000 - 9,000,000+ tokenizations per second
• “The tokenization scheme offers excellent security, since it is
based on fully randomized tables.” *
• “This is a fully distributed tokenization approach with no need
for synchronization and there is no risk for collisions.“ *
*: Prof. Dr. Ir. Bart Preneel, Katholieke University Leuven, Belgium
016
Session 9353
Evaluating Encryption & Tokenization Approaches
Evaluation Criteria
Area
Encryption
Database
File
Encryption
Impact
Database
Column
Encryption
Tokenization
Centralized
Tokenization
(old)
Availability
Scalability
Latency
CPU Consumption
Data Flow
Protection
Compliance Scoping
Security
Key Management
Randomness
Separation of Duties
Worst
Best
017
Session 9353
Memory
Tokenization
(new)
Evaluating Field Encryption & Distributed Tokenization
Evaluation Criteria
Strong Field
Encryption
Formatted
Encryption
Disconnected environments
Distributed environments
Performance impact when loading data
Transparent to applications
Expanded storage size
Transparent to databases schema
Long life-cycle data
Unix or Windows mixed with “big iron” (EBCDIC)
Easy re-keying of data in a data flow
High risk data
Security - compliance to PCI, NIST
Best
18
Worst
Session 9353
Memory
Tokenization
Token Flexibility for Different Categories of
Data
Type of Data
Input
Token
Comment
Token Properties
Credit Card
3872 3789 1620 3675
8278 2789 2990 2789
Numeric
Medical ID
29M2009ID
497HF390D
Alpha-Numeric
Date
10/30/1955
12/25/2034
Date
E-mail Address
[email protected]
[email protected]
Alpha Numeric, delimiters in
input preserved
SSN delimiters
075-67-2278
287-38-2567
Numeric, delimiters in input
Credit Card
3872 3789 1620 3675
8278 2789 2990 3675
Numeric, Last 4 digits exposed
Policy Masking
Credit Card
19
3872 3789 1620 3675
clear, encrypted, tokenized at rest
3872 37## #### ####
Session 9353
Presentation Mask: Expose 1st
6 digits
Some Tokenization Use Cases
• Customer 1
• Vendor lock-in: What if we want to switch payment processor?
• Performance challenge: What if we want to rotate the tokens?
• Performance challenge with initial tokenization
• Customer 2
• Reduced PCI compliance cost by 50%
• Performance challenge with initial tokenization
• End-to-end: looking to expand tokenization to all stores
• Customer 3
• Desired a single vendor
• Desired use of encryption and tokenization
• Looking to expand tokens beyond CCN to PII
• Customer 4
• Remove compensating controls on the mainframe
• Pushing tokens through to avoid compensating controls
20
Session 9353
Tokenization Use Case #2
• A leading retail chain
• 1500 locations in the U.S. market
• Simplify PCI Compliance
• 98% of Use Cases out of audit scope
• Ease of install (had 18 PCI initiatives at one time)
• Tokenization solution was implemented in 2 weeks
•
•
•
•
•
•
•
21
Reduced PCI Audit from 7 months to 3 months
No 3rd Party code modifications
Proved to be the best performance option
700,000 transactions per days
50 million card holder data records
Conversion took 90 minutes (plan was 30 days)
Next step – tokenization servers at 1500 locations
Session 9353
Case Study 1: Goal – PCI Compliance &
Application Transparency
Credit Card
Entry
Retail
Store
Central HQ Location
Applications
FTP
Applications
File
Encryption:
Windows
File
Decryption
Database
Encryption:
DB2 (zOS, iSeries),
Oracle,
SQL Server
: Encryption service
22
Session 9353
File
Encryption:
Windows,
UNIX,
Linux, zOS
Case Study 2: Goal – Addressing Advanced
Attacks & PCI DSS
Credit
Card
Entry
Retail
Store
Central HQ Location
Encryption
Application
Application
FTP
End-to-End-Encryption
(E2EE)
: Encryption service
23
Database
Encryption:
DB2,
SQL Server
Application
Session 9353
File
Encryption:
Windows,
UNIX,
zOS
Application
Encryption Topologies – Mainframe Example
DB2
1
Micro-second*
VIEW
Mainframe
(z/OS)
UDF
User Defined Function
Local
Encryption
DB2
DB2
1
Micro-second*
Key Server
CPACF (CCF)
ICSF
EDITPROC
Integrated Cryptographic
Services Facility
1
Micro-second*
EDITPROC
CP Assist for
FIELDPROC CPACF Cryptographic
Function
Remote
Encryption
DB2
VIEW
UDF
TCP/IP
1000 Micro-seconds*
: Encryption service
24
Crypto Server
Session 9353
* : 20 bytes
Column Encryption Performance - Different
Topologies
Rows Decrypted / s (100 bytes)
1 000 000 –
z/OS
Hardware
Crypto - CPACF
100 000 -
(All Operations)
10 000 –
Data Loading (Batch)
1 000 –
Queries (Data Warehouse & OLTP)
I
I
Network Attached
Local Encryption
(SW/HW)
Encryption (SW/HW)
25
Encryption
Session 9353
Topology
Evaluation of Encryption Options for
DB2 on z/OS
Encryption
Interface
Performance PCI DSS Security
API
UDF DB2 V8
UDF DB2 V9 Fieldproc
Editproc
Best
26
Worst
Session 9353
Transparency
Different Tokenization Approaches Performance
PAN Tokenization
(per second)
On-site
New Distributed
Tokenization Approach
200 000 –
(per deployed token server)
100 000 –
10 000 –
Old Centralized
On-site
Outsourced
27
1000 –
5–
Tokenization Approach
(enterprise total)
Tokenization
I
I
Old
New
Session 9353
Topology
Evaluating Different Tokenization
Solutions
Evaluation Area
Hosted/Outsourced
On-site/On-premises
Evaluating
Different
Tokenization Implementations
Area
Criteria
Central (old)
Distributed
Central (old)
Distributed
Availability
Operati
onal
Needs
Scalability
Performance
Per Server
Pricing
Model
Per Transaction
Identifiable - PII
Data
Types
Cardholder - PCI
Separation
Security
Compliance
Scope
Best
28
Session 9353
Worst
Integrated
PCI DSS - Ways to Render the PAN*
Unreadable
Two-way cryptography with associated key management
processes
One-way cryptographic hash functions
Index tokens and pads
Truncation (or masking – xxxxxx xxxxxx 6781)
* PAN: Primary Account Number (Credit Card Number)
029
Session 9353
How to not Break the Data Format
Protection Method
Hashing Binary Encryption Alpha Encoding -
!@#$%a^&*B()_+!@4#$2%p^&*
!@#$%a^&*B()_+!@
aVdSaH gF4fJh sDla
Encoding - 666666 777777 8888
Partial Encoding - 123456 777777 1234
Clear Text - 123456 123456 1234
Length and
Type Changed
Type Changed
Tokenizing
or
Formatted
Encryption
Data Field
Length
CCN / PAN
30
Session 9353
Different Security Options for Data Fields
Evaluation Criteria
Strong
Encryption
Formatted
Encryption
New Distributed
Tokenization
Disconnected environments
Distributed environments
Performance impact – data loading
Transparent to applications
Expanded storage size
Transparent to database schema
Long life-cycle data
Unix or Windows &“big iron”
Re-keying of data in a data flow
High risk data
Compliance to PCI, NIST
Best
31
Worst
Session 9353
Old Central
Tokenization
Choose Your Defenses – Positioning of
Alternatives
Database Protection
Approach
Performance
Storage
Availability
Transparency
Monitoring, Blocking,
Masking
Column Level
Formatted Encryption
Column Level Strong
Encryption
Distributed Tokenization
Central Tokenization
Database File
Encryption
Best
32
Worst
Session 9353
Security
Data Protection Challenges
• Actual protection is not the challenge
• Management of solutions
• Key management
• Security policy
• Auditing and reporting
• Minimizing impact on business operations
• Transparency
• Performance vs. security
• Minimizing the cost implications
• Maintaining compliance
• Implementation Time
33
Session 9353
Single Point of Control for Data Encryption
Applications
API
RACF
Encryption
Solution
ICSF
DB2 z/OS
Mainframe
z/OS
Hardware
Security
Files
DB2 LUW
Central Manager for:
•Encryption keys
•Security policy
•Reporting
Informix
Hardware
Security
System i
Other
: Encryption service
34
Session 9353
Data Security Management
Secure
Distribution
Policy
File System
Protector
Database
Protector
Secure
Collection
Audit
Log
Application
Protector
Enterprise
Data Security
Administrator
Tokenization
Server
Secure
Archive
Broad Platform Support
35
Session 9353
Hiding Data in Plain Sight – Data Tokenization
Data Entry
Y&SFD%))S(
Tokenization
Server
Data Token
400000 123456 7899
400000 222222 7899
Application
Databases
036
What is Encryption and Tokenization?
Used Approach
Encryption
Tokenization
Cipher System
Code System
Cryptographic algorithms
Cryptographic keys
Code books
Index tokens
Source: McGraw-HILL ENCYPLOPEDIA OF SCIENCE & TECHNOLOGY
37
Session 9353
Comments on Visa’s Tokenization Best
Practices
• Visa recommendations should have been simply to use a
random number
• You should not write your own 'home-grown' token
servers
038
Reducing the Attack Surface
123456 123456 1234
123456 123456 1234
123456 999999 1234
123456 999999 1234
123456 999999 1234
123456 999999 1234
123456 999999 1234
123456 999999 1234
Applications & Databases
: Data Token
39
Unprotected sensitive information:
Protected sensitive information
Positioning of Different Protection Options
Evaluation Criteria
Strong
Encryption
Formatted
Encryption
Security & Compliance
Total Cost of Ownership
Use of Encoded Data
Worst
Best
40
Session 9353
Data
Tokens
Why Tokenization – A Triple Play
1.
2.
3.
041
No Masking
No Encryption
No Key Management
Session 9353
Why In-memory Tokenization
1.
2.
3.
042
Better
Faster
Lower Cost / TCO
Session 9353
$