PKF AvantEdge

Page 15 of 40

Penetration Testing and Vulnerability Scans

March 27, 2018 / / 0 Comments

In our compliance services, oftentimes, we are tasked to assist our clients in security testing – either conducting those ourselves, or to verify previously conducted tests for compliance purposes. There are many occasions where clients decide to perform the scanning on their own, aside from the obvious option of engaging another party to do this. When we receive the test reports from our client to verify, that’s when the excitement begins.

The fundamental question we often face is, what should a penetration testing report look like? What does a vulnerability scan looks like? This age old question has been haunting PCI-DSS for years, so much so that the council decided to publish a guidance on this, found: https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf

It’s a good read, if not fairly simplified, but it seeks valiantly to answer the question of what is a penetration testing vs vulnerability scans. This is important, because in PCI-DSS, the latter needs to be done quarterly, while the former needs to be done annually. When you multiply that by the costs and number of assets in scope, we could be looking at a decision involving tens of thousands of dollars.

In the document, section 2.1 dives into this and attempts to seek a differentiation between these two. In the basic concept of penetration testing methodology, these two activities serve specific purposes, for instance in the activities of Discovery, Enumeration, Footprinting, Exploitation, Cleanup etc, depending on which approach you take. And while there are many ways to explain the differences, to summarise:

A penetration test can be a vulnerability assessment (or scan, we will use interchangeably for the sake of this article) and beyond, while a vulnerability scan is not a penetration test.

A Penetration test can be initiated with a vulnerability assessment. The result from the vulnerability assessment will be used by the tester to penetrate or perform a more detailed assessment to circumvent controls or exploit the discovered vulnerabilities. In the process, the tester will also use manual methods to “test” the vulnerable system and likely during this process of poking around, discover more vulnerabilities or loopholes in the system that may not be detected during the initial scan. In the presentation of the findings of a penetration testing report, typically the ‘Proof of Concept’ (POC) detailing how the vulnerability was exploited will be documented.

Vulnerability assessment is the process to find out known vulnerabilities by using an (oftentimes) automated method (such as scanning software or scripts) against the targeted system. The result of the scanning will detail down the vulnerabilities, the risk exposures and action that can be taken to remediate these vulnerabilities. There is typically no manual proof of concepts that is done in the penetration test. The objective of a vulnerability assessment is to discover and report known vulnerabilities, not to exploit them.

A penetration test will normally take longer time to complete, i.e. few days, considering the manual verification or activities that need to be carried out to ‘penetrate’ the vulnerabilities. A vulnerability assessment can be completed in a shorter time frame, depending on the size of scope and software installed on the target system and it can be run on automated or scheduled basis. In our vulnerability scans, we also refine the results further by eliminating false positives, such as a patch that might not have been applied, but other secondary controls like virtual patching are in place to mitigate the risks. In either case, these are different activities, and in PCI, we need to understand what is NOT Penetration Testing.

We once received a 250 page report from our client who proudly said this was a professional work done by an outsourced security testing company offshore. Surprised as such a tome, which we assumed must have excerpts of Tolkien’s Lord of The Rings in there for good measure – we went through it. We found that it was nothing more than a raw report of the entire software inventory of the entire scope of around 50 plus assets. Meaning it listed down in excruciating detail what are the software installed in each of these systems, the licenses the OS versions etc. It was nothing more than a dump of the system’s software and nothing more. Not even the courtesy vulnerability scan. We told our bright eyed customer that we cannot accept this, and while this is a good book to have in terms of detailing the software they have, it has nothing to do with penetration testing, or vulnerability assessment. From singing praises of the offshore company, he ended up throwing them invectives that would make a pirate cringe.

We do need to be careful. We are not saying that the entire industry is filled with such charlatans peddling so called pentest services for a song and giving you a report that only provides you with the figurative emperor’s clothing for your security needs…but we must be able to differentiate what is, and what is not, security testing.

If you have further questions on security testing, drop us a note at avantedge@pkfmalaysia.com and we can quickly assess your needs and advice you on your next options to take.

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 and the Pervasive Certification Myth

March 4, 2018 / / 0 Comments

The pervasive certification myth is so pervasive in PCI-DSS that we are going to give it its own Acronym: PCM. Because we are so tired of having to explain this over and over, we are going to canonize this corporate disease called PCM and forever immortalise it as the one of the most deluded, misleading and misinformed quackery to ever blanket the PCI-DSS industry, the same sort of quackery that insists urine therapy should still be used today for natural teeth whitening. Yes, it seems appropriate to compare these two in the same breath.

Please note that the below article is satirical (borne out by our immense frustration and oftentimes resignation that this will never be properly sorted out, ever).

PCI-DSS and PCM

