Category: Technology (Page 6 of 11)

We are Minerals being Mined

It is often said, and its almost cliche – Personal Information is the new currency.

And now, with the news on Facebook and Cambridge Analytica, we are faced with the sort of global privacy crisis that we always knew it would be coming. Furthermore, it wasn’t as if Cambridge Analytica was a key data broker/trusted partner/premier solutions arm of Facebook. It just developed software to get the data. That’s it. 50 million users.

It was as simple as getting an app to use your facebook login to enter the app and that’s it. We think we are just logging into the app, but we are actually allowing the app to login into our facebook and take everything. Everything.

But what did we actually expect? Think about it.

Did we expect to have such a service like facebook where we can get information, connect with long lost friends, advertise our solutions and products, express our opinions in a global platform, create online value, message and chat, have thousands of hours of free access to apps etc etc – FOR FREE?

Unless Zuckerberg has the title of a ‘Saint’ in front of him, then that would be a hard sell.

No, Facebook says. You guys agreed to it. The terms of services says it. The one that is too long for you to humanly read. The one that they update without letting you know, and allowing trickles of liberality of information usage to seep in.

Facebook even contends that developers who have these information from their app cannot “transfer any data that you receive from us (including anonymous, aggregate, or derived data) to any ad network, data broker or other advertising or monetization-related service.”. That’s pretty kind of them. But in the first place, did Facebook inform users that their apps would be literally stealing the entire bank of information from the users?

It’s the sort of finger pointing activity you would expect – a phrase and sentence here and there that says, “Hey, we told you we are getting your information and we told these guys not to share! What can we do if they do share??!” But is Facebook giving excessive details? So in PDPA terms, it’s not just about third party sharing of information, it is about excessive collections.

In any case, I don’t think we have a case of PDPA against Facebook here as they do not have any systems in Malaysia processing personal information. But the point is that we have wittingly or unwittingly sold our information to Facebook in order to get the services they provide. Same for Google. Same for Apple. Same for Instagram. Same for Pokemon-go.

A great site we always give in our presentation of PDPA or information privacy to clients is: https://tosdr.org/

Terms of Services Didn’t Read. It’s a great site that basically summarises all the terms of services to human readable content and rate them according to how cavalier they are with our information. All the big guns are there. Even if not rated, we can look through their terms and have a little more details on what we are ‘paying’ them.

Take a look at Google, Youtube, Twitter to start with.

Facebook’s TOS:

  • The copyright license that you grant to Facebook goes beyond the requirements for operating the service. For instance, it includes the right for Facebook to transfer the license or to license it others on their terms (“sublicense”). Also, the copyright license does not end when you stop using the service unless your content has been deleted by everyone else.
  • This service uses cookies to track you even if you are not interacting with them directly. Amazon for instance, use cookies to track your device and serve targeted advertisements on other websites (Amazon associates, websites using Amazon Checkout). They “obtain certain types of information when your Web browser accesses Amazon.com or advertisements and other content served by or on behalf of Amazon.com on other Web sites”.
  • Facebook automatically shares your information with Bing, Pandora, TripAdvisor, Yelp, Rotten Tomatoes, Clicker, Scribd, and Docs, unless you manually opt-out.
  • Including: data analysis, testing, service improvement, control of the effectiveness of the personal ads, and location features and services.
  • You must use your legal name publicly on the service. Using a pseudonym or a pen name is not allowed. This can have negative consequences on the freedom of expression, especially for people who exercise certain professions, or who live in certain countries.
  • Facebook uses, pixels and local storage in order to gather information about you, your device, your browser cache, your use of Facebook. Facebook also uses cookies for adversing purposes.

For years I have advocated clients (and also my personal friends and family) to use Facebook with these in view. For family: Never post about your current location. Never put photos of your children up online. Never reveal too much about your views and opinions. For work: Never give any views on your current work, the time you finish work, the after drinks parties etc etc. Basically, never give any relevant information.

Will Facebook be able to still get information? For sure. Every “Like” you click. Every news you click. Even when you are not on Facebook, and you are browsing the web, there are Facebook plugins that can track what you are searching for. Even if you search on Google, whatever you are looking for will appear eventually on Facebook. Data brokers and advertisers trade our information like anything – and what you do on Google surfaces in other social media platforms.

