Re: PCI DSS & Firewalls

[Frank Knobbe <frank () knobbe us>]

On Thu, 2009-04-02 at 07:25 -0500, Victor Williams wrote:
> PCI DSS is pretty sad.  They could have taken another 
> already-established standard with some brains behind it and adopted it 
> instead...just said, you must follow "OrgA" standards for system 
> hardening and auditing and whatnot...called it a day.


While I'm a PCI QSA, I don't mean to step up on the pedestal and defend
the PCI Standard. There is room for improvement, which is an ongoing
process. I just wanted to say that this is not an "industry standard" in
terms of laying out specific details that can be followed to the letter
to be compliant. It's also not a checkbox-type checklist to magically
make you compliant (or secure). Rather, it is a guide to help QSAs
assess the security of entities having to be PCI compliant. It provides
a minimal baseline in my opinion, and assessors should always strive to
use common sense while reviewing networks and systems, and apply best
practices in order to achieve maximum security.

Just because there is a checkbox for "application level" firewall, or
"server separation" it doesn't mean you have to to follow it. First, you
have to look at what is required in context. Would you run your database
server on the same box as the Internet facing web server? Probably not.
Separation there makes sense. Does it mean you need to have a different
server for your AD/DNS/Print services? No, not necessarily. (Heck and
one can even argue web and database on the same box.... if they are
virtualized with strong access control between them).

Second, there are mitigating controls. If you don't have an application
layer web firewall, but have IDS and a reverse proxy (just an example),
you may be okay. It really all depends on the environment at hand.

When I assess networks for PCI, I first set the "standard" aside and
check what Frank would do. Then I check if everything is in fact
compliant with the PCI "standard", again taking into account mitigating
controls.

The standard is not the leading instrument here, it's the experience and
common sense of the assessors. The PCI doc merely serves as a checklist
to demonstrate to the PCI council that requirements have been fulfilled.
Either verbatim, or in any other shape or form that still fulfills the
desired goal.

Two items most folks struggle with: Scoping and mitigating controls.
Take these into account, and your checklist standard already does not
apply to everyone the same way. Proper scoping can make becoming
compliant much less painful. (Sadly, there are folks who perform PCI
audit in the best interest of themselves, and not in the best interest
of their client) 

If you have to be compliant and look at the PCI requirements document,
and say "this is sad" or "that is not defined", talk to a decent QSA. He
can help make this a less confusing and painful experience.

Cheers,
Frank


PS: No, I'm not a PCI pimp. When I first saw the standard several years
back, and assisted (as technical lead) in gap assessments, I thought the
PCI standard is crap. It took me a bit to realize what it really means
and how it works. It's actually quite usable.

If you are serious about improving the process and the "standard", I'm
sure the PCI council would be happy to hear your suggestions.

 


-- 
It is said that the Internet is a public utility. As such, it is best
compared to a sewer. A big, fat pipe with a bunch of crap sloshing
against your ports.

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards