Category: Risk Management (Page 1 of 5)

PCI-DSS v4.0 vs v3.2.1 Deepdive Part 1

OK, now that we are well into 2023, the main question here is why isn’t the current assessments this year going into v4.0? Most of our customers are still doing their v3.2.1 for 2023, before doing 4.0 the next cycle. The answer is: Well, you can go for v4.0 if you want to. There’s really not much difference for now. The difference is probably more on the auditor side, as reporting requirements are different in V4.0. But from the client end, some of the scary changes like authenticated scans for internal vulnerability scanning, or updating of password complexity to 12 characters etc – these actually don’t come in force until March 2025. So there’s actually a grace period for v3.2.1 to v4.0 and another grace period for PCI v4.0 controls to be implemented, up to March 2025. Basically, anything past March 2025, the controls in v4.0 becomes Standard. No more compromise. Its like the biblical ten Commandments, except you have around 300+ commandments here. That’s a lot of chiseling on the rock by Moses.

Before we deepdive into v4.0, let’s set out the landscape a bit again, like unfurling a carpet or a mat before we feast into our metaphorical compliance picnic.

  1. Scope and Applicability

One of the key changes in PCI DSS v4.0 is the clarification of the scope of the standard. The new version provides more explicit guidance on how to apply the standard to different types of organizations, and it emphasizes the need for organizations to understand the scope of their cardholder data environment (CDE). This comes as a fairly significant change, as the initial pages of V4.0 is strewn with explanations of scoping and methodologies on how to define scope. It reads almost like they are trying to make up for lost time, and trying to cover all their bases, whereas in the previous version, just a cursory glance was done. PCI DSS v4.0 also provides guidance on how to identify and manage different types of risks. Risk has always been a difficult item to quantify in PCI. Because at the end, PCI is a result of a risk assessment anyway, done by the card schemes. It’s specifically to mitigate the risks they identified that the PCI program was born. So what’s the point of running a risk assessment in PCI-DSS if its already a standard? Well, PCI DSS v4.0 states that organizations should have a risk management program in place to identify and prioritize risks, and to take appropriate measures to mitigate those risks. Its a way of saying that while controls are required, how you address the controls are dependent on your risk assessment. Additionally, you can even opt to go above and beyond the PCI standard to address a particularly high risk area (although to find a company doing this is like finding the Lost Ark). Above the brownie points you would get from the QSA by showing you are a company keyed into your risk assessment practices; a risk assessment will likely help you identify other areas of concerns as well. The standard also requires organizations to have a process in place for identifying changes to their CDE, and for reviewing and updating their risk management program as needed. So to the point on whether the risk assessment is useful – yes. Whether it is critical to passing your PCI-DSS – well, I would say that depends a lot on your QSA. We’ve seen QSAs pass a bunch of colored coded excel sheets off as a PCI risk assessment easily.

2. New Control Objectives

PCI DSS v4.0 introduces several new control objectives to address emerging security risks. One of the key new objectives is to address the risks associated with cloud computing. The new version of the standard includes new requirements for securing cloud environments, including the need to assess the security of cloud service providers and to implement additional controls to secure cloud-based data. In v4.0, the word ‘Cloud’ appears 42 times in the entire standard. In v3.2.1, the word ‘Cloud’ appears as often as ‘NasiLemak’. Which is zero.

3. Password Requirements
PCI DSS v4.0 introduces new requirements for password management. We are in 2023 and we are still trying to remember all our passwords. PCI is now making our lives easier by introducing longer passwords! Great, now everyone just add incremental numbers behind your password from seven to twelve. The standard requires the use of multi-factor authentication for all non-console administrative access, this has already been evident in previous version. This just basically means that organizations must implement additional security measures, such as biometric authentication or smart card authentication, in addition to a password, to access sensitive systems and data

4. Encryption

The new standard maintains that organizations use more robust encryption algorithms and key lengths as per 3.2.1. Key management more or less remain as it is, but the biggest issue in v4.0 is the doing away with full disk or transparent encryption. We will do a deep dive in this later.

5. Penetration Testing and Vulnerability Management

PCI DSS v4.0 includes new requirements for penetration testing and vulnerability management. Among others is the requirement for Internal vulnerability scans to be authenticated whereas previously, this was a bit more gray area (actually not required). This could have potential impact especially for entities chasing a quarterly deadline, if you have a lot of systems in your scanning scope. So this makes the scoping a lot more critical. Because you can be sure the effort for internal scans are going to be going way up.

6. Remote Access

PCI DSS v4.0 includes new requirements for securing remote access to cardholder data environments. PCI requires organizations to implement multi-factor authentication for all remote access, and to use secure protocols, such as SSH or VPN, to access sensitive systems and data. While this remains, the other issue with 4.0 is the need to implement controls to prevent copy/relocation of PAN for all personnel unless there is a business need. We have a bad feeling about this. This could generally mean getting a DLP in place or a NAC in place to limit what can or cannot be done by users logging in remotely. There are solutions for these, but this needs to be planned and invested. The key word here is to ‘prevent’ not just ‘detect’, so this basically mean a proactive control in place to block these actions.

So in the next couple of articles, we will dive right into the changes for v4.0 in detail, including those requirements where it is stated “This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.”

We will also look into the SAQs and what has changed in the SAQs for those preparing to do self assessment in accordance to v4.0.

In the meantime, for any PCI related queries or any standards like CSA, ISO27001 etc, drop us a note at pcidss@pkfmalaysia.com and we will get back to you!

Trends for InfoSec moving into 2023

When I was a kid, I used to watch this show called Beyond 2000 and imagined, if I lived to year 2000, I would be seeing flying cars and teleportation and space travel. Later on, I had to temper my expectation but was still filled with optimism when October 21, 2015 rolled around, at least, we would have a hoverboard to fool around with. At least.

We are now in 2023. No flying cars. No hoverboards or hovertrains and no flux capacitors to go back in time to make gambling bets. We do have a lot of information security issues, though, and while not really sexy enough to make a Hollywood movie around it, it’s still giving us enough to do as we ride into this new year on what trends we think may impact us moving forward.

To understand why information security has become increasingly important in recent years, we look at the sheer amount of sensitive information being stored and transmitted electronically, and shared in our everyday interaction. We share and give information without us knowing it, even. Everytime we browse the net, everytime we hover our mouse over a product, everytime we use our credit card to get your coffee or pay for Karaoke session, everytime we check our location on Waze:- the vast array of information and data is being transmitted and curated carefully by organisations intent on peering into our lives to make it “better”.

As information continues to grow, increasing amount of incidents follow. Some of the more high profile ones include

a) SingHealth – In July 2018, one of Singapore’s largest healthcare group, SingHealth, suffered a data breach where personal information of 1.5 million patients, including Prime Minister Lee Hsien Loong, was stolen. How was this achieved? The attackers had gained unauthorized access to the network and exfiltrated the data through a sophisticated method, which involved using a “well-planned and carefully orchestrated cyber attack” and a “spear-phishing” campaign in which the attackers sent targeted emails to specific individuals within the organization to gain access to the network. No matter how much investments we make in technology, the weakest link still remain the humans around it, especially those interested to click on links depicting a cat playing the piano furiously.

b) India’s National Payment Corporation of India (NPCI) – In January 2021, the NPCI, the company that manages India’s Unified Payments Interface (UPI) system, which enables inter-bank transactions, experienced a data breach. The breach was caused by a vulnerability in the UPI system that was exploited by hackers, who then used the stolen data to make fraudulent transactions. The incident resulted in a temporary suspension of the UPI system, causing inconvenience to millions of users.

c) Garmin – Back in 2021, Garmin, a leading provider of GPS navigation and fitness tracking devices, was targeted by a ransomware attack. The attackers used a variant of ransomware called WastedLocker, which encrypted the company’s data and demanded a ransom payment. The attack caused the company to shut down its operations, leading to widespread service disruptions.