But we know. Services aren’t free. Our parents says, “There is no free lunch” and this is certainly true. But how much do we know about this lunch we are paying? We might be getting Subway sandwiches, but paying the money for Burgers and Lobsters dining. That, I suppose, is what the world is now only finding out.

For more on our information security services and PDPA services, drop us an email at avantedge@pkfmalaysia.com. The only thing we are collecting from you is whatever you tell us on that email. That’s our term of services!

 

 

PCI-DSS Segmentation with Host-Based Firewalls

One of the frequent queries we have faced in the past months as we ramp up our consultancy and advisory for travel agencies and other merchants, has been the question of segmentation.

Now, before travel agencies were imposed with the requirement for PCI-DSS by IATA, we had very few opportunities to work with small merchants for PCI-DSS. It’s not because small merchants are exempted from PCI. They are not. Small merchants must be PCI compliant, but in reality, very few banks are chasing smaller merchants for their compliance. Our experience with merchants had been with the fairly large ones – the large petrol companies, the large retailers, the telcos and the largest travel agency being our experiences. From the time we started PCI back in 2010 to around 2014, it has mainly been for financial institutions and banks. But now with IATA flexing their regulatory muscle to make sure agencies are PCI compliant by 1st of March 2018, we have had plenty of opportunities to go into much smaller environments that we are used to. And it has been a really great experience.

So when we discuss about the topic of network segmentation, we need to be clear from the start:- it’s actually NOT a PCI-DSS requirement. PCI doesn’t state that we need to segment our network. We could very well be PCI compliant on a flat network. Page 11, of PCI-DSS v3.2 states so:

“Without adequate network segmentation (sometimes called a “flat network”) the entire network is in scope of the PCI DSS assessment.”

And we have done this before. One of our client has a completely isolated network for PCI-DSS with its own gateway and basically its a flat network with everything as CDE (Card Data Environment). Possible, but in enterprise environment, probably not so realistic if it drags in hundreds of systems. Without going too much into scoping, the main topic of this article is: if we need to segment, how do we do it?

At the onset, the question seems superfluous. How to segment? Why, by network subnets of course, or by VLANs (virtual LANs). These terms (subnet and VLAN) have been used interchangeably by myriad of customers over the years, and in most cases, they actually do multiple VLANs across different subnets, but in theory you can also have VLANs on single subnet as well. So, no – VLANs and subnetting are actually not the same but for the sake of not being pedantic, most of the time, we just allow the client to use whichever term they choose.

In most cases over the years, our clients won’t have a problem with this. Segmenting either via VLAN or network subnet, they can achieve this fairly easily through their switch or their edge router, as they usually have advanced firewalls/routers/L3 switches deployed in their network.

But going into the very small companies with a handful of people, no technology personnel, and running the D-Link DIR-615 low end routers provided by Telekom? How do we do this?

We have heard other consultants declare that these companies need to invest in enterprise grade firewalls/routers to achieve PCI compliance, because some of the entry level router/firewalls are unable to do any segmentation or VLAN. Of course, you could hack the DIR-615 to WRT and that might provide you some limited VLAN capability, but that’s beyond the scope of this article. And in any case, we doubt any of the smaller merchants have the inclination to fiddle around with their routers. So if you are stuck with a firewall/router that cannot do any network segmentation, does that mean that everything needs to be brought into scope? Does that mean you need to spend thousands to get a firewall upgrade?

So let’s have a couple of references here. First of all, the canon document from PCI will help, this is the official PCI-DSS v3.2 documentation, page 11, stating a few salient points:

Without adequate network segmentation (sometimes called a “flat network”) the entire network is in scope of the PCI DSS assessment.

This phrase actually enables many people to pre-suppose that PCI is stating that the only segmentation allowed here is by the methods we discussed above – i.e anything that creates a non-flat network. But this is confusing because when we say ‘flat network’, we are already indicating we are referencing to Layer 3. However it’s entirely possible to have layer 2 VLAN isolating systems within the SAME SUBNET (multiple VLANs – Single Subnet design). Heck, you could even have multiple subnet on a single VLAN if you want … I think I remember this from my Cisco CCNP days. So, actually, in theory , unless PCI refers to something else when it says ‘Flat Network’, their statement isn’t that accurate. You could isolate systems in a flat network.

Network segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists, or other technologies that restrict access to a particular segment of a network.

While agreeing on this one as a whole, the other confusion here is the term “Physical OR logical”. As tech nerds, we take these conjunctions very seriously. For instance,  my wife asked me the other day if I wanted a cheeseburger OR a double quarterpounder happy meal. The answer to that would be “TRUE”, meaning, Yes, I can have cheeseburger OR a double quarterpounder since “OR” here is inclusive. As long as any or both of those statements are true, it’s true.  This is usually what we do in Boolean values, for instance

1 > 2 || 3 > 2 = TRUE

1 > 2 && 3>2 = FALSE

So back to the phrase Physical OR logical, this generally means PCI accepts Physical segmentation, even if there is NO LOGICAL SEGMENTATION? What does that mean? Does it mean if I have two systems hooked into the same switch, on the same network, pinging each other, I set up a physical brick wall between these two systems, I have achieved Network Segmentation? Surely not. The physical segmentation example here would be having two separate switches servicing two different networks as opposed to using a single switch and using it’s logical functions to achieve that segmentation. Can both be used or one or the other? Yes, either can be used. So whoever have written this phrase either needs to clarify this statement proper, or simply, he or she is !(Tech Nerd).

At a high level, adequate network segmentation isolates systems that store, process, or transmit cardholder data from those that do not.

So finally they decide and say, ok, anything that ISOLATES systems can be considered network segmentation. So at least we have a lead here to go with. Anything that ISOLATES.

The next journey we take is to this document:

https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf

Section 3.1, page 13:

Examples of controls that could be applied to prevent out-of-scope systems from compromising a connected-to or security-impacting system include:

– Host-based firewall and/or intrusion detection and prevention system (IDS/IPS) on in scope systems that block connection attempts from out-of-scope systems.

This is one indication that PCI looks at alternate ways of ‘segmentation’, other than getting an enterprise grade network firewall. Once more, the conjunction used here is “AND/OR”, which we take to mean, either AND (&&) or OR (||) can be used for these two statements (Host-based firewall, IDS/IPS). So what this basically states is that a host-based (not network firewall) firewall is good enough, if configured properly to be considered as a segmentation tool.

Now if you do know a little history behind this documentation, it has a grandfather document called “Open PCI DSS Scoping Toolkit”, a copy can be found here:

https://www.isaca.org/Groups/Professional-English/pci-compliance/GroupDocuments/OpenPCIScopingToolkit.pdf

This was way before the PCI-DSS document came about. We had to use the OPEN PCI scoping toolkit to define what is in scope, not in scope, CDE, non-CDE in scope etc. This is why sometimes we say systems that are non CDE are ‘infected’ , i/e pulled into scope because they are in the same subnet/VLAN. This term isn’t found in the PCI document but is used in the old scoping toolkit document. Of course, this document is deprecated and the SSC doesn’t officially endorse it. However, some concepts had made its way into the SSC scoping document and what we are focusing here is mainly on the usage of host based firewall, and whether it’s logical for it to be used for some sort of segmentation. Other parts of this document has been succeeded by the official PCI scope document, so be aware. Back to this document, a few QSAs had looked at us in amusement when we used these terms and some even commented that these are very strange terms we are using, showing how young these QSAs actually are. I am not sure about the other regions, but I have had discussions with QSAs who are 10-15 years younger than me and never had one day of experience in actual security operations. One QSA even insisted we put our logging system into the DMZ as good security practice, which I then responded with an emoji face slap to our customer. With all due respect to QSAs, I have had many arguments with them over the years – some are very good, very experienced; while some are, as Bart Simpson would put it: “Meh.”

Anyway, we digress.

In the scoping toolkit, Page 13 gives an indication of what we are talking about:

The mechanism providing the isolation or controlled access functionality may be either logical or physical. Examples of mechanisms include network and host-based firewalls, virtual routing and switching appliances, and access control lists

This is still less clear due to our “AND” and “OR” arguments, because aside from the illogical “logical or physical” statement (which PCI clearly inherited), we have the problem stating “network and host-based firewalls, virtual routing and switching appliances, and access control lists”. This, to us, might mean we need ALL of these things for isolation to be TRUE.

Thankfully, this is clarified further down in Page 36:

In order to restrict other workstations on the same network from being “infected,” the dumb terminals must be isolated (e.g., using a host-based or network-based firewalls, etc.).

The example here is “using a host-based or network-based firewalls.”. As you now are very well aware, this means this statement is true if any of these options, or both these options are true.

You see, some writers do not think twice about the usage of “AND” and “OR” operators or ‘conjunctions’ to normal English-speaking people. These are extremely powerful operators and carry entirely different meanings to what normal people may deem as normal sentences having the same meaning. Another key life example here would be if your wife (again a very relevant example) were to ask you after a late night out with the guys whether you’ve been to the bar to watch football or to watch strippers, to which you respond: “YES”.

So be careful because different people parses sentences differently, depending on whether you see life in code or not. It could very well change your life.

We have also discussed this topic of segmentation at length with some senior QSAs (QSAs who have much more experienced compared to the green horns) and they have agreed that host-based firewall, or Host IDS are acceptable forms of isolation, but requires a significant amount of configuration to ensure isolation is done properly. “Done properly” here carries a fairly subjective weight to it. QSAs are a funny lot, because many of the requirements in PCI are general, and then it’s up to the QSAs to decide whether a particular control satisfies their own concerns whatever that might be. To summarise, segmentation can be carried out easier through deployment of a network firewall and getting the segmentation rules sorted out there, but if the merchant is short on funds, and have 1 or 2 systems only to configure, a fix could be a “properly configured” host-based firewall, or a host-based IDS/IPS.

Segmentation testing still needs to occur, though, but that will be for another article for another day.

Now, I will have my coffee OR tea to finish up my day. TRUE.

For more information on PCI-DSS, feel free to drop us an email at pcidss@pkfmalaysia.com.

PCI-DSS: SAQ A and SAQ A-EP differences in a nutshell

OK, we are tackling this wonderful subject for the second time. We have last year touched on this through this post. Unfortunately there are still so many questions on this, that we feel that we need to re-tackle this matter again.

One response a company received regarding this issue from their payment processor was as follows (when merchant requested if they can do SAQ A-EP)

“No. SAQ A-EP you are still not allowed to transmit card data. Please have a look at below snippet taken from the SAQ A-EP AOC:

* All processing of cardholder data, with the exception of the payment page,is entirely outsourced to a PCI DSS validated third-party payment processor.

* Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor.

If you want customers to enter their card data on your website you require the
PCI SAQ D.”

And so, our lengthy reply was as follows:

Your payment processor could be correct (or incorrect) depending on how your page is set up. They are sort of correct in saying you are not allowed to ‘transmit card data’. Because in the SAQ A-EP example, you serve the payment page, and then the card data is transmitted from the user desktop directly to the Payment processor. It is the way the SAQ A-EP is worded that makes it so confusing. You can clearly see that these two statements may sound like they actually conflict each other:

* All processing of cardholder data, with the exception of the payment page,is entirely outsourced to a PCI DSS validated third-party payment processor.

* Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor.

If you read the above, it actually says that, all processing must be outsourced except the payment page (meaning the merchant can host the payment page). The below statement seems to shoot itself in the foot by putting in “The website does not receive cardholder data but controls how cardholder data is ‘redirected’ to a payment processor.” Unfortunately this is not the only place where PCI SSC mucks up its documentation. I can name like a dozen more times they read like its written in Hebrew and translated to English after that.

The only way to really explain is to refer to two documents I will refer to here – first, the “Understanding SAQ document” and the other is from VISA itself, the “Processing Ecommerce Payments Guide” which is what SAQ A vs SAQ A-EP is based on.

Read Page 4 of Understanding SAQ document and tell me how you interpret the table.

Its basically saying the payment page can come from EITHER the merchant website OR a PCI DSS website. As if that’s not enough to clarify, the next page, PCI even gives an example, whereby the “MERCHANT SITE CREATES THE PAYMENT FORM”. So this is clear. The payment form CAN BE IN YOUR WEBSITE.

Apparently they differentiate “receive cardholder data” and creating a payment form doing a direct post to the payment processor. Because in the form, you can send it directly to the processor to process the form posts and input, or you can process it on your own (I used for instance <form action=”PHP_SELF”> which was many years back to reprocess the form input in the same page). The latter example is what they mean by “receive cardholder data”. Not by creating the form itself, but by actually processing what the form is sending when user clicks submit.

You can process it, and then send it to the processor; or you can send it to the processor direct and have them process it.

The first one is SAQ D, the second one is SAQ A-EP. Both occasions the form is still residing on your merchant page. It is what happens after the ‘submit’ is clicked that is important.

If you want to read further, Visa has a better document, the “Processing Ecommerce Payments Guide”. In page 5, the bottom table clarifies a lot.

Basically if you are a merchant 3 and 4 doing either a direct post or javascript, with payment page sitting on your website, then you are eligible for SAQ A-EP.

Lets look at direct post in page 10 and tell me what you are interpreting.

  1. The merchant website CREATES a payment form and SENDS it to the customer computer
  2. The customer computer displays the payment form
  3. The customer enters their card data into the payment form and presses the OK button
  4. The customer computer SENDS the card data to the PSP

The red parts are all done IN YOUR ENVIRONMENT or your customer. Only in step 4 is the card data sent directly to the PSP. So yes, technically, your website is only “serving” the payment page. Once the page is ‘served’, it goes via direct post to the PSP when the submit button is clicked.

SO, in conclusion:  The key thing here is that if your website is directly processing the entries of the forms, then it falls under XML or ‘anything else’ and that’s SAQ D and your processor is correct. This is page 14 of the ecommerce payments guide from VISA. We sometimes see this in merchants who create the form, then for some reason or another prefer to process the information entered into the form and then only sends the information on its way to the processor. They don’t store it, but they process it first before shooting to the processor.

Once more, you can see this by your form. If you have a <form action=”to your own page” or current_page or whatever> then basically you are processing the form before sending to your processor. If your action is to direct to the processor site, then SAQ A-EP can be used.

Hopefully this matter is put to rest!

PCI-DSS v3.2 for ePetrol Services Sdn Bhd

Congratulations to ePetrol Services Sdn Bhd for being certified PCI-DSS v3.2 Level 1!

ePetrol is a secure and reliable payment switch and service provider that offers a variety of payment solutions to a broad spectrum of industries encompassing oil and gas, finance, healthcare, retail, e-Government and telecommunications.

Founded in 2007, ePetrol – a subsidiary of Dialog Group Berhad – is a MSC status company which conceptualised and pioneered an innovative payment system which uses the Malaysian National ID Card (MyKad) as the payment instrument for purchases of goods and services. Their MyKad solution is also designed for welfare distribution and subsidy management.

Besides payment, ePetrol offers variety of IT solutions such as Loyalty Solution, Scheme and Entitlement Solution and Enterprise Management Solution to meet the client’s needs.

PKF and ePetrol actually had started the PCI journey together earlier, however due to the move from their old office to the current Dialog Tower, we then rebooted the process. We are happy to be part of the journey of PCI and the highs and lows we have had with the team. It has truly been a fulfilling experience in the project and we are looking forward to serving ePetrol for years to come.

Congratulations!

IATA and PCI-DSS to Travel Agents: Data Channels

PCI

IATA has for a few years been championing the need for PCI-DSS to the travel agencies that are registered under them. More recently, they have been pushing compliance for PCI and even made a deadline at June 2017 for all agencies to be PCI compliant. Unsurprisingly like many well intentioned deadlines, it is now pushed further back to March 2018. Our prediction is that by November or December this year, we might see yet another delay in the deadline. But that doesn’t mean there’s any let up in compliance. Therefore, we’ve been reaching out to many of the agencies who were our clients previously and letting them know if they need help on their SAQ, they know where to find it. Us!

Now, just to summarise, being registered with IATA means a big deal to an agency. It simply means you can issue tickets. So how it works is that IATA is like a national ‘switch’. Whereby registered members can receive calls from clients, and based on pricing etc, select the airline and pricing and issue these tickets – either to other clients or in behalf of even other agencies. Firstly, there is credit card involved, of course. Secondly, IATA members can tap into the BSP – the IATA Billing and Settlement Plan. This is like a huge payment switch – whereby it handles all the payments to multiple airlines from the agencies, so that agencies don’t have to deal individually with airlines for settlement of the tickets. Which is good. Secondly – there is the GDS (the global distribution system). There are a few players in the market – Sabre is one of the biggest (used by Malaysian Airlines), others are like Amadeus, Patheo etc. We’ve so far encountered Sabre and Amadeus in our clients and both of these are PCI certified providers.

