This is the third blog in the series focused on PCI DSS, written by an AT&T Cybersecurity consultant. See the first blog relating to IAM and PCI DSS here. See the second blog on PCI DSS reporting details to ensure when contracting quarterly CDE tests here.
PCI DSS requires that an “entity” have up to date cardholder data (CHD) flow and networking diagrams to show the networks that CHD travels over.
Googling “enterprise network diagram examples” and “enterprise data flow diagram examples” gets several different examples for diagrams which you could further refine to fit whatever drawing tools you currently use, and best resembles your current architecture.
The network diagrams are best when they include both a human recognizable network name and the IP address range that the network segment uses. This helps assessors to correlate the diagram to the firewall configuration rules or (AWS) security groups (or equivalent).
Each firewall or router within the environment and any management data paths also need to be shown (to the extent that you have control over them).
You must also show (because PCI requires it) the IDS/IPS tools and both transaction logging and overall system logging paths. Authentication, anti-virus, backup, and update mechanisms are other connections that need to be shown. Our customers often create multiple diagrams to reduce the complexity of having everything in one.
Both types of diagrams need to include each possible form of ingestion and propagation of credit card data, and the management or monitoring paths, to the extent that those paths could affect the security of that cardholder data.
Using red to signify unencrypted data, blue to signify data you control the seeding or key generation mechanism for and either decrypt or encrypt (prior to saving or propagation), brown to signify DUKPT (Derived Unique Key per Transaction) channels, and green to signify data you cannot decrypt (such as P2PE) also helps you and us understand the risk associated with various data flows. (The specific colors cited here are not mandatory, but recommendations borne of experience).
As examples:
In the network diagram:
In the web order case, there would be a blue data path from the consumer through your web application firewall and perimeter firewall, to your web servers using standard TLS1.2 encryption, since it is based on your web-site’s certificate.
There may be a red unencrypted path between the web server and order management server/application, then there would be a blue data path from your servers to the payment gateway using encryption negotiated by the gateway. This would start with TLS1.2, which might then use an iFrame to initiate a green data path directly from the payment provider to the consumer to receive the card data, bypassing all your networking and systems. Then there would be a blue return from the payment provider to your payment application with the authorization completion code.
In the data flow diagram:
An extremely useful addition to most data flow diagrams is a numbered sequence of events with the number adjacent to the arrow in the appropriate direction.
In the most basic form that sequence might look like
- Consumer calls into ordering line over POTS line (red - unencrypted)
- POTS call is converted to VOIP (blue - encrypted by xxx server/application)
- Call manager routes to a free CSR (blue-encrypted)
- Order is placed (blue-encrypted)
- CSR navigates to payment page within the same web form as a web order would be placed (blue-encrypted, served by the payment gateway API)
- CSR takes credit card data and enters it directly into the web form. (blue-encrypted, served by the payment gateway API)
- Authorization occurs under the payment gateway’s control.
- Authorization success or denial is received from the payment gateway (blue-encrypted under the same session as step 5)
- CSR confirms the payment and completes the ordering process.
This same list could form the basis of a procedure for the CSRs for a successful order placement. You will have to add your own steps for how the CSRs must respond if the authorization fails, or the network or payment page goes down.
Remember all documentation for PCI requires a date of last review, and notation of by whom it was approved as accurate. Even better is to add a list of changes, or change identifiers and their dates, so that all updates can be traced easily. Also remember that even updates which are subsequently reverted must be documented to ensure they don’t erroneously get re-implemented, or forgotten for some reason, thus becoming permanent.
