PKF AvantEdge

Category: PKF Avant Edge (Page 9 of 18)

PCI-DSS: Business Not As Usual

June 21, 2018 / / 0 Comments

Have you heard the phrase Too Long, Didn’t Read? What if this applies to your PCI DSS compliance program, rephrased to “Too administrative, didn’t’ do?”.

We get this all the time in our meetings. Everyone mobilise for the big PCI project, everyone celebrates when they get certified and everyone suddenly gets collective amnesia and forgets about it. They forget there are daily requirements (like daily review of logs), weekly requirements (like FIM file comparisons), monthly (like critical patching), quarterly (ASV etc), half yearly (firewall reviews etc) and annual (testing etc). Yes, there are such requirements. We generally encourage our client to celebrate their success for first time certification but keeping in mind these obligations. Certain things you just can’t afford to miss out like your ASV scans and Internal VA scans.

PCI calls this Business As Usual (BAU). Being so long on the receiving end of these compliance requirements and now dishing it out in our advisory, I can safely say: PCI isn’t business as usual. In theory, yes, it should be, but theory and reality remains as far away as the possibility of Malaysia winning the next World Cup. A lot of our clients, after winning the PCI certification, find themselves completely overwhelmed with the so called Business As Usual theory that they wonder, whether after achieving PCI Business As Usual whether there will be any Business left to be usual about.

So what happens now that you are PCI compliant? When you are planning your PCI DSS compliance maintenance, you may want to setup a team to look into all the requirements, be it the technology, process and people. After you get your PCI DSS compliance, remember, the ‘maintenance’ clock starts. Yes. So if you take 2 months to celebrate your victory over this dastardly villain called PCI, you technically have one month left to do your Internal Scans and ASV scans. So don’t forget about what you need to do. Your PCI team needn’t be dedicated personnel (Very few companies can afford that), but there should be a lead person, relatively not bogged down by day to day operation works, and ideally independent from the operations as well. If you have a info sec team, it would be good, else a technical project manager to lead and the responsibilities to maintain, to go back to the process or system owners.

True, even before PCI arrives, you are probably already bogged down by other compliance requirements on top of your normal day to day. ISMS, customer audits, regulatory audits and assessments, internal audit, and now PCI. It’s like eating pancakes after pancakes except these are horrible tasting pancakes.  You might forget some of the administrative tasks that need to be maintained as part of your PCI DSS compliance process and we have had customers scrambling to complete their quarterly scans after missing them. Eventually, after a period of time, all these tasks will pile up on your plate and you are left with the prospect of being unable to be recertified. Your PCI DSS compliance will be at risk of becoming non-compliant and void and really, it’s not something the board will be too happy about, after taking 3 months of budget to celebrate the victory earlier. It’s like winning the English Premier League one season and getting relegated the next. The emotions are too much. We may think these maintenance tasks are petty but it is an important component in your PCI DSS compliance ecosystem.

Here are some insights to some examples of these administrative tasks that might be missed:

Changes on firewall/switch/router rules or configuration– it is highly critical that before a change is done, proper testing, approval and documentation are carried out. As these devices are critical components in the network infrastructure, any misconfiguration may result in security issues or in our observation, even bring down the whole network and have people scrambling over the weekend unnecessarily. Proper testing and approval process are any case required before changes can be made and this must be documented. Documentation provides an audit trail of changes and why these changes are required. So, don’t forget to document this process. Or risk the weekend being messed up.

Patching – There is this perception that if I’ve setup my systems to perform patching automatically, everything is well. Wrong! You need to review the patches and ensure that it is safe to be deployed and it will not like, I don’t know – crash your production systems? Next is to make sure the patching applied is being documented so that you have a history of updates on your system. A configuration information (CI) system can do that, or you can ensure you run your inventory checks regularly, as Windows would keep track of these applied patches. If the system is being patched up manually, you need to have the procedure of checking for updates on a regular basis. Make it a habit to check if your system is running with the latest patches regardless if the patching is automatic or manual by making it as a checking activity in your periodic task list. Remember, PCI would require a one month critical patch deadline and three months for non critical security patches.

Anti-malware – anti-malware will normally update automatically and periodically and we will assume that it will run as what it is being configured to do. As such we will not bother to check unless something bad occurs (which almost always does). As part of your administrative task, you should make it as a daily task to check the anti-malware system status, malware detected and the resolution of it and put this task in your checklist.

