Tag: scoping

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 pcidss@pkfmalaysia.com 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!

PCI-DSS and how we messed up the scope


Reflecting on challenges of a recent PCI-DSS project for a client and the key learning points for an effective implementation

People team challenges – having a team to champion the project

When we started the PCI project, we were faced with multiple changes in the client’s project manager and so the project was like a car unable to start on a cold morning (for those old enough to remember there were such cars back in the 80s!).

Eventually, by working with the client, the musical chairs stopped and we had a stable project team to champion the PCI-DSS project.

The importance of the scope

By then, so many changes had been made in the systems and people that we were asked to rescope the work.  Now, scope in any PCI-DSS project is absolute key. If you start wrongly, you will definitely go down the rabbit hole and never come out.

(Mis)Understanding the process flows

The client described how the credit card data was fed into their system through the credit card terminals connected to their POS systems in their nationwide store network.

Initially, we were quite surprised that credit card data would be flowing back into the retailer’s system so they could do their reconciliation.  Our experience suggested that retailers would simply transit credit card information through the credit card terminals to the acquiring bank and then receive back a transaction ID or approval code.

Further enquiries got the same answer and we were assured that the information would be ‘encrypted’ and stored in ‘encrypted’ form.

On the basis of their answers, the client expected to undergo an onerous Self-Assessment Questionnaire, consisting of over 320++ questions!

Managing information

Our team took their word for it, and began the project by asking them to draw out their process flows so we could assist them in scoping their systems and completing an asset inventory (a key part of the PCI-DSS programme) together.

And this was where things got a little messy.

Because they insisted the credit card terminals that were interacting with the cards belonged to the acquiring bank and they had no influence over it, they did not have an asset list.

Also, with a significant number of branches it was difficult to provide an asset list to cover all relevant hardware and software across the portfolio.

The pushback caused the project to once again grind to a halt. Without a scope confirmation, we could not start any PCI implementation for them, in case we over-committed or under-committed on the plan.

Benefits of documenting process flows

The project was being worked out at management level for a long time before it was brought up to the director level, but once it did, things began to move.

We decided to go on the ground to a few of the store locations to really see what was going on.

What we found out surprised everyone:

Credit card information indeed never flowed back into the client’s system!

Getting the terminology right

The so-called ‘encrypted’ credit card information from the bank that was supposedly sent back to the client after the authorization, was in fact, ‘truncated’, not ‘encrypted’.

Apparently, the client had thought these were the same thing.

In PCI speak, encrypt means to protect credit card details by making the information unreadable with a key. The main reason is that there is a need to ‘de-crypt’ the information back again.

Truncation, on the other hand, meant that the card number itself, when sent has already its numbers ‘X’ed out. This is different in a sense that truncated card information is NOT card information because the critical numbers have already been X’ed out, leaving (usually) just first six and last four numbers of the credit card number visible.

Immediately, it was like a light being flipped on.

The team worked hard to optimize the scope by confirming the other flows and observing live transactions take place.

At the end of a 2 day onsite scoping assessment, we concluded that this client was eligible for a much reduced – only around 80 questions – assessment and then by filtering further, we pared down their compliance questions to only 40 reducing the scale of this compliance project by more than 85%.

Key messages

The takeaway here, from our experience would be:

  1. All PCI-DSS assignments require a stable and strong project team – get the right people, in the right place, with the right focus
  2. Understand the client’s terminology and descriptions and then check and check again. Ensure that you start from the best position, and not chasing the wrong end of the stick.
  3. For PCI-DSS merchant compliance it is essential to explore if the client is eligible for any reduction in the scope and don’t just go with the default. The time and cost elements of getting this wrong could be very substantial.
  4. Nothing beats being onsite and to undertake live walkthroughs of the actual processes. In this case, the earlier the better, so the assignment can be properly scoped.  A different set of eyes might be able to unlock the project obstacle – and in our case, it was essential to have the onsite scoping exercise.

Finally, because of these findings, the compliance is now ongoing and finally we are seeing the light at the end of the tunnel.

If you have any queries on your scope or compliance on PCI-DSS, drop us an email at pcidss@pkfmalaysia.com and we will get back to you ASAP.

PCI DSS and the Problem of Scoping


I recall in an actual case a few years back when I received a call from a company requesting us to do a certification for PCI for them. So I met them and drew out their PCI plan starting with a gap assessment, remediation and certification audit.

