Problem to Solve:  My company must comply with PCI.   Can I even run APM/NPM tools inside my business?

Contributing Author – Robert Wright, Network Engineer with 15+ years experience

The Great PCI Myth

When I started researching PCI for the first time, I found that many IT managers believed their teams are unable to deploy sniffers, NPM, and APM tool sets because in their minds, it would place them into a state of non-compliance. Those beliefs relate to the fact that many sniffer and performance vendors rely on packets to generate their data sets. Thus, if these tools have access to the packets, then the technicians using or administrating the product must also have access to this raw communication. This isn’t necessarily true. Lets get started on debunking this myth!

What is a Packet and How Does it Relate to PCI?

When information must travel between two network attached devices it is placed into a unit of data called a “packet”. This packet includes basic information such as where it is from and where it needs go. In addition to this address information, you will also find a payload which will include either a request for data or the response.

For example, Robert slides his credit card inside a grocery store to purchase a loaf of bread. When he slides his card through the machine, card holder data from the magnetic stripe located on the rear of his card is transmitted via packets to the appropriate bank for authorization. If he has an appropriate amount of funds, the bank will respond with an approval. This is an example of data communication which falls under the PCI DSS standard.

Another example. Robert sends his best friend Ken an email asking for fashion advise concerning baseball hats. When Robert completes the email to Ken and hits send, the email and all of its content is converted into a series of packets destined for Ken’s inbox. Because Robert’s email does not contain cardholder data, it is not required to comply with PCI.

The last example shows that just because information is placed into a unit of data called a packet, it does not mean it must comply with PCI. If I were to add details around where Robert’s or Ken’s laptops were connected, then that could likely create a situation where PCI would apply.

What is Considered Cardholder Data?

Per PCI DSS 3.0 the definition is as follows

Account Data
Cardholder Data includes:	Sensitive Authentication Data includes:
Primary Account Number (PAN) Cardholder Name Expiration Date Service Code	Full track data (magnetic-stripe data or equivalent on a chip) CAV2/CVC2/CVV2/CID PINs/PIN blocks

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

What is Cardholder Data …….. in English?

To confuse things even a little bit more for the average person working in IT, the standard utilizes generic terms in certain areas. So the chart below should put things in perspective.

PCI	English
Primary Account Number	Credit Card Number
Cardholder Name	Cardholder Name
Expiration Date	Expiration Date
Service Code	Where the can be used and if PIN is required.
Full Track Data	Magnetic-Stripe
CAV2/CVV/Etc	Security code
PINs/PIN Blocks	Think ATM withdraw

What does PCI DSS v3 say about “Packet Sniffers”?

The standard itself calls out packet sniffers twice explicitly, and both times are limited to the “Guidance” column. Guidance as dictated by the standard is as follows:

Guidance – This column describes the intent or security objective behind each of the PCI DSS requirements. This column contains guidance only, and is intended to assist understanding of the intent of each requirement. The guidance in this column does not replace or extend the PCI DSS Requirements and Testing Procedures. 

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf    (see page 18)

Now direct your attention to the two excerpts below from the official standards document. So in both instances the standard is attempting to convey to the reader the importance of following the requirements to avoid being compromised by these simplistic attacks. In no way is it stating that packet sniffers or sniffer based technology is not permitted.

… wireless sniffers can eavesdrop on the traffic, easily capture data and passwords, and easily enter and attack the network …   2.1.1 Guidance PCI DSS V3

… malicious individual can easily intercept unencrypted passwords during transmission using a “sniffer,” … 8.2.1 Guidance PCI DSS V3

 

No requirement? Then Sniffers for Everyone!!!

Hold on there Superman. While v3 doesn’t explicitly call out the prohibition of sniffers or systems deriving themselves from packets, doesn’t mean its the “wild wild west”. Care must still be headed, and the decisions you make will determine if you receive CIO recognition or produce a resume generating event.

Officially the standard states we can store various credit card data if we follow various criteria (PCI DSS v3 Table 1, Page 8; Requirement 3.3, Page 37; Requirement 3.4, Page 38). While other data sets, i.e., Pins. are forbidden from being stored even if rendered unreadable (Requirement 3.2, Page 35).

But before we continue… You must ask yourself an important question. Of the data that is permitted to store why would I want my NPM/APM solution to store it? Do I even have a valid business reason to do so? This is an absolute critical path when reviewing the procurement of a solution or application permitting retrieval of packets.

For basic network troubleshooting, utilizing what is referenced to as “headers” is enough to facilitate most needs. While the “payload”, where this sensitive data lives, can be thrown away. Now there are various methodologies to remove this data-set. We can implement this easily enough through filters due to PCI requirement 1.1.3 which requires the documentation of cardholder data flows.

Best Practice

The best methodology in my opinion is to utilize aggregation switching which supports the ability to perform packet slicing.  You can reference this previous blog on the topic.   https://problemsolverblog.czekaj.org/aggregation-switch/deploying-aggregation-switch-cisco-nexus-environment/    This removes both the administrative and processing overhead of other tool-sets performing this function. For compliance purposes, providing a single location where this control is implemented will make your life easier. But maybe your project doesn’t include an aggregation switch, what then?!

The best strategy when not utilizing an aggregation switch, is to select tools which derive metadata from the actual raw data, yet doesn’t actually store the packet. The “bee’s knees” is selecting a solution which permits you to select which individual protocols have their packets stored, while simply saving the metadata for PCI sensitive protocols.

In any solution, confirm with the vendor what packet capture capabilities exist (reactive or proactive) and if appropriate access controls can be implemented regarding who can run packet captures. And finally but not least, verify that audit logs are kept for each packet capture.