[Seaside] Anyone familiar wityh PCIDSS?

[James Foster]

Boris,

Thanks very much for the comments. I recognize that the database needs to be internal and protected from the DMZ by a second firewall. The question is whether it is required that the application server be separate from the database (e.g., in the DMZ). If Apache is communicating with the app server/database using FastCGI over port 9000 through a firewall, would that be okay? Section 2.2.1 (quoted below) explicitly refers to web server and database, but does not mention app server. Is it commonly accepted that the app server will be on the web server?

When you say that we should not store card data, does that mean that the customer needs to enter it for every transaction?

James

On Jul 26, 2012, at 8:00 AM, Boris Popov, DeepCove Labs wrote:

> All of the below, of course, only applies if you intend to store the
> card data yourself, and unless you're a processor, there really
> shouldn't be any need for anyone to do that these days.
> 
> -Boris
> 
> 
> -----Original Message-----
> From: Boris Popov, DeepCove Labs 
> Sent: Thursday, July 26, 2012 10:59 AM
> To: Seaside - general discussion
> Subject: RE: [Seaside] Anyone familiar wityh PCIDSS?
> 
> My colleague responsible for coordinating our annual Level 1 audits had
> this to say about it yesterday:
> 
> The database server containing card data definitely needs to be in a
> different zone from the DMZ and the intention is that the DMZ contains
> web and application servers. That is clear not just from this section,
> but also implicitly and explicitly from,
> 
> 1.1.3 Requirements for a firewall at each Internet connection and
> between any demilitarized zone (DMZ) and the internal network zone.
> 1.3 Prohibit direct public access between the Internet and any system
> component in the cardholder data environment.
> 1.3.7 Place system components that store cardholder data (such as a
> database) in an internal network zone, segregated from the DMZ and other
> untrusted networks.
> 
> Bottom line, I think it will be a tough slog getting a QSA to sign off
> on architecture that enables connections from the Internet to terminate
> on a GemStone database containing card data, even if that is only via
> HTTP. You may be able to get away with terminating connections on a web
> proxy in the DMZ and then forwarding to GemStone especially if that
> proxy is Apache and you can convince the auditor the Apache instance is
> the web server. But really you will be finessing the below,
> 
> 2.2.1 Implement only one primary function per server to prevent
> functions that require different security levels from co-existing on the
> same server. For example, web servers, database servers, and DNS should
> be implemented on separate servers.
> 
> HTH,
> 
> -Boris
> 
> -----Original Message-----
> From: seaside-bounces at lists.squeakfoundation.org
> [mailto:seaside-bounces at lists.squeakfoundation.org] On Behalf Of Paul
> DeBruicker
> Sent: Thursday, July 26, 2012 10:46 AM
> To: Seaside - general discussion
> Subject: Re: [Seaside] Anyone familiar wityh PCIDSS?
> 
> I don't know.  It would be good to know. Hopefully there's a way to
> learn without going through an audit first.
> 
> Here are some ideas about ways to store it that may get around the
> issue:
> 
> 1.  Use a MySQL (or whatever) database on another machine to store the
> credit card info.
> 
> 2.  Use Braintree's Vault product
> (https://www.braintreepayments.com/tour/vault) which just stores the
> info safely in a payment processor agnostic way.
> 
> 3.  Use Stripe (http://www.stripe.com) if you don't have a merchant 
> account or don't need one yet.   I've made a Pharo/Gemstone package 
> here: http://www.squeaksource.com/Stripe.html I think they charge 2.9% +
> $0.30 per transaction
> 
> 4.  Maybe putting your externally facing webserver (e.g. apache) on
> another machine and referring to your Pharo/Gemstone installations as
> the app server/ database server is enough for separation of concerns.
> 
> 
> 
> 
> 
> On 07/25/2012 10:15 AM, James Foster wrote:
>> The Payment Card Industry Data Security Standard
> (https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf)
> specifies in section 2.2.1: "Implement only one primary function per
> server to prevent functions that require different security levels from
> co-existing on the same server. (For example, web servers, database
> servers, and DNS should be implemented on separate servers.)"
>> 
>> My interpretation is that this does not specify the application
> server, so it can be co-located with the database server. I just talked
> to someone who thinks that it is fine to put the application server with
> the web server but not with the database server. If the application
> server and the database server have to be on separate machines, then
> this would prohibit image-based persistence (whether Pharo or GemStone).
>> 
>> Any comments?
>> 
>> James Foster
>> 
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>> 
> 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>