Home > IT Answers > AS/400 > PCI Compliance in an iSeries Network Environm...
Pmirchin
5 pts.
0
Q:
PCI Compliance in an iSeries Network Environment - Request for advice and direction
iSeries, Compliance, WebSphere Commerce, PCI
We’re trying to comply with the Payment Card Industry’s PCI DSS requirements. We have a home-grown ERP system running on an IBM iSeries computer that stores and processes credit cards taken over the phone and by mail. We also have a website hosted on another iSeries computer. The site uses a Websphere Commerce v. 6 application to accept and process credit cards. The Websphere Commerce application feeds information about credit card transactions to the back-end ERP system.

There’s lots of information out there about how to achieve compliance but none of it is clear and much of it is contradictory. The result, for us, is paralyzing confusion. But we really want to comply and we intend to take action. It’s just that we’d prefer have a direction to move in rather than dashing off madly in all directions at once.

We’d love to hear from anyone who works with a similar environment and who has achieved the holy grail of PCI compliance, or who is trying to comply, or who has even thought about it. Independent consultants with real expertise in this area would be welcome as would other IT departments engaged in the same struggle.

Any and all advice will be greatly appreciated.
ASKED: Aug 22 2008  12:43 AM GMT
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
RELATED QUESTIONS
0
Metallimirk
15 pts.
0
A:
 RATE THIS ANSWER
0
Click to Vote:
  •   0
  •  0
  • AddThis Social Bookmark Button
Hi,
This is strange, I am going thru the same thing myself... making our proprietary ERP system PCI compliant. I'll share what I have for you so far.

Here is a website that was provided to merchants late last year regarding PCI compliance. It is a survey to determine if your business is PCI compliant and also offers a link to the services of Trustwave which is a company you pay to make sure your company is PCI compliant. They will do testing on your systems and investigate your internal operations to be sure the paperwork you keep on hand is secure.

http://www.pcisecuritystandards.org/saq/index.shtml

Here's also a Q&A I found on PCI compliance on the internet as well. Just in case you want to check it out as well.

http://www.pcisecuritystandards.org/saq/index.shtml

In addition, there is some encryption software that is available thru a company called Patrick Townsend. My contact is a woman named Sharon. I havent called her yet, but will in the very near future, if we work together, we might get a bundle deal to save some money. Contact information is below:
Patrick Townsend & Assoc.
Ph: 847.478.8910

Thanks!
Metallimirk

P.S. Let me know if you want to discuss direct, I am willing to share my experiences as I go thru this process.
Last Answered: Aug 27 2008  3:17 AM GMT by Metallimirk   15 pts.
  •   
0
0
RSS - Discussions Help
Discuss This Answer:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _



_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

DanTheMan 2   395 pts.  |   Aug 27 2008  2:51PM GMT

Hi guy’s

I’ve been working on a PCI project last year and basically, here are the main lines we use to determine the requirements:

PCI compliment is based on the following sentences:
- Need to have;
- Need to know.

Wherever you store personnal card informations, either you have to encrypt or hash the informations. By the way, when I say “wherever” I mean “wherever”:
- Data files
- Communications between system (even internally)
- Backup (physical or not)
- Even within applications
- …

We then establish a simple rule to determine if the informations hve to be encrypt or hash:
- If we are positivelly sure that we’ll never have to retrieve the personnal card informations then it is hashed, otherwise the PC info is encrypt.

Then, we decide to use a combination of public and private encryption keys:
- If the PC info is incomming or outgoing from/to a third party such as VISA public keys are used
- If th PC info is for internal use, we use a combination of public and private keys.

Encryption key management is driven by 2 individuals who are owner’s of their part of securized access and can’t individually figure the other part of the key meaning that it is mandatory to have both individual action to manage the key’s. Informations about those access are well documented and place in a sealed envelop and places in safe hands.

The big challenge is to find all places in your company where you stored or manipulate PC informations. To do so, we start at the source (POS) and track the PCI up to the end of all processes dealing with the PCI.

Good luck !

 

Jeff3x   10 pts.  |   Sep 3 2008  2:47PM GMT

Hi. I must declare a vested interested – we’re a UK-based iSeries software house with our own card payment system.
We therefore obviously have hands-on knowledge of PCI, and have implemented AES-256 encryption, using iSeries APIs and key management on relevant, retainable card data, and have removed all sensitive card data from files within our own software. We have extended the encryption to card data held on customers’ systems, but outside our package by a series of our own APIs.
The data is available in both scenarios on a “need-to-see “ basis as required by the PCI standard. Access to the data is controlled by our own security system.
This represents part of the PCI standard requirements, but still leaves areas such as physical security, internet access vulnerability, password control etc.
We are able to give advice and pointers, and, of course, sell our solutions.

I can be contacted on 00 44 161 793 4674 or  <a href="mailto:jeffh@3xsw.co.uk" title="mailto:jeffh@3xsw.co.uk">jeffh at 3xsw.co.uk</a>

Regards,

Jeffh

 

Gpalgon   10 pts.  |   Sep 26 2008  8:33PM GMT

I’m with a solution vendor as well, nuBridges Inc., who provides data security solutions to the IBM i (AS/400, System i, i Series) and a member of the Payment Card Industry’s Security Standards Council (PCI SSC).

Having just returned from the 2nd annual meeting in Orlando this week, I would suggest taking a look at the PCI DSS 1.2 standard when it is published in October and review the Network Segmentation section. This will drive what parts of your environment are in-scope and out of scope.

Then, you will need to review the requirements to see what you need to do to comply. For instance, you have a homegrown application so it may be required to have code review, etc.. Every situation is different so without knowing the details of your environment, you’ll have to determine what is right.

Feel free to contact me if I can be of additional help.

Gary Palgon
VP Product Management
nuBridges, Inc.
 <a href="mailto:gpalgon@nubridges.com" title="mailto:gpalgon@nubridges.com">gpalgon at nubridges.com</a>
770-730-3726

 

WoodEngineer   2150 pts.  |   Sep 29 2008  3:56PM GMT

We took a very simple approach when we gave our customers the option of paying via credit card.
We built a separate file which contained minimal data - basically internal customer number and payment card number. We used IBM’s internal encryption features to encrypt and decrypt payment card info. Turns out the card info is needed by very few applications. This kept the task small and manageable. This approach also met the requirements of our payment card company.

It took a little while to understand IBM’s encrypt and decrypt APIs, but once we got it, it worked great. Plus, everything we needed was already on the iSeries.

 
0