PCI Compliance Tip – Preparing Network Documentation

As we continue our series of blogs hitting on some tips to help your organization maintain PCI compliance, we’re going to take a look at network documentation. When preparing for an initial PCI-related audit or trying to maintain your compliance program over time, an important part of that is your network documentation. This includes things like network diagrams, cardholder data flow diagrams, asset inventories, etc. If this documentation isn’t well maintained and up-to-date when you start a PCI assessment, it can cause issues for every other phase of the assessment. Let’s look at some different tips for preparing network documentation and cover some of the impacts if these things aren’t taken care of.

Why Should You Care?

First of all, network documentation is extremely important when it comes to PCI, as it helps to drive and confirm the scope for the entire assessment. Strong network documentation can make an auditor’s life easier and, in turn, make your audit go much smoother. But the converse is also true. Complicated network diagrams can lead to mistakes in scope, by both the organization and the auditor, leading to the mis-application of requirements for certain portions of the network. Poorly maintained or out-of-date network diagrams can lead to non-compliance (these documents are required to be kept current per PCI DSS Requirement 1.1.3) or result in inaccurate scoping which can lead to wasted resources or non-compliance.

Additionally, if changes are made to your network architecture and your diagrams/inventory aren’t also updated, it can be hard to go back and catch up after the fact. A quick change becomes a more resource intensive research project to figure out what changes have been made and understand what the network really looks like in practice. If items on your inventory can’t be found on your network diagrams, or vice versa, this can lead to additional scrutiny for an auditor or an extra project for an employee.

Ways to Improve Network Documentation

Now that we understand why this is important to your compliance management (not to mention overall security), let’s dive into some considerations that may help you maintain compliance and make your life easier:

• Make sure you have all appropriate documentation – Before we can make improvements to documentation, we need to make sure it exists. You can check out our tips for PCI documentation we have provided in the past, but these should be current and dated when last modified. For networks and scoping at a high-level, you’ll want to at least have:
  • Network Diagrams – These should cover all aspects of your PCI environment and include enough detail to show individual devices (with names/IP addresses) and connections. Groupings for particular VLANs or subnets can be used where they make sense, but for smaller environments it’s usually more helpful to show all in-scope servers and network devices, at a minimum.
  • Cardholder Data Flow Diagrams – These can be as simple as colored overlays to your network diagrams noted above. It should be clear exactly what systems and devices come into contact with CHD at any point in time.
  • Hardware/Software Inventory – This should include all in-scope systems/devices and software per PCI DSS Requirement 2.4.
• All network documentation should be accurate and up-to-date – Every organization needs an internal process to keep this kind of network documentation current as changes are made to a network over time. For compliance purposes, you should be confirming that these processes are actually happening and documentation is being updated. At the very least, before you undergo any type of PCI gap analysis or a full onsite assessment, you should review each one of these to confirm they are accurate.
• Ensure network documentation is consistent – This is different than just making sure the documentation is updated and is a problem we run into quite often with organizations. The provided network diagram does not match the CHD flow diagram and neither match the provided inventory. This creates a lot of confusion when you’re performing an audit and can lead to a lot more scrutiny. Additionally, if these records don’t match up it’s very likely that systems or devices aren’t getting all of the same security controls applied throughout an environment, as well.
• Apply these standards consistently through your organization – PCI DSS should really be nothing more than a minimum baseline for security controls and a set of guiding principles for how you need to think about security in your organization. In many cases, PCI’s recommendations do not even meet what most security practitioners would call security best practice. But too often we see companies that try to apply PCI requirements to only the payment card portion of their business and ignore the guidance or standards developed for everything else. Not only does this lead to inconsistent application of internal processes, but it can create more work for your organization to try and figure out what needs to be secured, what doesn’t, and constantly worrying about what is in-scope or not. While not all controls make sense to apply across the board, try and maintain a consistent set of policies and procedures that can be used throughout your organization that meet PCI’s minimum baseline.
• Utilize this documentation – Yes, these documents are a compliance requirement if you want to adhere to the PCI DSS. But that doesn’t mean that these documents have no other use for your organization. Your team should make it a habit of referring to your inventory and diagrams when making architectural changes and rolling out new security controls. This ensures that nothing gets left out when you’re rolling out new or modified security controls (e.g. do all your systems have the same AV product that is getting updates and logging back to your central server) and network changes don’t impact your security posture negatively.

These are just a few things that come up regularly when it comes to network documentation. There are a lot of other considerations for PCI compliance and security best practice that we will continue to try and point out as we come across them. Our goal when it comes to compliance is to make it easy, attainable, and repeatable for organizations. We also want organizations to not simply check a box when it comes to compliance, but to use the standard as a guideline to enact meaningful change on security. As always, if you’re not sure how to get started or need help sifting through how to apply compliance requirements to your organization, let us know!