Anyone familiar wityh PCIDSS?

> 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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

>
> Any comments?
>
> James Foster
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

>
> Any comments?
>
> James Foster
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> 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: [hidden email]
> [mailto:[hidden email]] 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
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> 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

> 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

> 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: [hidden email]
> [mailto:[hidden email]] 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

> +
> $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

>>
>> Any comments?
>>
>> James Foster
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> 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.