Minimize the Impact of PCI Section 3 on SAP Applications - Paymetric

Innovative Payment Card Solutions 

<strong>Minimize</strong> <strong>the</strong> <strong>Impact</strong> <strong>of</strong> <strong>PCI</strong> 

<strong>Section</strong> 3 on SAP Applications 

A New Approach to Credit Card Encryption 

© 2008 Paymetric, Inc. All rights reserved.

<strong>Minimize</strong> <strong>the</strong> <strong>Impact</strong> <strong>of</strong> <strong>PCI</strong> <strong>Section</strong> 3 

on SAP Applications 

A New Approach to Credit Card Encryption 

Contents 

Introduction .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

<strong>PCI</strong> Requirement 3: 

The Biggest Obstacle to Compliance . . . . . . . . . . . 4 

The Challenges <strong>of</strong> Encryption .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

The Mandate: Keep Cardholder Data 

Storage to a Minimum .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

A New Approach to Encryption 

Management for Heterogeneous 

SAP Environments .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

An Introduction to XiSecure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

Conclusion .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

Encryption represents one <strong>of</strong> <strong>the</strong> 

most important mandates for <strong>PCI</strong> 

compliance—and it also represents 

one <strong>of</strong> <strong>the</strong> most difficult requirements 

to implement successfully and 

cost effectively for companies that 

run SAP. This paper describes a new 

approach to managing encrypted data 

in SAP that significantly streng<strong>the</strong>ns 

an organization’s security posture, 

while minimizing <strong>the</strong> impact <strong>of</strong> <strong>PCI</strong> 

compliance on SAP. 

© 2008 Paymetric, Inc. All rights reserved. 

.

<strong>Minimize</strong> <strong>the</strong> <strong>Impact</strong> <strong>of</strong> <strong>PCI</strong> <strong>Section</strong> 3 on SAP Applications 

<strong>PCI</strong> Requirement 3: The Biggest Obstacle 

to Compliance 

With <strong>the</strong> advent <strong>of</strong> <strong>the</strong> Payment Card Industry Data Security 

Standard (<strong>PCI</strong> DSS), encrypting stored credit card numbers 

is no longer optional. Any company that stores, processes, or 

transmits credit card information—regardless <strong>of</strong> size or volume 

<strong>of</strong> transactions—must encrypt stored credit card data or face 

serious consequences for non-compliance, including fines <strong>of</strong> 

up to $500,000, <strong>the</strong> loss <strong>of</strong> brand integrity, and erosion <strong>of</strong> 

market value. 

While <strong>the</strong> <strong>PCI</strong> standard <strong>of</strong>fers broad guidance—featuring rules 

on <strong>the</strong> proper use <strong>of</strong> firewalls, computer access controls, antivirus 

s<strong>of</strong>tware, and more—it is <strong>the</strong> encryption requirements 

that are proving to be among <strong>the</strong> most difficult for organizations 

to address. According to a study conducted by Verisign Global Security Consulting Services, 

failure to address <strong>the</strong> data encryption requirements found in section 3 <strong>of</strong> <strong>PCI</strong> is <strong>the</strong> most common 

reason for failing a <strong>PCI</strong> audit: 

“Companies were most frequently non-compliant with Requirement 3 <strong>of</strong> <strong>the</strong> <strong>PCI</strong> Data Security 

Standard; 79 percent <strong>of</strong> <strong>the</strong> failed assessments did not meet 

<strong>the</strong> requirement to protect stored data (that is, <strong>the</strong>y did not 

encrypt data).” — Lessons Learned: Top Reasons for <strong>PCI</strong> Audit 

Failure and How to Avoid Them, Verisign Global Security 

Consulting Services. 

“Companies were most frequently 

non-compliant with Requirement 

3 <strong>of</strong> <strong>the</strong> <strong>PCI</strong> Data Security 

Standard; 79 percent <strong>of</strong> <strong>the</strong> 

failed assessments did not 

meet <strong>the</strong> requirement to protect 

stored data (that is, <strong>the</strong>y did not 

encrypt data).” 

Selected <strong>Section</strong> 3 Requirements 

