Comments on: PCI Compliance in an iSeries Network Environment - Request for advice and direction http://itknowledgeexchange.techtarget.com/itanswers/pci-compliance-in-an-iseries-network-environment-request-for-advice-and-direction/ Fri, 27 Nov 2009 21:51:13 +0000 http://wordpress.org/?v=2.6.2 By: CharlieBrowne http://itknowledgeexchange.techtarget.com/itanswers/pci-compliance-in-an-iseries-network-environment-request-for-advice-and-direction/#comment-70344 CharlieBrowne Thu, 12 Nov 2009 20:27:35 +0000 #comment-70344 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 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 <a href="http://www.linomasoftware.com" title="http://www.linomasoftware. " target="_blank">www.linomasoftware.com</a>

]]> By: DanD http://itknowledgeexchange.techtarget.com/itanswers/pci-compliance-in-an-iseries-network-environment-request-for-advice-and-direction/#comment-70331 DanD Thu, 12 Nov 2009 17:58:34 +0000 #comment-70331 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. 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.

]]> By: WoodEngineer http://itknowledgeexchange.techtarget.com/itanswers/pci-compliance-in-an-iseries-network-environment-request-for-advice-and-direction/#comment-56770 WoodEngineer Mon, 29 Sep 2008 15:56:38 +0000 #comment-56770 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. 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.

]]> By: Gpalgon http://itknowledgeexchange.techtarget.com/itanswers/pci-compliance-in-an-iseries-network-environment-request-for-advice-and-direction/#comment-56723 Gpalgon Fri, 26 Sep 2008 20:33:23 +0000 #comment-56723 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 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

]]> By: Jeff3x http://itknowledgeexchange.techtarget.com/itanswers/pci-compliance-in-an-iseries-network-environment-request-for-advice-and-direction/#comment-56116 Jeff3x Wed, 03 Sep 2008 14:47:25 +0000 #comment-56116 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 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

]]> By: DanTheMan 2 http://itknowledgeexchange.techtarget.com/itanswers/pci-compliance-in-an-iseries-network-environment-request-for-advice-and-direction/#comment-55964 DanTheMan 2 Wed, 27 Aug 2008 14:51:17 +0000 #comment-55964 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 ! 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 !

]]>