Tag: pci malaysia (Page 4 of 4)

PCI-DSS and the Retailer Conundrum

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.

PCI-DSS v3.2 is officially published

pci-compliance

After some back and forth on the draft versions, PCI v3.2 is now officially published. You can go ahead and download it here, and click on the nice little link saying 3.2 and agree to all sorts of terms and agreements nobody ever reads about.

Anyway, a little bit of background on this release. Usually, versions for PCI are released in the later stages of the year in November. In fact, even I mentioned this to a few clients that version updates were done in November, until PCI recently announced that v3.2 is to be released in March/April timeline due to a few factors as described in this article. So yeah, now I need to admit I was bamboozled. PA-DSS v3.2 is likewise to be released sometime in May or June.

So here’s how it works: 3.2 is now officially effective. PCI v3.1 will be retired end of October 2016 (basically to allow everyone to sort of complete the v3.1 if you are already in the final stage of completing it). So all assessments/audit that occurs AFTER October will be version 3.2. This is important to note, because if any gap assessments begin now, and has a timeline to complete AFTER October, you want to use 3.2. For ongoing projects, it is best we scurry and get it all done before October! Chop chop!

There is a bunch of ‘best practices’ that will become requirements by February 2018. Other dates you need to be aware of:

a) June 30, 2016 – for companies not migrated yet out of SSL/early TLS, you will need to have a secure service offering (meaning an alternative service utilising TLS.1.1 and above. I will go out on a limb here and suggest to use TLS1.2 knowing how volatile PCI guys are in changing stuff).

b) June 30, 2018 – SSL/early TLS becomes extinct as far as PCI is concerned. No more mitigation plan! The exception is on POS terminals that has no known exploits.

c) January 31, 2018 – This is the deadline where new requirements graduate from being ‘best practices’ to ‘mandatory requirements’.

OK, now that’s out of the way, here’s a snapshot on the main stuff of v3.2 and what we are facing:

a) New Appendix A3 covers the Designated Entities Supplemental Validation. This basically means that if any acquirer or VISA/Master deems that a service provider needs to go through ADDITIONAL requirements on top of the torture they have endured for PCI, they can. These victims could include companies making ridiculous amount of transactions, aggregators or companies that are constantly breached. So PCI has a whole bunch of extra stuff for you to do, mainly to deal with BAU activities, incident response, documentation and logical access controls.

b) Additional cryptographic documentation – Service providers are not going to enjoy this. We will now need to formally document the protocols, key strength, cryptoperiod, key usage for each key and HSM inventory. This should technically be done anyway in your key management procedure document, but now its a requirement. Take a look at NIST SP800-57 for the key concepts to get you started.

c) 8.3 is significant : Multifactor login. Whereby previous versions stated that 2 factor authentication is required for remote access from non-secure networks, now 3.2 shifted this requirement to “all personnel with non-console administrative access, and all personnel with remote access to the CDE”. Wait, what? This means, even if you are accessing an administrative UI or page (non-console) from a secure environment, multi-factor (2 factor is good enough) is required! I think there would be some pushback on this as this requires a fair bit of effort. We have until February 2018 to implement this.

d) Another big one is 11.3.4.1 – segmentation PT now needs to be done every SIX months as opposed to a year. This is not good news for some clients who have segments popping up like acne on a pubescent face. That’s quite a lot of work for them to do and this might give them more cause to think of a completely isolated network just for PCI-DSS with its own link and architecture, as opposed to sharing with multiple not in scope segments. Again, we have some grace period till Feb 2018.

e) New requirement 12.11 is interesting. I have always been an advocate to do constant checks with clients to make sure they are at least practicing PCI. We have this free healthcheck service every quarter for clients who take up our other services and we are checking exactly this: daily log reviews, firewall is clean, new systems are documented and hardened, incidents are responded, proper approval for changes etc. It’s nice to see that our efforts now have something formal tied to them. Feb 2018 is the deadline.

f) Here’s a downer. Appendix A2. We all know there was some sort of escape loop for those who were caught with SSL and early TLS in their applications. They created mitigation documents which may or may not be true. Just saying. Now, if you take this route, this is no longer a free pass for your ASV scans or vulnerability scans. If you have these protocols in place, your mitigation plan must fully address A2.2 requirements. If you are a service provider, take note of A2.3: YOU MUST have a secure service option in place by June 30, 2016! Not 2018. 2018 is when you stop using SSL/early TLS. So this timeline is slightly confusing. Like X-Men:Days of Future Past confusing.

Some main clarifications include:

a) Secure code training now officially needs to be done annually – you won’t want to guess how much push back I get on this when I tell clients it’s annual, and not something that is done when they have the budget for it (which is never).

b) Removing the need to interview developers to ‘demonstrate’ their knowledge – I do programming a bit, but I’ll be foolish to think I can go up against a senior developer who eats, breathes and … lives for coding. How awkward I’ve seen some younger QSAs struggle to do this (determining whether the senior dev guru is good enough), when its obviously not something they even know about. Let auditors audit and let developers code.

c) Finally, note added to Req 8 to say that authentication requirements are not required for cardholder accounts, but only to administrative or operational/support/third party accounts. We have always practiced this anyway but now its clear.

d) More clarifications on addressing vulnerabilities considered ‘high’ or ‘critical’. I am not a big fan of these. I think every vulnerability should eventually be addressed, just prioritised in terms of timing. Even if it’s low or medium, it’s still important to have a mitigating factor to it. There is a reason why it’s a vulnerability and not something you can sweep under the carpet.

e) A good note on pentesting in 11.3.4c – testing now needs to be done by qualified internal or external resource with independence. Again, we already practice this but it’s good that now it’s official.

So, that’s about it. Of course, there’s a fair bit more. I suggest you to poke through the summary of changes first and then go through the documentation itself.

Be aware of those dates! It’s all over the place (June 2016, June 2018, Jan 2018), and who knows these might change in the future. Have a happy compliance.

 

 

 

Application of PCI-DSS in Retail

“Technology…is a queer thing; it brings you great gifts with one hand and it stabs you in the back with the other.” – CHARLES PERCY SNOW”

This was a quote by a man born more than a century ago, that is resonating in its applicability even now, especially in the payment processes for retailers.

On one hand, we are discovering amazing new methods and breakthrough in payment and doing transactions, all driving convenience to the end customer. mPOS has been around for years, and is now migrating to using smartphones to replace bulky handheld terminals; Applepay and other technologies enable mobile phones to make micro transactions through a few clicks; internet transactions increasing to the billions whereby someone a thousand miles away can order something and receive it a few days later. And we are only skimming the possibilities. Cryptocurrencies like Bitcoin might dictate the future of retail where the entire currency is virtual. Transporting of goods through drones might be in the horizon, and in the future not as distant as you would like to think, 3D printing will enable item blueprints to be sent to your printer by the retailer and the item can be created in front of you. It is an exciting time to be involved in technology, for sure.

Yet, on the other hand, as there are people aiming to make a positive impact to the world, there are also those who will twist technology to their selfish ends. Every transaction funneling through the world wide web can be tracked, and tapped, and risk being stolen. Credit card information residing in so-called secure servers can be taken off by just one employee accessing the hard drive through a malware-infected laptop. The very thing that makes life convenient can also make it dangerous: the very same 3D printer that prints out your son’s first airplane toy, can also be used to print out a functioning AK-47 by terrorist cells.

Payment Card Industry Data Security Standard (PCI-DSS) is one of the emerging standards in the attempt to counter this onslaught of security risks. This standard was created by a group consisting of VISA, Mastercard, American Express, Japan Credit Bureau and Discover a decade ago and has now evolved to version 3.1 (with version 3.2 coming this year). The standard applies to any retailers involved in any sort of credit or debit card transactions involving any of these brands.

In PKF Avant Edge, we know there is no magic pill to solve all security issues. But having been actively involved in PCI-DSS since 2010, and with a portfolio of more than 30 PCI-DSS clients, ranging from up and coming payment processors that processes online games to mega sized oil and gas firms, we have experienced companies that are virtually built like a house of cards. Without proper guidance, their IT systems and information security have survived only by sheer luck. Through our methodology of assessing, remediating and certifying, we have helped them strengthen their systems; secure their information and limit needless propagation and storage of critical information assets.

Retailers have a larger challenge, whereby the more locations you have, the more security headaches you will receive. PCI-DSS attempts to do two things for retailers – limit only necessary credit card information to where it should be and to secure this information where it is stored, transmitted and processed. It is not always easy – in fact, the opposite is often true. Most retailer underestimate their security posture and think that PCI-DSS can be passed in a few weeks. In all cases, the rude reality is that they have to undergo changes to their architecture and project thought to be completed in 2 months can stretch to 6 to 8 months. Or even longer.

