PCI DSS – The devil is in the…….diagrams

PCI DSS - The devil is in the…….Diagrams, pci dss, pci ,payment card data security standard , infosec, information security, iso 27001
When looking at the key success criteria for any PCI compliance programme, there is no disputing
the importance attached to accurately scoping the cardholder data environment (CDE). 

 

Within this blog, we are not going to delve into the murky depths of why a network component may be in
or out-of-scope (thank goodness I hear you say), but hope to remove some of the confusion surrounding
the documentation of the overall CDE and how to demonstrate that all the disparate components of
complex environments are interrelated.

 

Yes, we’re talking about DIAGRAMS!

 

Network diagrams (high-level and detailed) and dataflow diagrams are mandatory requirements of the PCI DSS and are
key ingredients of any successful Report on Compliance (RoC). However, when we are conducting PCI assessments, we are
often find the diagrams that are presented to us fail to include the necessary criteria for compliance.

 

The harsh reality is that creating compliant diagrams which provide value to an organisation take time and effort to produce.
In this blog, we have put together some guidelines to help you create compliant and useful diagrams.

 

Network Diagrams

Firstly, let’s start by clarifying a couple of basic requirements
  1. The ‘High-level Network Diagram’ is not actually part of a PCI control, but is a separate diagram required within a RoC
    executive summary.

 

  1. The ‘Detailed Network Diagram’, also required in a RoC executive summary, is tied to assessment steps for PCI controls
    1.1.2, 1.1.4, 6.4.6, and 11.4. The main thing to note is that an inadequate diagram potentially renders these controls non
    -compliant.

 

Unfortunately, we find that the naming of the two network diagrams serves only to create further confusion.  As we shall explain,
the name of the network diagram in the section heading does not accurately correspond to the level of detail required by their
associated reporting instructions.

 

The so-called ‘High-level Network Diagram’ actually requests considerable granular detail.

The ‘High-level Network Diagram’ is not actually part of a PCI control, but is a separate diagram required within a RoC executive summary.

The inclusion of key systems, POS devices, systems, databases, webservers and other payment components are all items
which would ordinarily be expected in a more detailed diagram.

 

The ‘Detailed Network Diagram’, however, is representative of an overview with less granularity.

The ‘Detailed Network Diagram’, also required in a RoC executive summary, is tied to assessment steps for PCI controls 1.1.2, 1.1.4, 6.4.6, and 11.4. The main thing to note is that an inadequate diagram potentially renders these controls non-compliant.

The detail required includes segmentation, network connections and communication points which would generally regarded
as ‘higher-level’ requirements and does not require the level of granularity that most people would expect or anticipate.

 

Dataflow Diagrams

The ‘Dataflow Diagram’ required in the RoC executive summary is tied to reporting instructions from PCI DSS control 1.1.3.
 The diagram(s) should be closely linked with dataflow narratives to provide a holistic view of the CDE, illustrating inbound,
internal and outbound flows of CHD.  A dataflow diagram must include all payment channels and processes where CHD is
handled.  Managed service providers (MSPs) or other entities that do not store, process or transmit CHD, are expected to
detail flows for whatever process/service was assessed in the RoC.

 

Reporting Instructions

To meet compliance, the ‘High-level Network Diagram’ needs to clearly:

  • Represent all physical locations in the RoC
  • Show in-scope and out-of-scope segments (possibly with shaded boxes around each area)
  • Show all inbound and outbound connections to the CDE and protections for cardholder data (CHD)
  • Illustrate segmentation within the CDE, including devices enabling segmentation (For large, complex environments,
    representative segmentation can be used)
  • Label all segments and the labels must match segmentation narrative in the RoC
  • Represent wireless segments with appropriate icons
  • Indicate representative icons and labels for all security devices related to PCI controls, any system in the payment flow
    and any other critical systems providing services to the CDE
  • Identify virtualisation technologies and the hypervisor. Related management hosts and actual virtual/guest systems
    should be indicated separately (For large environments, representative icons can be used)
  • Explain colours/shading/icons through the use of a key.

 

To meet compliance, the ‘Detailed Network Diagram’ needs to clearly:

  • Illustrate the CDE versus the non-CDE
  • Illustrate all connections to the CDE from areas outside the CDE
  • Illustrate all wireless devices both in and out of the CDE
  • Illustrate all connections to third-parties, card brands and other business units
  • Illustrate all physical locations in the RoC
  • Indicate, for connections into and out of the CDE, all protections on the transmitted CHD
  • Label all segments and this labelling should be consistent across all diagrams in the RoC
  • Explain colours/shading/icons through the use of a key
  • Show the date it has been produced/updated, indicating a review within current assessment year.

 

To meet compliance, the ‘Dataflow Diagram(s) need to clearly:

  • Depict any and all storage, processing or transmission of CHD
  • Align with the two (2) network diagrams with respect to locations, CDE boundaries, devices and data protections (Use
    the same labelling methods for consistency)
  • Depict all payment channels, processing flows or any other flow of CHD detailed in the RoC (card-present, card-not-present,
    PIN/Debit, batch processing, fraud, loyalty or any process that involves a Primary Account Number (PAN)):
    • Depict flows that correspond to Capture, Authorisation, Settlement and Chargeback
    • Include any other flows of CHD applicable to the assessed environment
    • Entities not handling CHD (e.g. MSP), should depict any process that is covered in the RoC
  • Depict all payment applications
  • Depict all storage locations and protections applied to the stored data
  • For communication across open/public networks or untrusted networks, indicate the protections on the CHD and/or
    communication channel
  • Depict all wireless segments/transmissions and associated protections on the CHD
  • Show the date it has been produced/updated, indicating a review within current assessment year
  • Explain colours/shading/icons through the use of a key

Conclusion

The key message from this blog is not to allow an inaccurate depiction of what exists in your environment to derail your assessment. 
Taking extra care in developing diagrams will be time well spent and will help to alleviate any unnecessary stress at a time when you
and your staff are likely to be inundated with evidence requests and are spending time adjusting / enhancing the CDE to comply with
the other PCI controls.  On many occasions, we have observed the benefits of collaboratively developed diagrams helping to propagate
an understanding of the environment and being used as a tool to keep abreast of developments and changes which may affect the
organisation’s compliance.

 

If you would like to explore how URM’s consultancy and training services can benefit your organisation, we offer a ‘no obligation’ discussion with a senior member of our consultancy team.  Please let us know the specific challenge you are facing within our areas of expertise e.g. information security (ISO 27001, PCI DSS), data protection (GDPR, DPA 2018), business continuity (ISO 22301) and risk management so that we can arrange a discussion.