PKF AvantEdge

Page 19 of 40

IATA and PCI-DSS to Travel Agents: Data Channels

April 30, 2017 / / 0 Comments

PCI

IATA has for a few years been championing the need for PCI-DSS to the travel agencies that are registered under them. More recently, they have been pushing compliance for PCI and even made a deadline at June 2017 for all agencies to be PCI compliant. Unsurprisingly like many well intentioned deadlines, it is now pushed further back to March 2018. Our prediction is that by November or December this year, we might see yet another delay in the deadline. But that doesn’t mean there’s any let up in compliance. Therefore, we’ve been reaching out to many of the agencies who were our clients previously and letting them know if they need help on their SAQ, they know where to find it. Us!

Now, just to summarise, being registered with IATA means a big deal to an agency. It simply means you can issue tickets. So how it works is that IATA is like a national ‘switch’. Whereby registered members can receive calls from clients, and based on pricing etc, select the airline and pricing and issue these tickets – either to other clients or in behalf of even other agencies. Firstly, there is credit card involved, of course. Secondly, IATA members can tap into the BSP – the IATA Billing and Settlement Plan. This is like a huge payment switch – whereby it handles all the payments to multiple airlines from the agencies, so that agencies don’t have to deal individually with airlines for settlement of the tickets. Which is good. Secondly – there is the GDS (the global distribution system). There are a few players in the market – Sabre is one of the biggest (used by Malaysian Airlines), others are like Amadeus, Patheo etc. We’ve so far encountered Sabre and Amadeus in our clients and both of these are PCI certified providers.

So, with this basic understanding of how agencies work, how does PCI apply?

First of all, unless IATA makes a statement otherwise, agencies DO NOT NEED a QSA to do a level 1 certification or sign off on SAQ, unless explicitly requested do. Since IATA is the processor for the agencies in this case, it’s their call. But it’s a big call, because level 4 merchants aren’t very large and they might not be able to get QSAs to help sign off their documents. We are working with one of the largest merchants at the moment and even they are not requested by their acquirer to get a sign off on SAQ from a QSA.

99.99% of agencies out there will fall under the Level 3 or Level 4 merchant band and we all know what that entails – SAQ, signed off by their executive – only if required should they get a QSA to participate. But it helps to have someone that knows about PCI or else you would be groping in the dark with the SAQ options.

What we see a lot are merchants automatically selecting SAQ D-MER when it comes to PCI. Again you don’t have to.  Depending on the number of channels you have you might be able to select C-VT, or B, or even A-EP, A. We call these specialised SAQs – remember, if you don’t meet any of these criteria, you drop into the SAQ D bucket.

What many people don’t know is that you can opt for a separate SAQ for each channel, instead of having one SAQ D to cover all. Both are possible, but its just that for SAQ D, you would be marking a fair bit N/A if you are say just doing POS and e-commerce.

Before we venture into the dark arts of SAQ selection, let’s explore probable channels that agencies have.

a) Through the website – this is not that common actually. Now with Expedia, Agoda and all these portals coming up, it’s easier for consumers to get the best price regardless. But for corporate trips etc, some of these websites might still prove useful. Most of these websites will either redirect to another payment gateway or might even link to a GDS. Either way, they generally do not host the site where credit card information is being entered. So in this case, SAQ A might work. If they have card information collected in their environment before sending it over to the payment gateway, then SAQ A-EP. Questions for A = 22, A-EP = 191. So please think it over as to why you want to collect card information on your site.

b) MOTO – or Mail Order Telephone Order. In most cases, there would be a call into the agency requesting booking. Now it’s important then how card data is now transmitted, processed and stored. The agent likely will not have any funky call system like Ameyo or Genesys, and may just rely on our good old PSTN phone line. Once call is received, the agent will request details , including card details and type it directly into a GDS system. In this case, as there is no recording on the line, it’s fine, and as long as the agent is using a hardened desktop/laptop with a virtual terminal into the GDS, you can rely on SAQ C-VT to cover this. Now, what is a virtual terminal? Basically, it’s a virtual POS. You just don’t need to buy the POS devices. All GDS offers this solution, whereby you log into the virtual terminal and just input the card information.

The tricky part here is that not all information is received on phone. Sometimes, clients will say, OK, let me send you a batch of credit card info in a text file via email. Or, hold on, I am shooting you an image via WhatsApp or Skype. Or, wait, let me fax you the form. Oops.

Now what happens is that other channels are being utilised. You have storage of credit card information. You are no longer eligible for C-VT. C-VT = 81 questions. D-Mer = 332 questions. So, if you can stop these practices, I would suggest, go ahead and stop it.

c) Walk-In – most agencies have outlet(s) and you can walk in, and pay off the counter. They will either key in the information as if you had called, into the virtual terminal – OR, they might have an actual POS machine for you so you can dip your card and make a card present transaction. In this case, it depends on how the POS machine is setup. It would be pretty similar then to a normal retailer transaction – like a grocery store or departmental store. We’ve already written this at length here: http://www.pkfavantedge.com/it-audit/the-saq-bs-and-how-they-apply-to-you/.

So there you have it. Remember the following

SAQ A = 22 questions (good!)

SAQ A-EP = 191 questions (not great!)

SAQ B = 41 questions (good!)

SAQ B-IP = 82 questions (not so great!)

SAQ C = 160 (not very good!)

SAQ C-VT = 81 (that’s ok!)

SAQ D- MER(SP) = 332 or 359 questions (bye bye weekends!)

So there you have it. If you are an agency or a retailer and you need any help at all to clarify this PCI-DSS requirement, drop us an email at pcidss@pkfmalaysia.com. We will attend to you immediately!

 

 

Deploy HIDS agent in a Checkpoint Environment

April 6, 2017 / / 0 Comments

avlogo

In our years of deploying and implementing SIEM, if we get 10 ringgit everytime a customer says: “Nothing wrong on our side, your SIEM is the problem” and then after hours of troubleshooting, the customer responds: “Ooops sorry, seems like our problem, we blocked your traffic” – we would all be as rich as Jack Ma by now.

The issue here is not so much that SIEMs are notoriously difficult to deploy – they are not, but its more that other devices need to talk to it. Deploying SIEM is easy, the finetuning is the problem. Because products need to get logs to the SIEM – either through the good old Syslog via UDP/TCP 514 or through agents installed on the systems, or through third party applications like Snare and NXLog – both for the naughty Windows machine where no syslog facility is found for some strange, Bill Gatesy reason.

It’s also because most Administrators guard their systems like pitbulls and any request for them to send logs over is generally greeted by a dumbfounded “Why are you so stupid” look, or “Over my dead body” look, or simply you get ignored completely. Oh, and also the “I want to go home at 5 pm today, so don’t mess with my jam” look. Whatever. The war between Administrators and Implementers has been going on longer than the blood feud between Lycans and Vampires.

We have been through deployments where countless of hours were spent just trying to convince our customer: “We are NOT getting anything on the interface. No packets. It’s being blocked.” And customer: “No, there are no firewalls between.” Five hours later, customer: “Oh yeah, there is a small firewall between and it’s blocking. Cheers”. On our SIEM, it’s easy. If our interface doesn’t see it, it ain’t there. That’s it. Do a tcpdump and grep the IP or port and boom, we know it’s not our problem.

The issue here is that “Not our problem” generally gets translated to “It’s now your problem” and we end up troubleshooting for our clients how to fix THEIR systems and devices. I’ve called my pals at Fortigate, Bluecoat, Cisco, Juniper etc so many times, asking them about issues that my client should be doing it themselves.

So anyway – we had this issue whereby we deployed a fair bit of HIDS (Host IDS, aka OSSEC) agents in a fairly large environment. It basically traverses through a firewall (Checkpoint). That Checkpoint firewall dropped UDP 1514 connection between agent and our AlienVault server. Port 1514 is the port that our HIDS uses to communicate between agent and server.

Firstly, establish whether we are getting those traffic or not in the interface. If we are not, then the problem could be on their end. When we do a tcpdump for udp 1514 on that specific host, we are able to observe some traffic from the server and vice versa. In our case even with that, the connection cannot be established. Bascially, our agent is able to reach the server but the server tries to respond but the traffic disappears. Therefore, the agent is orphaned.

For this case, after troubleshoot and checking, we found out that Checkpoint is dropping the UDP 1514 traffic responses from the alienvault server. So the communication between the HIDS agent and the server is never established. The log shows that UDP traffic is dropped with the following message:

Message_Info: Violated unidirectional connection

Great. UDP traffic is a stateless protocol. According to Checkpoint, by default, a reply to a UDP packet is not allowed. The Security Gateway can mark a connection in the Connections Table to allow traffic to pass only in one direction (hence the term ‘unidirectional’). If a UDP connection uses a bi-directional communication method, this would create a violation.

Therefore, the workaround to this is to allow Checkpoint to respond to this bi-directional communication. It’s pretty straightforward for Checkpoint actually.

You will need to add or edit a service object in Checkpoint. Again, we are Alienvault implementers but we end up mucking through Checkpoint firewalls just to get our job done!

So on a checkpoint edge box, it’s basically

Main Menu->Network->Network Services tab

You can now edit or add.

Go ahead and add a new UDP service, fill in the requirements, and then you will have an option for advanced, click OK.

In the Advanced UDP service property, ensure “Accept Replies” is clicked.

Now go ahead and use this service under the new or existing policy rule that has been set up for Agent->Server communication for HIDS.

Ta-da, done!

If you have any questions on Alienvault USM deployment, drop us a note at alienvault@pkfmalaysia.com.

The SAQ Bs and how they apply to you

March 31, 2017 / / 0 Comments

pci-compliance

We always say SAQ As and Ds get all the glory and attention.

This is because a majority of our SAQ clients are e-commerce companies and therefore they apply SAQ A or A-EP depending on where their credit card information is collected.

However, recent times, we have been working on a well-known retailer and were told that SAQ D would be the one that applies to us. Now the SAQ was passed to them by the bank and the bank insisted that they do SAQ D-Mer.

Now this post is going to assume that you have some working knowledge on what SAQ’s are in PCI-DSS world. Self Assessment Questionnaires are one of the most misunderstood concepts in PCI. They are like Donald Trump’s foreign policy and the plot of Interstellar all mashed into one misunderstood mess. Often because acquirers find it so hard to understand, they just tell all their merchants that they should go for SAQ D.

Now we have fought for our clients before – where we overturned the acquirer insistence for one of our e-commerce clients to do an SAQ D-Mer, and instead got them to agree that an SAQ A-EP is sufficient. SAQ A-EP = around 140 questions. SAQ D-Mer = around 320 questions. Big difference.

Why is this important? We firmly believed in the concept of overdoing PCI is not a good thing. Why? Because our clients have other things to do and limited time and money to do these. Ideally, sure, everyone should go on Level 1 Certification. But the reason why the PCI Council created a whole bunch of ‘levels’ and then types of SAQs is simply because different businesses face different risks. It doesn’t make sense for a neighbourhood grocery that accepts 10 cards a month to implement the same million dollar controls as, say, Tesco or Exxon Mobil. So. Don’t overdo things, but don’t under-do it as well.

Back to SAQ Bs. So with this client, after talking to them a few rounds we found out that:

a) Their credit card terminals are separate and not integrated with their POS machines and connected via USB.

b) The POS machines are all connected back to the branch switch (let’s call it branch switch) and from there connects back to corporate HQ for reconciliation purposes

c) However – we found out that the Credit Card terminals have their own connectivity to their own ethernet switch (lets call it Credit Card switch) that connects to an ISDN router and directly to the bank.

This means, there are two flows – once the credit card is used on the Credit Card terminal, the card information is sent out directly via ISDN to the bank. Whatever approval etc that comes back, it will go through the USB to update the POS.

The crunch here is that NO CREDIT CARD information is ever sent back to the client’s environment. Everything is out through the bank environment – as the Credit Card Switch all belongs to the bank. It’s only located on the customer premise but the customer has no access to it – physical or logical.

So begin our argument with the acquirer, to overturn their SAQ D to SAQ B or B-IP. Let’s look at SAQ B criteria as per PCI document:

a) Your company uses only an imprint machine and/or uses only standalone, dial-out terminals (connected via a phone line to your processor) to take your customers’ payment card information;

Seems like it. Technically, the question here is whether a credit card terminal connected to a POS machine with USB is considered ‘standalone’. Our argument here is yes, as long as no credit card info flows through that USB connection and only approval/decline/transaction dollar amounts etc. Remember the USB connection connects the terminal to to the POS machine (a Windows box). Credit card info flows out the other way, directly to the bank via a circuit switched technology like ISDN (i.e dial out). For the millenials, ISDN used to be the granddaddy of broadband. If you have ever gone through internet connectivity era with normal dial up 14.4kbps, ISDN is like what God would send to us out of mercy and grace.

b) The standalone, dial-out terminals are not connected to any other systems within your environment;

Again, the argument here is ‘connected’. What does this mean? Is it through IP means, or even an RS232 connectivity is considered connected? Our reasoning is that this is USB connection and no card data flows through this ‘connection’ and we will use this reasoning once we get on the table with the acquirer.

c) The standalone, dial-out terminals are not connected to the Internet;

No they aren’t. They are on ISDN direct to the acquirer.

d) Your company does not transmit cardholder data over a network (either an internal network or the Internet);

No they don’t. In fact, no credit card info is stored, processed or transmitted anywhere in the customer environment. Except for the physical protection over the bank equipments residing on customer premise.

e) Any cardholder data your company retains is on paper (for example, printed reports or receipts), and these documents are not received electronically; and

They do have some credit card info on paper which they need to protect, but these are manual forms they need to fill out for refund process. And the process is dictated by the bank.

f) Your company does not store cardholder data in electronic format.

No, of course not.

So you see, except for the tiny word ‘connected’ in question b), our client does meet all the SAQ B criteria. It’s really ridiculous to have someone go through the entire SAQ D when they do not have card holder data in the environment they control. And what if they have 80 branches, each with 10 POS terminals and servers? That would mean 800 systems in all branches come into scope for pentest, internal scans etc? No wonder I hear some retailers using PCI as a cuss word these days.

So, we don’t know how this is sorted out yet, but we will soon, and perhaps that will constitute another post. For now, if you need any help with your PCI-DSS – SAQ or Level 1 certification, drop us an email at pcidss@pkfmalaysia.com.

Cheers for now!

PCI and Multi Processing Environments

March 31, 2017 / / 0 Comments

PCI

Since our last post, we have received some queries from other companies asking us about their PCI compliance. Just to be clear, we do not charge a fee for replying to your email and assisting you make sense of this compliance. We know how frustrating it is, and no, anyone that tells you that PCI is easy as 1-2-3 isn’t really letting you know the full picture. This is because some emails had been – “I have this question, but wait, if you are going to respond and charge me a fee, then don’t bother.” What are we, mercenaries? Yes we are a company requiring profits and not an NGO, but over the 7 years we have been involved in PCI, we have actually done a fair bit of advisory without charge, just to get PCI awareness out there into the market.

So, to save the trouble, I’ll put up a public post here to sort some of the questions out. This question, we have been getting a fair bit: What if the company has a multiple processing environment? What does this mean?

Let’s say, a retailer. It has a POS environment whereby they run standalone terminals connecting to the bank for purchases in their store. Credit card is used here – card present transactions. Then they launch their e-commerce site, which redirects all card non-present transactions to a PCI certified payment gateway, where the card collection page is hosted by the gateway.

You see here – there are two different channels for credit card interaction. The traditional POS, and the e-commerce site. Both are completely outsourced – one is direct dial up to the bank, the other to the payment gateway. So how do you deal with this?

You have two options – one is to do separate SAQs for both environments. Yes, you can. In the example above, doing an SAQ B for your POS environment and an SAQ A for your ecommerce environment (assuming you are level 3 or 4 merchant) should be able to suffice. The second option is to combine these channels into one SAQ. Once you do that however, you won’t be able to go through the ‘specialised’ SAQs. Specialised SAQs are like A, A-EP, B, B-IP, C, C-VT – meaning they have conditions in which you need to adhere to in order to use them. For instance for A, it says that this will only apply to merchants with card non-present business. And likewise for B, it has condition that you do not store card information electronically and is not applicable to e-commerce merchants. So when you don’t fall into any of these SAQ buckets, you end up with SAQ D-MER, which basically covers everything in PCI. But don’t worry, you a lot of the SAQ would be non-applicable in this case, and only those related to outsourced e-commerce and POS facilities would apply.

Now another related question, and one that I ended up having a 2 hour discussion with a client on = can an entity be both merchant and service provider?

The short answer is yes, you can.

An example would be a telco. Telcos generally have massive merchant business. They accept payments for their pre-paid, post-paid etc from end customers through e-commerce, POS channels etc. But the Telco could also support a manage services and hosting environment whereby other merchants are hosting their payment sites on. Then, now you have a service provider environment.

Or, it could even be within the same organisation, you have your merchant business of a payment portal, Mobile POS, or mobile app, connecting to an outsourced payment gateway. Suddenly you decide you want to set up your own payment gateway and channel all the transactions of your merchant business to your own payment gateway.

In the first instance, if you have separate environments and businesses isolated from each other – you can again opt for separate compliance. You could be a Level 3 Merchant filling up an SAQ B form, and also a Level 1 Service Provider doing an ROC with a QSA.

In the second example where your merchant business connects to your own payment gateway, it’s a little more complicated because in all likelihood, the systems utilised by both business would be common. In this case, isolation and demarcation of type of business is more difficult to attain. Assuming you are eligible for Level 2 service provider, you can technically fill that up and ensure that it includes your payment channels within that SAQ. If you are doing a Level 1, then similarly, the QSA would likely include your payment channels (previously what you would call your merchant business) into your service provider certification efforts. Otherwise, you can still opt for a separate PCI compliance program, whereby you fulfill your merchant compliance, and for your service provider compliance program you do it separately.

For the latter option, the advantage is that if you launch your payment gateway and you provide options for other companies (not just your own) to connect to you, your compliance isn’t dependent on your payment channels (your merchant business). You would treat your own payment channels as just another merchant out of many, that are connecting to you. The downside of this is that you would likely need a clear demarcation and separation of systems between your merchant and service provider business.

Again, there are many ways to skin PCI. The best way (on paper at least) is to get your acquirer on the table or your payment service provider to ask them what is applicable to your business. Unfortunately, around 99% of the time in this region, the acquirers aren’t too knowledgeable themselves and either give wrong information or just tell our clients to do a Level 1 Certification with a QSA.

As part of our job scope – we will assess our client’s environment and provide the options on the table, and in some cases even be present on the table in the discussion with their acquirer – to obtain a clear indication on how to move forward and what PCI options are acceptable.

As always, drop us a note at pcidss@pkfmalaysia.com and we will do our best to accommodate your inquiries!

PCI-DSS Logging in MySQL Community Version with MariaDB Plugin

March 18, 2017 / / 0 Comments

pci-compliance

PCI-DSS is a standard that brings to mind the famous sayings of Jimmy Dugan, the coach of an all-girls baseball team in the movie A League of their own (Played by Tom Hanks):

“It’s supposed to be hard. If it wasn’t hard, everyone would do it. The hard… is what makes it great.”

Well, at least the first part. Whether the banter of it making it ‘great’ is a different story. Most PCI-DSS sufferers will add the word ‘pain’ after the word ‘great’. And, one of the main pains for PCI-DSS is logging and monitoring. That’s requirement 10 for you. So much so that PCI-DSS recently released a document specifically addressing this issue here. So you will be faced with myriads of issues – from the simple to the hard: no we cannot centralise log anything, we do not have logging function in our application, we do not know how to do daily monitoring of our logs, we do not know what to log or how to log, we are all running on DEC VAX from 1974. So many reasons.

One of the challenge we recently faced with the client was that they were using MySQL community version. The challenge was how they can log administrator actions and security INSERTS, UPDATES etc in mysql community version? Logging is totally available in Enterprise, but not the free one – or at least not in its limited form.

Enter Maria-DB Plugin. Now before we go into semantics, MariaDB is an opensource database created by guys who created MySQL. It’s a fork, because MySQL was acquired by Oracle some time back and everyone was afraid that Larry Ellison might gobble MySQL up the way Galactus ate planets. The cutest story here is that MySQL was named after the founder’s daughter – My. And yes, MariaDB is named after his other daughter! But the first daughter’s name is “My”…so it’s like, “Yeah, this is My, My Daughter.”

Anyway. So what we are talking about here is not for them to install MariaDB, but to use it’s ‘plugin’ for MySQL. Make sure the QSA doesn’t get confused on this because ours did and we entered into the twilight zone of communications for a while where nothing made sense.

The Advantages of using MARIA DB AUDIT PLUGINS are:

So this article, we are going to explain on how we install the plugins in MySQL version 5.6.35 that is based on CentOS 7.

  1. Download the latest plugin from the links given above and you should see the download directory as below. Choose the latest version. We used server_audit-1.4.0.tar.gz. in centOS. We can use the wget command that is: 
    wget https://downloads.mariadb.com/Audit-Plugin/MariaDB-Audit-Plugin/server_audit-1.4.0.tar.gz
  2. Extract the tar file by using the command 
    tar -xvzf <file name>
  3.  Login into MySQL and locate the Plugin Directory of MY SQL using the command below 
    SHOW GLOBAL VARIABLES LIKE 'plugin_dir';
  4. Copy the plugin to plugin directory in MySQL based on your linux server (64 bit/32 bit). 
    • cp server_audit-1.4.0/linux-x86-64/server_audit.so /usr/lib64/mysql/plugin/
    • chown -R mysql.mysql /usr/lib64/mysql/plugin/server_audit.so

     

  5. Install the MariaDB Audit Plugin into the MySQL Server by this command inside MySQL 
    • INSTALL PLUGIN ‘plugin name’ SONAME ‘filename.so’;
  6. Once Installation is complete, we’ll start the daemon with the following command in the command line: 
    sudo systemctl start mariadb
  7. The command systemctl doesn’t display the outcome of all service management commands, so to be sure we succeed, we’ll use the following command: 
    sudo systemctl status mariadb

    If MariaDB has successfully started, the output should contain “Active: active (running)”

  8. Next, let's take a moment to ensure that MariaDB starts at boot, using the systemctl enable command, which will create the necessary symlinks: sudo systemctl enable mariadb
  9. Next, we’ll turn our attention in configuring the syslog FormatSet the Type of Action that will be log (within MySQL)
  • Connect: connecting and disconnecting to/from the server will be added to the log. An unsuccessful connect will be logged as a failed connect including the error code.
  • Query: full statement including the values will be logged
  • Table: Any operation on a table triggered by query will result in an event the MariaDB Audit Plugin can catch to log it directly
SET GLOBAL server_audit_events='CONNECT, QUERY,TABLE';

You need to have root privilege to be able to change the Audit Plugin variables.  With this changed we are ready to enable the auditing, which we now will do by using the following command within MySQL:

SET GLOBAL server_audit_logging=ON;

The full set of variables is found on this page: https://mariadb.com/kb/en/mariadb/server_audit-system-variables/

To make the changes to the configuration of the MariaDB Audit Plugin permanent, we now need to add these settings to my.cnf. This ensures that the same configuration will be used after server restart.

Under [mysqld] in my.cnf, add in

server_audit_events=CONNECT, QUERY, TABLE
server_audit_logging=On

There you go, now your MySQL is ready to face the scrutiny of the QSAs in your PCI-DSS compliance program!

Email us at avantedge@pkfmalaysia.com for any enquiries regarding this plugin or PCI-DSS in general and we will get back to you as soon as we can.

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