The history of PCM has its roots in PCI-DSS itself being considered as a standard that can be certified against. Because of the name, Payment Card Industry Data Security Standard, immediately, fairly important people in the financial and banking industry who generally prefer to spend more time golfing and drinking fine wine than to actually read the standard and understand it better – these people concluded that like any other standard, there must be a certificate to ‘prove’ you are compliant. I mean, why not? ISO9001 has it. ISO27001 has it. Additionally, these were the same people who insist on having a certificate for literally everything that they do in their corporate life, from attending a half hour seminar talk on how to grow daffodils, to sleeping though a computer based training webinar; to providing a poor soul whose car has broken down some assistance in pushing it to the side of the road. Where’s my certificate to prove that I helped you, my good man?

Apparently, certificates are absolutely critical to our financial industry, without which our entire economy would surely descend into the Dark Ages of Financial Purgatory. In the same way, it has perpetuated into PCI-DSS that despite everything that the PCI council has said and has begged the entire industry to reject this PCM quackery, 99% of the time, we are still faced with the mind boggling, soul numbing, heart wrenching email or question stating: I want to see your PCI certificate.

Here’s the official statement from PCI council:

FAQ #1220

Are compliance certificates recognized for PCI DSS validation?

 

No. The only documentation recognized for PCI DSS validation are the official documents from the PCI SSC website. Any other form of certificate or documentation issued for the purposes of illustrating compliance to PCI DSS or any other PCI standard are not authorized or validated, and their use is not acceptable for evidencing compliance. The use of certificates or other non-authorized documentation to validate PCI DSS Requirement 12.8 and/or Requirement 12.9 is also not acceptable.

 

The PCI SSC website is the only source of official reporting templates and forms that are approved and accepted by all payment brands. These include Report on Compliance (ROC) templates, Attestations of Compliance (AOC), Self-Assessment Questionnaires (SAQ), and Attestations of Scan Compliance for ASV scans. Only these official documents and forms are acceptable for the purposes of compliance validation.

 

Because certificates and other non-authorized documentation are not officially recognized, entities that receive these documents to indicate their own compliance (for example, from a QSA or ASV) or another entity’s compliance (for example, from a service provider) should request that official PCI SSC documentation be provided. Any organization issuing, providing, or using certificates as an indication of compliance must also be able to provide the official documents.

OK.

We actually would prefer the answer to just be: “No. For heavens’ sakes stop asking the council such questions and waste our typing time on the keyboard!” But we are not the council. Else we will be out of work within a day.

You ask then: Wait a minute, if there is no certification, what are we supposed to submit then?

Well the answer to that is: it depends.

If you are a level 1 merchant or service provider, then you submit your Attestation of Compliance (AoC) signed off by yourself and the Qualified Security Assessor (QSA) or Internal Security Assessor (ISA). You may also submit your ASV scan reports, or if requested your full Report of Compliance (RoC). But rarely those last two are needed. What is needed is the AoC. That’s your PCI ticket. If you are doing a self signed Self Assessment Questionnaire (SAQ), you submit in your AoC, and if required the full SAQ documents with your response on the applicable questions.

I suppose we (the consultants, advisors, auditors) didn’t help in stopping this PCM disease ourselves, by oftentimes referring to Level 1 as a PCI ‘certification’. It’s more of figure of speech than anything, meaning that a third party is to validate your compliance as opposed to you doing a self validating process under the Self Assessment Questionnaire (SAQ) path. So we end up saying certificate, certificate, certificate and finally everyone asks, well, then, where is my certificate? As in the actual, real certificate, and not this figure of speech one?

It also doesn’t help that most (if not all) QSAs play along with this ridiculous fallacy. They will come up with their own ‘certificate’, made to look very official, very grand, very formal and very important looking. You know, those papers with flowery borders at the side and some huge bold statement saying, So and So are official certified, and signed off by a very important person. Some even put a seal in there for good measure. As if they graduated from Hogwarts.

The truth is, that certificate paper is just piece of paper. It’s not acceptable in any way for PCI-DSS and shouldn’t even be requested by acquirers or banks. Yes, no matter that the QSAs even make it look like it’s gold laced, and our customers print it out in all its Arial font glory, and spend a few bucks to frame it up nicely. That’s all well and good, and they are entitled to do anything with it, but PCM rears its ugly head when acquirers, banks, customers and clients insist on having it. INSIST.

If you have gone through the level 1 validation with a QSA and that QSA is able to provide one of these certificates, as a consequence of the PCM disease, then I suppose it’s fine, you can just play along as opposed to haranguing them about the PCM disease like what we are doing right now. Just provide them that dratted document. This does increase the myth further though, and it starts infecting the entire industry even more, because, now the acquirer/client/bank will go to another company and declare they need the certificate that the other merchant had provided. Until they reach a small company who is doing their own SAQ, whereby they say: “Yes, even if you are doing a level 4 merchant compliance, you should still be having a certificate! Come on now, chop chop!”

And that’s what we are facing.

Without exposing which industry right now we are assisting (those following our recent blog posts may venture a very educated guess), we are helping a lot of merchants undergo level 4 self signed SAQs. This is absolutely allowed by PCI-DSS. There is zero requirement to get QSAs involved. ZERO. In fact, PCI council printed this out in their Top 10 myths of PCI-DSS.

So now, our clients want to submit their compliance document (AoC) to the group requesting for it and here is the summary of response they received: 

a) The group requesting our client’s compliance says that the SAQ needs to be sent over to the QSA so that the correct SAQ type applicable to our client’s business will be determined. (WHAT?!)

b) Our client only now has to submit the PCI DSS compliance certificate.

I looked at it and we just shrugged. Resignation. PCM. This is what this disease has caused.

Firstly – the first phrase is proof that the writer has not bothered to even understand the background of SAQ and PCI.

No. The SAQ DOES NOT NEED TO BE SENT TO THE ASSESOR! It doesn’t even make sense. You are telling me to send the assessor the SAQ document I filled up so they can determine what SAQ I need to fill up? What sort of recursive devilry is this? Is this one of those tricky while-do loop we do as programmers that never ends because the condition to end is the condition to begin as well?

How many times have the PCI council stated that it is not the QSA’s role to define the validation requirements of the merchant, or the service provider or the bank. It’s NOT. The QSA’s role is to assess based on whatever validation requirements that has been determined. Yes, they can advice. Yes, they can with their amazing experience and god-like understanding of PCI-DSS, suggest which validation requirement to take. But at the end, the acceptable validation requirements are based on the bank, the acquirer, or worst case whichever company requesting the merchant to be compliant. If none, then the validation requirements must fall back to the guidelines provided by PCI SSC, which means, it falls back to the individual card brands. We are not going to go into that for now, but in general, VISA/Mastercard has an agreement on merchant levels, but Amex has some weird levels of their own. What we are stating is that, if a merchant is considered a level 4 merchant based on its volume, but the acquirer decides that they must still undergo Level 1 validation, then that’s the acquirer’s call. But it’s never the QSA/consultant to decide this. The QSAs job is to assess the company against the validation requirements and have an opinion if it is pass or fail. The type of validation is determined by the acquiring party. So, no the first sentence is already incorrect, never mind the recursive gibberish.

The second sentence is where PCM disease kicks in. Because nothing is known about the ‘AoC’, everyone immediately assumes that the certificate is an official document from PCI-DSS and it should be sent in. No. If the merchant is doing a level 4 self signed SAQ, that is 100% allowed by the council and by their acquirers, where in Thor’s Holy Hammer are they going to get a certificate to fulfill your insatiable lust for PCI certificates??!!

I am tempted to just have my 5 year old son draw a smiley face on an A4 paper, and stick one of his favourite Cars 3 character sticker on it, sign off and laminate it.

Go ahead – I dare you to google “PCI certificate” and click on ‘images’ and see the result of PCM in our world. Thousands upon thousands of PCI certificate documents, some even daring to put the PCI SSC logo on the certificate as if to say PCI SSC has endorsed the certificates, to provide these documents an air of official integrity. Even worse, we see QSAs giving ‘certificates’ for clients undergoing SAQs. Wait, if they have audited them, then OK, fine. But if is a self signed SAQ, how can certificates be even provided?

We are not saying what they are doing is wrong. No, it’s not wrong to provide a PCI certificate. But PCI SSC has clearly stated that if you guys want to do this, you must state clearly that these are not official PCI documents and these are supplementary, not mandatory and only provided by the QSA/ASV and not endorsed by PCI-SSC and cannot replace the official documents like AoC or RoC. Basically, PCI is just saying, “Put it up in your office or your lobby so you can brag, but please don’t show it to us and say you are PCI compliant, we rather be looking at a piece of art written by a 5 year old kid with some Cars 3 character sticker on it.”

Finally, to end this article (or rant, it may seem to some). The reason why this is written is to drive home the fact that PCI-DSS has no actual paper certificates. None. Whatsoever. The actual document you should be requesting for is the Attestation of Compliance (AoC). Please do not ever request for the Certificate of Compliance ever again because this means, you are guilty of spreading the epidemic of PCM across the world.

Note: This article is meant to be satirical, for us to blow off steam and not intended to offend any party or to dispense actual advice. There is actually no such thing as an official PCI Pervasive Certification Myth. At least, it has not yet been officially defined, as far as we know.

 

 

 

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 »

© 2024 PKF AvantEdge

— Up ↑