Network Sniffing and PCI

[trooney75]

I am working on PCI compliance with a large merchant that is struggling with the requirement for encrypting cardholder data anywhere it is stored. Does anyone know if an official declaration has been made regarding network sniffing? This company performs network sniffing to troubleshoot problems and at some point may have to capture cardholder data. I have traditionally advised against sniffing cardholder data, but I know there may be a business case made for its value. Has anyone run across a similar scenario? Thanks.

[lyalc]

Nothing in PCI says you can't diagnose network (or applicaiton) issues using any valid tool.
In the case you really do need to keep the packet captures, you would need to treat the packet captures as any other file containing card data - erase/overwrite as soon as not needed, encrypt under a suitable key management process, or use a series of pipes to re-write the packet captures with masks over the card number e.g. via regular expressions.

But why do you need to retain the packet capture to begin with. Only reason I can think of is legal evidence, and suitably PCI-aware chain-of-custody processes could be suitable to a QSA.

Lyal

[adam.muntner]

A NIDS that stored full packet data or entire streams after a trigger is hit might capture this stuff inadvertently.

[trooney75]

The standard does say that sensitive authorization data can never be stored. This data, while not stored by the payment application, would pass through the network monitor device. For forensic purposes, the device has a 7 day cache. Therefore, if the solution were implement, the device would see and store sensitive authorization data. The data is passed using SSL encryption on the stream, but that still conflicts with the PCI standard. I just want to perform due diligence on behalf of the merchant. The PCI standards council is slower than the DMV in responding to inquiries, so I thought I would hit the professional community.

[lyalc]

If the stream that is sniffed is encrypted, and the IDS/forensic tool doesn't have the SSL certificate/Private key - so what?
The sniffed data is stored encrypted.
Show that the sniffed data packet is always segregated from the SSl certificate keys stores, (and old private keys are deleted/destroyed) and the intent can be argued to have been met.

If the forensice device has un-encrypted authorisation/sensitive data, or access to the link/SSL keys, then the capture files must be deleted, or sanitised as per section 3.

Lyal

[trooney75]

First, I must retract a previous statement that the council does not respond in a timely manner. I received a response to my inquiry inside 10 working days. A great improvement upon previous inquiries. Included is part of the response received from the PCI standards council:

{Text Removed}

You must take into consideration what cardholder data your monitoring device is capturing and secure that data per PCI Data Security Standard. If the network device is capturing ‘transactional data passed by POS’, you should ensure you are not capturing ‘sensitive authentication data’ (full track, CVV2/CVC2/CID) which cannot be stored subsequent to authorization.

{Text Removed}
{End of Text.}


My interpreation of this response is that the council is stating that network sniffing with capture cannot be performed if the CVV2 value if passed by the POS. My understanding is that the CVV2 value is passed by the POS to complete the transaction, so in this case, the solution cannot be implemented.

[K Heath]

The PCI DSS requirements are quite specific in this regard, full track data, the CVV2 and the PIN block must not be stored post authorisation, even if encrypted. I'd consider capturing this information with a network sniffer would contravene the PCI DSS.

I guess you would have to consider whether your NIDS or sniffing tool can be configured to selectively not capture, or delete from the capture log, this information.