PKF AvantEdge

Page 6 of 40

Hardening Checklist

August 7, 2021 / / 0 Comments

Picture from https://guardiansafeandvault.com/

Requirement 2.2 has been often deliberated by customers undergoing PCI-DSS. To recap, the requirement states:

Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
Sources of industry-accepted system hardening standards may include, but are not limited to:
• Center for Internet Security (CIS)
• International Organization for Standardization (ISO)
• SysAdmin Audit Network Security (SANS) Institute
• National Institute of Standards Technology (NIST).

Requirement 2.2

So often, customers go ahead and download the CIS hardening documents at https://www.cisecurity.org/cis-benchmarks/ and copy lock stock and barrel into their policies and send it in. Now all this may be well and good, but now you have around 1,200 page tome with guidelines like 14 character alphanumeric password, as opposed to what PCI requires (7 Alphanumeric). This is where our customers get stuck, and some even send in a 1000 page hardening document to us to review, only for us to find that they have not implemented even 1% of what is noted in their hardening document.

After that, the hardening documents get re-jigged again until it meets a reasonable, practical standard that is implementable, usually in the form of a checklist. For a very quick hardening checklist, this is the initial one we often end up using, just to get our clients up to baseline speed, whether it’s PCI or not:

Hardening ItemServersNetwork DevicesDatabases
Assign individual server for each critical role (App, Web, DB, AD, AV, Patching etc)YNAY
Disable/Rename/Remove default user accountsYYY
Assign role based access to usersYYY
Disable insesure or unnecessary servicesYYNA
Use Secure Versions of Remote Access Services (SSH, RDP over SSL)YYY
Install well known Anti Virus with latest signaturesYNANA
Install latest OS / Firmware / Software security patchesYYY
Disable inactive users automatically after 90 daysYYY
Ensure Following Password Policies –
1. Use Complex Password with 7 characters or more
2. Remember minimum last 4 Passwords
3. Require passsword change within 90 days
4. Require password change upon password reset and first logon		YYY
Ensure following account policies –
1. Account lockout threshold – Max 6 attempts
2. Account lockdout duration – 30 mins or until admin unlocks
3. Idle Session Timeout – 15 Mins or less		YYY
Ensure passwords are stored securely with encryptionYYY
Enable Audit logging to Capture at minimum following events –
1. Successful Login
2. Failed Login
3. Administrative Actions
4. User Creation
5. User Deletion
6. User Updates
7. Escalation of Privileges
8. Access to Audit Trails
9. Initialization or stopping auditing		YYY
Configure NTP and time syncronizationYYY
Implement File Integrity Monitoring`YYY

Now obviously this doesn’t cover all the requirements of PCI (testing, scans, retention etc) but this should give us a fair idea of how ready our systems are for an audit or assessment.

If you have any queries on PCI or ISMS or any other security related standard, drop us a message at avantedge@pkfmalaysia.com.

Do or Do Not – ASV for SAQ A

July 24, 2021 / / 0 Comments
pci-compliance

I would have thought this debate died out with the extinction of dinosaurs, but apparently, we are still at this subject in 2021. Still. Going. On.

So in the past weeks, there were some debate between us and some consultants as to whether the SAQ A requires an ASV scan or not. Our position was No. Their position was yes. So let’s look at it.

Now, keep in mind, we aren’t talking about best practice. We are talking about PCI-DSS v3.2.1 and what it says about ASV scans being mandatory for SAQ A. That’s it. That’s the statement. Now, debate.

There is actually no debate. This isn’t some sort of grey area, hard to explain, obscure rule in Sanskrit and written on the Sankara stones. This is just: Look at SAQ A, search for ASV, don’t find it. Thank you.

The ASV requirement is present in item 11.2.2 of PCI-DSS.

SAQ A does not have it.

So why do consultants still insist people do ASV scans for SAQ A?

There could be a lot of reasons, ranging from ‘guideline’, ‘best practice’ and so on. No doubt, having a scan (which isn’t expensive in any case) would be the least effort of security done by the merchant if they are hosting an e-commerce website that is redirecting customers to their payment processor once the “Click here to pay” is clicked. I mean, even if it has nothing to do with PCI, it may seem like common sense to have at least a scan done on your site to ensure it passes the very minimal requirement of security. So do we advocate an ASV scan to be done on any e-commerce site that deals with payment options (not necessarily payment data)? Yes, we do. There are many ways a site may get compromise. A coding error may allow data to be siphoned off, or passwords may be compromised. A re-direct may be vulnerable to man in the middle attacks; or even a total redirect to another page altogether where payment data is inadvertently entered. While the e-commerce site may be outsourcing the payment part to a processor, it still has the job of redirecting traffic to it.

Think of it as an usher (not the singer, but the job); where you enter into a dark auditorium, let’s say Royal Albert Hall to watch Ed Sheeran – and the usher takes you through this row of lights to what is supposedly your seat which you paid RM10,000 for.

When the lights come on, you find yourself in nice cosy room and in front of you someone who seemed to resemble Ed Sheeran but slightly off. His hair isn’t ginger and he isn’t as chubby as you see that guy on TV and he speaks with a slight Indian accent. And isn’t the Royal Albert Hall a HALL? Why are you in this room that resembles a glorified grandmother’s living room? You find out later that the usher had led you through the wrong Hall into a neighboring pub attached to the side of the hall and you are listening to the wonky music of Eddy Shiran.

The point is, the usher is pretty important in leading people to their seats. So as a redirect, even though you aren’t the main draw, you could end up leading your customers to Eddy Shiran instead.

But back to the main debate, whether it is required for SAQ A customers to go through ASV? No, it’s not.

However, there is always a but in everything. There are exceptions.

Some acquirers make it a point to state that they still require an ASV report even if merchants are going through SAQ A. That’s completely fine because the guidelines from Visa/Mastercard are just guidelines. At the end, the acquirer or payment brands may make individual decisions based on merchants, so it’s not written in stone. However, if there are no such requirement, we’re left to interpret the SAQ as it is, and it doesn’t state anything there.

Some may point out within the SAQ A under part 3a, there is a statement

ASV scans are being completed by the PCI SSC Approved Scanning Vendor (ASV Name)

Triumphantly being pointed out as proof of ASv requirement

Take note however, that above, under Part 3a, the instructions do state:

Signatory(s) confirms:
(Check all that apply)

the realisation that asv is still not needed for Saq A (or B)

Even under the title “PCI DSS Self-Assessment Completion Steps” of the SAQ:

Submit the SAQ and Attestation of Compliance (AOC), along with any other requested documentation—such as ASV scan reports—to your acquirer, payment brand, or other requester.

It does seem to be grappling at straws if this sentence was used to justify the requirement for PCI-DSS. “Such as” generally denotes an example, which may or may not exist or is required.

In previous requirements of merchants from Visa, there used to be statements describing merchant levels such as 

 * Merchant levels are based on Visa USA definitions
** The PCI DSS requires that all merchants perform external network scanning to achieve compliance. Acquirers may require submission of scan reports and/or questionnaires by level 4 merchants

And perhaps there is where the myth was perpetuated from. In recent times Visa has updated its site (https://www.visa.com.my/support/small-business/security-compliance.html) to reflect a better understanding, stating:

“Conduct a quarterly network scan by an Approved Scan Vendor (“ASV”) (if applicable)”

In conclusion, SAQ A and B do not require ASV scans. If it’s required by the acquirer then so be it. If it’s supposed to be done out of best practice requirements, so be it. But you don’t want to hear an ASV/QSA telling you that you need to do something that is above and beyond your PCI requirement without them pointing to something in the standards that states so.

Finally – for SAQ B, which usually applies to POS terminals dialing up to the bank for authorisation; we’ve even seen some consultants requiring the merchant’s website to undergo ASV, which has nothing to do with their POS Terminals. Why ASV the website? Don’t know. So the merchants go about scanning their website that hasn’t been updated since 2012 and wonder, what sort of nonsensical requirement is this from PCI-DSS that needs them to pay just to scan something that is built by an 18 year old intern who had left the company 10 years ago? You don’t need to. So don’t do it.

Anyway, that’s it for now. Let us know your thoughts or questions and send to us at pcidss@pkfmalaysia.com and we will get back to you ASAP. Now, back to listening to our Spotify for Eddy Shiran!

PCI Delta Assessments

July 16, 2021 / / 0 Comments
pci-compliance

Let’s start off by saying this isn’t a way for us to make light of the current situation by using the word ‘Delta’ here. We all know how dangerous and virulent the current strain of COVID is and this isn’t a matter of writing an article simply to get a search hit on that word.

That being said, this is a topic that seemed a bit obscure, even to us who have been doing PCI-DSS for more than a decade now.

So the question that can sometimes pop up would be: Great, we got our PCI-DSS certification now, everyone is celebrating and patting each other on the back. In 2 weeks time after our AoC/RoC has been produced, our product management rolls out a new Application XYZ which deals with credit card information along with a new environment, database, systems etc. Is this Application XYZ included in our current PCI-DSS certification or not?

It’s a good question. Because the fact is that many view PCI-DSS as a point in time audit, whereby the audit is done at a certain time and not over a period of time. One might argue that during the audit itself, sampling will be done over a 12 month period, therefore it cannot be categorised as a strictly point in time assessment. Regardless how you categorise it, at the end of the audit, there is the big result: a compliant AoC/RoC pair. Don’t get us started on the dreaded Certificate of Compliance or CoC, or CoC-n-Bull in our terms. Enough of that certificate nonsense. As for the AoC/RoC pair, the scope is stated clearly in it, defining the audit scope, the boundaries, the applications scoped in, locations etc. So this is great. When we get a new application onboard, we just add in that application into the AoC, right?

Right?

Unfortunately, at this point, the QSA will say, not really. Once the AoC is out, it’s out. Unless you want to re-do the audit or to recertify, then yes, that new application can be added in.

Now, we’ve faced such a situation before. And in fact PCI-DSS addresses it nicely at this wonderful piece of work: https://www.pcisecuritystandards.org/documents/PCI_DSS_V2.0_Best_Practices_for_Maintaining_PCI_DSS_Compliance.pdf

In item 3.10.3 it states:

Any change to the network architecture or infrastructures directly related to or supporting the CDE should be reviewed prior to implementation. Examples of such changes include, but are not limited to, the deployment of new systems or applications, changes in system or network configurations, and changes in overall system topologies.

PCI reminding us to stay focus!

So in this case, application XYZ falls under new application. The point of PCI-DSS is that, just because you deploy a new thing or new firewall or new application doesn’t mean you are no longer compliant to PCI-DSS. After all, PCI encompass the practice and process as well, so the council understands and advice that these changes be implemented into the PCI program and PCI processes ensures that this stays compliant. So in short, if you have application XYZ coming in, make sure the PCI controls apply to it and it will then be reviewed under the next audit and included into the PCI AoC of the coming year. Let’s just update the current Aoc and we all go home now, right?

Right?

But wait, you aren’t listening, says the auditor, you still can’t update the current AoC. The AoC is already fixed for that year, unless you want to do an audit. Again. Like a month after you have done and dusted your recertification audit for that year.

In most cases, these changes for our clients go through the maintenance cycle without and issue and the following AoC simply gets updated to include it. But what if the customer insist on having the CURRENT AoC updated? This could be due to requirements from their client, regulatory or what not. How do we put that application into the current AoC without spinning off the whole audit all over again?

In short, you can’t. You either wait it out for the next year audit OR you re-do your certification audit and nullify the previous one. However, this is where that little obscurity comes in. Delta assessment.

Now I’ve heard of Delta assessment for PCI, but it’s almost invariably related to PA-DSS (SSF now), PCI PTS, P2PE where basically, vendors who had completed, let’s say their SSF, can validate low risk changes to their application and do a delta assessment. In PTS, the delta is done by the PTS Lab, but for SSF, the SLC vendor can basically do a self attestation. However, we don’t see any such item or recourse for PCI-DSS.

Discussing with the auditors, we find that indeed, there are possibilities of a delta assessment to be done, although rare, and not exactly cost effective, since whatever the delta is doing, it’s would just have a short lifespan before the changes get swallowed up by the main PCI program once the yearly audit cycle rolls in. That’s why we rarely see this done. But I rarely see a tapir doing a jig in a tutu, but that doesn’t mean it doesn’t exist.

So what happens is that the auditor will formally audit this application and its environment and go through the certification process as would normally be done – except that this is limited to the application and systems. Once assessed, a formal delta AoC/Roc pair is released to supplement the existing AoC/RoC pair. And so that’s it, these supplement documents can then be shown together with the current AoC/Roc for verification purpose and in the next cycle, it’s consolidated back into the main RoC.

Now, this is fairly new to us. The logic of it is still beyond us somewhat because the whole point of PCI is for an environment to be able to handle changes and not have it audited everytime there is a significant change that occurs. Because every audit is costly and I’m sure every organisation has already got its hands full trying to sort out budgets during these times, without worrying about delta assessments.

The above is basically what we gather from discussions with auditor and not really from experience, because at the end, once the proposal was put out, our client thought better of it and decided not to pursue. So really, it’s still in the realms of theory and we may not be accurate in our assumptions. However, it’s still something interesting to keep in mind, though rare – like the tapir in tutu – it helps to know that this option does possibly exist.

Drop us a note at pcidss@pkfmalaysia.com and we will try to address all your concerns on PCI or other compliance matters like ISO27001, ISO20000 etc!

PCI Pentesting and ASV Scans

May 24, 2021 / / 0 Comments

Back in the days (as in when we started PCI more than 10 years ago), when it came to testing and scans, there were probably very gray lines on it. We saw a lot of reports that came out under the guise of ‘penetration testing’ that was straight out lifted from an automated Nessus Scan or one of the free Acunetix scans available. The problem was exacerbated when these penetration testing reports were further accepted by regulatory bodies like our regulatory bank and passed by other internal/external auditors. They basically just looked at a report and if it sounded and looked technical enough then it was technical enough.

Now, PCI got the hint and released a few versions of the Penetration Testing Guidance document, the latest iteration on 2017. A big part of it talks about scoping, clarifying on qualifications and requirement 11. But one of the key features of the document is highlighted in 2.1:

This came about to stem the misconception that as long as you have completed the vulnerability scan, you can use that to pass off as a penetration testing. We still see customers going down this route, in whatever creative ways they can conjure to avoid the penetration testing exercise.

An example was this response on their external PT report stating:

“We have conducted the PT exercise based on the recently passed ASV scan report by the QSA. Since the ASV scan has passed, the penetration testing report is also considered to be passed as there are no vulnerabilities to test.”

Which is basically the philosophy that as long as the scans do not yield any high or medium vulnerabilities, i.e a passing scan, there is no longer a need to conduct any penetration testing. Their concept was simple and fairly understandable: since there are no “vulnerabilities” in the scan, there is nothing for us to ‘test’.

Of course, this was rejected by the QSA.

While there are many arguments on this matter, the simple case against this is: the scan produces potential vulnerabilities and may even miss some out that may not be reported. False negatives do exist even in commercial scanners such Qualys or Nessus (two common auto-scanners). Additionally, a passing scan does not mean no vulnerabilities, it just means there are no medium/high vulnerabilities based on a non-contextual scan to the environment. A non-contextual scan means a lot of scanners already use internal libraries in their scanning database to categorise vulnerabilities without the definition of the actual environment risk it is scanning. So to equate CVSS to the actual risk of the organisation may be too broad an assumption as some low vulnerabilities may still be able to be exploited manually. The classic example here is when we check a simple form entry password and find it is well protected and designed, technically. However, a pentester may then go out into the organisation’s forum and discover that the admin regularly upkeeps a password file in Google Drive and shares it to the entire world inadvertently. The scanner won’t discover things like that.

Therefore to simply state, just because there is a passing ASV scan, it equates to penetration testing passing, is not going to get a free pass in PCI.

Another question that many organisations come back to us, when they have their team of penetration testers doing internal testing is: Well, then how do you do a penetration test, then, if you state we cannot use the ASV report to also pass our external penetration testing?

And it would seem weird, that when I look at them and answer: wouldn’t your penetration testers be able to answer that, instead of us? So from the auditor perspective, we look at 3 things: Tools, Technique, Team.  

The tools being used are important, but not all for pentest. Just by stating you have Kali or Metasploit doesn’t necessarily mean you know how to operate it. Technique (or method) is important to document. This is key for PCI and a key difference between hackers and pentesters. A pentester would know how to document each step, inform their client and normalize and not destroy the environment. A hacker (or let’s use the more correct term cracker) would simply go in and cause as much damage as possible, depending on his/her objective. You would rarely come across crackers developing comments and detailed reports/documents to their victims and executive summaries to the Audit Committee justifying their methods, the scope of coverage and the time and date of engagement. And finally, PCI looks at the personnel (or team) conducting the exercise. They may be certified (or not), but they should at least be qualified. In this case, if the pentester has no idea how to start a pentest, then the normal assumption would be — he’s not a pentester. A chef doesn’t ask people how to start cooking. He may require an input or two to understand what he needs to cook, or how spicy the broth should be for the customer; but if the he’s asking how do we start the cooking process or what is a wok, then that should be a red flag.

So, while the coverage of penetration testing and vulnerability scanning in the entire document is not the the purpose of this article, it is keenly important to know the difference between both (penetration test vs vulnerability scan), and not use one to justify the inaction of the other. Your QSA may bounce back that vulnerability scan attempting to disguise itself as a penetration test and waste precious compliance timeline in the process.

Drop us a note at pcidss@pkfmalaysia.com for any queries you have for PCI-DSS or ISMS and we will get back to you straight away! Stay Safe!

The Biggest (Real) Myths of PCI-DSS: Part 3

May 10, 2021 / / 0 Comments
pci-compliance

OK, we are down to the final 3 Real Myths of PCI-DSS, so here we go!

Real Myth 8: PCI-DSS gets easier and cheaper every year

This is quite understandable, seeing that the idea behind PCI-DSS , to many is to do once and be done with it. And in a sense, this is actually borderline correct. If you learn how to ride a bike at the start, you may need to get your Dad to teach you how to ride it so he is holding you for a while. After a while (sometimes, for some, maybe six years), you are able to ride the bike on your own and you don’t need your Dad hanging around anymore. So it’s the same. Except, replace the bike with PCI activities and your Dad with outsourced consultants or implementers.

The great thing about PCI-DSS is that it doesn’t dictate you to go out and purchase expensive services. In fact, the more you “in-source” the less costly your PCI will cost you (in terms of money going out of your company). If for the first year, you paid maybe 20K for all your penetration testing services – after 2 or 3 years, you decide to set up an internal InfoSec team to do these activities – done. You don’t have that 20K output anymore, and you have a team of pentesters to do it. (Of course, the question comes – how much are you paying your pentesters’ salary?)

However, whether it becomes easier/cheaper is probably not the case. You see, the first time you go through PCI-DSS, you are in what we call, First Time Certification stage. In this part, some of the requirements, such as quarterly ASV scan, quarterly IVA, half yearly firewall reviews, 12 months of log archives etc does not apply. And you go, huh? Why? Because you get a free pass, that’s why. In the first time cert, you simply have to do one iteration of these activities. For instance, the ASV scan, you just need to demonstrate one cycle of scan for all in scope systems. Your first time cert time range should be around 6 months…so, in this case, you could run an ASV scan one time, submit that as evidence for certification and get certified.

Once you are certified, keep an eye on the date when you signed off your AoC. 12 months from that date is your expiry, so that is your maintenance year. Your maintenance year is then divided into 4 quarters and you will need to ensure your annual, quarterly, bi-weekly, weekly, daily activities are done accordingly. So instead of ONE ASV scan, you now have 4. For each of your IP. Instead of one Internal VA, you have 4. Instead of one segment PT, you have 2. Instead of 1 Firewall Review, you now have 2. You get the gist. So for those who wonder if it gets easier in the second, third, fourth year, there is a rude shock. Furthermore, your scope may increase based on your growth so instead of testing 10 systems, your second year may test 20. Additionally, knowledge may also not be kept because there your IT team or compliance team may leave. That’s reality, so you are typically back where you started. So now you know. PCI-DSS is not unlike a marriage. You need to keep working on it to make it work.

Real Myth 9: A company is considered PCI compliant even after the expiry of certification, due to 90 days grace period from the council

I know what you are thinking. You are thinking, this myth is way too specific and it sounds as if this is a real life scenario that actually occurred. You are right. Because this was exactly what we faced not long ago. You see, we had a financial institution we were chasing for a PCI renewal. They outsourced their datacenter to another company (which is common), so therefore, in accordance to PCI requirements, that datacenter needs to be included in their PCI-DSS, either demonstrating their (DC’s) own AoC or to participate with my client’s. The DC chose the former, to show their own AoC. So far, it’s ok. But then, our client’s PCI-DSS expiry is on February. The DC over the years have always managed to renew their own PCI-DSS cert on time (about a month or so before our client) so we have always had a compliant report from them (the DC). Until recently.

So while checking requirement 9 Physical Security, we noted that the AoC provided to us from the DC had already expired about two months back, and our client’s expiry is in about a month’s time. So we rightly requested them to provide us an updated AoC. Instead we received a response stating that even though their AoC has ‘expired’, as per PCI, their compliance status is still valid for 90 days (3 months) grace period, and they will be conducting an audit sometime within these 3 months.

Oh-kay.

Firstly, just to be clear, PCI-DSS doesn’t give any 90 days grace period or what not. As in, it’s not part of the standard, or part of the PCI Council’s policy. Any grace period is given by the card brands to those under their contract and that even if they choose to do so. It’s those sort of thing that is like a ‘privilege not a right’. However, since this data center has NOTHING to do with the card brands (they are directly providing service to an Financial institution, and not connected to the card brands), how did the card brands provide this 90 day grace period to them? It’s definitely not the QSA who can provide any grace period. So where did it come from?

Secondly – a grace period is a grace period against something that you did not meet. In this case, it’s the PCI standard that you did not meet, i.e you are NON COMPLIANT with an expired AoC. That’s why it’s called a grace period. Whatever the penalty or action is, that 90 days is the ‘grace period’ you have before the hammer of justice falls. The fact is, the deadline has already been missed. You are now under ‘grace’. The meaning of grace is ‘undeserved favor’ (evangelicals like to use this terminology, but I digress). You don’t deserve it, because you are non-compliant and you have missed the deadline. But the card brand is giving you a favor before they implement PCI-DSS penalties or fees on you. 90 days, get your act together, else boom.

Now, obviously, if this data center gives this response as a justification of not producing a compliant AoC, how can our QSA accept that as a proof of compliance? Unless you are saying, our client should also be delayed 3 months from their compliance date just because this data center decides to take advantage of this so called ‘grace period’? You see where the problem is. The grace period isn’t stating the company is still compliant to PCI (they are no longer compliant without a valid AoC) – it’s stating, that’s the period of time the card brands will give before they smack you with penalties according to their contract.

Real Myth 10: If the company is an ISMS certified company, they have already complied to 90% of PCI-DSS

We get this a lot. And again, it’s very understandable why people think of such. And to be honest, there is some truth here. Being ISMS certified DOES help you become PCI compliant. And vice versa. They are both IT security standards/guidelines and seen as a distant cousin of each other. However, we do get potential customers arguing to us that because they are already ISMS certified, then we should only charge them 10% of what we normally charge for PCI.

That’s a head scratcher for sure. It’s like if I had a driving license from Malaysia and I apply to get my license in Australia and I demand the Australian government (or whoever runs their driving license department) to give me the Australian driving license for 10% of the fee. How? The audit for PCI needs to be done regardless of whether you are ISMS or not. Where you will likely save up money is in the remediation stage where you may end up implementing less controls. But the audit has to be done in the same manner as any other audit.

Additionally, while both ISMS and PCI deals with the same subject – Information Security – the philosophy is different. ISMS hinges on the Statement of Applicability and the risk assessment process. That’s key. In fact many of the controls and their implementation will be based on the risk process – and furthermore, how the ISMS can be improved in every iteration. It is a ‘system’ after all.

PCI is different. While there is a ‘token’ risk assessment in there, you need to understand that PCI-DSS is a risk-based standard…only, not your risks. But the card brand’s. It’s the result of a risk assessment, which has already been done by the card brands. That’s why they decide to impose these standards – logical security, audit and monitoring, secure software development etc on you. There’s not much disaster recovery or backup requirements because that’s a business risk. It’s not a risk to credit card confidentiality. So is a risk assessment still useful? I think it still is. A whole article can be written on how useful or superfluous one may find the risk assessment requirement is for PCI, but let’s leave it for another day.

Summary

Even from the start of writing this series till now, I’ve been beset with new enquiries and PCI interpretations that has left me flabbergasted. Some of these interpretations are not unlike theories of the flat world, where it can be easily explained. Others have found little tiny crevices in the standard itself that I myself after reading the standard a dozen times over would never think of. So, to say, we are still learning a lot about PCI-DSS and how different entities see it and interpret it, so these myths may not age well. There could be a whole new list of 10 Real Myths in about a year or so. Till then, drop us any enquiries at pcidss@pkfmalaysia.com and we will do our best to guide you through PCI-DSS and the infinity that lies beyond.

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