[Seaside] Anyone familiar wityh PCIDSS?

Thu Jul 26 15:41:26 UTC 2012

James,

As with any audit, exact interpretation and enforcement is up to any
given auditor. I know it's commonly accepted that database servers are
in a standalone secure zone with no other functions residing in that
zone. It's not been an issue putting application servers and web servers
on the same hosts in the DMZ for us.

As for storage of card data, all decent processors allow you to process
a transaction and use some notion of a resulting token for any follow up
transactions leaving the storage concerns to the processor. If you never
store card data and only have it in memory while it's transiting your
system on the way to the processor, then your (self-)audit and
compliance becomes trivial in most cases. Some processors, like Stripe,
avoid passing card data through your environment altogether, by having
the browser send the card data to them and replacing it with a token
that then gets submitted to your application to initiate a payment.

HTH,

-Boris

-----Original Message-----
From: seaside-bounces at lists.squeakfoundation.org
[mailto:seaside-bounces at lists.squeakfoundation.org] On Behalf Of James
Foster
Sent: Thursday, July 26, 2012 11:21 AM
To: Seaside - general discussion
Subject: Re: [Seaside] Anyone familiar wityh PCIDSS?

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
> 

_______________________________________________
seaside mailing list
seaside at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside