Month: April 2017

IATA and PCI-DSS to Travel Agents: Data Channels

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

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.

© 2020 PKF AvantEdge

Theme by Anders NorenUp ↑