PKF AvantEdge

Author: pkfavantedge (Page 16 of 37)

IATA PCI-DSS: New FAQs!

January 23, 2018 / / 0 Comments

So, it has been a while since we’ve updated on the ongoing PCI-DSS program from IATA. Just a brief recap then: Airlines have demanded that IATA support their own internal compliance project by making the BSP (Billing Settlement Plan) card sales channel PCI DSS compliant. This is why IATA Accredited Travel Agents now need to become PCI DSS compliant by 1st March 2018. Yes, that’s roughly 6 weeks ahead of this writing. And no, it doesn’t seem like there might be any extension towards this compliance from IATA. However, there are some pretty big news headed your way on this compliance, as we are in touch with IATA over the last couple of months and also assisting many travel agencies to get PCI-DSS sorted out in their payment channels.

However, for this article, we will focus on the brand new FAQs that just came out a few days ago (18 Jan 2018)! You can find the updated FAQs here at http://www.iata.org/services/finance/Documents/pci-dss-faqs.pdf, and we are going to look through a few changes.

FAQ #3

What if I do not have an acquirer?

Old FAQ: We suggest that you contact the credit card branch that you are working with.

New FAQ: In that case, you are solely accountable for the PCI DSS compliance of the BSP card transactions you are making on account of the airline whose ticket you are selling. We suggest you contact your GDS provider who can provide some guidance, and then review through which of your systems card details transit or are stored. Starting from this you will know which of your systems
must undergo a PCI DSS evaluation.

Our opinion: The first FAQ was of course, not exactly extremely helpful, since most credit card branch does not give two hoots about travel agencies banging down their doors in search of their response. The new FAQ is basically saying, well – you just need to figure out yourself then, but you can ask the GDS guys if you wish. We have. The GDS guys are very important in this factor, because they first need to be PCI compliant. Sabre, Amadeus and I think Galileo Travelport is. Secondly, they can give some guidance on how agencies can approach PCI based on the client software that is installed on the agency side.

What do we mean by this? Because for agencies not storing credit card, they can possibly be eligible for shorter SAQ (Self Assessment Questionnaires) for PCI. An SAQ D has 340+ questions. An SAQ A has only 20+. If an agency uses the GDS for credit card passthrough transactions (i.e the credit card form of payment), and not store credit card information in the back office or any electronic form (email, skype, excel etc), they might qualify for shorter SAQs. The question is which?

Some advisors claim the SAQ C is correct due to the fact that the GDS is a payment system. The reasoning is that this is no different from integrated POS systems like Micros. In Malaysia, we have hundreds of different vendors in POS solutions for retailers, F&B franchisees etc. But is the GDS really like an integrated POS solution? SAQ C has around 160 questions. The amount of time you will spend on this is probably the same amount of time taken to watch two seasons of the Game of Thrones. Or three, depending on whether you binge watch or not.

Some advisors veer to the other extreme, claiming that the GDS client is simply a browser system that is redirecting the entire card data processing work to the GDS provider, so they are eligible for A. 22 questions. Maybe an episode of Seinfeld. But A is generally for a web browser based site with absolutely zero handling of credit card on their end, not just systematic, but also manual. The only way this works for travel agency is that they outsource an entire call center to handle their MOTO business and do not accept walk-in customers. I don’t think that’s happening. Most feedback I get from livid agencies about PCI-DSS is that they are struggling too much on thin margins. So, no, SAQ A is entirely too liberal.

SAQ C-VT has a seemingly better balance to it, as discussed in our previous articles Part 1 and Part 2.

We even sent out queries to two GDS (their names pending once I get their agreement to publish) and their responses were these

Amadeus: (When Queried if SAQ C-VT is correct to be filled, and if the Amadeus Selling Platform can be eligible for VT): Basically, if the payment is done via Amadeus and entered manually from a personal computer directly into the GDS – you have a right form for Amadeus agents and tick it off with confidence. 

I believe your original question was ‘If Amadeus is considered virtual payment terminal?’

Our answer is Yes.