that Centralization and Tokenization 

Helps Address 

What does requirement 3 say, and why is it so challenging? 

Titled “Protect Stored Cardholder Data”, this requirement 

focuses on all <strong>the</strong> aspects essential to ensuring that stored payment 

data remains safe. This requirement applies to essentially 

any system in which card holder data is stored, including applications, 

databases, backup tapes, and portable digital media. 

Requirement 3 includes <strong>the</strong>se mandates: 

• <strong>Minimize</strong> <strong>the</strong> amount <strong>of</strong> credit card information stored. 

• Encrypt credit card data that remains stored. 

• Protect encryption keys against both disclosure and misuse. 

• Implement sound key management processes. 

• Rotate encryption keys annually. 

Rule 

Requirement 

3.0 Encryption is a critical component <strong>of</strong> cardholder 

data protection. 

3.1 Keep cardholder data storage to a minimum. 

3.4 Render account number unreadable through… 

strong cryptography and associated key management 

3.5 Restrict access to keys to <strong>the</strong> fewest number <strong>of</strong> 

custodians necessary 

3.5.2 Store keys securely in <strong>the</strong> fewest possible locations 

and forms 

3.6 Fully document and implement all key management 

processes and procedures for keys used 

for encryption <strong>of</strong> cardholder data 

3.6.4 Periodic changing <strong>of</strong> keys…at least annually 


.

The Challenges <strong>of</strong> Encryption in SAP 

While most security pr<strong>of</strong>essional recognize <strong>the</strong> merits <strong>of</strong> 

encrypting credit card data, <strong>the</strong>y <strong>of</strong>ten struggle with <strong>the</strong> 

limitations inherent in SAP. The SAP Cryptographic Library 

(SAPCRYPTOLIB) functionality <strong>of</strong>fers a starting point for native 

encryption logic in SAP ERP. Basis Administrators can download 

<strong>the</strong> library relevant to <strong>the</strong>ir operating system and configure SAP 

to encrypt credit card data. SAP Note 766703 answers frequently 

asked questions about credit card number encryption logic in <strong>the</strong> 

SAP R/3 and SAP ERP products. O<strong>the</strong>r notes <strong>of</strong>fer similar guidance 

for o<strong>the</strong>r SAP products. However, security pr<strong>of</strong>essionals must address <strong>the</strong> encryption limitations 

in native SAP enumerated below. 

This targeted coverage in only 

four tables leaves card number 

data in o<strong>the</strong>r standard SAP 

tables and in custom tables 

unencrypted and exposed. 

• Limited Tables. Encryption functionality in SAP R/3 and SAP ERP secures payment card number 

data in only four tables: two tables related to storage <strong>of</strong> card numbers on customer master 

records, VCKUN and VCNUM; a third table related to storage <strong>of</strong> card numbers on sales orders 

and invoices, FPLTC; and a fourth table related to storage <strong>of</strong> card numbers on accounting documents, 

BSEGC. This targeted coverage in only four tables leaves card number data in o<strong>the</strong>r 

standard SAP tables and in custom tables unencrypted and exposed. 

• Limited Algorithms. Only three encryption algorithms are made available by SAP and <strong>the</strong>y may 

not meet <strong>the</strong> <strong>PCI</strong> DSS definition <strong>of</strong> strong cryptography due to <strong>the</strong> inability to verify <strong>the</strong> actual 

algorithm being utilized. 

• Limited Flexibility. SAP’s <strong>of</strong>fering supports only a s<strong>of</strong>tware-based cryptography, leaving no 

possibility to use hardware based cryptography components that are fast becoming <strong>the</strong> standard 

for <strong>the</strong>ir additional security benefits. 

• No Predefined Integration Point. For organizations interested in integration <strong>of</strong> best-<strong>of</strong>-breed 

third party encryption solutions, SAP provides no single, predefined point <strong>of</strong> integration. The 

CCNUM domain is not <strong>the</strong> only domain in which credit card numbers will be found, so multiple 

integration points will be required. 

• Downtime for Key Rotation. SAP only supports a single encryption key at a time, which is stored 

in a .pse file. This presents a significant challenge to meeting <strong>the</strong> annual key rotation requirement 

found in <strong>PCI</strong> <strong>Section</strong> 3.6.4. To rotate encryption keys, SAP must be taken <strong>of</strong>fline so each credit 

card number can be manually unencrypted with <strong>the</strong> old key and re-encrypted with <strong>the</strong> new key. 

Order-entry and billing processes must be discontinued during this time to avoid storing credit 

card numbers in clear text, or to avoid failed authorization and settlement resulting from mismatched 

keys. 


.


The Mandate: Keep Cardholder Data Storage 

to a Minimum 

The challenges presented in <strong>the</strong> prior section are significant for SAP organizations. For those that 

also store credit card numbers in o<strong>the</strong>r systems outside <strong>of</strong> SAP, <strong>the</strong> encryption challenge grows 

exponentially more imposing. 

Rule 3.1 <strong>of</strong> <strong>the</strong> <strong>PCI</strong> standard advises that organizations, “Keep 

cardholder data storage to a minimum.” To do so, organizations 

must first identify precisely where all payment data is stored. While 

this may seem simple, for many large enterprises it is anything but. 

In fact, for a large enterprise <strong>the</strong> data discovery process can take 

months <strong>of</strong> staff time to complete. 

The more repositories that 

house credit card information, 

<strong>the</strong> more points <strong>of</strong> 

exposure and <strong>the</strong> higher <strong>the</strong> 

cost <strong>of</strong> encryption and <strong>PCI</strong>. 

While rule 3.1 <strong>of</strong> <strong>PCI</strong> speaks to common sense—that is, don’t keep 

sensitive data where it’s not required—<strong>the</strong> reality for many organizations 

is that retention <strong>of</strong> credit card data in multiple locations is critical to a host <strong>of</strong> business 

processes. For most business-to-business transactions, credit card numbers are required throughout 

<strong>the</strong> entire order-to-cash process. Some retailers require <strong>the</strong> data for returns, disputes, and 

fraud protection. For <strong>the</strong>se organizations <strong>the</strong> reality is that credit card data must be stored in many 

separate and distributed systems, making <strong>the</strong> encryption requirements <strong>of</strong> <strong>PCI</strong> section 3.1 onerous 

and expensive. It’s simple, <strong>the</strong> more repositories that house credit card information, <strong>the</strong> more 

points <strong>of</strong> exposure and <strong>the</strong> higher <strong>the</strong> cost <strong>of</strong> encryption and <strong>PCI</strong>. 

But what if <strong>the</strong>re was an alternative for <strong>the</strong>se organizations? 

What if <strong>the</strong>re was a way to take 3.1 a step fur<strong>the</strong>r, 

and remove credit card numbers from all disparate 

systems, while at <strong>the</strong> same time enabling all essential 

business processes to continue as needed? Some 

organizations have done this very thing—by adopting a 

new approach to encryption management. The following 

section <strong>of</strong>fers an overview <strong>of</strong> this approach, outlining 

how it works, some <strong>of</strong> its benefits, how it compares to 

traditional encryption methods, and more. 

What if <strong>the</strong>re was a way to…remove 

credit card numbers from all disparate 

systems, while at <strong>the</strong> same time 

enabling all essential business processes 

to continue as needed? 


.

A New Approach to Encryption Management for 

Heterogeneous SAP Environments 

Today, <strong>the</strong>re’s a new approach to encryption management that <strong>of</strong>fers an array <strong>of</strong> benefits, both 

in terms <strong>of</strong> security and ease <strong>of</strong> administration. This approach focuses on using an encryption 

management server to control and manage not only encryption keys, but <strong>the</strong> underlying data. 

This approach is based on two key facets that deliver value throughout an enterprise: 

Centralization. All credit card numbers stored in 

SAP and o<strong>the</strong>r business applications and databases 

are removed from those systems and placed 

in a highly secure, centralized encryption management 

server that can be protected and monitored 

utilizing robust encryption technology. 

BEFORE 

Tokenization. Each credit card number that previously 

resided in SAP or o<strong>the</strong>r applications is replaced 

with a token that references <strong>the</strong> credit card number. 

A token can be thought <strong>of</strong> as a claim check that an 

authorized user or system can use to obtain <strong>the</strong> associated 

credit card number. In <strong>the</strong> event <strong>of</strong> a breach 

<strong>of</strong> one <strong>of</strong> <strong>the</strong> business applications or databases, only 

<strong>the</strong> tokens could be accessed, which would be <strong>of</strong> no 

value to a would-be attacker. 

Before Centralization and Tokenization 

SAP 

1 2 3 4 

Encryption and key management 

technology must be implemented 

on each system in which credit card 

numbers are stored. 

Web Store 

1 2 3 4 

Encryption 

# # # # # # # # # # # # 

#### 

# # # # Encryption 

#### 

#### #### 

Payment App 

1 2 3 4 

# # # # 


# # # # 

#### 


.

#### 


AFTER 

After Centralization and Tokenization 


1 2 3 4 1 2 3 4 


# # # # 

Web Store 

1 2 3 4 

Payment App 

Encryption and key management 

technology must only be implemented 

in a single, centralized system. 

Benefits <strong>of</strong> Centralizing and Tokenizing Data 

By implementing this encryption management server approach, companies 

can realize a range <strong>of</strong> benefits, including a reduced impact <strong>of</strong> <strong>PCI</strong> on SAP, 

improved security, optimized application integration and performance, and 

simplified administration. 

SAP no longer bears 

<strong>the</strong> full weight <strong>of</strong> <strong>PCI</strong> 

requirements. 

Reduced <strong>Impact</strong> <strong>of</strong> <strong>PCI</strong> on SAP 

By removing stored credit card information from SAP and o<strong>the</strong>r systems to a centralized server, 

<strong>the</strong> majority <strong>of</strong> focus and energy for <strong>PCI</strong> compliance will be on <strong>the</strong> centralized server. SAP no 

longer bears <strong>the</strong> full weight <strong>of</strong> <strong>PCI</strong> requirements, nor subsequent modifications that could be 

determined by a <strong>PCI</strong> audit. 

Improved Security 

By centralizing and tokenizing data, organizations gain <strong>the</strong>se security benefits: 

• <strong>Minimize</strong>d exposure <strong>of</strong> data. As mentioned above, <strong>PCI</strong> requirement 3.1 requires that 

organizations keep payment data in <strong>the</strong> minimum number <strong>of</strong> locations, and this approach 

addresses this requirement fully. Security is immediately streng<strong>the</strong>ned by minimizing <strong>the</strong> 

number <strong>of</strong> potential targets for would-be attackers. 


.

• Segregation <strong>of</strong> card data from applications. Unencrypted data never resides 

in SAP or o<strong>the</strong>r applications. SAP users never see payment data in clear text 

unless <strong>the</strong>y have specific, valid authority. 

• Reduced exposure <strong>of</strong> keys. <strong>PCI</strong> requirements 3.5.1 and 3.5.2 mandate that access 

to keys is restricted to <strong>the</strong> fewest number <strong>of</strong> custodians and that keys are stored 

securely in <strong>the</strong> fewest possible locations. By centralizing keys on a secure server, 

an encryption management server optimally addresses <strong>the</strong>se requirements. 

• <strong>Impact</strong> <strong>of</strong> breach limited. With this approach, if an attacker somehow bypasses 

both <strong>the</strong> token and encryption, <strong>the</strong>y will only have access to one card number. 

In contrast, with many encryption solutions, if an attacker gains access to one 

cryptographic key, <strong>the</strong>y can potentially decrypt thousands or even hundreds 

<strong>of</strong> thousands <strong>of</strong> records 

If an attacker 

somehow 

bypasses both 

<strong>the</strong> token and 

encryption, <strong>the</strong>y 

will have access 

to only one card 

number. 

Optimized SAP Performance and Availability 

Through employing an encryption management server, organizations can enjoy a range <strong>of</strong> 

advantages in integration and performance: 

• Improved application processing. Tokens can be passed between SAP and o<strong>the</strong>r applications 

without requiring any encryption or decryption, thus also providing encryption 

“on-<strong>the</strong>-wire” at system integration points. Fur<strong>the</strong>r, SAP is freed from having to do resourceintensive 

cryptographic processing. This can significantly streamline transactions across <strong>the</strong> 

enterprise. 

• Optimized application availability. Full key rotation can be realized without SAP downtime 

as this will occur in a separate system entirely. 

• Smart tokens. Smart tokens, tokens that feature embedded strings, can be used and can 

eliminate <strong>the</strong> need to do frequent decryption <strong>of</strong> data for reporting and related purposes. 

Simplified Administration 

Tokenization significantly eases <strong>the</strong> administrative burden <strong>of</strong> 

encryption, <strong>of</strong>fering a range <strong>of</strong> administrative advantages: 

• <strong>Minimize</strong>d compliance requirements. By removing 

payment data from disparate repositories, <strong>the</strong> cost <strong>of</strong> <strong>PCI</strong> 

is drastically reduced. Instead <strong>of</strong> implementing encryption, 

managing keys, and implementing policies on multiple 

systems, only one central server will be <strong>the</strong> focus <strong>of</strong> <strong>PCI</strong> 

encryption efforts. 

Tokens can be passed 

between SAP and o<strong>the</strong>r applications 

without requiring any 

encryption or decryption... 

• Streamlined key management. All keys and policies can be managed centrally, as opposed 

to having keys in multiple, distributed locations. This makes such <strong>PCI</strong>-required tasks as key 

revocation and rotation much faster and easier. 


.


• Centralized log management. With an encryption management server, administrators gain one centralized 

location that contains information on all decryption requests, which significantly eases compliance audits as 

well as surveillance and remediation efforts. 

How Credit Card Processing in SAP Works with an Encryption Management Server 

One <strong>of</strong> <strong>the</strong> more difficult issues with encrypting credit card data at rest is that <strong>the</strong> data must <strong>of</strong>ten be decrypted 

for standard business routines, such as recurring payments or repeat purchases. Without <strong>the</strong> proper mechanisms 

in place, this ongoing need for decryption can present a range <strong>of</strong> challenges, such as slow application response, 

<strong>the</strong> potential for unauthorized access, and complexity in application development. 

With an encryption management server, organizations can address <strong>the</strong> need for decryption while avoiding <strong>the</strong>se 

challenges. The diagram below depicts how <strong>the</strong> encryption management server would support payment processing 

in an SAP environment. 

Payment Processing with Encryption Management Server 

Request for Credit Card 

Authorization Originates in SAP 

Token Associated With that 

Credit Card Sent to SAP-certified 

Payment Processing Application 


Submits Token to Central 

Repository and Requests 

Decrypted Credit Card Number 


PAYMENT 

APPLICATION 

1 2 3 4 

Central Repository Returns 

Encrypted Number to Payment 

Application 

1 2 3 4 

Payment Application Submits 

Credit Card Number to Payment 

Processor for Authorization 


# # # # 

Authorization Returned to 


and <strong>the</strong>n to SAP 

Authorization Sent to SAP from 



10.

How an Encryption Management Server Compares with Traditional 

Encryption Approaches 

Many security pr<strong>of</strong>essionals have ei<strong>the</strong>r deployed or are familiar with such traditional approaches 

as application encryption and database encryption. How does <strong>the</strong> approach outlined on page 10 

compare to <strong>the</strong>se traditional approaches? Following is an overview <strong>of</strong> <strong>the</strong> differences, and how 

<strong>the</strong>se solutions can work in concert toge<strong>the</strong>r. 

Application Encryption 

Application encryption is an approach in which encryption and decryption 

<strong>of</strong> <strong>the</strong> data takes place within <strong>the</strong> SAP application. The data is encrypted or 

decrypted by SAP every time it is written to or retrieved from <strong>the</strong> database. 

As a result, <strong>the</strong> data residing on <strong>the</strong> database is always encrypted. 

Once an organization has employed an encryption management server, 

SAP no longer directly participates in any cryptographic operations. 

The application relies on <strong>the</strong> central token server to manage cryptographic 

operations and key management processes. This means SAP does not require 

local cryptographic technology and so is spared <strong>the</strong> management and performance 

issues associated with encryption. 

By replacing <strong>the</strong> 

card number with a 

token into <strong>the</strong> same 

SAP Database Table 

field <strong>the</strong>re is no additional 

database space 

required. 

With this approach, a central server issues a token to replace <strong>the</strong> credit card number in SAP. 

A benefit <strong>of</strong> this approach is that <strong>the</strong>re is no need to encrypt or decrypt at every step in <strong>the</strong> 

SAP workflow, but only when <strong>the</strong> unencrypted number is specifically needed, such as for 

payment processing. The token becomes a surrogate for <strong>the</strong> credit card number itself and may 

even be exchanged with o<strong>the</strong>r applications in <strong>the</strong> enterprise as if it was a real credit card number— 

without <strong>the</strong> overhead <strong>of</strong> decryption and re-encryption, or <strong>the</strong> risk <strong>of</strong> exposure. Also, by replacing 

<strong>the</strong> card number with a token into <strong>the</strong> same SAP Database Table field <strong>the</strong>re is no additional database 

space required. 

Database Encryption 

Database encryption is an approach to encrypting data at rest in which encryption 

and decryption is handled at <strong>the</strong> SAP database server level, ra<strong>the</strong>r than at <strong>the</strong> 

application level. The data to be protected is encrypted every time it passes from 

<strong>the</strong> application to <strong>the</strong> database. Likewise, as data is requested from <strong>the</strong> SAP database, 

it is decrypted before being returned to <strong>the</strong> application. The data is only in an 

encrypted state when it’s at rest in <strong>the</strong> database. Application processing happens 

independently <strong>of</strong> encryption and decryption, with all data stored unencrypted in <strong>the</strong> 

SAP’s memory. 

When an encryption management server is deployed, SAP interfaces with <strong>the</strong> 

central server as described in <strong>the</strong> previous section. The SAP database no longer 

Cryptographic 

processing is completely 

removed 

from SAP, which 

enhances performance. 


11.


requires means for cryptography and key management, with all intelligence for encryption being 

centralized within <strong>the</strong> encryption management server. Again, this centralized server interfaces with 

o<strong>the</strong>r databases and applications by issuing a token in place <strong>of</strong> <strong>the</strong> credit card number. 

This approach <strong>of</strong>fers significant benefits over traditional database encryption. First, unencrypted 

payment data is removed from <strong>the</strong> SAP application and database at all times, which boosts 

security. Second, cryptographic processing is completely removed from <strong>the</strong> SAP servers, which 

enhances application and database performance. 

Implementation Requirements 

To implement this new encryption management approach for heterogeneous 

SAP environments, an organization must deploy a single, secure 

server that will house all credit card data and will act as <strong>the</strong> central 

system for managing keys, tokens, and security policies. 

Following are <strong>the</strong> core capabilities that this centralized server 

must include: 

• SAP interface. An encryption management server must have <strong>the</strong> 

capability to extract <strong>the</strong> credit card number when it enters SAP 

in <strong>the</strong> normal business workflow and <strong>the</strong>n replace it with a token. 

This will require a custom remote function call (RFC) that 

involves a conversion exit when <strong>the</strong> credit card number is 

entered into SAP. Integration with <strong>the</strong> CCNUM domain provides access to more than 160 

standard tables, but as noted earlier more domain integrations will likely be required. Modifications 

to SAP at <strong>the</strong> code-level for this approach are usually minimal and limited to <strong>the</strong> 

RFC, with no modifications required for cryptographic functions. 

• Non-SAP interface. For most o<strong>the</strong>r applications, a Web Services interface will be required 

that functions much like <strong>the</strong> SAP RFC. 

• Token management. The encryption management server should include an application for 

issuing tokens, which should be a maximum 25-digit number to match <strong>the</strong> field length for 

credit card numbers in SAP. Where o<strong>the</strong>r data with varying lengths needs to be encrypted, 

<strong>the</strong> server should accept a source-system generated token that uses a unique identifier for 

