I have a client project to implement PCI/DSS compliance. The PCI/DSS auditor has stipulated that the web server, application middleware (tomcat), the db server have to be on different systems. In addition the auditor has also stipulated that there be a NTP server, a "patch" server, The Host OS on all of the above nodes will be CentOS 6.2. Below is a list of things that would be necessary. 1. Digital Certificates for each host on the PCI/DSS segment 2. SELinux on each Linux host in the PCI/DSS network segment 3. Tripwire/AIDE on each Linux host in the PCI/DSS segment 4. OS hardening scripts (e.g. Bastille Linux) 5. Firewall 6. IDS (Snort) 6. Central ?syslog? server However, beyond this I would appreciate any comments/feedback / suggestion if you or your organization has undergone a PCI/DSS audit and what are the gotchas that you encountered, especially with respect to CentOS/ open source stack. I came across this which kind of brings out issues between the implementer and the PCI/DSS auditor. <http://webmasters.stackexchange.com/questions/15098/pci-dss-compliance-for-a-vps-using-centos> Thanks very much. -- Arun Khan
Arun Khan wrote:> I have a client project to implement PCI/DSS compliance. > > The PCI/DSS auditor has stipulated that the web server, application > middleware (tomcat), the db server have to be on different systems. > In addition the auditor has also stipulated that there be a NTP > server, a "patch" server, > > The Host OS on all of the above nodes will be CentOS 6.2. > > Below is a list of things that would be necessary. > > 1. Digital Certificates for each host on the PCI/DSS segment > 2. SELinux on each Linux host in the PCI/DSS network segment > 3. Tripwire/AIDE on each Linux host in the PCI/DSS segment > 4. OS hardening scripts (e.g. Bastille Linux) > 5. Firewall > 6. IDS (Snort) > 6. Central ?syslog? server > > However, beyond this I would appreciate any comments/feedback /<snip> I had a short-term contract with a company that a) did managed security, and b) was a root CA. I *think* the auditor missed one thing: as I understand it, if the three servers aren't hardwired to each other, *all* communications must be encrypted between them. mark
wow, seems like quite a lot. What "level" of PCI/DSS compliance are you going for? The only other thing I might add.... Are you hosting the hardware? If it's hosted else where then the "facility" that's hosting the hardware needs to be PCI/DSS complaint. On 5/25/2012 10:22 AM, Arun Khan wrote:> I have a client project to implement PCI/DSS compliance. > > The PCI/DSS auditor has stipulated that the web server, application > middleware (tomcat), the db server have to be on different systems. > In addition the auditor has also stipulated that there be a NTP > server, a "patch" server, > > The Host OS on all of the above nodes will be CentOS 6.2. > > Below is a list of things that would be necessary. > > 1. Digital Certificates for each host on the PCI/DSS segment > 2. SELinux on each Linux host in the PCI/DSS network segment > 3. Tripwire/AIDE on each Linux host in the PCI/DSS segment > 4. OS hardening scripts (e.g. Bastille Linux) > 5. Firewall > 6. IDS (Snort) > 6. Central ?syslog? server > > However, beyond this I would appreciate any comments/feedback / > suggestion if you or your organization has undergone a PCI/DSS audit > and what are the gotchas that you encountered, especially with respect > to CentOS/ open source stack. > > I came across this which kind of brings out issues between the > implementer and the PCI/DSS auditor. > <http://webmasters.stackexchange.com/questions/15098/pci-dss-compliance-for-a-vps-using-centos> > > Thanks very much. >
2012/5/25 Arun Khan <knura9 at gmail.com>:> I have a client project to implement PCI/DSS compliance. > > The PCI/DSS auditor has stipulated that the web server, application > middleware (tomcat), the db server have to be on different systems.requirement "one primary function per server".> In addition the auditor has also stipulated that there be a NTP > server, a "patch" server,true also.> > The Host OS on all of the above nodes will be CentOS 6.2. > > Below is a list of things that would be necessary. > > 1. Digital Certificates for each host on the PCI/DSS segmentUsually needed, if you use https or similar protocols.> 2. SELinux on each Linux host in the PCI/DSS network segmentSELinux is not usually needed.> 3. Tripwire/AIDE on each Linux host in the PCI/DSS segmentOssec (www.ossec.net) can do this.> 4. OS hardening scripts (e.g. Bastille Linux)Some hardening needed.> 5. FirewallHardware and software firewall on each network segment with nat enabled.> 6. IDS (Snort)Ossec can do this> 6. Central ?syslog? serverOssec server with samhain is good solution for that.> > However, beyond this I would appreciate any comments/feedback / > suggestion if you or your organization has undergone a PCI/DSS audit > and what are the gotchas that you encountered, especially with respect > to CentOS/ open source stack.-- Eero
On Fri, 25 May 2012 22:52:13 +0530 Arun Khan <knura9 at gmail.com> wrote:> I have a client project to implement PCI/DSS compliance.Some advice from my practical professional knowledge...> The PCI/DSS auditor has stipulated that the web server, application > middleware (tomcat), the db server have to be on different systems. > In addition the auditor has also stipulated that there be a NTP > server, a "patch" server,There is always the scope to be understood. If a server has card numbers somewhere, that server in on scope. So is any other server on the same network segment. So is any firewall delimiting these network segments. Now... if you have a sufficiently large number of systems in scope, it's more practical to suppose PCI:DSS is in scope on all servers. This eases your maintenance as you won't have exceptions to deal with, or justify, but if you have very few systems in scope rather than most of the others which aren't, it'll be your decision considering the work overload. I personally still advise to follow most rules on the non scoped servers as they are in fact wise rules.> The Host OS on all of the above nodes will be CentOS 6.2.Not a good practice to say "6.2". Merely applying patches as time goes on means in some time you'll be running 6.3. Say 6. :)> Below is a list of things that would be necessary. > > 1. Digital Certificates for each host on the PCI/DSS segment > 2. SELinux on each Linux host in the PCI/DSS network segmentBeware that many instructions tell you to disable selinux. I found that with a little bit of work and the help of audit2why and a few more selinux commands, you can usually work around bad apps by assuming the risk of allowing what they need. A master will write his own selinux rules according to apps, though.> 3. Tripwire/AIDE on each Linux host in the PCI/DSS segmentI advise OSSEC, rather than those, as it's a much better Host IDS.> 4. OS hardening scripts (e.g. Bastille Linux)I'm very wary of these generic ones, I usually bet on strongly reducing the packages installed and defining the security settings straight from my kickstart install scripts.> 5. Firewall > 6. IDS (Snort) > 6. Central ?syslog? serverBe careful to send logs under TLS. I found that as a syslog server, rsyslog on RHEL/CentOS 5 *sucks* and gets you in trouble with ram exhaustion and crashes. I had to backport from 6 as the idiotic siem software running on that server demanded series 5 (even though it's just java *sigh*) and we ran into this issue with rsyslog, which is quite old under RHEL/CentOS. This siem server does not support TLS syslog, only plain UDP/TCP unecrypted syslog, so one has to use a syslog server to receive under TLS then forward to the localhost.> However, beyond this I would appreciate any comments/feedback / > suggestion if you or your organization has undergone a PCI/DSS audit > and what are the gotchas that you encountered, especially with respect > to CentOS/ open source stack.Use sudo extensively. If you have many servers without central password validation and too little people, it's better to have passwordless sudo restricted to admins group as identified by access via OpenSSH RSA keys than having to change your password every month on hundreds of servers. Restrict your access to root shell, and keep it's password (written by two persons, each knowing their own half) in a safe where none of you can access without paper trail. Yes, as an admin you can override that, but if you have externalized logs audited by a separate set of people, your trails may get you in trouble, so that risk is mitigated.> I came across this which kind of brings out issues between the > implementer and the PCI/DSS auditor. > <http://webmasters.stackexchange.com/questions/15098/pci-dss-compliance-for-a-vps-using-centos>I see there some things that are not true, namely WRT CentOS versions. It has a lot to do with *how* you do your things, what evidences you register, whether the auditor is excessively strict and/or knows the technology and/or does a risk based assessment, how segmented is your network, and so on. Rui