[CentOS] PCI/DSS compliance on CentOS

2012-05-25 Thread Arun Khan
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.


Thanks very much.

-- 
Arun Khan
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-25 Thread m . roth
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 /

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

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-25 Thread Ken godee
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.
> 
>
> Thanks very much.
>

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-25 Thread m . roth
Ken godee wrote:
> wow, seems like quite a lot.

Heh. When I was working for the company, I had a guy who sat in easy
earshot who was one of their folks who dealt with questions from companies
and businesses. The *easiest* one, the lowest level, was 60 or 63
questions. The serious, highest one was over 220, and really required
people on at least our level to answer some of them.

mark
>
> 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.
>> 
>>
>> Thanks very much.
>>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-25 Thread Eero Volotinen
2012/5/25 Arun Khan :
> 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 segment

Usually needed, if you use https or similar protocols.

> 2. SELinux on each Linux host in the PCI/DSS network segment

SELinux is not usually needed.

> 3. Tripwire/AIDE on each Linux host in the PCI/DSS segment

Ossec (www.ossec.net) can do this.

> 4. OS hardening scripts (e.g. Bastille Linux)

Some hardening needed.

> 5. Firewall

Hardware and software firewall on each network segment with nat enabled.

> 6. IDS (Snort)

Ossec can do this

> 6. Central “syslog” server

Ossec 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
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-25 Thread Arun Khan
On Fri, May 25, 2012 at 11:27 PM, Ken godee  wrote:
> wow, seems like quite a lot.
>
> What "level" of PCI/DSS compliance are you going for?

I have to check this with the client.   Credit card information will
be encrypted and stored in client's own db.

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

The client will be hosting it on their own office premise (the
physical security aspect is being handled by another vendor).

Thanks,
-- Arun Khan
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-25 Thread Arun Khan
Hi Eero,

On Sat, May 26, 2012 at 1:12 AM, Eero Volotinen  wrote:
> 2012/5/25 Arun Khan :
>> 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.

... snip ...


Thanks for your input on each points in OP.   I appreciate it.

-- Arun Khan
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-25 Thread Eero Volotinen
2012/5/26 Arun Khan :
> Hi Eero,
>
> On Sat, May 26, 2012 at 1:12 AM, Eero Volotinen  wrote:
>> 2012/5/25 Arun Khan :
>>> 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.
>
> ... snip ...
>
>
> Thanks for your input on each points in OP.   I appreciate it.

Usually you also need to implement WAF (web application firewall) on
front of public webservers.

I think cheapest solution is use mod_security*) on apache and then
proxy valid requests to tomcat.

*) http://www.modsecurity.org/


--
Eero, RHCE, CISSP
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-25 Thread Ken godee
>> What "level" of PCI/DSS compliance are you going for?
>
> I have to check this with the client.   Credit card information will
> be encrypted and stored in client's own db.

Yup, this is exactly what they don't want people to do and
I believe in the future they'll strive for just a handful
of processors that will meet there criteria.

> The client will be hosting it on their own office premise (the
> physical security aspect is being handled by another vendor).
>

I'm sure I'm talking way over my head at this point but
this must be for a fairly large merchant (1M+ transactions yearly).

Not quite sure why one wouldn't use one of processors gateway 
facilities, there's convenient api's that would handle anything to do
with cc's and at a "small fraction" of the price to set up and maintain.

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-25 Thread Eero Volotinen
2012/5/26 Ken godee :
>>> What "level" of PCI/DSS compliance are you going for?
>>
>> I have to check this with the client.   Credit card information will
>> be encrypted and stored in client's own db.
>
> Yup, this is exactly what they don't want people to do and
> I believe in the future they'll strive for just a handful
> of processors that will meet there criteria.
>
>> The client will be hosting it on their own office premise (the
>> physical security aspect is being handled by another vendor).
>>
>
> I'm sure I'm talking way over my head at this point but
> this must be for a fairly large merchant (1M+ transactions yearly).

"The client will be hosting it on their own office premise" sounds
really bad. Usually this kind of systems are located in really secured
datacenters.

--
Eero
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-26 Thread Rui Miguel Silva Seabra
On Fri, 25 May 2012 22:52:13 +0530
Arun Khan  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 segment

