PKF AvantEdge

Tag: pcidss malaysia

PCI-DSS Card Data Discovery Scans

January 24, 2022 / / 0 Comments
pci-compliance

For PCI-DSS, there are some fairly obvious requirements that are set in stone in order for you to pass PCI-DSS. ASV scans quarterly. Internal vulnerability scans – quarterly. Annual penetration testing. Half yearly reviews of firewall config and policies. Annual training awareness. These are biblical principles of the gospel of PCI.

And then again, there are other areas where interpretation is a little more of a touch and go; up in the air; subjective to the wind; sort of the things where there are as much disagreements and controversies as whether Han shot first or Greedo was just an absolute tool who misses from two feet.

And while most arguments often stems from our clients and us as we try to explain some concepts to them, there comes once in a while a subject where we find ourselves against the explanation of QSAs. Now, not all QSAs are created equal. When I say QSAs here, I refer to the individual QSA, not the organisation QSA. As in the human being who are QSAs for the QSA-C (QSA Company). We’ve worked with some who are technically well versed; we’ve worked with some who are strong in documentation and theory, we’ve worked with some who can communicate well but not so technical, and those who are opposite. But every once in a while, we come across QSAs who think they know everything (they don’t), and they stubbornly stick to a point of argument even when we have exhausted all avenues to show them their point is flawed. The more we argue, the more adamant they take their stance even if their justifications seem to be plucked directly out of their …. posterior appendages.

One of the items you will often see coming up in PCI-DSS is this thing called the Credit Card Discovery Scanner (CDD). What is this? In PCI-DSS standard pg 10:

To confirm the accuracy of the defined CDE, perform the following:
The assessed entity identifies and documents the existence of all cardholder data in their environment, to verify that no cardholder data exists outside of the currently defined CDE.

PCI DSS v3.2.1

The CDD process is basically just a process using a tool usually to identify whether card information is stored in the clear within the organisation. These are usually regular expressions based applications; where it can categorise the type of card based on BIN or the initial numbers. These tools are often quite useful as well to find other forms of information like personal information etc, as long as you can identify filters and regular expressions for them. Some tools out there are from Groundlabs, Managed Engine, ControlCase etc. We also have free CDD tools like Pan Buster, Credit Card Scanner etc. The free tools are a little bit more difficult to use in our opinion and there seems to be less support for database scans and more false positives overall, so you may spend a longer time cleaning up the results.

Whether commercial or free tools, what PCI has been fairly silent about is whether these are mandated in the standard to be done. Unlike ASV scans or penetration testing, the standard doesn’t specifically state the need to run these tools for a normal PCI-DSS standard. When I say ‘normal’; I refer to a set of additional requirements under Appendix A3: Designated Entities Supplemental Validation (DESV) . These are specially assigned entities that has large volume of card data or has suffered significant breaches. This is designated by payment brands or acquirers, and it’s not something a QSA or even the audited entity decides on.

So looking into the card data scan requirements; we only have the Pg 10 scoping requirement and in the DESV portion , A.3.2.5 – “Implement a data-discovery methodology to confirm PCI DSS scope and to locate all sources and locations of clear-text PAN at least quarterly and upon significant changes to the cardholder environment or processes”

In most cases, CDD scans are done on an annual basis for normal PCI-DSS (non DESV), or at times half-yearly as required by the QSA.

So along came another QSA who stoutly declares that all companies are required to do a quarterly CDD scan regardless of size for all systems in scope. When politely reminded that he seems to be mixing up the DESV quarterly scan requirements; he says no. He is highlighting requirement 3.1: “A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.”

When pressed to explain why this is a CDD scan, he states its obvious, that everyone needs to run the CDD scanner every quarter to address this requirement.

OK. We disagree. Completely. This is one of the instance, where QSA super-imposes requirements on each other just because it sounds the same.

Let’s break it down by looking at the PURPOSE of the CDD scan. And the best way is to go back to the standard and pick up the part where the standard states a ‘data-discovery’ method in DESV A3.2.5.

Implement a data-discovery methodology to confirm PCI DSS scope and to locate all sources and locations of clear-text PAN

A3.2.5 PCI-DSS V3.2.1

It’s clear that the CDD purpose is to locate where CLEAR-TEXT PAN is found in the CDE (and non-CDE) environment. Why is this important? Because in the CDE, there should never be any clear-text PAN found in storage. All PANs must be protected by either of the Four Horsemen of the Apocalypse: Encryption, Truncation, Hashing or Tokenization. A failed CDD means there are card PAN found in clear text within the CDE.

So with that in mind, lets go back to requirement 3.1. This is nothing to do with identifying clear PAN. It talks about identifying AND deleting EXPIRED card data (based on retention policies). That’s it. If the PAN is encrypted or tokenized but its stored beyond its retention period; requirement 3.1 tells you to delete it. It talks about retention period and storage beyond it. Which part of it talks about doing a card data scan to identify clear text card information?

In the description, it further states: A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.

So QSA, please RTFM; requirement 3.1 isn’t talking about the need to run CDD quarterly to identify clear-text PAN storage; it is to run something (script) or manual; to identify PAN storage that is already expired. It is to discover duration of storage; not security of storage. Running a shell script may be good enough to get the timestamp of files; or checking the timestamp on the database entries to ensure that all card data is removed or anonymized after a period of say, 7 years.

If you need assistance in PCI-DSS or any other compliance standards like the ISMS or ITSM, drop us a note at pcidss@pkfmalaysia.com. We can help clarify some of these annoying requirements that even QSAs (as experienced as they are) are plucking out of their rear appendages.

PCI-DSS and the Retailer Conundrum

October 18, 2016 / / 0 Comments

pci-compliance

Over the past six years, we have had our share of PCI-DSS experiences across different verticals. Unlike other standards, companies each have their own unique PCI journey to compliance, due to the type of business they have in regards to storing, processing and transmitting credit card information.

Payment gateways usually have a challenge in securing stored credit card information. Here we identify the areas and types of storage and the option for securing this data – usually with encryption. The good news is that most payment gateways do not have many physical locations in scope, so we are generally looking at maybe one main site and one DR site, or two at most. This helps significantly.

BPOs or outsourced companies are another animal altogether. These are generally multi site projects, with various types of interactions with credit card information – usually phone, or MOTO (mail order, telephone order).

Banks are probably the top of the food chain in terms of complexity. Not only do they have hundreds of sites which are in scope, they also have storage of card data all over, as well as ATMs in scope in different branches.

Somewhere in between, we have the retailers. Not the e-commerce only retailers but traditional retailers. And here, in this layer of retailers, choke full of credit card and personal information, the hackers ply their trade.

Target (ironically the target of one of the largest information heist in history), Neiman Marcus, Home Depot, PF Chang’s, even Wendy’s – these were all hit with credit card breaches, resulting in millions upon millions of credit card information siphoned off into the jungles of the Dark Web. Why?

In general, hackers view Retailers (and hospitals) as easy targets. One example is where hackers ship a box full of new POS (point of sales) devices to the retailer outlets with a note from the Chief Operating Officer that these are devices to be installed and used from here on due to security or upgrade concerns – and once installed, these POS devices start hijacking credit card information in behalf of the hackers. A similar vector of attack is to infect the POS updates with malware and once the malware (like BlackPOS) is installed, it’s open season.

For the Target case, 40 million credit/debit cards were lost through POS. The reality was that the hackers breached Target’s main network first and accessed the database. Thanks to PCI, their database were encrypted and instead of hacking the keys, the hackers decided to go to the source (the POS devices). If the data in the databases was not encrypted, the damage would have been much, much more (we are looking at 70+ million).

PCI has stringent considerations for the security of POS, including software and hardware checks, as well as physical location checks. This is why retailers going through PCI is facing such a hard time. Some of the main issues are:

a) Retailers are underfitted for security. I am not sure if there is such a word underfitted – but in most cases, budgetary concerns are usually the reason why there is so little investments in security systems for retailers. The focus is on efficient transactions, and often efficiency and security are strange bedfellows. While millions are spent on customer relationship management tools, and systems to predict customer buying habits and big data solution, the backend hardware are outdated – we have seen XP and its variants still going strong in some retailers.

b) Inventory is haphazard. Some retailers grow, and in growing they do not keep stock of their internal inventory of systems. Some customers we go into have a very rudimentary excel sheet dated back to 2009 for their systems inventory, that is inherited several times by different IT administrators who seem to be going in and out of the company.

c) Like b, IT admin staff in retailers generally do not stay long. While some of the have good intentions in implementing certain structures and projects, these get lost along the way as new staff replaces them.

d) Location, location, location. In security, more locations, more problems. We see main branches carrying out good security practices but replicating along 85 branches in the country is a different story. In most attacks, hackers might infiltrate through a smaller branch with less focus on security and less education on preventing breaches.

e) Technical considerations. Most retailers we see have rudimentary effort in securing the network. Perimeter wise, we have seen a conglomerate of firewalls from yesteryears that no longer have any updates – and a plethora of free security software that does not have any auto-updates on signatures and in some cases, are spyware themselves. The network itself is usually flat (because of efficiency) and this brings in a huge amount of scope when your database is next to your ERP and accounting system that is being connected by a 100 of junior staffs with their desktops running XP.

There are many reasons why retailers are now prime target for PCI breaches. How do we avoid these breaches?

Well, you can’t. You can deter, but you cannot fully remove the risk of breaches. PCI helps a lot but as of now, there is no silver bullet to resolve security completely, except to unplug everything and set up a pen and paper store like back in the Wild West. But where PCI comes in – physical location security, POS security, network and database security – these are all critical areas where retailers can start with. Some first steps for retailers:

– Set up a proper inventory of systems: In my University in Western Australia, there is a huge engraving on one of the main halls: KNOW THYSELF. We generally use that advice a fair bit especially when we have had a fair bit of alcohol in the Beer Parties, while stumbling back to our dorms. But in order to know what we are up against, we need a proper inventory of what we have and set about securing these systems.

– Secure the perimeter: Firewalls and IDS/IPS are important here to ensure that attacks are sorted out and abnormal traffic behaviour is properly caught.

– Segment the network: While Segmenting is not for everyone, the security benefit here is considerable. Databases which are critical systems should not reside on the same network as your junior associate’s desktop, especially one who spends half his/her time downloading music or watching youtube. An analogy here is simple: when you put a healthy person in a room with a sick person, the sick person doesn’t get well, the healthy person gets sick.

–  Eyes on everything: We can’t iterate enough how important monitoring is in retailers. A good security information and event monitoring (SIEM) system is KEY to their security. Because of the lack of security personnel, the SIEM takes away a lot of these manual responsibility in tracking down strange and abnormal events. If a SIEM was set up properly in the Target case, they would have realised that one of their printer spooler device was sending out FTP packets out from the network into another system in the internet.

– Test, test and retest: Test your systems for vulnerabilities. You don’t need to spend truckloads on penetration testing if you don’t want to. Scanning using a Nessus scanner or even OpenVas will be useful as a first step. If a system is not patched, patch it. If you are still using Windows XP, seriously consider upgrading it.

– Finally, educate the users: While this has become a mantra for consultants and trainers, it’s still true. The weakest link in the security killchain is between the keyboard and chair. That’s the person. Security awareness training is key. While firewalls, email filters and Intrusion detection systems can go a long way, the security infrastructure is compromised by one executive clicking on an email attachment with the word: “Watch this Cat play the piano!”. Boom. Welcome malware, welcome ransomware, welcome sleepless nights for IT.

In summary, PCI-DSS establishes good and practical security practices for retailers. It might not be cheap, but once you have been hit by a ransomware or have your data pilfered, the fallout costs would be even more significant. For retailers looking to start off your PCI journey, or who need assistance on your ongoing one, please email us at pcidss@pkfmalaysia.com and we will get back to you immediately.

The Long Road of PCI Recertification

September 10, 2016 / / 0 Comments

pci-compliance

We have been in PCI-DSS for six years.

When we began back in 2010, we were tasked by one of our offshore customers in Brunei to get them “PCI” certified. Honestly, back then, early 2010, we were mainly doing IT audits under COBIT, a lot of penetration testing, some IT forensics and bogged down with piles of ISO27001 ISMS opportunities.Back then PCI was more known as Peripheral Card Interconnect, which are those add-on cards that you slot into your motherboard back in the days when you wanted to extend your network interfaces, graphics accelerators etc. I used to build computers in those dodgy computer shops back in the days, so I kind know that very well.

Fast forward six years, and now we are getting more and more queries for PCI-DSS. So much so that we have dedicated an entire team from our company to work only on PCI-DSS projects.

In earlier years, we brought our PCI clients through their first year certification, and many of them are now going through their 2nd, 3rd year recertification etc.You would think that most companies will find re-certification easy compared to the first time certification.

Don’t be fooled.

The thing about PCI is, during the re-certification, there is a lot more expectations on your organisation for compliance. An example – PCI requires logs to be retained 3 months online, 12 months offline. It also requires daily log reviews, as well as quarterly internal and external vulnerability scans.

Now for the first time certification, some of these requirements get a free pass: meaning, if our client had just installed a SIEM and only has 2 – 3 months logging set up, we verify those controls and based on those controls, we can pass their PCI. We don’t need to wait for 12 months to get the offline requirement passed. Likewise, if our client provides us with one internal and external scan, we can pass them for first time, we do not need a 4 quarterly scan before we sign off on the initial AoC.

However – once the re-certification arrives, these become MUSTs. Some of our clients want to undertake internal scans themselves and missed one quarter and expects us to still pass them. Or they have a SIEM, but no action done on daily reviews, or their SIEM was not set up properly and no logs were sent there. They get upset when we say we can’t pass them on those basis because their response was “We did this last year!”

Also, evidences.

Whenever we conduct our audits, we conduct it onsite. Onsite, the QSA will verify these controls if they are in place or not. On top of that, we require audit evidences. This is normal even out of PCI – in our governance audit or ITGC we often rely on audit artefacts (we call it), to supplement our opinion on whether certain controls are in place. In PCI, these evidences might come in forms of documents, policies, screenshots, configs etc – anything that can prove controls are in place, and effective, and accordingly used as per PCI requirements.

The onsite audit confirms these controls. The evidences supplement the QA process. Each QSA needs to go through a stringent QA (quality assurance) process internally, whereby, the QA requires supplementary evidences to prove why the QSA arrives to such and such an opinion. Therefore,  there is always that post-audit work of compiling audit evidences.

Some clients are of the opinion that the onsite audit should end the process and the auditor passes PCI then and there. Unfortunately it’s not so simple as there is a check and balance involved. An example is this: one of our clients recently added in a few out of scope devices into the CDE. During the onsite audit, we referred these and requested these systems removed or resettled in another segment. They said, OK, we will put it in another VLAN. So, if they do that, is that ok? We said OK.

Fast forward to the post-audit work, we asked “Hey, have you done your VLAN yet?”

“Yes, we have. Can you pass us?”

“OK, can you give a screenshot of the new configuration in your firewall or switch to prove that you have done this action?”

“WHAT??! Why??!”

You see – as auditors, we simply cannot trust you for your word. It’s not personal. It’s not that because we find you are a shifty trader looking to spin some yarn and fleece us of our money. It’s simply because it’s part of our job. Evidences provide us with some measure of assurance that these controls are done correctly and in place. It’s not that we question your integrity. It’s strange that even at this stage, many people find this difficult to accept, and we have gone through many, many strange situations whereby I have faced a red-faced, yelling executive thinking that I am personally insulting him and his family name by not trusting what he is saying.

Audit evidences. It’s part of PCI.

There are of course some exceptions, such as certain private and confidential documents or config that cannot be shared – even in that case, we generally ask these information to be anonymized, but evidences to be submitted all the same: for instance, evidence of VLAN config, you can screenshot the config, and remove elements deemed sensitive (IP Address, versions, other information etc).

In summary – the second year onwards, this is where the real PCI battles begin. Your recertification efforts will be a whole lot more than the first time, so get started early. We will be posting more articles on tips and actions that will make your PCI certification successful.

In the meantime, drop us a note at pcidss@pkfmalaysia.com and we will attend to any queries you have.

Get Ready for PCI-DSS version 3.2

February 19, 2016 / / 0 Comments

PCI Council released in the December 2015 bulletin, extending the deadline for Secure Sockets Layer (SSL)/early Transport Layer Security (TLS) migration. Recently, the PCI Council announced it would publish a new version of the PCI Data Security Standard (PCI DSS) in early 2016 to include the revised migration dates and address changes in the threat and payment acceptance landscape.

PCI Council’s Chief Technology Officer Troy Leach talks on what to expect with the release of PCI DSS 3.2 and how organizations can start planning for it now.

Excerpt taken from the PCI Perspective Blog:

When will PCI DSS version 3.2 be released?

Troy Leach:  The Council will publish the revision in the first half of 2016 – we are aiming for the March/April timeframe. We will keep stakeholders informed as we move closer to that date.

Based on what you’re saying, there is no expectation of a PCI DSS release in November 2016?

Troy Leach: That’s correct. We are not planning any additional releases of PCI DSS during 2016. The version 3.2 release in the first half of 2016 replaces the expected fourth quarter 2016 release.

What changes are expected?

Troy Leach: When making changes to the standard, in addition to market feedback, we look closely at the threat landscape, and specifically what we are seeing in breach forensics reports as the trending attacks causing compromises. With this in mind, for 3.2 we are evaluating additional multi-factor authentication for administrators within a Cardholder Data Environment (CDE); incorporating some of the Designated Entities Supplemental Validation (DESV) criteria for service providers; clarifying masking criteria for primary account numbers (PAN) when displayed; and including the updated migration dates for SSL/early TLS that were published in December 2015.

How long will organizations have to move over to PCI DSS 3.2?

Troy Leach: As usual, there will be a transition period, and we will keep everyone informed as we approach publication. Version 3.2 will become effective as soon as it’s published, and version 3.1 will be retired three months later to allow organizations to complete PCI DSS v3.1 assessments already under way. Keep in mind, though, that new requirements always have a sunrise date prior to them being effective. This allows organizations to plan accordingly prior to validating to new PCI DSS requirements. The new requirements will be considered best practices for a sunrise period to be determined based on the release date.

As a reminder, the SSL/early TLS updates in PCI DSS v3.2 are those made public in December. Organizations can and should already be addressing this issue, starting with reviewing the Bulletin on Migrating from SSL and Early TLS  now for more information on where to begin with migration and taking advantage of the guidance and resources outlined.

PCI-DSS Applicability to Hosting Providers and Data Centers

July 12, 2015 / / 0 Comments

MDCA-final_FINAL-logo-300x199

Recently I was invited to speak in the quarterly meeting for the Malaysian Data Center Alliance (MDCA) regarding the applicability of PCI-DSS to their business.

More and more we are getting questions from traditional data center and hosting businesses on whether they should go for PCI-DSS and whether we can help them.

Here’s a quick FAQ for these businesses:

a) Why do Data Centers need PCI?

Actually – you don’t. PCI-DSS is applicable to businesses dealing with payment card data – storing, transmitting and processing. These are probably your clients – and in general, where they need to be PCI certified, they want to ensure their ‘providers’ – such as yourself – are certified as well.

The pressure for compliance does not come from the payment brands for data centers – instead in almost all cases, they come from the customer themselves.

b) So what benefit do I get from PCI?

The move of hosting providers to become PCI compliant is in parallel to the move of businesses to offload their servers and infrastructure to the ‘cloud’, or to third party providers to host their applications. The cost savings vs building their own data centers from ground up makes sense to most entities, except for large payment companies and banks. Even so, some of these larger entities will outsource their disaster recovery site to a third party – and if they deal with credit card, then that DR site needs to be compliant as well.

c) So should I be spending money on this compliance?

From a data center perspective, there is no direct requirement to be PCI compliant. However, if their customer is going for PCI-DSS compliance, and the data center is NOT compliant, then the data center is obligated to participate in the customer’s PCI program. While this might be manageable for a small group of customers, the idea of managing multiple customers projects and participating in such projects over the long run is not feasible. Therefore, more and more data centers and hosting providers are moving to become ‘PCI Certified’ themselves. Doing so, basically requires them to just show their certificates to their clients instead of participating in their individual compliance programs. Some of the largest success stories of PCI certified hosting/infra are Amazon Web Services and Microsoft Azure Trust Center.

d) SO…how much will it generally cost?

This is very subjective because even hosting providers and DCs have scope. However, the general rule of thumb is that the less visibility you have on card data and less services you offer, the less it will cost. For instance – if a data center only offers M&E and Physical room for client. This against another data center that offers those AND an internet gateway to get out and IPS/IDS, firewall etc. The latter DC will be up against Requirement 1, requirement 3, requirement 9 and other related requirements, while the first one will probably just need to deal with Requirement 9. You could be looking anywhere between RM30K – RM40K for the entire compliance program. (Gap, Remediation, Certification, Scans etc)

This might sound like an awful lot, but the whole program consist of two assessments from QSA (Gap and Cert) and a whole lot of other services during remediation. A typical onsite security assessment is around 18 – 20K already from any of the big 4 firms. And they usually just send their juniors who are just out of college and generally still staying with their parents. Here you get a full fledge QSA and director or senior management level guys supporting the audit. We take it extremely seriously, and we don’t send out pencil pushers with a little checkbox and hardly a stubble under their chin. Penalty for PCI is very very serious and we need to ensure all our clients get the best possible support.

e) Are you open for a quick meeting onsite?

Of course. Drop me an email at pcidss@pkfmalaysia.com and we will get working on it!

© 2024 PKF AvantEdge

— Up ↑