I completed the PCI Professional Certification (PCIP) today. It wasn’t very difficult actually, but this is coming from a guy who has gone through more than a dozen projects for PCI-DSS for clients ranging from merchant, service provider and bank, doing gap assessments, implementation and coordinating certification with our partner QSA. So yeah, I found it OK, but that’s not to say the other guy might find it so. The questions are really taken from the PCI 12 requirements, and our understanding of it. There are a bit of PTS, P2PE and PA-DSS, but the bulk of it is really in the implementation of PCI in an organisation. It’s a good exam for someone wanting to know more of PCI and needing some good security foundation, but I’d say the QSA cert would be better. Unfortunately it’s not available for me, so PCIP it is then.
In order to be a PCIP, you need to obviously pay for the exam – right now it’s a whopping USD1390. Last year, it was just about USD995. I should have taken it, but the joys of procrastination has no end. You can have an optional training online as well, but for me, since I have been eating and drinking PCI – and also training my clients as well – USD1390 was plenty enough. Once done, we need to submit our CV to PCI-SSC for them to see whether we are….well, qualified. I don’t know what is non-qualified – do they require some sort of years of service etc? I don’t know, because they responded I was fine and time to set my exam with VUE at any exam center. This is really convenient, because I have an exam center like 5 minutes walk from my home.
So what next? We are planning to start our PCI training program next month. I noticed a lot of my clients are in need of understanding of PCI, and what better than to tie up our program with PCIP? Stay tuned!
In one of the more awkward consulting situation, I was sitting in a room where the technical lead of my client, along with his impressionable junior staffs started talking about Requirement 3 of PCI, which we all know is the mother of all inconvenience – Secure storage.
Obviously we reached a point where I was talking about strong encryption and recommended AES-256. The technical lead sagely says that he prefers SHA256 instead of AES. There was a slightly muted pause when he said that, and while his juniors all nodded equally sagely, I was caught whether to respond and possibly correct him in front of his juniors or just mutter an agreement.
You see, AES and SHA are fundamentally used for different things. One is used for hiding and encrypting, the other is used for verifying. SHA is a hash function like the old MD5, while a proper comparison of AES could be 3DES. SHA has no key. Once you SHA’ed it, it’s SHA’ed for life. AES can still be decrypted, and obviously there can be key management in place for it.
I decided to correct him, by saying that these are two different things altogether. However, he still insisted SHA could be used as an encryption. I am pondering on the day that he decide to SHA his entire database (if that can be done), and I guess we’ll have a very large number of hashes to verify with. We are still in discussion over this.
Over the course of MANY PCI-DSS projects, we have come across a fair bit of scenarios. From the shake-your-head unbelievable nonsense, such as the acquirer bank sending in full PAN over fax or email to our service provider, and then refusing to comply to PCI, to the often stated problem – we need to keep full PAN to identify the transaction so we can reconcile it later.
That last one is particularly grating. Because it forces our customer’s scope to be so large, so unnecessarily. One of the clients we are working with now, when asked, and asked and asked again, finally conceded that actually they don’t require Full PAN.
According to PCI Compliance 3rd Edition by Syngress:
Did you know that you only need four elements to uniquely identify any transaction in your enterprise, and one of those is not the full card number? These elements are as follows:
First six and last four (or just last four) digits of the card number,
Date and time of purchase,
Amount of purchase,
Customers who have used this method have never reported that two transactions matched these elements identically but had different card numbers.
I’ve always been saying that from day one. You don’t need full 16! The reason why people insist on it is that they or the service provider or the developers are just too lazy to change primary reference key to incorporate several parameters to identify a unique record. It’s laziness. So instead they take the most unique key and just use it, forcing compliance that could have easily been avoided. Unless you are an issuer or acquirer, you technically can avoid painful compliance controls if you just STOP obsessing over storing PANs!!
Almost a year in since PDPA was enforced last year, we are still faced with slow adoption by many of our clients. We are still getting questions on whether they need to ‘register’ or not, and if they don’t, they assume they are exempted from the Act.
Registration and compliance are two different matters. Registration applies to the 11 categories of industries, while compliance applies to every organisation dealing with personal information for commercial purpose, including HR.
As for easier reference, the data user classifications and details, once more, as follows:
|Communications||Licensees under the Communications and Multimedia Act 1998
Licensees under the Postal Act 2012
|Banking and Financial Institutions||Banks and investment banks licensed under the Financial Services Act 2013
Islamic banks and international Islamic banks licensed under the Islamic
Financial Services Act 2013
Development financial institutions under the Development Financial Institution Act 2002
|Insurance||Insurers licensed under the Financial Services Act 2013
Takaful operators and international takaful operators licensed under the
Islamic Financial Services Act 2013
|Health||Licensees, and holders of a certificate of registration of a private medical clinic or a private dental clinic, under the Private Healthcare Facilities and Services Act 1998
A body corporate registered under the Registration of Pharmacists Act 1951
|Tourism and Hospitality||Persons carrying on or operating tourism training institutions, licensed tour operators, licensed travel agents or licensed tourist guides under the Tourism Industry Act 1992
Persons carrying on or operating a registered tourist accommodation premises under the Tourism Industry Act 1992.
|Transportation||Malaysian Airlines (MAS), Air Asia, MAS Wings, Air Asia X, Firefly, Berjaya Air and Malindo Air|
|Education||Private higher educational institutions registered under the Private Higher Educational Institutions Act 1996
Private schools or private educational institutions registered under the Education Act 1996
|Direct Selling||Licensees under the Direct Sales and Anti-Pyramid Scheme Act 1993|
|Services||Companies or persons in a partnership carrying on businesses in connection with legal, audit, accountancy, engineering or architecture services ;
Companies or persons in a partnership conducting retail dealing and wholesale dealing as defined under the Control Supplies Act 1961;
Companies or persons in a partnership carrying on the business of a private employment agency under the Private Employment Agencies Act 1981
|Real Estate||Licensed housing developers under: the Housing Development (Control and Licensing) Act 1966; the Housing Development (Control and Licensing) Enactment 1978, Sabah; and the Housing Development (Control and Licensing) Enactment 1993, Sarawak.|
|Utilities||Tenaga Nasional Berhad, Sabah Electricity Sdn Bhd, Sarawak Electricity, Supply Corporation, SAJ Holding Sdn Bhd, Air Kelantan Sdn Bhd, LAKU Management Sdn Bhd, Perbadanan Bekalan Air Pulau Pinang Sdn Bhd, Syarikat Bekalan Air Selangor Sdn Bhd, Syarikat Air Terengganu Sdn Bhd, Syarikat Air Melaka Sdn Bhd, Syarikat Air Negeri Sembilan Sdn Bhd, Syarikat Air Darul Aman Sdn Bhd, Pengurusan Air Pahang Berhad, Lembaga Air Perak, Lembaga Air Kuching and Lembaga Air Sibu.|