PCI Compliance in an iSeries Network Environment – Request for advice and direction

5 pts.
IBM iSeries
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.

Answer Wiki

Thanks. We'll let you know when a new response is added.

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.


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.


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


P.S. Let me know if you want to discuss direct, I am willing to share my experiences as I go thru this process.

Discuss This Question: 6  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • DanTheMan 2
    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 !
    395 pointsBadges:
  • Jeff3x
    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 jeffh@3xsw.co.uk Regards, Jeffh
    10 pointsBadges:
  • Gpalgon
    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. gpalgon@nubridges.com 770-730-3726
    10 pointsBadges:
  • WoodEngineer
    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.
    7,900 pointsBadges:
  • DanD
    As gpalgon suggest, knowing DSS 1.2 is a must. If your credit card data, or SOURCE CODE FOR PROCESSING CREDIT CARD DATA is transmitted on any part of your network, that network and anything network segments that touch it must have ALL DATA ENCRYPTED. The SOURCE FOR CREDIT CARD PROCESSING PROGRAMS MUST BE ENCRYPTED. PCI is going to get tighter every year. Home grown code must have an outside code review. If you are a Level 3-4 PCI shop, you may as welll bite the bullet and get a change control system that handles encrypted source or use 3rd party code from a certified vendor. That includes change management, not just the card processing code. Any wireless networks need to be 256bit encrypted if they touch any part of your network that handles PCI data. If you don't have a security software package that includes the network exit programs, you may as well bite the bullet and buy one. SMTP relay needs to be set to *NONE or limited to other PCI compliant servers that are inhouse. Most PCI auditors have had very limited knowlege of the iSeries, but I'm pretty sure they will be at least as tough as a good SOX auditor within another two yrs. so you better implement strong object level security with no *public access to anything in production and not more than three profiles with *allobj on the entire system. One of those will be QSECOFR. You are going to need to monitor all updates and even reads to files with credit card data, even if they are encrypted. You will probably need REAL TIME alerts for configuration changes, changes to security level system values, activation of *allobj profiles, network intrusion attempts. Lots of luck folks, it is only just beginning. But noncompliance will be more expensive than doing what it takes. Read DSS 1.2 and make sure your upper management and the business are prepared for the pain of changes and the cost.
    2,865 pointsBadges:
  • CharlieBrowne
    We also process credit card information on an AS400 and were required by our auditors to become PCI compliant. After much research, we have purchase software from Linoma Software. We have Crypto Complete for AS400 applications and Go Anywhere for all FTP and file transfer processes. Both are totally PCI compliant. These were the best priced and extremely easy to install and start to use. Our Contact is Donnie Laughlin @ 800-949-4696 ext 719 Their web is www.linomasoftware.com
    62,340 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: