Re: Firewalls and PCI

["Lyle Worthington" <lyleworthington () gmail com>]

The PCI DSS requirements related to segmenting a network only
specifically address a separation of the internal network from the DMZ
(requirements 1.1.3 and 1.3.4) - more specifically publicly accessible
servers.  The rest simply talks about having an adequate firewall and
sufficiently restrictive rules to limit allowed traffic to any credit
card processing servers or databases.  Based on your description of
the network above it isn't possible for me to tell you if your setup
is PCI compliant, because that depends on the rules you've put on your
firewall, and also on how you protect two machines on the same LAN
from each other.  For instance if machine X and Y are both on the same
LAN (say, database servers) and machine X has no business need to get
credit card data that is stored on machine Y, then you must restrict
all network access from X to Y either with a local firewall on Y or
with access lists on the switch.  This protects Y from X should X get
compromised.  Similarly your firewall rules at the border of each
network should only allow business need network traffic to any credit
card server or database.

Is the network your client wants a 2 layer NAT between the PUBLIC
(internet) and any private LAN such as your LAN and database server
network (but only one NAT to DMZ) or simply additional transparent
firewalls plugged directly into your border firewall?  There is no
specification in the PCI DSS that this is required as a single
firewall sitting between your 3 networks with appropriate rules and a
NAT for private to public traffic will be sufficient.  Be warned,
though, that if you also NAT between your LAN and your database server
network you will be limiting the granularity of the rules you put on
your database server network firewall and border firewall, as all
traffic from every computer on your LAN network will appear to come
from a single IP address to your database network firewall and border
firewall and vice versa.  You will have to restrict the access from
the LAN users on the LAN network firewall, and just blindly trust all
traffic coming from the LAN network NAT IP on the database server
firewall AND border firewall and vice versa.  We currently have a 2
layer NAT between our public and internal network and a firewall
between each network, however we do not NAT between our internal
private networks so that we can provide both outbound filtering on the
LAN networks and inbound filtering on the server room network.
Probably redundant, but I just don't like having "Allow all traffic
from this entire network into our server room" rules, I prefer to have
my most strict rules on the most important firewall, and I monitor the
logs on that firewall MUCH more.  We are a large spread out network,
though.  It is possible to do all of this with a single router and
firewall and switches with VLANs and be fully PCI compliant.


On Jan 16, 2008 4:34 PM, Josh Haft <pacmansyu () gmail com> wrote:
> So the question remains... how do PCI regulations directly affect the
> segmenting of networks, if at all?
>
>
>
>
> On 16 Jan 2008 19:58:44 -0000,  <evilwon12 () yahoo com> wrote:
> > The assumption of items being untrustworthy is good, however it is a bit overboard to state that a DHCP network is 
> > more untrustworthy than one with purely static IP addresses.
> >
> >
> > If a bad guy has physical access to machines on, or access to your PCI network nothing else matters.  The mission 
> > to protect data has failed.  This has nothing to do with DHCP, hard coding addresses to mac addresses or using 
> > 802.1x (although this is much better).  In places that I have been, people have had to badge into the building, 
> > pass a security guard with a picture badge, and then badge into the door to get into the area with the PCI network 
> > (segmented from other corporate networks).
> >
> >
> > Segmenting out the network is a good thing if you are dealing with PCI, if it is done properly.  The key with it is 
> > to properly segment it while still ensuring business functionality.