that specific field, such as primary bank account number. 

• Manage and rotate keys. Ensure that <strong>the</strong> server can automate routine key management 

tasks and intelligently handle key rotation, or that it can be integrated with third-party 

solutions that deliver <strong>the</strong>se capabilities. 

An encryption management 

server must have <strong>the</strong> capability 

to extract <strong>the</strong> credit 

card number when it enters 

SAP in <strong>the</strong> normal business 

workflow and <strong>the</strong>n replace 

it with a token. 

• Logging. The server should track all decryption activity to provide an audit trail specifying 

who has decrypted sensitive payment data. 


12.

• Secure access. Capabilities need to be in place to ensure that only authorized staff can 

access administrative functions. 

• Performance and high availability. The server should support high volumes <strong>of</strong> encryption 

routines and token requests without impeding <strong>the</strong> performance <strong>of</strong> associated applications 

and workflow. In addition, <strong>the</strong> server should be enabled for continuous processing, even in 

<strong>the</strong> event <strong>of</strong> a server outage. 

Hurdles to Developing a Centralized Encryption Management Server 

Developing all <strong>the</strong> capabilities outlined above can present significant challenges if a security team 

seeks to build a solution in-house. Following are a few <strong>of</strong> <strong>the</strong> biggest hurdles an internal team could 

face in this endeavor: 

• Developing application interfaces. Developing a custom RFC 

for SAP and a Web Services interface for o<strong>the</strong>r applications may 

require unique expertise and consume significant resources. 

Consideration must be made for how this interface will affect 

business workflow, SAP tables, and overall application performance. 

Developing ei<strong>the</strong>r <strong>of</strong> <strong>the</strong>se 

interfaces would require 

a great deal <strong>of</strong> expertise 

in order to ensure performance 

and availability. 

• Developing token applications. Writing an application that is capable 

<strong>of</strong> issuing and managing tokens in heterogeneous environments 

and that can support multiple field-length requirements 

can be complex and challenging. Fur<strong>the</strong>r, ongoing support <strong>of</strong> this application could be time 

consuming and difficult. 

• Development time. Allocating dedicated resources to this large undertaking and covering 

for responsibilities this staff would o<strong>the</strong>rwise be fulfilling could present logistical, tactical, 

and budgetary challenges. 

• Development expertise. For many organizations, locating <strong>the</strong> in-house expertise to 

develop such complex capabilities as key management, token management, policy controls, 

and heterogeneous application integration can be very difficult. 

• Accommodating new algorithms. Over time, an organization’s security needs change, and so 

<strong>the</strong> cryptographic algorithms or encryption mechanisms in use may also change. Once initial 

development has been done, <strong>the</strong> development team may need to add capabilities for integrating 

with a new protocol or encryption solution, which may entail a substantial rewrite <strong>of</strong> 

<strong>the</strong> application in use. 

• Minimizing impact on application performance. Writing code that interfaces with multiple 

applications while minimizing <strong>the</strong> performance impact on those applications presents an 

array <strong>of</strong> challenges. 


13.


• Maintaining s<strong>of</strong>tware upgrades and updates. The overhead <strong>of</strong> maintaining and enhancing a security 

product <strong>of</strong> this complexity can ultimately represent a major resource investment and a distraction from an 

organization’s core focus and expertise. 

These challenges are significant and can severely undermine <strong>the</strong> value <strong>of</strong> an encryption management server. For 

security administrators looking to gain <strong>the</strong> benefits <strong>of</strong> centralization and tokenization, without having to develop 

and support <strong>the</strong>ir own encryption management server, Paymetric <strong>of</strong>fers an <strong>of</strong>f-<strong>the</strong>-shelf solution called XiSecure. 

An Introduction to XiSecure 

Paymetric’s XiSecure is a breakthrough encryption management 

solution for centralizing and tokenizing credit card data across an 

enterprise. XiSecure works exactly as described in this document: 

it removes credit card numbers from distributed business 

applications, replaces <strong>the</strong>m with tokens, and stores <strong>the</strong> numbers 

in a centralized, highly secure server. 

XiSecure <strong>of</strong>fers all <strong>the</strong> benefits 

