Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "J.O. Aho" Newsgroups: comp.lang.php Subject: Re: Need help with two-way script (PCI DSS) Date: Fri, 9 Sep 2016 18:21:12 +0200 Lines: 103 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: individual.net gePYeEkANEfubB9VDYhQnAyPaRGT//ArqtDbTBVrw9jQlIrSaJ Cancel-Lock: sha1:03xKNp5ZtHEJ6jvpFAlqjvuUySk= X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 In-Reply-To: Xref: csiph.com comp.lang.php:17045 On 09/09/2016 04:05 PM, Jerry Stuckle wrote: > On 9/9/2016 12:32 AM, J.O. Aho wrote: >> On 09/08/2016 10:59 PM, Jerry Stuckle wrote: >>> On 9/8/2016 4:06 PM, J.O. Aho wrote: >>>> On 09/08/2016 08:05 PM, Jerry Stuckle wrote: >> >>>>> So it sounds like you have control over both sides of the conversation, >>>>> in which case you can do about anything you want. So the first thing >>>>> you need to do is determine how you want to transfer the data. >>>>> >>>>> Personally, I would consider directly accessing the MySQL database - I >>>>> believe for the most part the less involved, the less that can go wrong. >>>> >>>> In this case you may get a PCI DSS dependency which you may not want to >>>> have, you will want as few machines as possible in scope, as this makes >>>> audits a lot easier and less work. >>>> >>> >>> Not if it's designed properly. For instance, MySQL can use encrypted >>> connections, and firewalls can limit access. >> >> If application A stores PAN/Card holder data in the database and >> application B only is interested in the email address and both access >> the same database, then both applications are in scope for PCI audit. >> > > True - but application B can be restricted so that it cannot access > anything but the email address. Just because it can access the database > does not mean it can access the entire database. But that is true for > any half-way decent RDBMS. Sure you can, but it's still in scope for PCI as it has access to the database where the PAN/Card Holder data is stored. >> If you let application A send the email address to application B with a >> https request and application B returns a true or false answer, then >> application B is out of scope for PCI. >> >> There are big difference in the amount of PCI documentation you have to >> have and less requirements on the server which application B is running. >> > > But then you also have an additional server and application(s) to > consider, when once again and place you in scope of a PCI audit. Yes, of course, but the additional server ain't within PCI scope as it's not able to access PAN/Card Holder data. >>> But if the MySQL database is on another system, you'll have that problem >>> anyway, no matter how you access it. >> >> You have a compensating control on the MySQL too, as it don't support >> encrypted columns, sure you can (must) have it running on a luks partition. >> > > You can encrypt the data in the database; but like most databases the > problem is you need the password to do anything with that column. But > that's true whether you are accessing the database directly or through > another app. This can be handled by key management systems in a database as for example in sybase, where you can grant the decryption and use of the decryption key to users. > You can, however, get around this problem by placing the password in > stored procedures. But that again adds another level complexity. And yet another compensating control. >> >> From PCI point of view, I would recommend to use postgresql unless you >> want to use money and go for oracle/sybase... the less compensating >> controls you have the smother the PCI audit will be. >> >> > > I prefer DB2, but that's my opinion. And both DB2 and Oracle have free > versions. Those versions are limited, but should work just fine for > what she needs. I would say this part of the thread is out of scope for Adrienne, she just doing the application B and do not really have to think about PCI, that is all up to their customers to solve. > The biggest problem when going to other databases will be installation > and maintenance. Most hosting companies are familiar with MySQL, and > some with PostgreSQL. However, very few are familiar with the > commercial RDBMS's, so she'll be on her own. I don't see the problem, most QSA's would fail you if you use normal hosting for PAN/Card holder data. You need to go for a dedicated machine and up to you what you install, not the head ache of the hosting company. -- //Aho