Tag: Payment card

PCI-DSS: Business Not As Usual

Have you heard the phrase Too Long, Didn’t Read? What if this applies to your PCI DSS compliance program, rephrased to “Too administrative, didn’t’ do?”.

We get this all the time in our meetings. Everyone mobilise for the big PCI project, everyone celebrates when they get certified and everyone suddenly gets collective amnesia and forgets about it. They forget there are daily requirements (like daily review of logs), weekly requirements (like FIM file comparisons), monthly (like critical patching), quarterly (ASV etc), half yearly (firewall reviews etc) and annual (testing etc). Yes, there are such requirements. We generally encourage our client to celebrate their success for first time certification but keeping in mind these obligations. Certain things you just can’t afford to miss out like your ASV scans and Internal VA scans.

PCI calls this Business As Usual (BAU). Being so long on the receiving end of these compliance requirements and now dishing it out in our advisory, I can safely say: PCI isn’t business as usual. In theory, yes, it should be, but theory and reality remains as far away as the possibility of Malaysia winning the next World Cup. A lot of our clients, after winning the PCI certification, find themselves completely overwhelmed with the so called Business As Usual theory that they wonder, whether after achieving PCI Business As Usual whether there will be any Business left to be usual about.

So what happens now that you are PCI compliant? When you are planning your PCI DSS compliance maintenance, you may want to setup a team to look into all the requirements, be it the technology, process and people. After you get your PCI DSS compliance, remember, the ‘maintenance’ clock starts. Yes. So if you take 2 months to celebrate your victory over this dastardly villain called PCI, you technically have one month left to do your Internal Scans and ASV scans. So don’t forget about what you need to do. Your PCI team needn’t be dedicated personnel (Very few companies can afford that), but there should be a lead person, relatively not bogged down by day to day operation works, and ideally independent from the operations as well. If you have a info sec team, it would be good, else a technical project manager to lead and the responsibilities to maintain, to go back to the process or system owners.

True, even before PCI arrives, you are probably already bogged down by other compliance requirements on top of your normal day to day. ISMS, customer audits, regulatory audits and assessments, internal audit, and now PCI. It’s like eating pancakes after pancakes except these are horrible tasting pancakes.  You might forget some of the administrative tasks that need to be maintained as part of your PCI DSS compliance process and we have had customers scrambling to complete their quarterly scans after missing them. Eventually, after a period of time, all these tasks will pile up on your plate and you are left with the prospect of being unable to be recertified. Your PCI DSS compliance will be at risk of becoming non-compliant and void and really, it’s not something the board will be too happy about, after taking 3 months of budget to celebrate the victory earlier. It’s like winning the English Premier League one season and getting relegated the next. The emotions are too much. We may think these maintenance tasks are petty but it is an important component in your PCI DSS compliance ecosystem.

Here are some insights to some examples of these administrative tasks that might be missed:

Changes on firewall/switch/router rules or configuration– it is highly critical that before a change is done, proper testing, approval and documentation are carried out. As these devices are critical components in the network infrastructure, any misconfiguration may result in security issues or in our observation, even bring down the whole network and have people scrambling over the weekend unnecessarily. Proper testing and approval process are any case required before changes can be made and this must be documented. Documentation provides an audit trail of changes and why these changes are required. So, don’t forget to document this process. Or risk the weekend being messed up.

Patching – There is this perception that if I’ve setup my systems to perform patching automatically, everything is well. Wrong! You need to review the patches and ensure that it is safe to be deployed and it will not like, I don’t know – crash your production systems? Next is to make sure the patching applied is being documented so that you have a history of updates on your system. A configuration information (CI) system can do that, or you can ensure you run your inventory checks regularly, as Windows would keep track of these applied patches. If the system is being patched up manually, you need to have the procedure of checking for updates on a regular basis. Make it a habit to check if your system is running with the latest patches regardless if the patching is automatic or manual by making it as a checking activity in your periodic task list. Remember, PCI would require a one month critical patch deadline and three months for non critical security patches.

Anti-malware – anti-malware will normally update automatically and periodically and we will assume that it will run as what it is being configured to do. As such we will not bother to check unless something bad occurs (which almost always does). As part of your administrative task, you should make it as a daily task to check the anti-malware system status, malware detected and the resolution of it and put this task in your checklist.

Logging and Monitoring – PCI DSS requirement 10.6.1 requires review of security events at least on daily basis. Most people stare blankly at me as if I’ve just told them elephants do wear tutus and can fly. Then they realise that I am not joking, they shake their head and invariably say (in variable tones, depending on how incredulous or stupefied they are): “WHAT?! DAILY?!?” .

Well, yes, in a way, although PCI in its supplementary document Effective-Daily-Log-Monitoring-Guidance.pdf, they have provided this little leeway for your ease:

“A reasonable timeline must be defined to allow less capable organizations to perform security log reviews while still enabling the organization to detect malicious or anomalous activity before it can likely escalate. In the case of Requirement 10.6.1, PCI DSS has determined that timeline to be a maximum of 24 hours or one calendar day.”

So when we refer to ‘daily”, it is with this definition in mind. Still a difficult one, but hey, OK.  In our advisory works, we have seen that clients often miss out the daily review and alert they receive (usually through email). It could be a SIEM (Security Information and Event Monitoring) system is deployed and configured to identify a threat and sends out an email to the person in charge. Instead of monitoring this email that might be a critical security issue, it is not reviewed. Not reviewing security alerts is a risk that may have adverse effect for obvious reason. In a recent retailer breach, for many months hackers were siphoning information from their POS systems to a spool server and removing that data file to an external system. If reviewed properly, such an abnormal data flow might have been spotted.

So, these are a few of the admin tasks. There are a lot more. Moving forward, be diligent, make it a habit to not miss any of these out and incorporate these administrative tasks as part of your daily routine tasks. Other tasks include ensuring quarterly testing such as ASV, annual penetration testing, etc as described in requirement 11 are carried out properly and given enough time to perform. Don’t expect your team or vendor to do a pentest on 50 systems and tell them to complete it by tomorrow. Failure to observe PCI timelines may result in you losing your compliance.

Don’t get relegated after winning the league!

Contact us at pcidss@pkfmalaysia.com for further queries on PCI-DSS and we will set up a meeting with you as soon as you are available.

PCI-DSS: Challenges faced in Malaysia

What began as separate compliance programs by major card brands, are now under a unified umbrella called PCI-DSS (Payment Card Industry Data Security Standard). PCI-DSS serves to protect the cardholder data and also the interest of the card brands. VISA, AMEX, MasterCard, JCB, and Discover (Diners Club) established the Payment Card Data Security Standards Council (PCI SSC). The goal of PCI SSC is now to guide any institution, especially the financial institutions to have better security surrounding their credit & debit card businesses.

Is there a need for yet another compliance program? The short answer is a resounding yes. According to StatiscsBrain[1], as of 18th of June 2013, in the United States itself, businesses have suffered more than 11 thousand cases of card fraud with an average loss of $4,930 for each case of card fraud. In total, it has cause a financial loss of around $ 21 million on average.

In Malaysia itself, we are now faced with an alarming rise of card fraud cases. According to Bank Negara Malaysia (BNM), [2] while the cases of fraud have decreased overall, the fraud volume still remains high. If the customer, merchant and the banks do not put in a concerted effort to fight these fraud cases, many more will fall victim to increasingly sophisticated attacks. This is also supported by The United States Security Council (OSAC)[3] stating: “credit card fraud has decreased but still continues to become a problem”. In short, the frequency might be less but the amount that each case brings is still a problem to the authorities.

In terms of the PCI DSS certification, a majority of large financial institutions in Malaysia, especially banks and larger service providers are still undergoing the process. Some have taken more than 3 years to be certified. PCI DSS is already a difficult compliance to begin with, with more than 300 plus controls to deal with. Financial institutions are pressured by card brands to ensure that PCI DSS become their utmost priority, both internally as well as for any service provider or merchants dealing in card business.

In some cases, one of the reason for certification delay is the lack of documentation done on each system in the PCI scope, causing a lack of proper maintenance on the system. This covers from software to hardware and network devices. This will affect the certification in the remediation phase where the administrator really needs to identify each data flow concerning card data and needs to clean up to ensure that unnecessary rules, ports and services are disabled. The amount of legacy rules, unmanaged inventory are significantly large, especially for banks that own distributed branches. The undertaking is intimidatingly difficult.

Furthermore, the implementation of Malaysian Electronic Payment System (MEPS) which allows the sharing of ATM networks, gives the ability for customers to withdraw their money via a different ATM bank using a debit card. Debit cards are under the PCI purview, and is often doubled as an ATM card that can be used to make purchases just by deducting the account balance by swiping it. These have enabled the storing of user Primary Account Number (PAN) in the institutions and to some extent in clear text for settlement purposes which violates the requirements in PCI DSS. The transmission of the card data must also be addressed, as the card data might travel through non-secured channels such as normal emails, or open channels that can cause the data to be intercepted in transmission. Therefore controls have to be taken to ensure that all networks in and out are secured

Another point of concern is the PCI DSS exercise budget. Every organization big or small, private or public listed have a certain amount of budget allocated. While IT budgets have grown significantly, it has to be reminded that PCI is NOT an IT initiative. It is a business initiative and might take a large portion of the said budget. The budget would be used for the engagement of third party experts or actual products to mitigate the concerns. Due to budgeting, companies often overlook certain areas by cutting down the budget such as avoiding expert consultancy. They opt to do the certification or the remediation process by themselves in order to save some portion of the budget. This has short term yield but sacrifices the long term goals. Taking on PCI is akin to journeying through an uncharted maze. Having a guide is therefore critical especially for first timers in a relatively large company.

In conclusion, there is still a long way to go for Malaysian companies to abide 100% to the requirements of PCI-DSS. For that, they need to  fully understand the  requirements and ensure proper scoping is done (as there are cases where one can OVERDO the compliance). For a free scoping or advisory on how we can help you in your PCI-DSS journey, drop us an email at avantedge@pkfmalaysia.com or contact us at +603 6203 1888.

Article by: Wafiy Karim

PKF Avant Edge Sdn Bhd

© 2024 PKF AvantEdge

Up ↑