While some practitioners might say that the remediation effort is the most important aspect of the PCI-DSS program, we are of the opinion that it is in the scoping exercise right at the beginning. Retailers especially, due to distributed location, MUST scope correctly. In PCI, there is such a thing as ‘overscoping’, meaning the coverage of unnecessary items. This places pressure on cost, time and resources. There are alternative ways to make PCI easier, and this is where having an experienced PCI advisor is key. We are not just office consultants looking at a standard document or checklist. We are on the field technology practitioners not just experienced in PCI, but with real world work experience in IT service management, IT security and network operations control, security testing, software development, IT forensics and architecture solutioning. PCI-DSS is a technical standard, and whoever you select to guide you on your journey MUST be technical.

Contact us at pcidss@pkfmalaysia.com for more information about our services .

MPSB is re-certified as PCI v3.0!

logo_mpsb

Congratulations to ManagePay Services Sdn Bhd for re-certifying under PCI v3.0. They are the first among our clients who achieve V3.0!

PCI v3.0 maintained the 12 main requirements from PCIv2. PCI DSS v3.0 is effective January 1st 2014, but organisations are given the choice to comply to either v2 or v3 in 2014. All certifications in 2015 (MPSB included) is certified under v3.0. Under v3.0 however, major changes include:

a) Testing of segmentation adequacy through penetration testing

This determines whether segmentation had been done properly. We have seen many implementation where ‘segmentation’ was supposedly implemented, but we found that route between network had unfiltered access between zones. This will ensure whether CDE is properly isolated from non-scoped access.

b) Validation of 3rd party providers

PCI-DSS compliance must be validated if card holder data is being shared out to 3rd party providers. This is either through their own AOC (like AWS), or an agreement to participate in the customer’s PCI program.

c) Business as Usual

By far, this is the most challenging to us. Most of organisations undergoing PCI-DSS struggle in the second and third year re-certification as they need to demonstrate compliance in everyday activities and not just during audit period.

d) Protection of POS

Most of the issues of recent times like Target are due to POS Malware exploitation.V3.0 requires companies to maintain inventory and maintaining POS from being tampered with as well as periodic training.

Of course, v3.0 covers a lot more than these. For a more detailed look at PCIv3.1 and how it affects your organisation, you can contact avantedge@pkfmalaysia.com. Or you can join our monthly PCI training, which is HRDF claimable, the latest schedule is at http://www.pkfavantedge.com/training-programs/.

PCI v3.1 is out and so is SSL!

ssl-farewell

On 15th April, PCI became 3.1 versions old.

The ‘dot’ 1 from the version 3 that was just released around a year ago seeks to address the myriad of issues stemming from the old and dignified SSL protocol.

Ah, SSL. How I will miss thee. SSL itself had undergone its own transformation from a little protocol used by a little firm called Netscape to be one of the most used transmission protocol in the history of the entire universe. OK, that’s a little overstating it, but this is like the god father of Transmission Protocols. It’s like Don Vito’s father’s father. I will probably write another Ode to this wonderful protocol in another article, but suffice to say, SSL is no longer allowed in PCI. If Heartbleed hurt the protocol, POODLE killed it.

A lot of systems support both SSL 3.0 and TLS 1.0 in their default configuration. Newer software may support SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2. In these cases the software simply needs to be reconfigured. Extremely older software, dated back to the days when the T-Rex was still alive, may only support SSL 2.0 and SSL 3.0. This is an extremely rare sighting, and is often considered on par as the sighting of the Yeti himself.

On a more serious note, anyone still on SSL, even version 3.0 should consider migrating now to more secured protocols, such as TLS1.2. Like WEP, SSL and early versions of TLS will no longer be acceptable by PCI-DSS. The changes are requirement 2.2.3, 2.3 and 4.1. Current reviews for PCI will no longer accept these protocols. Passed certifications will be given a grace period until June 30th 2016 to change these protocols. Just use TLS1.2 and above (I know, you argue TLS1.1 is still secured, and it is, and it still can be used, so if you are using 1.1, then stick with it, else, might as well upgrade to 1.2)

OK, goodbye SSL and thanks for all the fish!

Newer posts »

© 2024 PKF AvantEdge

Up ↑