0

Question

Would using a firewall MITM capability to inspect all HTTPS web requests be against PCI compliance/rules?

Further Info

We have an issue where we need to allow access to some HTTPS sites on hosts that are in the PCI zone. The option we're leaning towards is to load the firewall certificate as a trusted CA on the hosts that need to access these sites so that the firewall can inspect the requests - this would also impact requests off to the payment providers.

To me, this seems like bad practice and seems like something that shouldn't be allowed under PCI (what if the firewall certificate is compromised etc).. but are also lots of use cases where I've seen this (in particular in workplaces)..

Is this allowed under PCI DSS rules? Any info on which rules would or would not allow this (if any) would be helpful.

2 Answers 2

1

Would using a firewall MITM capability to inspect all HTTPS web requests be against PCI compliance/rules?

Not necessarily - as long as it does not violate DSS rules such as storage of Sensitive Authentication Data (SAD) or unencrypted storage of Primary Account Numbers (PAN), it's fine.

What you're describing is effectively a Web Application Firewall (WAF), and the DSS §6.6 merely lays out expectations that a WAF:

  • Is situated in front of public-facing web applications to detect and prevent web-based attacks.
  • Is actively running and up to date as applicable.
  • Is generating audit logs.
  • Is configured to either block web-based attacks, or generate an alert that is immediately investigated.

The fact that the WAF will perform MITM decryption and re-encryption is not mentioned in the DSS itself, but it does come up in Supplement Requirement 6.6 Code Reviews and Application Firewalls Clarified which says the WAF should be able to:

Support SSL and/or TLS termination, or be positioned such that encrypted transmissions are decrypted before being inspected by the WAF. Encrypted data streams cannot be inspected unless SSL is terminated ahead of the inspection engine.

4
  • This info is very useful, thank you! In this context, I think a WAF might refer to something ele. The firewall is not between the client and the application, it's between the application and the card provider.. The client is actually an IVR (telephone call, pressing DTMF digits), this then talks to a web application internally and that internal app talks to the card provider. The firewall would be between app and card provider (and/or other internet endpoints required by the app)
    – jmurphyau
    Aug 16, 2021 at 21:37
  • @jmurphyau if the device "can inspect the requests" it's WAF-like... it may call itself a next generation firewall, an application-aware firewall, a content-inspection engine, or something like that. WAF is just our most succinct term for "device that inspects content before passing it on," even if the WAF is protecting something like OLTP or batch processing or something that isn't technically 'Web'. "Application firewall" is the closest match to what you're looking for in DSS.
    – gowenfawr
    Aug 16, 2021 at 23:23
  • I think the point I was trying to get at is this is being used as a mechanism to allow access to websites - instead of whitelisting thousands of IPs for example for Office 365.. So this isn't a potential external threat accessing our systems, this is an internal system (trusted, could be web app could be something else) accessing an external system (trusted), like the payment provider themselves or a trusted third party.. In this example, the provider would have a WAF but it doesn't make sense to consider our end also to have a WAF for that traffic? thats where im seeing the difference
    – jmurphyau
    Aug 17, 2021 at 0:33
  • @jmurphyau I see, you're questioning whether this inspection makes sense for outbound legs. That's a reasonable question, but to take this back to PCI, nothing in the DSS has an opinion on that.
    – gowenfawr
    Aug 17, 2021 at 1:05
0

As @gowenfawr notes, DSS is silent on this other than requirement 1.3.4 which explicitly requires this capability:

Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.

So your use of a TLS intercept for outbound control and inspection certainly allows you to meet this requirement.

There is however requirement 4.1 to consider if the outbound transmission contains cardholder data - and as your question says "this would also impact requests off to the payment providers." - I'm going to assume it does.

Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks, including the following:

  • Only trusted keys and certificates are accepted.
  • The protocol in use only supports secure versions or configurations.
  • The encryption strength is appropriate for the encryption methodology in use.

There are three things to consider.

  1. Remember DSS is silent about the encryption of cardholder data over internal networks -- it is not a requirement, so the connection between a) what ever is sending ChD out of the environment to the payment processor and b) the MITM device is not a PCI DSS concern (yes, it's a security concern, make sure you manage that internal cert properly)
  2. Requirement 4.1 then applies to the connection between the MITM device and the payment processor, so you need to make sure that the three bullet points of the requirement are fulfilled. Is the device checking the authenticity of certs? Are they expired? Are only secure versions of TLS allowed? Will it downgrade TLS crypto suites if asked? etc.
  3. However, DSS is not silent about the encryption of "authentication credentials" over internal networks (requirement 8.2.1), so if there is a chance that such "authentication credentials" will be decrypted and examined by the MITM device, then the certificate management and strength of cryptography between the device and whatever made the transmission would be in scope of meeting a "strong cryptography" test. And here I'm mostly thinking about an admin interface at the payment processor that allowed access to cardholder data. This may also apply if the device is acting as a cloud access security broker (CASB) between in internal CDE and a second CDE located at a cloud provider. (An edge case I know, but you should consider it, and if it doesn't apply document this to show your security assessor it had been thought about).

And finally, because the MITM device both transmits and processes cardholder data, it is definitely in scope of all the PCI DSS requirements and is part of your cardholder data environment.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .