Matt,
Thanks for the information. However,
http://www.relational-data.com/ is just a brochure-ware site managed by a big hosting company running PHP on Linux on Intel. I wouldn't recommend any of those environments for database workloads and more particularly if the data were sensitive.
In my first post to this thread I suggested separating external from internal networks, using routers w/ firewalls to establish DMZs, and running multiple HTTP server instances where all requests for business applications (PHP, JEE, CGI, etc.) were funneled through reverse proxies to ensure that any TCP/IP services including ports and types of services hosted under IBM i were completely hidden from public view, and channeled through specific control points.
I believe a configuration like that is completely in-line with both the letter and intent of PCI guidelines. Of course, network and web service topology are only a small part of PCI, but that addressed the immediate concern of OP.
PCI Guidelines suggest separation of concerns in the context of separating networks from applications and administering each separately. It seems that many people wrongly interpret them to mean using server farms (virtual or physical) which is common under Window and Intel.
I agree that you can't trust software to be written without vulnerabilities. But I claim that IBM i has much fewer than mainstream environments. Moreover, if you deploy something under IBM i that becomes unstable, that hardly ever has any impact on other concurrent workloads.
-Nathan
----- Original Message -----
From: Matt Olson <Matt.Olson@xxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Cc:
Sent: Tuesday, September 3, 2013 3:47 PM
Subject: RE: iSeries public WEB access, PCI security issues
Nathan, Just an FYI so I can open your eyes a bit more.
Your web server (relational-data.com) running PHP 5.2.5, Apache 2.0.63 currently has 92 PHP security vulnerabilities, and 17 Apache security vulnerabilities.
http://www.cvedetails.com/vulnerability-list/vendor_id-74/product_id-128/version_id-50739/PHP-PHP-5.2.5.html
http://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-66/version_id-80725/Apache-Http-Server-2.0.63.html
Still feeling confident in housing your card holder data on that same box and 100% confident that there is no way to get at card holder data on that box if it existed or would you do what the PCI guidelines are stating and separate that box out into different primary functions to mitigate exposure risks from the above 92 PHP and 17 apache vulnerabilities?
The correct answer is to split them out.
The reasoning is so simple I can understand why you are missing the point. You can NOT trust software is written 100% bug free. Therefore to minimize risk in the software stack you split things out as to lessen the blow when things do get exploited.
midrange.com