Logging and Monitoring – PCI DSS requirement 10.6.1 requires review of security events at least on daily basis. Most people stare blankly at me as if I’ve just told them elephants do wear tutus and can fly. Then they realise that I am not joking, they shake their head and invariably say (in variable tones, depending on how incredulous or stupefied they are): “WHAT?! DAILY?!?” .

Well, yes, in a way, although PCI in its supplementary document Effective-Daily-Log-Monitoring-Guidance.pdf, they have provided this little leeway for your ease:

“A reasonable timeline must be defined to allow less capable organizations to perform security log reviews while still enabling the organization to detect malicious or anomalous activity before it can likely escalate. In the case of Requirement 10.6.1, PCI DSS has determined that timeline to be a maximum of 24 hours or one calendar day.”

So when we refer to ‘daily”, it is with this definition in mind. Still a difficult one, but hey, OK.  In our advisory works, we have seen that clients often miss out the daily review and alert they receive (usually through email). It could be a SIEM (Security Information and Event Monitoring) system is deployed and configured to identify a threat and sends out an email to the person in charge. Instead of monitoring this email that might be a critical security issue, it is not reviewed. Not reviewing security alerts is a risk that may have adverse effect for obvious reason. In a recent retailer breach, for many months hackers were siphoning information from their POS systems to a spool server and removing that data file to an external system. If reviewed properly, such an abnormal data flow might have been spotted.

So, these are a few of the admin tasks. There are a lot more. Moving forward, be diligent, make it a habit to not miss any of these out and incorporate these administrative tasks as part of your daily routine tasks. Other tasks include ensuring quarterly testing such as ASV, annual penetration testing, etc as described in requirement 11 are carried out properly and given enough time to perform. Don’t expect your team or vendor to do a pentest on 50 systems and tell them to complete it by tomorrow. Failure to observe PCI timelines may result in you losing your compliance.

Don’t get relegated after winning the league!

Contact us at pcidss@pkfmalaysia.com for further queries on PCI-DSS and we will set up a meeting with you as soon as you are available.

PCI-DSS: The Art of Getting By

April 6, 2018 / / 0 Comments

The Art of Getting By is a movie that wasn’t very good. I don’t recall much of it, except the title was appropriate for this article.

The general idea of PCI-DSS is that it’s easier to maintain the compliance than to first obtain it, and while there are nuggets of truth there, we would venture to turn that idea upside down: It’s much harder maintaining it that to obtain it. Maybe it’s like marriage, where after the wedding and honeymoon, the real work begins in ensuring you have 40-50 years left in the tank with your partner (depending on when you tie the knot of course, and in some cases, depending on how many kids you end up having. That’s added stress.). In some ways, it’s similar, and over 8 years of PCI experience had taught us that while we should always (again – ALWAYS) celebrate the success of first time compliance to PCI, we must not forget what lies ahead of us.

PCI Council realises this and in Appendix A3 of their PCI standard, lists out a few extra things for DESV (Designated Entities Supplemental Validation). It must be noted however, these are not automatically mandatory for PCI companies, but for companies designated by their card brands or acquirer based on risks and oftentimes, volume of transactions. If you are not required to go through DESV, don’t go searching for it.

DESV puts in a few extra components to the PCI standard. One of the requirements is to Implement a continuous PCI-DSS program in the organisation. What has been noted by the council is that while many companies do attain PCI-DSS, they treat the standard as an event they need to get by each year. This means companies, instead of practicing PCI in their daily work, seek to re-certify each year based on a series of checklist they need to do at that point in time. Which isn’t cool. But that’s how almost everyone approaches it. It’s like taking your semester exams in University. It’s not like in day to day living, we are thinking about the real value of x in a log2 equation or what are the prime numbers that are relevant to your life. We are just thinking about hanging out, cutting classes and kicking up dust. When the exams come, we mug, we eat ramen noodles for every single meal, we don’t go out, we don’t sleep and we generally try our darnest not to fail, and then the whole cycle of meaninglessness begins again. I don’t really recall much of my university days, as you can tell. And that’s how PCI is sometimes approached.

So how does one stay compliant, instead of just pass compliance?

Management Buy In

We hear this a lot from our management text books. Management Buy In. Unless we have a top down support and sponsor on compliance, PCI is going to be a drudgery faced every year. IT is going to be bombarded with all kinds of requests on top of their already busy day to day work. Most success comes if the business recognises the importance of PCI to their organisation. We have some rare instance where clients do PCI just “because they want to, and they want to look good”, but more often than not, those attempts fizzle out once they realise it’s a rabbit hole you can’t get out of. A cost benefit analysis is key here, and a business case needs to be built, because you are going to end up spending a lot in this compliance, and that spend should be backed up with sound revenue and business in the pipeline – directly generated because of your compliance.

Having a Compliance Team

You need a go-to guy, or a go-to group for this compliance. We have experience where PCI is dumped into an organisation and every week we are dealing with different people. We have one customer who named a project manager to lead the project and his appearance in our meetings is as rare as Yeti sightings. We sit in the meeting and we go, “Where’s so-and-so?”. Some wide eyed junior IT guy goes, “Oh he’s busy with another project, and I am asked to lead”. Anything we discuss, he just goes, “OK, I need to check with so-and-so and get back to you.” Without decision makers in the team, we end up going around in circles and before you know it, 6 months have passed and we are still on the same agenda. It’s like going 3 levels deep in an Inception dream. Get a team. You don’t need to bring in 20 people in the meeting where 18 people sit away from the table, typing furiously at their laptops as if they are writing the next War and Peace novel. 3 or 4 key guys: Person in charge, network and server team representatives, developer rep and if you have SOC/security team rep. Everyone should either be an influencer or a decision maker, and we are good to go.

Business As Usual

We call it BAU. Many have suggested PCI is asking ridiculous requirements which are too difficult to meet. In reality, PCI is basically asking for baselines. The very least organisations should be doing to secure themselves. Security needs to be practiced, and not just implemented as a checklist over a short period of time. For instance, the requirement for daily log monitoring. This is not something you can conjure up when the auditor comes and audit. If you are not practicing it, you are not practicing it. Or simple things like CCTV monitoring. We faced a client doing recertification and on a pre-audit check, we found their CCTV had not be recording for 8 months due to maintenance. I asked why was this not reported or checked, and they sheepishly told me they had no clue and they had never bothered to even check since they passed their cert. PCI requires a fair bit from organisations, for example:

Daily Monitoring of logs, and access to secure area, weekly checks on FIM logs

Monthly checks on critical patches

Quarterly – Wireless Scans, ASV, Internal Scans

Half Yearly – Firewall review, user deactivation

Annual – Pentest, application testing, Risk assessment, training, Inventory checks and review, policy review, service provider review, Incident response, segment checks etc

Those are just part of the listing. So unless you plan to have sleepless nights during the audit period, it’s best to get these done as part of your day to day. We need to note that in most cases, these should be practiced in any case, regardless of PCI or not!

Yes, a lot of these are easier said than done. We are aware teams are being pulled sixteen different directions and PCI is just one of it. It falls back to how critical this compliance is. To many, it’s required to continue their business as it is a contractual obligation. So it’s not just about getting by, although in some cases that might work – but for PCI, we would recommend to embed these practices as much as possible into your organisation, so that when audit season comes, you don’t end up overeating your Ramen noodles.

Get in touch with us through pcidss@pkfmalaysia.com for any enquiry on PCI-DSS!

We are Minerals being Mined

March 25, 2018 / / 0 Comments

It is often said, and its almost cliche – Personal Information is the new currency.

And now, with the news on Facebook and Cambridge Analytica, we are faced with the sort of global privacy crisis that we always knew it would be coming. Furthermore, it wasn’t as if Cambridge Analytica was a key data broker/trusted partner/premier solutions arm of Facebook. It just developed software to get the data. That’s it. 50 million users.

It was as simple as getting an app to use your facebook login to enter the app and that’s it. We think we are just logging into the app, but we are actually allowing the app to login into our facebook and take everything. Everything.

But what did we actually expect? Think about it.

Did we expect to have such a service like facebook where we can get information, connect with long lost friends, advertise our solutions and products, express our opinions in a global platform, create online value, message and chat, have thousands of hours of free access to apps etc etc – FOR FREE?

Unless Zuckerberg has the title of a ‘Saint’ in front of him, then that would be a hard sell.

No, Facebook says. You guys agreed to it. The terms of services says it. The one that is too long for you to humanly read. The one that they update without letting you know, and allowing trickles of liberality of information usage to seep in.

Facebook even contends that developers who have these information from their app cannot “transfer any data that you receive from us (including anonymous, aggregate, or derived data) to any ad network, data broker or other advertising or monetization-related service.”. That’s pretty kind of them. But in the first place, did Facebook inform users that their apps would be literally stealing the entire bank of information from the users?

It’s the sort of finger pointing activity you would expect – a phrase and sentence here and there that says, “Hey, we told you we are getting your information and we told these guys not to share! What can we do if they do share??!” But is Facebook giving excessive details? So in PDPA terms, it’s not just about third party sharing of information, it is about excessive collections.

In any case, I don’t think we have a case of PDPA against Facebook here as they do not have any systems in Malaysia processing personal information. But the point is that we have wittingly or unwittingly sold our information to Facebook in order to get the services they provide. Same for Google. Same for Apple. Same for Instagram. Same for Pokemon-go.

A great site we always give in our presentation of PDPA or information privacy to clients is: https://tosdr.org/

Terms of Services Didn’t Read. It’s a great site that basically summarises all the terms of services to human readable content and rate them according to how cavalier they are with our information. All the big guns are there. Even if not rated, we can look through their terms and have a little more details on what we are ‘paying’ them.

Take a look at Google, Youtube, Twitter to start with.

Facebook’s TOS:

  • The copyright license that you grant to Facebook goes beyond the requirements for operating the service. For instance, it includes the right for Facebook to transfer the license or to license it others on their terms (“sublicense”). Also, the copyright license does not end when you stop using the service unless your content has been deleted by everyone else.
  • This service uses cookies to track you even if you are not interacting with them directly. Amazon for instance, use cookies to track your device and serve targeted advertisements on other websites (Amazon associates, websites using Amazon Checkout). They “obtain certain types of information when your Web browser accesses Amazon.com or advertisements and other content served by or on behalf of Amazon.com on other Web sites”.
  • Facebook automatically shares your information with Bing, Pandora, TripAdvisor, Yelp, Rotten Tomatoes, Clicker, Scribd, and Docs, unless you manually opt-out.
  • Including: data analysis, testing, service improvement, control of the effectiveness of the personal ads, and location features and services.
  • You must use your legal name publicly on the service. Using a pseudonym or a pen name is not allowed. This can have negative consequences on the freedom of expression, especially for people who exercise certain professions, or who live in certain countries.
  • Facebook uses, pixels and local storage in order to gather information about you, your device, your browser cache, your use of Facebook. Facebook also uses cookies for adversing purposes.

For years I have advocated clients (and also my personal friends and family) to use Facebook with these in view. For family: Never post about your current location. Never put photos of your children up online. Never reveal too much about your views and opinions. For work: Never give any views on your current work, the time you finish work, the after drinks parties etc etc. Basically, never give any relevant information.

Will Facebook be able to still get information? For sure. Every “Like” you click. Every news you click. Even when you are not on Facebook, and you are browsing the web, there are Facebook plugins that can track what you are searching for. Even if you search on Google, whatever you are looking for will appear eventually on Facebook. Data brokers and advertisers trade our information like anything – and what you do on Google surfaces in other social media platforms.

But we know. Services aren’t free. Our parents says, “There is no free lunch” and this is certainly true. But how much do we know about this lunch we are paying? We might be getting Subway sandwiches, but paying the money for Burgers and Lobsters dining. That, I suppose, is what the world is now only finding out.

For more on our information security services and PDPA services, drop us an email at avantedge@pkfmalaysia.com. The only thing we are collecting from you is whatever you tell us on that email. That’s our term of services!

 

 

PCI-DSS Segmentation with Host-Based Firewalls

February 17, 2018 / / 2 Comments

One of the frequent queries we have faced in the past months as we ramp up our consultancy and advisory for travel agencies and other merchants, has been the question of segmentation.

Now, before travel agencies were imposed with the requirement for PCI-DSS by IATA, we had very few opportunities to work with small merchants for PCI-DSS. It’s not because small merchants are exempted from PCI. They are not. Small merchants must be PCI compliant, but in reality, very few banks are chasing smaller merchants for their compliance. Our experience with merchants had been with the fairly large ones – the large petrol companies, the large retailers, the telcos and the largest travel agency being our experiences. From the time we started PCI back in 2010 to around 2014, it has mainly been for financial institutions and banks. But now with IATA flexing their regulatory muscle to make sure agencies are PCI compliant by 1st of March 2018, we have had plenty of opportunities to go into much smaller environments that we are used to. And it has been a really great experience.

So when we discuss about the topic of network segmentation, we need to be clear from the start:- it’s actually NOT a PCI-DSS requirement. PCI doesn’t state that we need to segment our network. We could very well be PCI compliant on a flat network. Page 11, of PCI-DSS v3.2 states so:

“Without adequate network segmentation (sometimes called a “flat network”) the entire network is in scope of the PCI DSS assessment.”

And we have done this before. One of our client has a completely isolated network for PCI-DSS with its own gateway and basically its a flat network with everything as CDE (Card Data Environment). Possible, but in enterprise environment, probably not so realistic if it drags in hundreds of systems. Without going too much into scoping, the main topic of this article is: if we need to segment, how do we do it?

At the onset, the question seems superfluous. How to segment? Why, by network subnets of course, or by VLANs (virtual LANs). These terms (subnet and VLAN) have been used interchangeably by myriad of customers over the years, and in most cases, they actually do multiple VLANs across different subnets, but in theory you can also have VLANs on single subnet as well. So, no – VLANs and subnetting are actually not the same but for the sake of not being pedantic, most of the time, we just allow the client to use whichever term they choose.

In most cases over the years, our clients won’t have a problem with this. Segmenting either via VLAN or network subnet, they can achieve this fairly easily through their switch or their edge router, as they usually have advanced firewalls/routers/L3 switches deployed in their network.

But going into the very small companies with a handful of people, no technology personnel, and running the D-Link DIR-615 low end routers provided by Telekom? How do we do this?

We have heard other consultants declare that these companies need to invest in enterprise grade firewalls/routers to achieve PCI compliance, because some of the entry level router/firewalls are unable to do any segmentation or VLAN. Of course, you could hack the DIR-615 to WRT and that might provide you some limited VLAN capability, but that’s beyond the scope of this article. And in any case, we doubt any of the smaller merchants have the inclination to fiddle around with their routers. So if you are stuck with a firewall/router that cannot do any network segmentation, does that mean that everything needs to be brought into scope? Does that mean you need to spend thousands to get a firewall upgrade?

So let’s have a couple of references here. First of all, the canon document from PCI will help, this is the official PCI-DSS v3.2 documentation, page 11, stating a few salient points:

Without adequate network segmentation (sometimes called a “flat network”) the entire network is in scope of the PCI DSS assessment.

This phrase actually enables many people to pre-suppose that PCI is stating that the only segmentation allowed here is by the methods we discussed above – i.e anything that creates a non-flat network. But this is confusing because when we say ‘flat network’, we are already indicating we are referencing to Layer 3. However it’s entirely possible to have layer 2 VLAN isolating systems within the SAME SUBNET (multiple VLANs – Single Subnet design). Heck, you could even have multiple subnet on a single VLAN if you want … I think I remember this from my Cisco CCNP days. So, actually, in theory , unless PCI refers to something else when it says ‘Flat Network’, their statement isn’t that accurate. You could isolate systems in a flat network.

Network segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists, or other technologies that restrict access to a particular segment of a network.

While agreeing on this one as a whole, the other confusion here is the term “Physical OR logical”. As tech nerds, we take these conjunctions very seriously. For instance,  my wife asked me the other day if I wanted a cheeseburger OR a double quarterpounder happy meal. The answer to that would be “TRUE”, meaning, Yes, I can have cheeseburger OR a double quarterpounder since “OR” here is inclusive. As long as any or both of those statements are true, it’s true.  This is usually what we do in Boolean values, for instance

1 > 2 || 3 > 2 = TRUE

1 > 2 && 3>2 = FALSE

So back to the phrase Physical OR logical, this generally means PCI accepts Physical segmentation, even if there is NO LOGICAL SEGMENTATION? What does that mean? Does it mean if I have two systems hooked into the same switch, on the same network, pinging each other, I set up a physical brick wall between these two systems, I have achieved Network Segmentation? Surely not. The physical segmentation example here would be having two separate switches servicing two different networks as opposed to using a single switch and using it’s logical functions to achieve that segmentation. Can both be used or one or the other? Yes, either can be used. So whoever have written this phrase either needs to clarify this statement proper, or simply, he or she is !(Tech Nerd).

At a high level, adequate network segmentation isolates systems that store, process, or transmit cardholder data from those that do not.

So finally they decide and say, ok, anything that ISOLATES systems can be considered network segmentation. So at least we have a lead here to go with. Anything that ISOLATES.

The next journey we take is to this document:

https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf

Section 3.1, page 13:

Examples of controls that could be applied to prevent out-of-scope systems from compromising a connected-to or security-impacting system include:

– Host-based firewall and/or intrusion detection and prevention system (IDS/IPS) on in scope systems that block connection attempts from out-of-scope systems.

This is one indication that PCI looks at alternate ways of ‘segmentation’, other than getting an enterprise grade network firewall. Once more, the conjunction used here is “AND/OR”, which we take to mean, either AND (&&) or OR (||) can be used for these two statements (Host-based firewall, IDS/IPS). So what this basically states is that a host-based (not network firewall) firewall is good enough, if configured properly to be considered as a segmentation tool.

Now if you do know a little history behind this documentation, it has a grandfather document called “Open PCI DSS Scoping Toolkit”, a copy can be found here:

https://www.isaca.org/Groups/Professional-English/pci-compliance/GroupDocuments/OpenPCIScopingToolkit.pdf

This was way before the PCI-DSS document came about. We had to use the OPEN PCI scoping toolkit to define what is in scope, not in scope, CDE, non-CDE in scope etc. This is why sometimes we say systems that are non CDE are ‘infected’ , i/e pulled into scope because they are in the same subnet/VLAN. This term isn’t found in the PCI document but is used in the old scoping toolkit document. Of course, this document is deprecated and the SSC doesn’t officially endorse it. However, some concepts had made its way into the SSC scoping document and what we are focusing here is mainly on the usage of host based firewall, and whether it’s logical for it to be used for some sort of segmentation. Other parts of this document has been succeeded by the official PCI scope document, so be aware. Back to this document, a few QSAs had looked at us in amusement when we used these terms and some even commented that these are very strange terms we are using, showing how young these QSAs actually are. I am not sure about the other regions, but I have had discussions with QSAs who are 10-15 years younger than me and never had one day of experience in actual security operations. One QSA even insisted we put our logging system into the DMZ as good security practice, which I then responded with an emoji face slap to our customer. With all due respect to QSAs, I have had many arguments with them over the years – some are very good, very experienced; while some are, as Bart Simpson would put it: “Meh.”

Anyway, we digress.

In the scoping toolkit, Page 13 gives an indication of what we are talking about:

The mechanism providing the isolation or controlled access functionality may be either logical or physical. Examples of mechanisms include network and host-based firewalls, virtual routing and switching appliances, and access control lists

This is still less clear due to our “AND” and “OR” arguments, because aside from the illogical “logical or physical” statement (which PCI clearly inherited), we have the problem stating “network and host-based firewalls, virtual routing and switching appliances, and access control lists”. This, to us, might mean we need ALL of these things for isolation to be TRUE.

Thankfully, this is clarified further down in Page 36:

In order to restrict other workstations on the same network from being “infected,” the dumb terminals must be isolated (e.g., using a host-based or network-based firewalls, etc.).

The example here is “using a host-based or network-based firewalls.”. As you now are very well aware, this means this statement is true if any of these options, or both these options are true.

You see, some writers do not think twice about the usage of “AND” and “OR” operators or ‘conjunctions’ to normal English-speaking people. These are extremely powerful operators and carry entirely different meanings to what normal people may deem as normal sentences having the same meaning. Another key life example here would be if your wife (again a very relevant example) were to ask you after a late night out with the guys whether you’ve been to the bar to watch football or to watch strippers, to which you respond: “YES”.

So be careful because different people parses sentences differently, depending on whether you see life in code or not. It could very well change your life.

We have also discussed this topic of segmentation at length with some senior QSAs (QSAs who have much more experienced compared to the green horns) and they have agreed that host-based firewall, or Host IDS are acceptable forms of isolation, but requires a significant amount of configuration to ensure isolation is done properly. “Done properly” here carries a fairly subjective weight to it. QSAs are a funny lot, because many of the requirements in PCI are general, and then it’s up to the QSAs to decide whether a particular control satisfies their own concerns whatever that might be. To summarise, segmentation can be carried out easier through deployment of a network firewall and getting the segmentation rules sorted out there, but if the merchant is short on funds, and have 1 or 2 systems only to configure, a fix could be a “properly configured” host-based firewall, or a host-based IDS/IPS.

Segmentation testing still needs to occur, though, but that will be for another article for another day.

Now, I will have my coffee OR tea to finish up my day. TRUE.

For more information on PCI-DSS, feel free to drop us an email at pcidss@pkfmalaysia.com.

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!

« Older posts Newer posts »

© 2025 PKF AvantEdge

— Up ↑