Sabre: (When asked if their client acts as a VT, defined by PCI as having “Internet-based access to an acquirer, processor or third-party service provider website to authorize payment card transactions.”) Yes, Sabre Red Workspace client requires an internet connection to authenticate and then it requires connections (dedicated or ISP with VPN) to connect to Sabre and no, it does not do batch processing. You may consider SRW is a virtual terminal and guiding your travel agency clients to achieve their goal.

Travelport (Galileo):  (When asked if their client acts as a VT, defined by PCI as having “Internet-based access to an acquirer, processor or third-party service provider website to authorize payment card transactions.”)

Yes. Galileo client does not store credit card information on the client software and client software requires internet connectivity, and cannot do batch transactions.

Based on these ‘guidance’ from GDS which IATA seem to defer to, SAQ C-VT is a likely possibility, as long as all the other eligibility are met. The GDS all claims they are virtual terminals, but that itself (while an important eligibility) isn’t the ONLY eligibility for SAQ C-VT, so you need to ensure the others are met before claiming SAQ C-VT is correct or your business.

Whew. That was a long one. Now back to our FAQs.

FAQ #9 : As a travel professional issuing and selling airline tickets, am I considered a merchant?

This is removed and rightly so. Though the previous response was right: “All the airline transactions processed through a GDS (Global Distribution System) and IATA BSP, the airline itself is considered as the merchant, not the travel agent.”

It only serves to confuse an already confused population further. It’s better they don’t explain this, because some agencies interpret this as IATA saying they are not ‘merchants’ so they need to be ‘service providers’. WHAT! So, yeah, we can explain in another article but this is better left out.

FAQ #22: We already have a PCI DSS Compliant certificate issued by a third party.
Is this enough to cover our BSP or do we need to complete more forms?

Not an addition or whatever, but I still wish that they would change this because the answer doesn’t match the question. The answer is lifted directly out of the PCI-DSS Top 10 Myths addressing the need for a QSA to be involved in the process. The answer is , it is recommended, but NO, for Level 3 and 4 merchants, there is no requirement to get a QSA involved.

Finally, a bonus opinion here.

Many agencies are still faltering in their PCI-DSS compliance. Some equate that just because they are level 3 and 4, they do not need to do ASV scans or penetration testing. Likewise, there are those who *might* theoretically (we don’t know any) qualify for level 1 or level 2 based on their volume, automatically assume they need to do ASV scans and do pentest for everything in scope.

NO.

Your merchant level DOES NOT dictate whether you need to conduct PCI scans or not. We need this to be clear. Because the table published in the FAQ from IATA for FAQ#13 isn’t clear (not their fault, this was lifted from the Mastercard site) – the column “Validated By” states ‘merchant’ and below “Approved Scanning vendor” for level 2 and below. This immediately presupposes that an ASV must be involved. This is incorrect.

Your level (determined by your card transaction volume) determines your VALIDATION TYPE. Validation type there are 3: QSA Certified/Validated; Validated SAQ by QSA/ISA and SELF SIGNED SAQ by MERCHANT OFFICER. That’s it. Your level doesn’t determine how you go through PCI, it determines how it is validated. And it’s not set in stone. Your acquirer can bypass these guidelines and decide that even if you only do ONE transaction a year, you still must go through level 1 compliance (audited by QSA). This is actually quite common!

So what actually determines what on earth you actually do in PCI-DSS?

Well, it’s your business. Or, for Level 2 merchants and below, your type of SAQ. You see, it’s your business that determines your SAQ type, it’s your SAQ that determines what you need to do, and based on what you have done, it will be validated in either of the 3 ways we’ve described above. That’s the harmony of PCI. That’s the zen. The yin and yang. The balance in the Force.

So, for instance, if you are doing SAQ A, SAQ B or SAQ C-VT, please point out to us the fact that you are REQUIRED to do ASV scans on all your internet address (some are told, even their dynamically allocated broadband IP must be scanned by ASV).

None. Magically, SAQ A, SAQ B and SAQ C-VT DOES NOT HAVE ANY requirement for ASV or penetration testing. For us who can provide these services, of course it kind of sucks since now those going through these SAQs don’t need our services anymore. But we rather tell them straight the correct way and sacrifice that part of our business than to let them know wrongly and give consultants a bad name. So what SAQ you are doing will determine whether you need to get something scanned or not.