They said they have already done their own gap assessments internally by their ISMS guys. And they will be doing all their remediation on their own and they just needed me to quote for certification audit because “PCI is forcing us to be certified by a third party, which we believe we can do it better than you can”.

There was nothing much to talk to them about, but I did mention that if we find major NC (non compliances, in ISMS speak), we would then use that ‘certification audit’ as our own gap assessment and that we might be required to come back again to verify.

The company truly believed that PCI was a subset of ISMS and they handled it as such.

So we came in for the certification and found out that their entire scope was completely messed up. For instance, there was another out of scope network and systems connecting into their CDE for monitoring. Because card data wasn’t passing through, they marked it as out of scope. Unfortunately, PCI doesn’t see it that way. This would be considered an Non CDE In Scope, and systems within this network will need to be secured as well, and hardened as per PCI. The logic is that if these systems are compromised, there is a path into the CDE that can be exploited.

They made a huge fuss on this, claiming that they are willing to absorb the risk and that their management signs off on the risk assessment.

ISMS is a best practice/guideline at best – it’s a great marker for security, but PCI is a standard. If you can’t meet it, then you don’t meet it. Of course, there are ways around this particular issue, but they insisted we passed them simply because their management accepted the risk.

Here’s another idea: PCI-DSS generally doesn’t really care about your business. It’s not about you. It’s about card data. Visa/Mastercard and the Jedi PCI council are not concerned about your business – they are concerned about the confidentiality and integrity of card data. That’s why you will not find any BCM or DRP requirement in PCI. RTO and RPO? Pfft. They don’t care. Your business can go down for 10 weeks but as long as card data is safe, it’s good.

And that’s why, scoping is HUGELY important. Many people might think that a gap assessment is a waste of time. It is, if it’s done incorrectly. I recently witnessed a ‘gap assessment’ report that was a complete mess. It just detailed the PCI twelve requirements and in each requirement gave an overview of the company’s controls and what they should be doing: ripped off almost verbatim from the actual standard itself. That can be downloaded for free.

A gap assessment needs to bring you from one place to another and needs to provide these:

a) A clear understanding of your scope, including a writeup on your network, and processes that have been assessed. It should also be clear what is out of scope. This initial scope usually is not set in stone as remediation would sometimes change what is in scope and what is not in scope. But at least you have something concrete to start with.

b) If possible, an asset register. For PCI. If this is not possible (for many reasons, e.g they have not purchase some assets required for a control), then the asset inventory needs to be prioritised a quickly as possible to see what is scoped and not. Asset should be clear on: Public ips, internal devices, servers, network devices, people involved, desktops, databases etc.

c) Network in scope and out of scope. This is key as companies are required to identify segments scoped out, and do segmentation testing. Also, CDE is clearly marked, NON-CDE IN SCOPE (we call it NCIS) must also be identified. Systems in NCIS could be monitoring system, SIEM, AD etc. Any system that connects to the CDE, but does not store, transmit or process credit card data are considered NCIS. NCIS must be scoped for testing, quarterly scans, hardening and such.

d) Clear roadmap for remediation and recommendations to proceed, specific to the organisation. These ‘gaps’ should all have a corresponding solution(s).

If the gap assessment doesn’t give you any of these, then it’s pretty useless. If it doesn’t move you forward or provide you with the information to move forward, it’s not a gap assessment. It’s an expensive training session.

So back to the first example of a customer. It wasn’t possible for us to certify them no matter how they argued, because simply they were not compliant (there were also many issues that they did not comply, for instance storage of card data in text files and sending via emails).

As a lesson – don’t neglect the proper scoping. It’s hard work, but as I always say: Start wrongly, do wrongly, finish wrongly. And that’s 6 – 8 months down the drain, with thousands of ringgit gone in investing, and job on the line. The second example is pertinent also. There is always a chance to OVERSCOPE as there is to UNDERscope.

An overscoping example would be to purchase all sort of snazzy security systems worth thousands of ringgit only to find that these were not needed, or that current controls were sufficient. It’s nice to have – but most of our customers, no matter how big they are, always have a trigger on the budget and cost optimisation is the topmost in their priority.

If you want us to help you in your PCI-DSS scoping, drop us a note at avantedge@pkfmalaysia.com and we can get you started with the initial understanding straight away!

© 2024 PKF AvantEdge

Up ↑