Month: May 2018

PCI and the art of scoping

A lot of people we have met had told us this: “Since we are ISO27001, PCI should be a piece of cake, right?”

The context of this is because ISO27001 and PCI are often seen as distant cousins. They are both very relevant in our country and region (unlike other compliance like HIPAA), both deal with information security, and the overlaps between the Annex A controls of ISMS and PCI are evident. Therefore, the natural conclusion is ISO27001 is either a superset or a subset of PCI-DSS.

The problem with this assumption begins right at the start. In ISO, the scoping is largely determined by information that matters to your business. Before the iteration of 2013, scoping was generally done in a cowboy sort of manner. We met a company who had tons of sensitive information and told us they were ISO27001 compliant – and their scope was the security of their printing documents. Yes. How they literally secured the hard copies of the printouts. That was their scope statement.

Now 2013 version of ISO27001 had tried to stem these shenanigans by introducing interfaces and dependencies. Basically now the scope needs to cover information that are deemed important enough to protect from business perspective. This would cover the products and services relevant to the context of the organisation. Overall, scope determination of the ISMS can be a prolonged matter if you have a large organisation, and is often subjected to the business side of the organisation.

PCI scope?

It’s determined by the information that matters to the payment card brands, not your organisation. Credit Card Information. Primary Account Number. That’s it.

If you store, transmit and process PAN, PCI applies. If you don’t do any of these, and you do not influence any transactions in the payment card flow, then PCI doesn’t apply.

Often, people express utter shock that PCI doesn’t have any business continuity requirements. In terms of the holy trinity of information security – Confidentiality, Integrity and Availability (CIA), PCI primarily focuses on Confidentiality. Integrity is only focused in terms of its relation to confidentiality (Integrity of logs, integrity of system changes, system files etc), and there is no concern on Availability. Which makes sense. Between you closing down your business for one week versus you losing credit card information of your customers, the latter is viewed as more critical to the payment brands than the former. Although from a business perspective, a loss of business for a merchant is a loss of business for the entire data flow, upstream or downstream, so PCI not really caring about your RTO or RPO may be counter productive – but that’s an argument for another day.

At the end PCI scope boils down to you storing, transmitting or processing card holder data (CHD). Even if you don’t do any of these 3, you might still be in scope if you influence the security – an example would be those SAQ A e-commerce merchants that redirects requests to another PCI service provider. Even though they don’t deal with the CHD, they influence the transaction through their redirects, therefore, some parts of the requirements need to be met.

So – before we start our PCI journey, it is  very important to know what is the scope that is covered in your PCI environment. We may not want to take the whole environment as IN SCOPE – for cost, quality and timeline purposes. Our normal practice here is to reduce the scope as much as we can, a process we consultants term as “Scope Optimisation” simply because it sounds grand. I mean it sounds better than “Reduce your scope” which generally is interpreted to “reduce your price”.

In general, there are six things that we have to compile before we truly initiate the PCI journey.

a) Location and Address of the PCI scope. This is simple enough. Usually your data center is in scope. Depending on whether you store, transmit or process card data in your other offices, those come in scope as well. A question here would be – what about HQ, where our administrators access the PCI systems in DC, via a VPN connection? Ah. The secret sauce of putting things out of scope in a remote location where there is no storage, transmission or processing (lets just shorten these to STP from here on) of card data but there is access from an admin systems – multi-factor authentication. As long as this is in place, while the admin system is in scope, the location itself is then put out of scope. So you can connect from Starbucks, your home, or Timbuktu, and you would not have these locations dragged into your precious scope.

b) Applications that STP CHD. Store, transmit or process card holder data. Many queries have been like – oh, do we need to use PA-DSS applications? Well, if you do use PA-DSS certified applications, it would be very useful. However, even if you do not, you can still access that application as part of your scope under Requirement 6. In fact, some applications may not even be able to be PA-DSS for many reasons, such as it not being part of the authorisation or settlement flow but still storing card data. A custom CRM for example would be one that cannot be PA-DSS but still in scope for card data application. OTC (off the counter) products that store card data are still in scope, however, they need to be assessed properly to determine if there are any security issues that may influence the confidentiality of card information.

c) Network Diagram – an updated network diagram is a must. And a network diagram needs to be detailed enough to be able to differentiate the PCI and non-PCI zones. The important thing we need to take note on the network diagram is the proper demarcation of PCI zones, so we know what are:

  1. Card data environment in scope (CDE-IN-SCOPE) – ZONE A
    1. Any system that store or process or transmit CHD
    2. For example, application server, Database server
  2. Non-Card data environment in scope (NON-CDE-INSCOPE) – ZONE B
    1. Any system that require to communicate with CHD
    2. For example, patch server, anti-virus server
  3. Out of Scope – ZONE C
    1. System not related and has no communication with CHD – but might communicate with NON CDE IN SCOPE.
    2. For example, CCTV server in your office environment

d) Asset List for PCI – the asset list is critical because this relates directly to the effort and remediation costs of your PCI program. There is a huge difference in doing pentest for 200 systems versus 20 systems. So in this case, we don’t care about your assets considered not in scope, we want to know the assets in CDE and in NON-CDE in scope (Zone A and B).

e) Public IP addresses – this is needed because of ASV scans required. ASV scans are security scans done by the ASV (Approved Scan Vendors) of PCI. You can’t do it yourself, you need to get an ASV to do this for you.

f) Data Flow Diagram – This shows the card data flow in your organisation. Basically every channel where credit card enters into your environment, stored and process and exits. This details the lifecycle of CHD in your organisation whether it ends up being stored in a database for seven years, or passed out to another service provider. It’s essential to understand this – and if you have multiple channels where card is being entered (e.g e-commerce, POS, MOTO, Call Centers, KIOSKS etc) you need to document each of these from start to end.

So there you have it. PCI scoping at your fingertips. Drop us an email at and we can have a free session with your organisation on what could be your possible scope, which likely may not be just your printouts coming out of your printer!

Proxies in PCI

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.


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 for more information on how we can help your PCI-DSS program!


© 2020 PKF AvantEdge

Theme by Anders NorenUp ↑