d) SolarWinds – Ah, this was probably one of the largest profile cases of data breach in recent memory. It was discovered that a sophisticated cyber attack had breached multiple government agencies and private companies, including SolarWinds, that runs IT management software. The attackers used a vulnerability in SolarWinds’ software to gain access to the networks of the companies and organizations that used it, and used those accesses to steal sensitive information. The incident was attributed to a Russian cyber espionage group known as APT29 or “Cozy Bear”.

Many more information security issues will continue to occur well into this year and the next and the next. One of the burning question is how companies can keep up with this movement, and how we can remain vigilant.

One trend that is likely to continue into this year is the establishment of cloud computing. While previously we had AWS/Azure, we now see a larger array and options for cloud providers. Within the cloud itself, services being offered are replacing traditional needs for separate security functions like logging systems, authentication systems etc. As more and more organizations move their data and applications to the cloud, it will become increasingly important to ensure that this data is protected against unauthorized access and breaches. This will require more stringent security measures to improve encryption, multi-factor authentication, and continuous monitoring of cloud environments.

One of the more interesting ideas that has floated around is the use of blockchain technology for security. Blockchain is a decentralized, distributed ledger that can be used to securely store and transmit sensitive information. This can help in the C,I,A triad of security. Encryption for confidentiality, immutability in blockchain records to ensure integrity; decentralization of data to remove single points of failure to ensure availability. There could be many more uses, but it still remains an abstract for many organisations looking at this for their information technology. As such for basic implementation, this may be useful for applications such as supply chain management, where multiple parties need to share information in a secure and transparent way.

Another growing trend, as always, is the need for strong cybersecurity workforce. As the number of cyber threats continues to grow, it will be increasingly important to have a workforce that is trained and equipped to deal with these threats. This will require organizations to invest in employee training and development, as well as to recruit and retain highly skilled cybersecurity professionals. Professional training, a big industry in Malaysia, will continue to play a key role in enabling people to carry out their vital tasks within the information security landscape.

Another abstract trend we often hear, deals with the Internet of Things (IoT) devices. In short, IoT refers to the growing network of physical devices, vehicles, buildings, and other items that are embedded with sensors, software, and connectivity, allowing them to collect and exchange data with each other. The example we always see is that fridge telling us we are running short on milk and placing an order to get milk for us. But IoT is happening whether we like it or not. Healthcare will be heavily dependent on it as information is exchanged with digital systems across nationwide healthcare systems; manufacturing of course is putting more traditional systems onto the network to integrate with automated processing tools; transportation is getting more digitized than ever, car manufacturers now looking not just to hardware but to cloud enablement of software running in cars. Even wearables, fitness apps, smart homes etc are impacting end users in more ways than we can imagine. It’s coming. or it’s here – eitherway, we expect 75 billion devices to be connected over IoT by 2025.

Another trend we like to see more in 2023 is the use of artificial intelligence and machine learning for security. These technologies can be used to detect and respond to cyber threats in real-time, as well as to analyze large amounts of security data to identify patterns and anomalies that may indicate a potential attack. We traditionally have threat intelligence but the time to respond to threats were still lagging behind, dependence on human intervention and decisions. With automated systems, more advanced rules and correlation of multiple information points, actions can be orchestrated through a more meaningful, machine learnt manner as opposed to depending on manual rules and signatures.

While not the most sexy or interesting, where we want to see improvement and a trend to get better, would be to improve and make more effective incident response plans. With the increasing number of cyber threats and attacks, it is critical that organizations have the ability to quickly and effectively respond to security incidents. This will require organizations to have detailed incident response plans in place, as well as to regularly test and update these plans to ensure that they are current and effective.

One trend we want to see more, especially in our accounting and auditing industry, is the adoption of security automation. This will involve the use of software tools and technologies that can automate various security tasks, such as vulnerability management, incident response, and threat intelligence. Implementation of tools such as Ansible has been done in our organisation, providing at least a first layer of understanding configuration and management of systems. With more automation, this will help us to more efficiently and effectively protect and respond against cyber threats.

Finally, some of the things we hardly talk about in information security is how much more integrated infosec needs to be in the field of humanities. A lot of us approach info sec from a technical viewpoint, which is great but perhaps a more effective viewpoint should be from the views from humanities. The humanities can play several roles in information security, including providing a broader understanding of the social and cultural contexts in which security threats occur, assisting with the development of effective communication strategies for raising awareness and educating the public about security risks, and helping to design user-centered security systems that take into account the needs and behaviors of different groups of users. Additionally, the study of ethics in the humanities can be used to inform decision making and policy development in information security. An example would be how implementing more stringent security monitoring may impact the innate need for privacy within employees – where, though the technology is sound and good and the intent is well thought of, organisations may still end up pushing out policies and technology that people will revolt against as opposed to embracing. This is not a field we often think of, but moving forward, it’s worth dwelling on and indeed provides us a more holistic way on how infosec can be part of our lives.

This isn’t so much of our traditional compliance article, but it’s always interesting to try to peer into a crystal ball and see what’s ahead and then at the end of the year see what has been proven more correct or wrong in our trends prediction. Drop us a note at avantedge@pkfmalaysia.com and tell us what you think, or if you require any of our services. Have a great year ahead!

Hardening Checklist

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.

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

pci-compliance

So, continuing the Real Myths of PCI-DSS, lets move down the list.

Real Myth 5: All PCI-DSS services must be outsourced

Now, this is a very important myth to clear up. Because it directly relates to the usually biggest concern of all: cost. A while ago, we provided an idea on how to cost PCI-DSS, and break it up into certification/advisory costing and implementation cost. While the certification-advisory cost is easier to gauge based on locations, processes, card storage, activities covered , implementation cost is harder to gauge. Because number one – you don’t know your scope yet. This means, you may have 10 or you may have 200 systems in scope, you don’t know. Some go, “Ah but we know, because we have already decided our scope!” and we go, “Ah, but that’s the Real Myth 7, that you can decide your own scope…read on, intrepid adventurer of PCI!”

In any case, one way to cap a cost or save cost is to in-source your work, i.e have your own people provide the implementation services. There are no “PCI-certified” company to actually do the implementation services. All services – except for ASV scans – can be performed by your own, if you are qualified enough to do it (more on that later). I’ll throw in some services that for a typical PCI project, is a must:- Penetration testing, Internal Vulnerability assessment, secure code review and code training, patching, logging and monitoring and daily review of logs, card data scan, application testing, systems hardening, segmentation penetration testing, encryption, key management etc. These are fairly typical activities you will find in PCI – and you can do it all on your own if you have the resources and knowledge to do it. So, don’t feel cornered by any firms or consultants stating that these services must be done by them in order to pass PCI-DSS!

Real Myth 6: All service providers MUST be certified to do implementation services

This is an extension of Real Myth 5. So once the company decides to outsource the PCI services, in the case where they do not have the resources to do it internally – they go about requiring “PCI qualified” service providers to do these services. We’ve seen this requirement before where the requirement was to be a “QIR – Qualified Integrator and Reseller” to do services like penetration testing and code reviews and such. QIR isn’t created for that. QIR is created for implementing merchant payment systems and has nothing to do with the services mentioned. Aside from that, there is a growing call for PCI services to be only performed by “Certified Penetration Testing Companies” with CREST or individuals with certifications like Certified Ethical Hacker etc. Now, while these are all well and good, and certainly mentioned even by the PCI-DSS as a guidance in selecting your vendors, these are by no means a requirement by the standard. Meaning, the QSA cannot enforce all your testing to be done by the above said certified entities if you have ready, qualified and experienced personnel on your end to do it. Again – this doesn’t mean any Tom, Dick and Harry, Joe and Sally can perform testing or activities in your environment. The above certs and qualifications obviously carry weight and we should not dismiss the fact that if an organisation takes the trouble to go through CREST, versus a company that was set up two days ago, and employ 2 testers working in Elbonia – which you should prefer or which one will the QSA has less of an issue of – that’s pretty obvious. What I am stating here is that, we’ve seen many veterans who are far more efficient or experienced in systems testing and security testing than we can ever hope to be and for whatever reason, they don’t bother much about these paper chase or certifications.

At the end, the QSA may raise a query on who carried out the test and may choose to check the credentials of the testers, but in most cases, if the testing seems to be in order, most QSAs are OK with it.

Real Myth 7: PCI scope and application of controls can be determined by the customer

This one is my favourite. Because it played out like an episode of a slapstick comedy. I was called one day by one of our clients who had a new group handling their PCI-DSS program. You see, we’ve been doing their program for four plus years and we’ve been servicing them fine for years – but the new group handling PCI now isn’t well versed with PCI. It’s frustrating because no matter how many “knowledge transfer” sessions we gave, we still ended up with the same questions. We realised we were stuck in a Groundhog Day scenario, where things never change no matter what we do. The group wasn’t technical, which was an obstacle but overall, I think maybe they just have too many things on their plate.

So on this call, they said they were going to compare our quote to other providers this time around and I said, yeah, it’s fine. They then proceeded to give me a scope to quote and I commented, “Hold on, this is the wrong scope. This is the list of assets two years back. You have now changed your scope, and there is a new list of assets under scope for PCI.”

From there, the proverbial excretion hit the fan. They maintained how did I know their scope? I said, well, we helped you guys work it out. Your operations team is aware of it, that every year we help you validate your scope (as per PCI-DSS guidance). And they went: “Why must the scope come from you? We are the owners of the environment and the project, so we decide the scope!”

Aha. This is where our points diverge. You see, while the organisation does have the overall responsibility in setting the scope for PCI, PCI-DSS also has a guidance document “Guidance-PCI-DSS-Scoping-and-Segmentation” that defines how that scope should include assets and networks and therefore affecting how and where services should be implemented. So for illustration:

Company A says, “Well, we have a payment gateway and a payment switch business. We also have a call center and a merchant business that accepts credit cards through kiosks or direct POS acceptance in our outlets. Now, getting our merchant environment to be certified is going to be a pain. We have decided to just certify our payment switch environment which is isolated in a cloud, and not related to our payment gateway at all which we are just about to launch a few months from now, so there are no transactions yet.”

So there you go, Company A has set their scope and from the outset, it kinda looks fine. Yeah, if these are all isolated environment, it’s ok. In any case, in the report of compliance, the QSA would detail any services offered by the company that are NOT assessed, making clear what are the services NOT PCI compliant for that company.

However, what Company A cannot decide are the services and the assets involved in their scope. There is a method to scoping defined by PCI-DSS and we have written at length in this article here.   There are a few ways to minimise the scope by segmentation and so on, but for instance if you run a flat network and insist on it being flat, then everything within that network comes into scope – be it it’s your payment gateway, your merchant business servers, your call center laptops etc. So you can ‘define’ your scope, but what gets sucked into your scope to do hardening, pentesting, patching and all the PCI controls – that is already defined by the PCI on how it’s done. And we just have to identify these assets and systems and networks that get sucked into scope. PCI is a like a giant vortex or blackhole. Everything that is sitting on the same network or touches the systems in CDE, gets pulled into scope.

So there you have it. We will be exploring the final 3 Real Myths of PCI soon, but for now, if you have any queries on PCI-DSS, or ISMS or Theory of Relativity and Blackholes, drop us a note at pcidss@pkfmalaysia.com. Till then, be safe!

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

pci-compliance

Sometime back, PCI-DSS published the Top 10 Myths of PCI-DSS which we debunked in our series of Myths of the Top 10 Myths here. In this article, we are going to jump into the real actual Myths of PCI-DSS and we will explain it as we go along. We are not going to touch on the original myths published by PCI Council, but this is really very much based on our experience in PCI-DSS for more than a decade here in Malaysia, and what we often hear companies going about.

Often this misinformation is because the client facing PCI-DSS finds it hard to dissect all the information needed for the standard. Unlike standards like ISO27001, PCI-DSS is like a journey with different routes to the same destination: PCI Compliance. There are 3 separate destination for PCI – Level 1 Certified with QSA, Level 2 Self Assessment with QSA/ISA signoff, and Level 2 Self Assessment with Self Sign off (no QSA, no ISA signoff). Of course if you are a merchant, then you have level 3 and level 4, but those are the same as the third iteration where you signoff the SAQ on your own without involvement of QSA/ISA.

But while the destination itself can be clarified, the whole process to obtain PCI can be convoluted. Some clients are told by their banks, that because they do not store credit card, they are considered SAQ level 2. Or some are told because they have a website, they must do ASV scans. Or some are told that QSAs must be involved in everything. Some are even told, that local QSAs must be hired, and not any other QSAs. Some are of the opinion that PCI is a license they need to purchase, or a training they need to do. And some are of the opinion that the ASV scan will make them PCI compliant.

Hence, it’s easy with all the above misinformation and more, that customers get frustrated with the expectations of PCI. When they hear a level 1 certification may set them back 15 – 20K USD or more, or that it would take them 6 months or so, they balk at it. It’s funny because often I would start my sales pitch by saying: “At the end of our conversation, it would be goal to try to get you to avoid getting services from us if possible.” Because it’s essentially true. Our job at the beginning isn’t to peddle services or consulting or audit that our clients may not need. Our goal is to provide them with enough information of PCI-DSS so they can make informed decisions. And yes, even if those informed decisions would be that they can avoid PCI, or do their own SAQ without any consultation or ASV scans or certification, or get exemption from their banks/customers or anything else that can lower their requirements for PCI-DSS. And yes, many people who have called us actually just pay us by saying ‘thank you’ and we never hear from them again. Because as advisors, it’s better we start doing the right thing at the very beginning instead of focusing to sell services that customers do not need. This philosophy has been adopted from the start of our company – which is one of the reasons why I failed so miserably in my previous corporate role as regional head of professional service sales. Or also why I was once told off by a potential business partner that I was a poor sales person and that he preferred to work with an organisation with someone better handling sales. Ah well.

So here are some of the top REAL myths of PCI-DSS that needs to be debunked, burned, destroyed and thrown out of the window for the garbage that it is.

1) All PCI-DSS Projects Require ASV Scans

2) ASV scans makes you PCI compliant

3) All PCI-DSS requires (local) QSA

4) All PCI projects are the same (One Certificate to Rule them All)

5) All PCI-DSS services must be outsourced

6) All service providers MUST be certified to do implementation services

7) PCI scope and application of controls can be determined by the customer

8) PCI-DSS gets easier and cheaper every year

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

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

So there is quite a bit of stuff – some may be half truths and other are utter nonsense – we need to uncover, likely will need to break this article up into two parts. Let’s jump into it.

Real Myth 1: All PCI-DSS projects require ASV scans

This myth is often peddled by those who are selling ASV scans as part of their service. Don’t get me wrong, we also do ASV scans through our ASV partners for sure, but you can’t go around town telling people that all PCI requires ASV scans when it doesn’t! Read SAQ A. Read SAQ B. You don’t see ASV being mentioned anywhere in the SAQ except for this portion in Part 3a:

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

And under “PCI DSS Self-Assessment Completion Steps”:

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.

The thing is, if you go through each control under the SAQ, the ASV control 11.2.2 isn’t mentioned, so therefore it’s not required. It’s highly frustrating to us, especially when travel agencies for instance who are just doing EDC terminal business (SAQ B) that connects directly via cellular or phone line to acquirer coming to us and asking us to quote for an ASV scan for their website. We tell them, you don’t need to do ASV scan for your website unless its in scope. You can force us to sell to you, but it’s against our moral code to sell you stuff you don’t need. We take a look at it, find its a simple site with only information and they tell us, “Well, their PCI advisor previously told them to scan their website.” No. You don’t need to. Don’t waste your money, and don’t do it unless you have a website in scope or you are doing an SAQ requiring ASV scan or you consciously make a decision to do it out of best practices and security requirement – NOT as a mandatory PCI-DSS activity.

So, please, take a look. Even SAQ A, usually adopted by e-commerce sites that redirects to a payment gateway for card input – where there is likely a website, the myth is that ASV needs to be done. Read SAQ A. Again, no requirement for ASV scan. You can still do an external scan for security purpose, but strictly for compliance? No. Not needed, unless requested specifically by the acquirer.

And yes, we do have ASV scans as part of our service. But that shouldn’t make us charlatans peddling services to customers when it isn’t mandatory. If the client still wants to pick it up, ok, fine – but don’t say it’s compulsory when it’s not!

Real Myth 2: ASV scans makes you PCI compliant

We have flogged this one half to death in our earlier article here: ASV scans=/ PCI Compliance

I won’t repeat what we have said there but by far, this is a myth that gets peddled a lot. One, sadly, is because the propagation of this nonsense seems to be acceptable by banks. I hear: “Oh, no problem, the bank says all we need to do is to run an ASV scan on our website.” I interject: “Wait sir, you aren’t doing that e-commerce business. You are doing a call center with virtual terminal payments..” <Click> <Dial tone due to hang up>

So there you have it : companies and merchants that have no business doing ASV scans , but using ASV scans as a means to ascertain PCI compliance. We get this even weirder ones when we are trying to obtain an AoC from one of our client’s service providers and they pass us their passed ASV scan report. We ask what the heck that is and they go – that’s our PCI compliance, so please shut up and stop bothering us. And it’s so difficult to go out and explain to them that whoever told them that, is wrong, and they have to go through the actual PCI compliance, which their wonderful ASV scan may (or may not) be part of that overall PCI Compliance.

Real Myth 3: The Auditor (QSA) must be Local

This is one of the strangest myths ever.

We get calls from customers going, “Is your QSA a Malaysian?” And I go, “No, we work with our partner QSA, from India, US or Singapore”. And they go, “Well we want a Malaysian QSA.” And I ask, “Why?”, and most of them are not able to ascertain why they need the QSA to be local, except that it may be a requirement checkbox in their document or policy.

Ok, I can’t argue with your policy, if you have nationalist preferences to your auditors for whatever reason. But it’s not logical for companies to have that requirement, that only local QSAs must be used. PCI-DSS never stated that. In fact, its preferable to have a QSA with regional/global experience as opposed to a local QSA. If PCI-DSS had this requirement for local QSAs to carry out audits, how can QSAs then say they have ‘regional experience’? You see the conundrum? You want an experienced QSA company, yet you want a QSA that is only local. If every enterprise in the world thinks that way, how would QSAs have regional/global experience? By that argument, then all QSAs would be local to that country – not just Malaysia – but each country would only have QSAs auditing in that country and nowhere else. And immediately you can see the fallacy and illogical argument attached to this myth. But this myth still prevails, for whatever reason (we sort of know the reason actually).

PCI-DSS requires a lot of experience. The last thing we need is a QSA with only a handful of experience and no operational idea of how to run things or recommend solutions and just rely on a checkbox and some cute marketing gimmicks. I’ve seen plenty of good auditors overseas, a whole lot better than the local ones I come across and vice versa. “Local QSA requirement?” It could be peddled by local auditors attempting to block off better equipped, or even cheaper auditors from overseas (better or worse) and really narrowing the options for their clients, who would be hemmed in by such requirement, thinking its a PCI-DSS requirement. It’s not.

If you mean by local support- that they can respond faster since they are local, then, yes, there is some sense in that. If you mean they are cheaper compared to a guy in US, then yes, but let that be a commercial decision and not a technical one. Sometimes even overseas (good) QSAs can be cheaper. Local support I agree, 100%. Nothing is more frustrating than sending a message to someone and them taking 24 hours to reply due to them being in another timezone. Local presence, local support – yes. But they technically don’t need to be a QSA. They could be consultants and there is a very good case in that. We noted it here in this article “PCI-DSS – So Why Aren’t We QSA?”. We consciously made a decision NOT to be a local QSA a few years ago to avoid possible conflict and to support our clients a lot easier and not to be bogged down by auditor responsibilities in PCI.
QSAs are a busy and itinerant lot. Aside from handling other audits, writing reports, they also need to be careful of overstepping their independent role by advising and implementing for their clients and then auditing this same control they devised.

There is really, if you come down to it, no perceivable value in saying having a “local QSA” is better or not. Having local support throughout the PCI-DSS compliance is important – and whoever is supporting should have at least the same or more knowledge than the QSA.

In some QSA Companies, they have a set up to differentiate the auditor and the consultant. Whereby the consultant is different from the auditor to ensure there is more independence. We have the same set up – PKF is the consulting arm and we deal mainly with implementation, testing and assistance of our client to get past PCI. The QSA is well, the QSA in this case, and they can do their audit without being too involved in the implementation. We know as much (and if not more, sometimes) than the QSA due to our operational experiences, and this puts us in a better position – conflict free- to get our clients certified.

So, no, in this opinion, there is no real value or even PCI requirement in having a local QSA, because that generally does not make sense and is counter-intuitive to peg a customer to only select local, less experienced auditors. Most QSAs can (and should) be able to do regional or even inter-regional work because a QSA Company, by its very nature is a regional or global company anyway (QSA pays to be auditors based on regions, and not country specific). Again, while our opinion may be biased because of the strategic decision we made years ago, we made that decision with all these considerations in mind.

Select the best QSA option based on experience, pricing and quality, not because they are local or non-local.

Real Myth 4: All PCI projects are the same (One Certificate to Rule them All)

A customer once said that we didn’t have much value and all we did was to forward their emails to the QSA for validation (not true). He said he had his team done PCI across other countries and we were just making it more complicated than necessary since they have already been experienced, implying that we hoodwinked them.

It’s very difficult to talk to people who are in this position because you can see from the onset, they do not support outsourcing advisory and consulting and they have a personal vendetta against this profession. So we don’t need to speak reason to them. In this case, we decided to pull out of the deal for advisory and all other works of implementation except for the ASV scans.

Two years from starting their PCI project on their own, and they are still in the wilderness. We ended up supporting them in any case, and perhaps their thought process had somewhat soften now because we are now finally seeing the end of the project, with us (ironically) leading them to it.

And their ‘experience’ from other PCI compliance projects? Different experience. Some were basically e-commerce SAQ A, A-EP type, some were their retail arm SAQ B or B-IP. But what they were doing in Malaysia was the outsourcing, call center and BPO – all of which involves credit card storage, processing and transmission.

Not all PCI-DSS projects are created equal.

Another company employed the ‘One Certificate to Rule Them All’ philosophy. They were providing warehouse storage facility to one of our clients, essentially storing physical copies of forms containing credit card information. So, this is a service provider, providing storage that needs to be assessed for their physical security.

They immediately told us they are already PCI compliant and they will send us the certificate. We insisted on AoC but they obliged us with their ‘certificate’ anyway, emblazoned with their QSA logo proudly, stating – SAQ C-VT Certified.

Huh? What has SAQ C-VT (merchant SAQ) got to do with the warehouse storage you are offering to my client?

Apparently that SAQ C-VT cert is from one of their parent companies overseas or something and has as much relation to our current project as me running to become the president of the United Sates. It means, One Certificate 100% does not rule them all. It’s a completely different business function and you can’t just use another SAQ or AoC from another parent/child company that is selling ice-cream cakes and had their call agent processes certified and say this applies to your warehouse storage facility half a world away!

Ok, we are halfway there, bear with us. Writing all these myths really can drag an article and you can probably read the frustration oozing out each paragraph. I’ll admit, we get extremely frustrated, but we also must remind ourselves – most of them (customers, banks – NOT QSAs, they don’t get any free passes for giving misinformation!) do not know better and they are just doing what they think it’s right or what they have been told by so called consultants or QSAs. That’s why we need to set their paths correctly so they know what options are there before them. So, we need to stop getting frustrated and blaming them for bad decisions, and get more involved in educating and providing information so they can make good decisions.

We will continue the next time once we catch our breath and go through the other wonderful misinformation on PCI-DSS we have heard over the years. Till then, drop us a note at pcidss@pkfmalaysia.com on anything to do with this standard or other standards like ISMS/ISO27001 etc.

« Older posts

© 2023 PKF AvantEdge

Up ↑