Beware 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 segment

I 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” server

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

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
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-26 Thread Rui Miguel Silva Seabra
On Fri, 25 May 2012 13:47:12 -0400
m.r...@5-cent.us wrote:

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

It's always a matter of risk based analysis.

Were that three servers on the same network segment (logical and
physical)? Do you have good and restrictive firewalls around them, and
so on.

It's not good security or a good audit result if you just throb all the
nobs.

Rui
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-26 Thread Arun Khan
Thanks to all who responded to my query.   Collectively, you raised my
awareness PCI/DSS, related tool sets and such.

I have submitted my proposal to the client and I am sure I will
discover a lot more if the proposal is accepted and I begin the
implementation.

@ Rui Miguel Silva Seabra - appreciate your advice and suggestions.

-- Arun Khan
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-27 Thread Eero Volotinen
2012/5/26 Arun Khan :
> Thanks to all who responded to my query.   Collectively, you raised my
> awareness PCI/DSS, related tool sets and such.
>
> I have submitted my proposal to the client and I am sure I will
> discover a lot more if the proposal is accepted and I begin the
> implementation.

Just remember that PCI DSS is not self service process, you usually
need to use PCI QSA (Qualified Security Assessor) to complete your PCI
process.

--
Eero
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-28 Thread Karanbir Singh
Hi Arun,

On 05/26/2012 04:06 PM, Arun Khan wrote:
> I have submitted my proposal to the client and I am sure I will
> discover a lot more if the proposal is accepted and I begin the
> implementation.

What are the chances that you might consider adding to the CentOS wiki
on the PCI/DSS issues and process's ? Given that you are clearly about
to allocate some time towards that.



-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
ICQ: 2522219| Yahoo IM: z00dax  | Gtalk: z00dax
GnuPG Key : http://www.karan.org/publickey.asc
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-28 Thread Arun Khan
On Sun, May 27, 2012 at 11:25 PM, Eero Volotinen  wrote:
>
... snip ..

> Just remember that PCI DSS is not self service process, you usually
> need to use PCI QSA (Qualified Security Assessor) to complete your PCI
> process.


Yes, indeed.  I am very well aware of it.   In the OP  I do mention
"The PCI/DSS auditor has stipulated that the web ..."

-- 
Arun Khan
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-28 Thread Kwan Lowe
Rui:

On Sat, May 26, 2012 at 3:36 AM, Rui Miguel Silva Seabra wrote:

> On Fri, 25 May 2012 22:52:13 +0530
> Arun Khan  wrote:
>
> > I have a client project to implement PCI/DSS compliance.
>
> Some advice from my practical professional knowledge...
>
>
Excellent post...


> > 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 is what we ended up doing. It was far easier to build everything to be
compliant than to selectively push PCI compliant configurations to a
handful of 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 segment
>
> Beware 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.
>
>
We have selinux in our base configuration. The only caveat here is that
vendors often will refuse to support an application if selinux is enabled.
Though I know very well that selinux itself is not the problem (i.e., it's
the policy that needs to be tweaked), the app owners claim that there is no
way to figure out what is wrong when selinux is enabled.


> > 3. Tripwire/AIDE on each Linux host in the PCI/DSS segment
>
> I 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” server
>
> Be 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.
>
>
We use sudo among other things. Lately we have enabled ACLs to allow
specific individuals access to specific configuration files.

The main caveat with sudo is finding those applications that allow shell
access, etc..



> 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 

Re: [CentOS] PCI/DSS compliance on CentOS

2012-05-28 Thread Arun Khan
Hi Karanbir,

On Mon, May 28, 2012 at 8:46 PM, Karanbir Singh  wrote:
> Hi Arun,
>
> On 05/26/2012 04:06 PM, Arun Khan wrote:
>> I have submitted my proposal to the client and I am sure I will
>> discover a lot more if the proposal is accepted and I begin the
>> implementation.
>
> What are the chances that you might consider adding to the CentOS wiki
> on the PCI/DSS issues and process's ? Given that you are clearly about
> to allocate some time towards that.
>

I am certainly open to your suggestion once I get the project and execute it :)

-- Arun Khan
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos