OnDemand User Group
Support Forums => MP Server => Topic started by: Bud Paton on May 26, 2010, 08:34:52 AM
-
Has anyone created a PCI compliant system with CMOD? Thanks
-
Hi Bud.
I'll answer your question with a question -- I've heard 'PCI' compliance mentioned for probably 5 to 7 years now, but I've never received a decent explanation of what it entails.
Does anyone have a reference to the specifications for PCI compliance? Are they public?
-JD.
-
Sorry I should have explained PCI Compliance:
Q: What is PCI?
A: The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed to ensure that ALL companies that process, store or transmit credit card information maintain a secure environment. Essentially any merchant that has a Merchant ID (MID).
The Payment Card Industry Security Standards Council (PCI SSC) was launched on September 7, 2006 to manage the ongoing evolution of the Payment Card Industry (PCI) security standards with focus on improving payment account security throughout the transaction process. The PCI DSS is administered and managed by the PCI SSC (www.pcisecuritystandards.org), an independent body that was created by the major payment card brands (Visa, MasterCard, American Express, Discover and JCB.).
It is important to note, the payment brands and acquirers are responsible for enforcing compliance, not the PCI council.
A copy of the PCI DSS is available here.
-
We have been working with several of our clients moving towards PCI compliance. Some steps taken to date include utilizing the User Preview Exit to mask credit card numbers for data that is already loaded into CMOD. We have also implemented a 3rd-party data encryption solution to encrypt the file systems for all of the CMOD directories: arsdb, cache, etc. This also includes encrypting disk storage pools defined in TSM.
-
Hi Steve,
I noticed that you had a post back in 2008 about using Vormetric for encryption but that it had a major performance hit on arsmaint processing. Did you get that resolved? I have a customer who is looking into encryption for PCI DSS compliance (specifically requirement 3.4 to "Render PAN unreadable anywhere it is stored").
Thanks
-
For what it's worth, cache data is unreadable on devices due to IBM's proprietary compression method (OD77). It's not encryption, but it's certainly serious obfuscation. Between that and striping data across hard drives, you'd have to be up against a seriously committed adversary who was extremely well funded and equipped.
In all seriousness, it's easier, (and probably faster) to just try and crack login passwords with a brute force methodology.
-
Hi all
Surprised that this topic has been quiet for a year. PCI has been gaining momentum. I would have guessed that there are a lot of companies that need to comply with PCI that run CMOD. We host CMOD archives for several clients that need to comply; one of them is looking for a solution. IBM has not been helpful.
There seem to be two logical approaches: either
- encrypt everything with all of the overhead that imposes, there are other posts on this site about experience with IBM's recommended encryption product 'Vormetric'. The additional logic for encryption (see encryption thread) seems like a lot of work. In addition, all of our other systems would need to be encrypted as well. A big effort all round.
- or alternately tokenise Credit card data before it hits the archive and therefore take CMOD (and everythinge else) out of scope. The only real problem with tokenisation is range queries. Additional logic at the front-end should not be too hard.
Love to hear from anyone who has experience here.
Regards - AW
-
Hi all,
some years ago we have implemented PCI in the following way: We have created aliase for credit card numbers (of course in a way that credit card number cannot be recalculated from alias). This mapping table is stored encrypted. Inside the system only the aliase are used. So inside the system the original credit card number is never used / stored (besides the mapping table). When leaving or entering the system the credit card number can be translated using the mapping table. In such an environment OnDemand would store the Aliase in it's documents. No encryption is needed in these documents. Only a PCI complient searching and viewing has to be implemented to see real credit card numbers and search for them. Only the programs at the beginning and the end have to be changed because all other programs will work with the alias instead of the credit card number without knowing anything about this.
The details are much more complex. But this is the main idea.
regards
Egon
-
Hi Egon
Very interesting, thanks for that. I think that the concept of an aliase is very similar to a token. What you have described is logically nearly identical except that in a "tokenised" environment the mapping table to the token would be externalised to a PCI secure zone which would be very highly protected; controls like 2-factor identification for all developers, every user request to the mapping table aliase needs to be logged etc.
The logic is however the same, only the programs at the beginning and end have to be changed.
We are not a merchant or bank, rather we are a service provider. So in our environment the aliase table concept would need a lot of other PCI controls to be put in place for the whole CMOD environment for it to work.
It would be great if you could share any more details about this, which programs needed to be changed etc. How much effort?
Thanks :)
-
Hi AWHS,
my experience was outside OnDemand. So I cannot tell you details. But some tasks would be relevant:
- loading documents with alias instead of real credit card numbers
elements:
a) input exit (to modify document)
b) index exit (to modify index values)
c) ICSF (to do security functions in Z/OS)
- searching with real credit card number to find documents
elements:
a) arsuperm (to modify search)
b) ICSF (to do security functions in Z/OS)
- showing real credit card numbers of documents
elements:
a) arsuprep (to modify the content to show)
b) ICSF (to do security functions in Z/OS)
regards
Egon
-
PCI entails a larger number of requirement above and beyond application security and encryption.
The data compression used in CMOD has no effect as far as a PCI auditor is concerned since the data is not "encrypted".
To date, IBM has no plans to make CMOD PCI compliant.
To help reduce the exposure, we do use Vormetric CoreGuard to encrypt all of the CMOD and TSM filesystems and backups are written to hardware encrypted tapes. We also have written a Preview Exit (arsuprep) that is used to mask credti/debit cards prior to display.
-
what about data in transit? we are using PSF and PDM to pull documents from host. Recently I was told that PSF and PDM doesn't support secure protocol. Does IBM has plan to support full PCI compliant solution?
-
To encrypt communications that don't support it natively, you can use an encrypted 'tunnel'. You build the tunnel between two systems, then, when you want to communicate to the remote server, you point the insecure service at a local TCP/IP port, at which point the data is automagically transported across the encrypted channel to the other side.
You can search your favourite search engine for "SSH Tunnelling', and there's lots of information on how to do this, often at no cost -- since most modern Operating Systems include the open-source 'OpenSSH' tool.
-JD.
-
Hi,
according to my statment before it is more performant to use allias/tokens. In this case no document encryption of documents is needed. Additonally secure TCP traffic is only needed, if real credit card numbers have to be transported. Only the matching table credit card number / alias needs to be encrypted. Of course such a scenario is only possible, if recalculate the credit card number from alias is not possible with current computers. In our project we have used a modified hash value of the creditcard number, which can be created by open ssl or ICSF.
regards
Egon
-
resurrecting to see if anyone has any new information.
-
Bump.
Anyone had any updates from IBM or solutions for PCI with CMOD (Z/OS)
J.
-
As a matter of fact, IBM just announced their built-in encryption feature for DB2. I'm not super-familiar with PCI's requirements, but encryption of database data checks one of the boxes as far as I know. I haven't seen it in action, but it could be an easy step in the journey to PCI compliance.
-JD.
-
Thanks. Hopefully it does not come with a performance hit.
-
Also, modern versions of CMOD have the ability to use SSL, ticking another box in the PCI-compliance checklist. The only thing really missing is the 'tokenization' of credit card numbers.
-JD.
-
Which is the golden egg! :)
-
Hi, I am new here, and althought this topic has been silent for quite a while, I thought I could add some info.
Back in 2011 or 2012, we got the requirement to PCI-DSS certify the CMOD system of a customer.
They have stored each single receipt for each store worldwide, and they keep them for 11 years (by law).
The requirement that we said yes to was to:
*export each document
* "wash it" from cc number data - i.e. we masked the required numbered of digits by replacing them with asterisks (*) //or maybe it was hash signs (#) can't remember //
* reload it back into OnDemand
NOTE: This would be categorized as option two described by AWHS above - "take CMOD out of scope".
On top of that, all POS systems in all stores had their software upgraded to automatically mask CC number data as described above.
We also require that any new data that is to be archive is "certified free from credit card numbers" - and we of course verify that before we start archiving it.
It was a tedious semi-automatic procedure, but sure enough, we processed and "cleaned" millions of report pages and receipts.
The only downside (which was pretty small) were that some stores complained that they could no longer find customer receipts by searching for CC number. So if that is an important requirement, the "aliase" method described above is probably better.