A proxy server is a server that serves as an intermediary between the requester (a client PC for example) and the responder (typically the destination server). There are 3 types of proxy servers that are commonly implemented in many organisations:

  1. Forward proxy – this is the most common proxy server. A forward proxy is a proxy server that serves the request of the internal client and processes the request for the client by sending and receiving the response from the destination server. In the most common implementation, it is an ‘internet facing’ server that will retrieve internet resources and return it to the requesting client. How is this useful? For one, it serves as a single point for security access control. If you have hundreds of systems coming through your firewall asking for a thousand of requests per second, a proxy can do a few things. It can control who gets what access. Additionally, if implemented with caching capability, a thousand requests for the new Beyonce video don’t need to get that video downloaded a thousand times. I can cache within the proxy and serve it up internally. Cool!
  2. Reverse proxy – Reverse proxy is the opposite of a forward proxy in terms of traffic flow. It is allowing what can access your internal resources. Again, it is an external facing proxy server that accepts request from an external requester and sends the request to the internal servers (for instance, an FTP, HTTP or SMTP server). The response returned to the requester will be as if it was coming from the proxy server. There are few objectives for reverse proxy e.g. shielding the internal servers from the outsider, load balancing, security controls etc.  It’s fairly easy to set up as well.
  3. Transparent proxy – transparent proxy is a proxy server that sits between the requester (client) and responder (server) and there is no configuration required on the client side. A transparent proxy is generally deployed inline, meaning, between the client to whichever gateway it is going to . It intercepts the client request before forwarding it to the destination, without the knowledge of the client. This is useful if you have thousands of systems, and limited control, or you just don’t like group policies from AD. Transparent proxy normally is used as a content filtering,  Internet traffic control and web caching.

Is a proxy server useful when it comes to remediation for your PCI DSS compliance? Yes it is . There could be some cost saving scenarios where a proxy server is useful.

Where can proxy server applies? An example: a client is running MariaDB on a  Linux server and using clamAV  for malware protection and they have a database storing credit card number (FULL PAN). Obviously, this server will be in a CDE “in scope” segment (Card Holder Data Environment in-scope).

In PCI DSS 3.2   Requirements and Security Assessment Procedures requirement 1.2.1 and 1.3.4, while it states that the traffic coming and going out from the CDE must be restricted, it does not state that you cannot have an outbound traffic from a CDE to the Internet. Below is the reference to the PCI DSS for inbound and outbound traffic to/from CDE:

1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.

Specifically INBOUND:

1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.

1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.

And OUTBOUND:

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

On proper reading, inbound traffic is a strict no-no for Internet to CDE. So either you tackle this with an intermediate server in the DMZ, or a reverse proxy can come in play.

Outbound is a little more flexible, whereby all traffic should be restricted

Restricted isn’t prohibited, but there is a good reason why proxies become useful here.

a) It’s better that organisations do not to expose their CDE systems to the Internet, even for outbound. This makes sense, even though in most cases you will likely NAT your outbound connections through your firewall. But try arguing this with your QSA and you will probably wish you had just implemented controls instead.

b) Firewall policy minimisation. Why? Because you need to do a firewall review. Imagine you have 50 systems in your CDE requiring patches or connectivity to external. You would need to have a policy that adds/removes these systems to specific ports, destination etc on your firewall. With a proxy, you deal with one IP going out.

So for the above example, if the client can’t expose their CDE segment to Internet, a forward proxy can be set up. Setup a proxy server (e.g. Apache, etc) in the DMZ (in scope) segment. Configure the database server to point to the proxy server. With this setup the database will be able to get the antivirus update through the proxy server but without connecting directly to the internet. The proxy server serves as the intermediary between the database server and the internet. The QSA is happy and everyone passes PCI.

In this example, implementing a proxy server is not the only method that can be used to connect to the internet and have antivrus getting the update. You can set up a ‘repository’ server in a non-CDE, in scope environment which will then download the antivirus updates and patterns and the CDE server pulls the updates from this server (like WSUS for Windows). As in many things PCI, or obtaining the latest Beyonce video online, there are a few ways to skin a cat.

Contact us on pcidss@pkfmalaysia.com for more information on how we can help your PCI-DSS program!