Now, of course, do not be tempted to fit your business into the easiest SAQ for the sake of it (see the example of travel agencies with GDS doing SAQ A) – there are huge eligibility requirements for these 3 SAQs and not many agencies can meet it. If you practice accepting cards through email, or photos on Whatsapp for your credit card; or store in back office for later processing, or have Enhanced Data Services from Visa/Mastercard or a thousand other ways you can be receiving credit card, you likely need to fit back into the dreaded SAQ D. But what we are saying is that if you ARE eligible for A, B or C-VT, then those will determine whether you need to do any testing or not.

It is our opinion that testing and scans should be done regardless for security sake, not so much for compliance but the choice is yours. You need to make that decision for your own business. Because that’s what heroes do.

If you have further queries on PCI-DSS or just how we are currently helping our clients get through PCI, drop us an email at avantedge@pkfmalaysia.com. We will respond ASAP!

Alienvault: File Integrity Monitoring on Linux Part 2

November 6, 2017 / / 0 Comments

So based on our previous article you have so far set up OSSEC (or HIDS in Alien-speak) in your Linux host which you want to monitor. The next thing to do is to configure FIM to work.

To recap, we have a running CENTOS7 system running in our lab and we finally got our ossec to be communicating with the Alienvault server. You can verify connectivity either through the CLI logs, or using the USM Interface. Now the HIDS can be used for a lot of things – it’s obviously a Host IDS (hence the name), but it’s also a log forwarder as well, so for Linux systems, it doubles up as a security logger, so you don’t need to configure separate plugins to log, for instance SSH denied attempts. If you don’t have the HIDS, you have to forward logs from rsyslog then setup Alienvault plugin for SSH to normalise SSH logs and create those events. HIDS does this for you. Try it. You can attempt multiple logins with wrong password and you should see an event called “SSHD Authentication Failed.”

But for this article, we will be focusing on File Integrity Monitoring or FIM for short. FIM in Alienvault USM is utilising OSSEC inbuilt integrity checking process called Syscheck. Syscheck runs periodically and depending on how many files/directories it is checking can run from 10 minutes to much longer. By default, syscheck in Alienvault executes very 20 hours – if that’s too long for you , you can shorten it in the configuration.

Let’s jump straight in.

In Alienvault (Server if you are using Standard), go Environment -> Detection and on HIDS tab, click on Agent. In the lower tabs, click on SYSCHECKS.

Over here is where you configure the Syschecks on the Agents and you can modify the frequency.

Because we are using Linux, we are going to ignore the portion where Windows Registry is being configured and go straight to: ”

FILES/DIRECTORIES MONITORED

Under files/Directories, put in a sample directory you need to monitor, for instance

/etc/pkf

Don’t worry, out of the box, standard directories being monitored are

/etc

/usr/bin

/usr/sbin

/bin

/sbin

We have in some cases clients insisting on us putting in /var/log in there to inform them of changes occurring in this directory. According to them, log files are key and they need to know if these log files are being changed.

Um, yes. Agree on the first part. But /var/log changes almost every nanosecond. Syscheck is not going to be of much use here. They are probably thinking about log archives as opposed to the current log folder. Anyway, we digress.

So go ahead and put in your own directory in there under agents and then restart HIDS from Alienvault, and also for good measure restart the agent as well (you can go Agent Control -> Click on the clock symbol under the Agent Name to restart). To check, you can click on Agent.Conf tab and you will find something similar to:

<agent_config>
    <syscheck>
      <frequency>1200</frequency>
      <auto_ignore>no</auto_ignore>
      <alert_new_files>yes</alert_new_files>
      <scan_on_start>yes</scan_on_start>
<directories realtime="yes" report_changes="yes" check_all="yes">/etc/pkf</directories>
    </syscheck>
  </agent_config>

So it looks all set up. If you have restarted HIDS and also the agent, you should be able to verify on the agent itself if the configuration has been uploaded. On the client, go to

/var/ossec/etc/shared

Look into agent.conf file and you should be able to see the same thing as the configuration above. Also, you can go to

/var/ossec/logs

and look into ossec.log file and you should be able to see something like

ossec-syscheckd: INFO: Monitoring directory: '/etc/pkf'.
ossec-syscheckd: INFO: Directory set for real time monitoring: '/etc/pkf'.

So there you have it. You can do some testing now.

So we will go into the local directory of our CENTOS and go ahead to create a few random files. The first thing you notice is that even if in our config there was:

<alert_new_files>yes</alert_new_files>

We still do not get any alerts once we create new files in the directory. This is because OSSEC doesn’t check new files in realtime (just changes to files), and we will need to wait for our syscheck to run, or you can go ahead and restart the agent from the Alienvault GUI. For good measure, change a few things about the files as well.

You might notice a strange thing happening here.

Going into the SIEM, you might not find any events relating to integrity issues in your host. This doesn’t seem to be an isolated incident, if you head over to the Alienvault forum, you will see many people having the same issue: We have enabled FIM and we can’t find anything on the SIEM or any events!

If you check on the agent itself, and you click on the “modified files”

You will see a raw list of all the files modified and you will see that /etc/pkf/filename is there listed as well, so it means OSSEC is working and syscheck is working. Another way to verify is to head over to your Alienvault Server and go to

/var/ossec/logs/alerts 

grep pkf alerts.log

Basically I am doing a grep on anything that identifies the files or directories I am looking at to see if alerts are generated. You should change the grep to something related to your filename/directory name. You should be able to see that alerts are generated.

So what gives?

Plugins.

Apparently for some strange reason, some Alienvault setup by default does not have the proper plugins enabled to read the integrity alerts log of ossec. This is very strange, as FIM is touted as a feature for Alienvault, but we need to still work further to get it up and running. So go ahead to your Alienvault GUI:

Configuration -> Deployment

Click on System Detail of your Alienvault setup

Click on Sensor Configuration in the menu on the right side

Go to “Collection”

You notice you have Alienvault_HIDS and Alienvault_NIDS enabled. However, in some cases, Alienvault_HIDS-IDM plugin might be missing and can’t be found under “Plugins Available” column. IDM Is for identity management and it needs to be enabled for FIM to properly work.

The plugin that makes this happen is

ossec-idm-single-line.cfg

In our case, the plugin file was there in /etc/ossim/agent/plugins, but it wasn’t in the ossim database as a “Plugins Available” option. This generally means that it wasn’t (for some reason) written into the ossim-db. So head over to the directory in Alienvault:

/usr/share/doc/ossim-mysql/contrib/plugins

You will see that there is an ossec.sql.gz in there, so go ahead and unzip it and run

cat ossec.sql | ossim-db

alienvault-reconfig

Wait for the reconfig to occur then head back to the GUI of Alienvault, all the way back to the sensor configuration->collection and you will be able to see Alienvault_HIDS-IDM available for selection.

Go ahead and select it there, and then reconfig and now you can try to run the FIM test again.

a) Create a new file

b) Restart the agent (to simulate the syscheck being run)

c) Check SIEM , filter Data Sources to Alienvault HIDS, you should find

AlienVault HIDS: File added to the system.

d) Go to the host and edit the new file and change it

e) Go back and check SIEM and you will find

AlienVault HIDS: Integrity checksum changed.

The last event should be immediate and need not have any restart of the agent. Unless of course, we noticed if the change occurred during the time syscheck is running, if so the event will occur once syscheck finishes. It’s not perfect, but it will have to do.

Congratulations, you have FIM events up and running for Alienvault! If you need further assistance in any Alienvault matters, drop us an email at alienvault@pkfmalaysia.com and we will look into it.

 

Alienvault: File Integrity Monitoring on Linux Part 1

October 31, 2017 / / 0 Comments

If you have been deploying or troubleshooting Alienvault long enough, you would know a few things: Alienvault is one of the most flexible SIEMs in the market. It has the most varied security features, and covers almost the entire spectrum of our PCI-DSS needs – from IDS, to SIEM, to File Integrity Monitoring, to vulnerability scaring to a partridge in a pear tree.

One of the products working under the Alienvault hood is OSSEC, which is a opensorce host based IDS. Sometimes, its interchangeable to HIDS, which is Host IDS, but really, the latter is simply the type; while the former is the actual name itself. For the sake of this article, we will interchange both terms.

OSSEC runs well with Windows, where Alienvault can do an auto deployment given the correct setup and credentials. However, it’s on Linux boxes that sometimes we get a bit concerned. Not because the product doesn’t work, but simply because the setting up of the installation. There is no auto deployment, so we need to set it up manually, and this might mean downloading the correct packages in the first place.

After this, we are going to look at a specific function of HIDS – File Integrity Monitoring or FIM for short.

Firstly, let’s get started. We have set up a simple CentOS 7 box in our lab in the same network as Alienvault, and we are going to install HIDS on this box as an AGENT. This will then talk to the Alienvault USM which is the server.

So let’s assume you have your agent system network setup (please ensure your DNS is set properly, you should be able to work this out in CentOS 7 either through the network tools or editing resolv.conf).

 yum groupinstall "Development Tools" -y

The CentOS development tools are very useful tools which is a bundle, used primarily for building and compiling software from source code. “Yum” here while making you think of going for a teh tarik is a command found in almost all red-hat based distros to run installations. It’s used for update, installations etc. In the old days before YUM, we would use RPM (which is really what YUM is using), but we would have to manually track down dependencies and it really sucks because to install an RPM package might mean to install a whole bunch of stupid libraries or updating stuff and you are basically running around the internet looking for RPMs like Where’s Wally. It looks awful now, but back in the days, RPM was heavensent. We didn’t need to do “tar”, configure, make, “make install” anymore!

Anyway, the -y argument behind simply automates the command by answering yes to the prompts. So once you run that, fingers crossed, everything runs ok and you get

Complete!

Which means everything is ok.

The next is to get the kernel-devel package.

yum install kernel-devel -y

This is a package that allows us to install a kernel driver later. It’s not the full kernel source, so it shouldn’t take too long before you see the “complete!”.

At this point you are ready to install OSSEC. If there are any issues, then troubleshooting is obviously required.

First, we need to locate the version of HIDS that can work with Alienvault. You might think heading to the latest HIDS in https://ossec.github.io/downloads.html might be the answer, but for Alienvault, we would recommend to get the 2.8.3 version. You can find it here:

https://bintray.com/ossec/ossec-hids/download_file?file_path=ossec-hids-2.8.3.tar.gz

So, go to a installation directory (optional) like /usr/src and run

curl -OL https://bintray.com/ossec/ossec-hids/download_file?file_path=ossec-hids-2.8.3.tar.gz

We used curl here because for some reason wget wasn’t installed. the -OL is supposed to handle the redirected links for that particular site and supposedly to rename it to a proper remote file name. It doesn’t do the rename though (don’t know?) and we wind up with a file called “download_file?file_path=ossec-hids-2.8.3.tar.gz”. Just rename it if you are into aesthetics to ossec-hids-2.8.3.tar.gz.

So now lets do an extraction

tar –xzvf ossec-hids-2.8.3.tar.gz

We now have a folder called ossec-hids-2.8.3. Go into this folder and then run

./install.sh

Once you run, you will be given a series of questions. Default should be fine for most, and you should just select ‘agent’ and also key in the server (Alienvault) IP address. Now if you are running a separate Alienvault setup (non-AIO), then this IP address is actually the address of your SENSOR. Not Alienvault Server. So don’t get mixed up. The Sensor is the Server. Hm.

So everything ready, fingers crossed, just go ahead and install. There will be a lot of text filling your screen but the important thing is that there is no ERROR or WARNING (well warning ain’t bad), but at the end you should have a welcome note stating

 Thanks for using the OSSEC HIDS.
 If you have any question, suggestion or if you find any bug, contact us 