So, with this basic understanding of how agencies work, how does PCI apply?

First of all, unless IATA makes a statement otherwise, agencies DO NOT NEED a QSA to do a level 1 certification or sign off on SAQ, unless explicitly requested do. Since IATA is the processor for the agencies in this case, it’s their call. But it’s a big call, because level 4 merchants aren’t very large and they might not be able to get QSAs to help sign off their documents. We are working with one of the largest merchants at the moment and even they are not requested by their acquirer to get a sign off on SAQ from a QSA.

99.99% of agencies out there will fall under the Level 3 or Level 4 merchant band and we all know what that entails – SAQ, signed off by their executive – only if required should they get a QSA to participate. But it helps to have someone that knows about PCI or else you would be groping in the dark with the SAQ options.

What we see a lot are merchants automatically selecting SAQ D-MER when it comes to PCI. Again you don’t have to.  Depending on the number of channels you have you might be able to select C-VT, or B, or even A-EP, A. We call these specialised SAQs – remember, if you don’t meet any of these criteria, you drop into the SAQ D bucket.

What many people don’t know is that you can opt for a separate SAQ for each channel, instead of having one SAQ D to cover all. Both are possible, but its just that for SAQ D, you would be marking a fair bit N/A if you are say just doing POS and e-commerce.

Before we venture into the dark arts of SAQ selection, let’s explore probable channels that agencies have.

a) Through the website – this is not that common actually. Now with Expedia, Agoda and all these portals coming up, it’s easier for consumers to get the best price regardless. But for corporate trips etc, some of these websites might still prove useful. Most of these websites will either redirect to another payment gateway or might even link to a GDS. Either way, they generally do not host the site where credit card information is being entered. So in this case, SAQ A might work. If they have card information collected in their environment before sending it over to the payment gateway, then SAQ A-EP. Questions for A = 22, A-EP = 191. So please think it over as to why you want to collect card information on your site.

b) MOTO – or Mail Order Telephone Order. In most cases, there would be a call into the agency requesting booking. Now it’s important then how card data is now transmitted, processed and stored. The agent likely will not have any funky call system like Ameyo or Genesys, and may just rely on our good old PSTN phone line. Once call is received, the agent will request details , including card details and type it directly into a GDS system. In this case, as there is no recording on the line, it’s fine, and as long as the agent is using a hardened desktop/laptop with a virtual terminal into the GDS, you can rely on SAQ C-VT to cover this. Now, what is a virtual terminal? Basically, it’s a virtual POS. You just don’t need to buy the POS devices. All GDS offers this solution, whereby you log into the virtual terminal and just input the card information.

The tricky part here is that not all information is received on phone. Sometimes, clients will say, OK, let me send you a batch of credit card info in a text file via email. Or, hold on, I am shooting you an image via WhatsApp or Skype. Or, wait, let me fax you the form. Oops.

Now what happens is that other channels are being utilised. You have storage of credit card information. You are no longer eligible for C-VT. C-VT = 81 questions. D-Mer = 332 questions. So, if you can stop these practices, I would suggest, go ahead and stop it.

c) Walk-In – most agencies have outlet(s) and you can walk in, and pay off the counter. They will either key in the information as if you had called, into the virtual terminal – OR, they might have an actual POS machine for you so you can dip your card and make a card present transaction. In this case, it depends on how the POS machine is setup. It would be pretty similar then to a normal retailer transaction – like a grocery store or departmental store. We’ve already written this at length here: http://www.pkfavantedge.com/it-audit/the-saq-bs-and-how-they-apply-to-you/.

So there you have it. Remember the following

SAQ A = 22 questions (good!)

SAQ A-EP = 191 questions (not great!)

SAQ B = 41 questions (good!)

SAQ B-IP = 82 questions (not so great!)

SAQ C = 160 (not very good!)

SAQ C-VT = 81 (that’s ok!)

SAQ D- MER(SP) = 332 or 359 questions (bye bye weekends!)

So there you have it. If you are an agency or a retailer and you need any help at all to clarify this PCI-DSS requirement, drop us an email at pcidss@pkfmalaysia.com. We will attend to you immediately!

 

 

« Older posts Newer posts »

© 2024 PKF AvantEdge

Up ↑