When it comes to PCI compliance, there's no such thing as "too careful." One of the keys to being careful enough? Isolating and protecting servers that handle cardholder data from the rest of your network.
You already know that you need to keep systems holding cardholder data secure and prevent access from outside your network. But there's more to it than that — PCI-compliant systems should be isolated from the rest of the company's systems as well.
Businesses have a range of systems and networks, and the access and policies that go with the various systems should reflect their importance and sensitivity of the data held on the systems.
PCI requirements are fairly stringent. In a large organization, ensuring that all computers meet PCI standards can be difficult to say the least. Depending on the nature of your business, you may also need to comply with different standards with different systems. For instance, you need to install and maintain firewalls for cardholder data. Now, you should do this already, but by ensuring that PCI systems are separate from the rest of the network you can guarantee that they are appropriately firewalled.
Finally, isolation reduces the scope and cost of audits. PCI-DSS requirement 11 calls for regular tests of security systems and processes. By isolating systems, you limit the number of systems that need to be audited for compliance or in the event of a possible breach. Systems storing data that needs to comply with HIPAA may be managed and audited separately. And so on — not all systems are equally sensitive.
Finally, you may have to communicate over unsecured networks. The PCI-DSS 4 requirement says you need to encrypt transmission of data over open, public networks. (Even if it didn't, you'd want to do this anyway.)
How do you ensure this sort of isolation? Instead of relying on user authentication alone, make use of machine authentication to ensure that only trusted systems have access to networks and system that hold payment card and cardholder data. One way to do this is using IPSec.
IPSec (Internet Protocol Security) is a set of standards designed by the Internet Engineering Task Force for securing communications over public and private networks. Why IPSec instead of SSH/SSL?
IPSec isn't application specific, and no special support needs to be added to any applications communicating over IPSec. It's scalable and helps to ensure all applications communicating over the network are encrypted, and it provides security at the machine level rather than the user level. To quickly send files over the Internet, SSH is a great way to go. To ensure that all communication between two PCI-compliant machines at two corporate offices are secure, you want to consider IPSec.
What do you need to do to get IPSec support on Linux? Nothing, really. IPSec is natively supported on Linux. See, for example, the IPsec-Tools page or Red Hat's guide to implementing IPSec on Red Hat Enterprise Linux (RHEL).
If you're running Linux, you're set. But the odds are, your company isn't running Linux exclusively. In fact, it's unlikely that all of the systems that need to be PCI compliant are only running Linux.
So you need to find a solution that works across platforms. TechRepublic has a short guide for mixing it up with Linux and Solaris, or this guide for Linux IPSec and Windows XP. It's possible to implement IPSec across platforms without anything but the tools available natively, but you may want to use a commercial solution like DirectSecure to simplify the process and add in Active Directory Support.
No matter how you approach it, it's important to ensure that your PCI compliant systems are isolated from any untrusted systems on your network and from the open Internet.