discussed in this whitepaper— 

with <strong>the</strong> additional value <strong>of</strong> rapid 

time to implementation and ongoing 

maintenance and support. 

A complete solution that features integrated hardware, s<strong>of</strong>tware, 

operating system, and database, XiSecure <strong>of</strong>fers all <strong>the</strong> following critical capabilities: 

• SAP R/3 and SAP ERP interfaces 

• Token management s<strong>of</strong>tware 

• Third party encryption and key management interfaces 

• Logging and secure access features 

• Web Services interfaces 

• Encryption and key management s<strong>of</strong>tware 

• High availability features 

In short, XiSecure <strong>of</strong>fers all <strong>the</strong> benefits discussed in this whitepaper—with <strong>the</strong> additional value <strong>of</strong> rapid time to 

implementation and on-going maintenance and support. 


14.

How Does XiSecure Work? 

XiSecure removes credit 

card numbers from 

distributed business 

applications and replaces 

<strong>the</strong>m with tokens. 

The credit card numbers 

are <strong>the</strong>n stored, in a 

centralized XiSecure 

server. 

Credit card numbers are 

encrypted and managed 

within <strong>the</strong> XiSecure server. 

Key management and key 

rotation can occur within 

<strong>the</strong> XiSecure server, without 

application downtime. 

CRM 

NO CREDIT CARD 

NUMBERS REMAIN 

IN BUSINESS APPS 

ERP 


0 1 2 3 4 5 67 8 9 

WEB 

Conclusion 

Whe<strong>the</strong>r a security administrator is tasked with complying with <strong>the</strong> <strong>PCI</strong> standard, adhering to 

ano<strong>the</strong>r standard such as HIPAA or GLBA, or is simply looking to optimize <strong>the</strong> security <strong>of</strong> sensitive 

information, encryption is essential. Companies with heterogeneous SAP environments adopting 

an approach to encryption in which sensitive data is centralized and tokenized, gain significant 

benefits in terms <strong>of</strong> security, efficiency, and cost savings. Paymetric’s XiSecure represents a 

commercial product that enables organizations to quickly and easily harness <strong>the</strong> benefits <strong>of</strong> 

centralization and tokenization—and so minimize exposure, streng<strong>the</strong>n security, and dramatically 

reduce <strong>the</strong> cost <strong>of</strong> encryption. 


15.

About Paymetric 

Paymetric, Inc. provides innovative s<strong>of</strong>tware for 

managing, protecting, and integrating payment card 

transactions in enterprise systems, most notably SAP. 

The company combines proven expertise in ERP 

payment processes with powerful s<strong>of</strong>tware and 

services to improve return on card acceptance, 

optimize purchasing card 

programs, and reduce barriers to compliance. 

To learn more about our innovative 

payment card solutions, visit: 

www.paymetric.com 

Paymetric, Inc. / 13430 Northwest Freeway, Suite 900 / Houston, Texas 77040 / tel 713-895-2000 / fax 713-895-2001 / www.paymetric.com 

XS/WP/<strong>PCI</strong> COMPLIANCE WHITE PAPER SAP/1-2008 

Copyright 2008 Paymetric, Inc. All rights reserved. Paymetric, XiPay, XiPay Extensions, XiPay Cartridges, XiBuy, XiSecure, and Paymetric Solutions are ei<strong>the</strong>r registered trademarks, service marks, or trademarks <strong>of</strong> Paymetric, Inc. in 

<strong>the</strong> United States and/or o<strong>the</strong>r countries. SAP and mySAP are registered trademarks <strong>of</strong> SAP AG. All o<strong>the</strong>r trademarks appearing on this document are <strong>the</strong> property <strong>of</strong> <strong>the</strong>ir respective owners. The names <strong>of</strong> third parties and <strong>the</strong>ir 

products referred to herein may be trademarks or registered trademarks <strong>of</strong> such third parties. All information provided herein is provided “AS-IS” without any warranty.

Minimize the Impact of PCI Section 3 on SAP Applications - Paymetric

Create successful ePaper yourself

Delete template?

Save as template?