at contact@ossec.net or using our public maillist at ossec-list@ossec.net 
(http://www.ossec.net/main/support/ ).

Press enter and you should be out of the installation. Congratulations!

You are not done yet. You still need to get Alienvault to talk to your box. The steps are as follows:

a) Generate an Agent Key from Alienvault

Go to your Alienvault AIO or your Server (since a standard sensor has no GUI, remember?).

Environment->Detection->Agents

Click “Add Agent”

Select the host from the list (It should be there automatically, but if it’s not just add it there through the asset list).

So now the agent has been created but you should see it as “Disconnected” from the list. Click the little Key sign that says “Extract Key”.

You should see something like

Agent key information for '2' is:

MiBIb3N0LTE5Mi0xNjgtMC01MCAxOTIuMTY4LjAuNTAgMDBmYzI0MzUyNzg4N.....etc
The garbled message is the key. So go ahead and highlight and copy it.

b) Import the key into the agent system

Go back to your agent system and head over to /var/ossec/bin and run

./manage-agents

Type in ‘I’ to import

Paste the whole key into the screen and confirm adding it.

Quit and then restart by going

/var/ossec/bin

And

./ossec-control restart

c) Restarting HIDS on the server

On the server head over to

Environment->Detection->HIDS Control

On the right side, click “Restart” the HIDS and you should be fine.

d) Check the Agent Logs

Head back to the agent system and check the logs

cd /var/ossec/logs
more ossec.log

You should (hopefully!) see

INFO: Connected to the server (192.168.0.xxx:1514).

where xxx is your server IP address.

Back in the USM server you will be able to see that now the agent is “Active”.

In the next article we will see if we can get the FIM to work.

PDPA and the Tale of the Telemarketer

October 29, 2017 / / 0 Comments

We were working very late on Saturday to roll out a PCI manual for some of our merchant clients, so I only slept at around 4.30 am. I am usually up on Sunday around 9.30 am at the latest due to my kids utilising my body as a trampoline which I can probably ignore for about 15 minutes before being entirely awoken, but 5 hours of sleep is pretty good so I will take that regardless.

At around 9 am unfortunately, my phone rang and I saw a number I didn’t recognise. Thinking this could be an emergency, I picked up the call and on the other line, this unrecognised voice chirpily said, “Hi, I am calling from <name of telco> and I would like to do a marketing survey with you!”

“Do you know it’s a Sunday?”

“Yes, it is a Sunday, I know!”

“Don’t you realise that you shouldn’t be telemarketing me on a Sunday morning?”

“We believe that you would be too busy on a weekday, sir, that’s why I am calling you on a Sunday!”

“Well, I am too busy now on a Sunday. Goodbye.”

And I hung up.

Now, I was fuming, because I just felt it was completely distasteful and disrespectful for them to be calling me up on a Sunday morning because they think I would reject them on a weekday. They think they will get me on a better mood on a Sunday morning?!

For the record, I don’t usually do this, as in, be rude or just hang up even on telemarketers. I am always reminded, that telemarketers are people. The person on the other line has a family too, and she probably wish that she was with them on a Sunday morning, taking her kids out for breakfast or hanging out with her friends or something. I mean, I doubt she is jumping up and down with excitement at the prospect of going into the office and dialing up people on Sunday so she could make her survey quota. I never experienced being a telemarketer, but in our first year, I did experience the emptiness of having zero clients and doing cold calling if anyone wanted my audit services. So, yes, I do commiserate with them. On normal calls I am usually civil to them. I usually politely tell them that they have already called me many times (Astro calls me like every week asking me to upgrade), and even thank them before hanging up, before I put their number in my ignore list. Some, I admit, when they do call, and I am in a the middle of something, I tell them that I am currently busy and then I put their number on my ignore list. It’s hard for me to ignore phone calls on any number because there could be a potential sales opportunity and not a telemarketer. But if it is a telemarketer, I don’t shut them down rudely. At least not in my memory.

But Sunday morning is a different thing. I did kind of feel bad, and was contemplating to call her back again to take that survey, but then Sunday life started (me being a trampoline) and I lost track of it.

But how does our Personal Data Protection Act fit into all of this?

Contrary to many people’s beliefs, PDPA actually allows telemarketers to call you. There is nothing in the act that says telemarketers cannot call you. The problem isn’t so much of telemarketers calling. Them calling you is already way downstream of the actual issue. The actual issue is your information being shared, leaked, sold, brokered by service companies to information brokers. Sometimes it’s our fault. We sign up for things and we don’t read the fine print. When we get a direct marketing call we get all up in a tizzy and blame the entire planet for conspiring to wake us up on a Sunday morning. But hey, we agreed to it. Yes, in that terms of services we did not read. In that privacy statement we implicitly agreed to when we gave our information to get a chance to win that free trip to Tokyo.

Privacy statements from banks, telcos, service providers all have to include the section of ‘disclosure’. Google your favourite bank or telco and put in ‘privacy statement’ and click to get their privacy statement. In most cases you will find them defining who they intend to share your personal information with, and in most cases, some broad sweeping statement such as :

Our agents and service providers with whom we have contractual agreements for some of our functions, services and activities; and/or

 

Financial service providers in relation to the products and services that you have with us (e.g. mortgage brokers, insurance companies); and/or

 

Strategic partners with whom we have a relationship with for specific products and services if consented to, by you; and/or

Now, let’s break that down. The first one is very broad. “Agents” and “Service Providers” where they have contractual agreements  – this basically means the entire ecosystem of companies providing services to this bank! The second at least defines it, but generally these are a subset of the first. Finally the ‘strategic partners’ part isn’t so much of an issue but the ‘if consented to, by you’ sounds very good and positive, only for you to realise that the implied consent is usually obtained by you agreeing to the privacy statement in the first place! You see, there is no need for explicit consent if this is not considered ‘sensitive data’, so don’t expect your signature to mean consent. By you taking up their service and agreeing to pass your data – that’s a consent enough for them to share your information. Boom.

So, technically the moment we sign up for a service, we agree that we would allow telemarketers to call us – whether in the middle of the night or on a Sunday morning is irregardless – the fact is that we gave that permission, mostly without knowing it and all just because of that carrot they usually hang in front of us. Dang, I lost that Tokyo competition! Hey, here’s another one – “provide phone number to win a Mazda 3”. OK, here’s my number! Yaay! Let me be lucky!

You get the drift.

Now, back to telemarketers calling us. They have the right. They have a bunch of phone numbers given to them by the bank, and God knows what other information so they can sell us specific services: and so they make the call.

PDPA regulates telemarketing through Section 43 of the Act: Right to prevent processing for purposes of direct marketing. 

So the proper channel to stop this: Technically you are supposed to provide in ‘writing’ to the data user (company calling you), requesting you not to be contacted anymore for telemarketing. This can be a courtesy respond during the call itself, whereby you state to them, please remove your number from their list and not call anymore (it’s not in writing, but you can try this first). If they persist in calling, write to them (their email is found in their company’s privacy notice of who to contact if you have a complaint), and if you still get called up, you can formally complain to PDPA commissioner at aduan@pdp.gov.my and follow that up with a call to 03-89115000 (please check their website to see if this has changed).

So, there you go. Malaysia was supposed to implement a Do-Not-Call (DNC) registry to block these telemarketer phone numbers back in 2014, but it has seemingly died down and implementation is still not done. We are monitoring to see if this is being looked into again, but for now, it looks like we need to fend on our own here.

Remember though – the person calling you may not wish to be calling you at all, and they might just be a phone call away from losing their jobs. While I am not advocating you to entertain them just for the sake of being nice, but on the flip side, there is no reason for some of the foul-mouthed tirade I have seen some people venting on these callers, as if they want to personally reach into their mobile phone and strangle the guy on the other line. Cool down. Ask to be removed, and block the number and move on, knowing you can rely on PDPA if your notice of removal is constantly ignored.

If anyone needs to know more on PDPA, drop us a note at avantedge@pkfmalaysia.com. We have been working with many companies to sort their PDPA concerns out and also implementing controls to address the 7 requirements.

 

IATA PCI-DSS: Why your SAQs Matter

October 25, 2017 / / 0 Comments

We have had a few discussions among consultants as we progress further into this compliance for our Travel Agency clients. And very often (if not always), the matter always comes down to, “Can we just do an ASV scan and you certify us?”

We have touched this topic many times. ASV scans cannot certify you as PCI compliant. They are just one of the requirements. In fact for some of the SAQs (self Assessment questionnaire), ASV is not even needed.

SAQ A

We’ve gone through the famous SAQ A in our last post. This is basically where no card data is being entered in merchant environment and they basically forward everything over to the payment provider. There is no requirement for ASV. That doesn’t mean it makes it right though. Imagine this scenario: the developer makes a hopeless job at coding their web application. There are two ways SAQ A can be done: redirect or iframe. Let’s recap.

A redirect occurs when the merchant website sends a redirect instruction to the client browser when payment needs to be made. This instructs the client to connect directly to the payment gateway. This instruction could be a simple

onclick="location.href='https://payme.com';"

Or similarly through some javascript with window.location.

The iframe is similar, whereby a ‘child’ window is called directly from the payment gateway and has a window in the main merchant site. Although everytime this occurs, I have nightmares of those old websites with scrolling words, flashing lights and like 5 – 10 frames running at once. Netscape days.

iFrames are simple as well, with the site you want to call embedded within the <iframe src> tags.

So, anyway, back to ASV scans on these merchant sites. Although its not required, if the web application itself is poorly constructed and is compromised, there could be a high possibility that the redirect process itself gets hacked and redirected to another site that looks like the real payment site. You can imagine what happens next. The solution here is to ensure even on the merchant site, this site is developed with good secure coding practices. If ASV is not required, it does not mean you don’t need to run any scans. We would recommend vulnerability scans to still run against it, whether ASV or not. In fact, any web facing system out there should be tested – because if you are out there, it’s open season – anyone can attack it, and it’s up to you to secure it.

Conclusion: No need for ASV, but recommended – if not ASV, at least some security scans.

SAQ B 

Ah, the good old SAQ B. A lot of people misunderstand this for a good reason. Some of our retail clients, or F&B clients insists this is the correct one as they are using card terminals. However, they forget that most of them have their integrated POS systems – specifically because they need to charge an amount like food etc. So their POS systems sends these details to their EDC (Electronic data capture) terminals and the EDC accepts the DIP cards. What happens is that, these EDCs sends back the transaction data and in many cases, they still swipe our cards on the payment system. SAQ B doesn’t qualify here. SAQ B is specific for dialup EDCs directly to acquirer bank. For those using 3g/4g, then these can be considered as well. If you are using WIFI, or internal broadband link then you are out of luck. No SAQ.

Because of the direct point to point or cellular connectivity, ASV is not required (for a good reason!)

Conclusion: No Need ASV – IF you actually qualify for the SAQ that is.

SAQ C-VT

Another difficult SAQ to be eligible for. It has very specific requirements – whereby a web-based browser connectivity to a virtual payment provider who is PCI compliant. I think it really applies more to hospitality or travel agencies. In this case, the question is often asked – what about my broadband IP accessing the net? Because for sure, when I connect to my virtual terminal provider, I am using the internet right, and not leased line or any point to point? So for sure, my broadband has an IP. Just type “whats my ip” in google and it will show. Most of them have dynamic IP addresses as well. In SAQ C-VT there is no requirement to ASV scan.

However, having a dynamic IP and no ASV scan in SAQ C-VT doesn’t mean you still can’t do it. Many routers/firewalls are poorly implemented or poorly patched. We would recommend to do an internal scan on the firewall interface to ensure vulnerabilities are identified. Again, it’s a matter of securing the internet exposed system.

Conclsuion: No Need ASV, but we recommend an internal security scan on the firewall to ensure the box is properly hardened.

So, there you have it. It’s critical to know your SAQs so you know the extent of what NEEDS to be done and what is BETTER to be done than not.

If you need assistance with your PCI-DSS, drop us an email at pcidss@pkfmalaysia.com

« Older posts Newer posts »

© 2025 PKF AvantEdge

— Up ↑