By now we all know that the key to becoming PCI compliant is all about how well you can control the number of in-scope devices. Obviously, the smaller your scope the better. The challenge is how to efficiently and judiciously reduce your PCI scope without breaking everything and costing you a ton of cash. Re-architecting your network to reduce and define PCI scope is one of the first action items you need to complete as you work towards compliance. Unfortunately, it is also one of the highest hurdles of the process. Well you know what they say, "When on a trip around the lake, always paddle into the wind first." Your right, I made that one up but it doesn’t' change the fact that your PCI journey is very front end loaded.
Once you have reduced the number of in-scope devices and networks as far as you realistically can hopefully the road to compliance now seems manageable. Being PCI compliant does not mean you are secure. However the reverse is usually true, if you diligently follow security best practices already then it is likely you will be PCI compliant or darn close. If your company has been doing its due diligence in securing IT then now is the time you will reap the rewards of that diligence. If you were the one responsible for it be sure to crow appropriately to the powers that be and show them how much time and money you've saved them. ☺ If you're on the flip side of the whole diligence thing, well then its time to pay the piper as it were.
I've compiled 5 tips and trinkets that you can employ to assist you on your drive towards PCI compliance.
1) Use VRF Lite for traffic and host segmentation. VRF-lite is built-in to several of Cisco's switch products. In a nutshell, it allows you to create a multiple and completely separate routing tables/domains within the L3 switch. You then can assign ports/vlans to individual VRF instances. As an example, you could create a PCI VRF and put all of your PCI devices into it. A VRF routing table is completely separate and has no visibility into the other VRF routing tables or the global routing tables. Hosts in a VRF can only talk to another VRF if you specifically allow it. Where you choose to have the VRF's meet you will put a FW at that choke point. Here is a parial configuration of how it is done. It is pretty easy.
description Wired Guest subnet
ip vrf forwarding guest
ip address 172.16.11.2 255.255.255.0
ip helper-address 172.18.2.10
standby 11 ip 172.16.11.1
standby 11 timers msec 250 msec 800
standby 11 priority 105
standby 11 preempt delay minimum 180
router eigrp 100
no passive-interface Tunnel0
no passive-interface Tunnel1 no auto-summary
address-family ipv4 vrf guest
network 172.16.100.0 0.0.0.255
network 172.16.200.0 0.0.0.255
network 172.16.11.0 0.0.0.255
6500-1-Bldg#sh ip route vrf guest
Routing Table: guest
Gateway of last resort is 126.96.36.199 to network 0.0.0.0
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.11.0 is directly connected, Vlan11 188.8.131.52/30 is subnetted, 2 subnets
C C D*EX 0.0.0.0/0 [170/297372416] via 184.108.40.206, 00:00:32, Tunnel1
220.127.116.11 is directly connected, Tunnel0 18.104.22.168 is directly connected, Tunnel1
[170/297372416] via 22.214.171.124, 00:00:32, Tunnel0
2) Use GRE tunneling to create centralized or localized network chokepoints that then pass through a stateful firewall. GRE tunneling can be combined with VRF –lite such that you create a PCI VRF that then dumps into a GRE tunnel. This tunnel from the remote switch can travel over the network back to a central switch where traffic drops out into a VLAN. The only way to get out of the VLAN is through a FW. This creates the segmentation required for PCI compliance. GRE tunneling is available on all Cisco routers and their 4500 and 6500 Catalyst switches. GRE is done in hardware only on the 6500 making it the most ideal platform for this. The hub configuration is shown below for an mGRE tunnel. mGRE is multi-point GRE, meaning multiple spokes coming into a single hub. The nice thing about this is you only configure the hub once and it doesn't have to change as you add new spokes.
ip vrf guest rd 100:1
description src mGRE tunnel for Guest
ip address 10.122.200.10 255.255.255.255
description mGRE tunnel for Guest
ip vrf forwarding guest
ip address 126.96.36.199 255.255.255.0
no ip redirects
ip nhrp map multicast dynamic
ip nhrp network-id 10
tunnel source Loopback10
tunnel mode gre multipoint
3) Take advantage of the security features built-in to your deployed routers. This one seems obvious but it is overlooked more than you would think. Cisco routers that have the security feature set or higher come with a full featured firewall, a functional IDS/IPS feature and of course VPN functions. For remote sites where you already have Cisco routers deployed it costs nothing to turn on the security features that will provide you the PCI segmentation, stateful FW and IDS that are required. The IOS FW can be configured in either layer 2 or layer 3 mode, it understands VRFs and can be virtualized. This allows you to use one IOS router to provide FW services to multiple networks at a time. A very common scenario is FW protecting the PCI domain from the non-PCI domain and Firewalling off wireless networks at the remote site at the same time. For more info on IOS Firewall see here http://www.cisco.com/en/US/products/sw/secursw/ps1018/index.html
4) Use client Certificates for two-factor authentication to save time and money vs. tokens. Traditionally two-factor authentication was synonymous with hardware one-time password tokens. Hardware tokens have been distributed for years to protect remote access into companies around the world. The issue with hardware tokens is they are expensive; and to a lesser extent are prone to get lost or broken. The good news is PCI allows you to use certificates for the second factor. Certificates are significantly cheaper to deploy and in some cases are more secure than hardware tokens. I've already written a few articles on this topic so check out my previous blogs here http://www.networkworld.com/community/node/24291
5) Use Layer 2 firewalls to reduce the amount of work caused by VLAN segmentation. Layer 2 firewalls work like bridges. For example suppose you have one PoS terminal on a VLAN (corp) with 50 other hosts that have nothing to do with credit card information. If you do nothing then the PoS terminal's precense will cause the other 50 hosts to become in-scope for PCI thus creating more work and expense for you. Layer 2 firewalling (also called transparent FW) makes it possible for you to quickly segment off the one PoS from everyone else. To do this you simply create a new VLAN (pci-vlan), change the PoS terminals switch port to be a member of pci-vlan and force all traffic through your L2 FW that connects the pci-vlan with the corp vlan. You do not need to create a new subnet on the pci-vlan or re-address the PoS terminal since a L2 FW is just a network bridge and not a router. So pci-vlan and corp vlan will be part of the same subnet. Pretty slick and saves you a ton of time and aggravation.
Those are my five shortcuts to help you become PCI compliant a little bit easier and cheaper. Hopefully you can make use of a couple of them in your environment. If you have any questions about them just comment back to this post. If you have any tips of your own please do share. Good luck!
The opinions and information presented here are my PERSONAL views and not those of my employer. I am in no way an official spokesperson for my employer.
More from Jamey Heary:
* Credit Card Skimming: How thieves can steal your card info without you knowing it
* Why you should always shred your boarding pass
* Video rental records are afforded more privacy protections than your online data
* The truth about new SSL attacks
* 2009 Top Urban Legends in IT Security/a>
Go to Jamey’s Blog for more articles on security.