[Seaside] Anyone familiar wityh PCIDSS?

Thu Jul 26 15:00:10 UTC 2012

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