PKF AvantEdge

Tag: PCIDSS (Page 5 of 6)

IATA PCI-DSS: What Exactly is Required?

May 30, 2017 / / 2 Comments

pci-compliance

Continuing our series on Merchant program for PCI-DSS. Why this is (or will be) so important is that in around 12 – 15 months, if you are a merchant, very likely you will be getting a call from your acquirer.

About 2 months back, Mastercard announced that all acquirers must have in place a risk assessment program for Level 4 merchants by March 31, 2019. This basically means that there is a great concern that 99% of Level 4 merchants out there are blissfully unaware of this PCI-DSS nonsense they need to comply. It is the acquirer’s duty, but the pain starts all the way at the merchants.

One industry feeling the pinch here is the travel industry. But don’t worry, travel agents, soon, the other industries like your cousins at the hotels and hospitality will be going through the same process as you are going through now. It’s just who is going through first. And the faster you get through the better.

Travel agents across the world has been mandated by IATA to be PCI compliant. Please read our previous post here.

We have gone through the requirements in that post, but we’ve been hearing a lot of things coming to us from the travel agencies recently, namely:

a) All Travel Agents need to engage a QSA to formally sign off their SAQ.

IATA should be able to give a formal statement on this. QSAs or consultants or PCI experts cannot dictate or mandate the validation requirements. Mostly this is by the processor (IATA) or the acquiring bank. If they can’t make a statement, then it would fall back into the card brand validation requirements. Which it has so far, unless IATA comes forward to clear this up. We can’t seem to find anywhere that IATA has had special requirements other than listed in the card brands requirements.

There might be further explanation needed based on their PDF at http://www.iata.org/services/finance/Documents/pci-dss-compliance-procedure.pdf

The procedure first states

Travel Agents are encouraged to contact their merchant bank (acquirer) or the applicable payment brand(s) to identify the appropriate procedures based on their eligibility.

But then at the bottom it implies that for assessment, it needs to have a QSA perform ‘on-site’ PCI assessment – which is not exactly accurate as it depends on their level. Further on right at the bottom, it states:

Depending on the number of card transactions handled those can be:
– PCI DSS Attestation of Compliance (AOC) which must be completed by a Qualified Security Assessor (QSA).
– Self-assessment questionnaire signed by an authorized officer.
– The results of quarterly vulnerability scans if applicable.

The problem here is that if the AoC is required to be signed by the QSA, so does its corresponding SAQ. These documents have the same signoff (3c for QSA) section. If you read the above you might be tempted to also argue that IATA is saying, depending on the number of card transactions (meaning your level), the requirements can be either:

– PCI DSS Attestation of Compliance (AOC) and ROC or SAQ which must be completed by a Qualified Security Assessor (QSA) – this applies to Level 1 Merchant (they can also use ISA but lets put that aside for now), and also Level 2 if you deal with mastercard.
– Self-assessment questionnaire (SAQ) and AoC signed by an authorized officer. – This applies to level 3 and 4
– The results of quarterly vulnerability scans if applicable.

Now we don’t know if this is what IATA is saying – it’s just the many ways this section can be interpreted so we do hope IATA will have a clarification on this matter. They CAN decide on a more stringent requirement for their agencies (such as ALL levels engaging a QSA to be onsite like a level 1 merchant), but this needs to be clear, so agencies can forge ahead with the proper budget and expectation.

Most travel agents fall under the Level 4 category of merchants, which based on the current requirements of PCI-DSS only requires a merchant officer to sign off the document.

Mastercard’s SDP services recently responded back to us on this with a confirmation as below:

Level 4 merchants are required to ensure they are PCI-DSS compliant by filling in the correct SAQ based on their processing environment and have the evidences prepared , and also to do this each year. There is no requirement from Mastercard to engage a QSA/ISA to signoff their SAQ on part 3c or part 3d of their SAQ/AoC and their executive signoff on part 3b is sufficient. This must be signed by the merchant. Engaging a QSA will be above and beyond their requirement and only done if they require assistance in filling their SAQ. Therefore, using a QSA is entirely optional and based on the discretion of the merchant.

This goes a long way in saying the same thing that has always been said. The logic I would argue here is, if your industry is made up thousands of merchants, how do we build a meaningful program to get all these merchants compliant? If QSAs are supposed to validate all the evidences, how much bottleneck will there be?

This is also inline with the famous PCI-DSS myth document at https://www.pcisecuritystandards.org/pdfs/pciscc_ten_common_myths.pdf. In Myth 6:

Myth 6 – PCI requires us to hire a Qualified Security Assessor
Because most large merchants have complex IT environments, many hire a QSA to glean their specialized value for on-site security assessments required by PCI DSS. The QSA also makes it easier to develop and get approval for a compensating control. However, PCI DSS provides the option of doing an internal assessment with an officer sign-off if your acquirer and/or merchant bank agrees. Mid-sized and smaller merchants may use the Self-Assessment Questionnaire found on the PCI SSC Web site to assess themselves.

Now, I know, there are so-called ‘merchant programs’ out there run by a few QSAs. I’ve spoken to many merchants who deem themselves compliant just because an ASV ran a scan on their external IP address and gave them a ‘certificate’ of compliance (which is not even a recognised document by PCI-SSC!).  If anything, it just makes the merchant falsely complacent and gives PCI a bad name and a bad rep as an on-paper compliance but practically as useful as ice is to eskimoes.

The crux of the matter isn’t whether QSAs need to be involved or not. It would be super if they can get involved, but the matter is cost and time. QSAs programs are not cheap, and also, how much work do they actually do for the client? The counter argument is, if QSAs are not involved, what then? You get a bunch of executives just signing off they have a firewall when in their mind they are thinking, “Man, Which wall am I going to have to set on fire to comply to this stupid request?”. It’s not a knock on their intelligence, but really, a lot of merchants are really good in doing whatever they are doing and they don’t exactly have a CIO to standby to interpret all the requirements of PCI-DSS for them. And PCI, despite its oftentimes banal requirements, is a compliance requiring a lot of technical understanding.

How do we solve this? Awareness.

The SAQs reason for existence serves simply as a baseline document and puts the onus on the merchant to ensure they have the proper security in place. A lot of merchants are not aware of this obligation. The moment they sign off that document, they are saying, I am taking responsibility over this document. I verify and validate this as true. If it’s not…well. If it comes to any breaches or anything, then the merchant takes responsibility.

If they are fully aware of their responsibility, then getting help is likely required. But now, there is no need for a formal QSA to get involved. If you can, then do so as QSAs do theoretically should have more experience in PCI – but consultants, or advisors can take this role. And there are many reasons why it might turn out better this way which I will explore in my next few articles.

b) All Travel Agents need to engage ASV to do their security scans

Man. This is probably the most misunderstood requirement of all time. All time. 100s of merchants have come to us proudly saying their ASV scan proves their PCI compliance. No, it doesn’t. The ASV scan is just one of many requirements you need to go through. It’s like you dressing for work and wearing only your shoes and nothing else and go to work and say, “Hey, I am all dressed!”. Um. No.

And while ASV is important, we have seen our fair share of trigger happy ASVs being done for travel agencies. Oh, you have a website? ASV! Oh, you have an internet facing IP and router? ASV!

Come on. We recently adviced one client who was having trouble remediating an issue on their website. I asked them, wow, for a small company doing internet transactions, its a big deal. And they went like, “What in the good name of **** are you talking about?” And they explained they just had a corporate website and were asked to do a scan. I went and look, and aside from the site looking like it had been designed by a 15 year old drinking too much mountain dew, it serviced no credit card transactions at all. They don’t even have any systems doing that. They just do EDC terminals that connect directly to the bank and completely isolated. So why the scan?

Because we were told, they said.

And so I drafted an email for them and told them to send it over to their QSA (they are level 4 by the way) and the response came back, “Oh thanks man, they told us there is no need to scan anymore! Yay!”.

The problem remains. How many merchants are scanning their completely static websites and receiving a certificate of compliance and pronouncing they are PCI ‘certified’? Is it the ASV or QSA’s problem? No. PCI clearly states that it is the merchant (or scan customers) who ‘defines the scope of the scan’, so merchants are taking a fair bit of the burden if the ASV is done incorrectly. ASV scans are needed if your site does credit card acceptance (SAQ A-EP). It’s also needed on any external IPs you might have if these are transmitting card information (SAQ B-IP, SAQ C). SAQ A, B and C-VT has no scan requirements listed. A lot of clients could possibly fall under the SAQ B and possibly SAQ C-VT, so ASV scans can be further avoided.

c) All Travel Agents will be fined XYZ amount for non-compliance

Now, this might be true but IATA hasn’t really come out to say anything. Frankly I will be very surprised if there is such a requirement. Basically, IATA is just saying, if you don’t become compliant, don’t connect to us. If you don’t connect to us, then you can’t issue tickets. This is a worse threat than being fined. So they don’t have to be overbearing to impose such a condition AND impose a fine for clients who are non compliant. Because technically, if you are non compliant, you are not connected to IATA. If you are not connected to IATA, what are they fining you for?

smartmurphy

d) PCI-DSS is applicable to all Travel Agents even those without credit card acceptance and transactions

OK. I am not sure whether there will be such agencies or not, meaning there is ZERO card acceptance or processing or storage or transmission in your merchant environment. Now do note, even e-commerce when you outsource your ENTIRE payment processing, the fact that you have the credit card payment option on your website puts you in need of compliance. For merchants that do not have any facility whatsoever (either card present or card-non-present), then technically, PCI-DSS should not apply. I say technically. Because if you are connecting to IATA’s processor (BSP) then even if you make zero or a million transactions, the risk is still there. So yes again IATA as the big boss of BSP has the right to ask for compliance from agencies with zero credit card transactions. In this case, my suggestion is to write to IATA  and see what is the next step. I can’t imagine any merchant business now not catering to credit/debit card payment but, wait. OK, my neighbourhood barber actually told me they only accept cash only, or barter trade my iphone for 2 years supply of haircut. So yeah, why not. But really, if no credit/debit card payment is an option and you regularly settle through agency credit or carrying a pile of cash, you technically can ask IATA what’s the next step.

In summary, we are not saying that there is some sort of conspiracy theory going on where QSAs are trying to pull a fast one on customers and creating F.U.D in the industry. After all, we ourselves have been certifying clients for 7 plus years already. But what we need to understand is that wrong information could be worse than no information. We need to get the right information out there so that merchants can make informed decisions. If they want QSAs, then ok all the better. If they prefer in house or specialised consultants, then OK. If they decide to do the hokey pokey instead of PCI compliance, then hey, that’s an informed decision on their side.

So, let’s get this awareness out. Travel agencies have about 10 months to get compliant. It’s not crunch time yet. This is like the start of the 3rd quarter in basketball. Important, but not Michael Jordan clutch time.

If you need more information on PCI-DSS applicability in your merchant business, drop us an email at pcidss@pkfmalaysia.com. We’ll get in touch with you ASAP.

The SAQ Bs and how they apply to you

March 31, 2017 / / 0 Comments

pci-compliance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No, of course not.

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

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

Cheers for now!

PCI-DSS Evidences: Your Type of Compliance

February 25, 2017 / / 0 Comments

pci-compliance

Since our last post, we have received some queries on how do we get PCI-DSS started. A majority of our clients are doing Level 1 Certification – this is where we come in and do a gap assessment, determine scope and then remediate and certify. However, lately we have been seeing more and more clients looking to do PCI-DSS on their own.

The question is: Can they?

Well – as with many questions for PCI-DSS, the answer is: it depends.

You see, the journey to PCI-DSS is different for different companies. Some need to go through the whole road. Some goes through just a little. Some need a third party to audit, some can do their own assessment…so while the standard is ONE, the ways to achieve it is MANY.

Now, enough of the philosophical babbling. Simply put: if you are doing PCI-DSS, you simply have 3 available options:

a) Third Party Certification

b) Validated Self Assessment Questionnaire (SAQ)

c) Self Signed Self Assessment Questionnaire (SAQ)

That’s it. You will fall into one of these buckets. If you fall under b) or c), you will then further have to wade through the types of SAQs: A, A-EP, B, B-IP, C, C-VT, D-SP, D-Mer, P2PE. Yes. They have a lot. But in general, your consultant or QSA should be able to tell you which one is right for your business.

Now back to the buckets. What’s a third party? No, it’s not literally a third party that you go to after your graduation and you are getting smashed. In audit terms, there are 3 kinds of audit – first party which is where internal auditors of the company audit themselves. Second Party which is where an external company with ties to the auditee company audits the auditee company – for whatever reason. It could be a supplier audit, it could be a due diligence audit before takeover, it could be a regulator auditing its regulatee etc. Finally a third party is a completely independent organisation auditing the company.

So the first bucket is a third party certification. This is where an external company called a Qualified Security Assessor (QSA) assesses your company and provide a Report on Compliance. This is where they will ask you to do a gap assessment, assist you through the ‘remediation’ period, and do the certification. What a lot of people don’t know is that actually, Merchant Level 1 also has an option to do a first party audit. This means they need an ISA (Internal Security Assessor) in their organisation who is able to sign off on the ROC. Of course, getting an ISA certified is another story, and in most cases, many just take the QSA route.

The second bucket is a Validated SAQ. This will not apply to Level 1 Merchants or Level 1 Service providers, and this is available for Service Providers Level 2 or Merchants Level 2 and below. Basically this means that theoretically, you can complete the SAQ that is applicable to your company and sign off and you are ‘compliant’. This also means any Tom, Dick and Harry who thinks that a firewall constitute setting an actual office wall on fire, can sign off on 1.1.4 (a) which asks if a firewall is implemented in your company. Seriously though. That’s why Mastercard has this caveat:

“Effective 30 June 2012, Level 2 merchants that choose to complete an annual self-assessment questionnaire must ensure that staff engaged in the self-assessment attend PCI SSC ISA Training and pass the associated accreditation program annually in order to continue the option of self-assessment for compliance validation. Alternatively, Level 2 merchants may, at their own discretion, complete an annual onsite assessment conducted by a PCI SSC approved Qualified Security Assessor (QSA) rather than complete an annual self-assessment questionnaire.”

Many, including myself, find this caveat extremely frustrating. To cut the long story short, Mastercard is simply saying for all Level 2 merchants you have 2 routes:

a) Do the Level 1 route. Get a QSA

b) Do your SAQ, but get the staff ‘engaged in the self assessment’ to be ISA certified. Now the first confusion is staff engaged in self assessment does not mean everyone involved in the audit. It basically means the one doing the assessment in behalf of the organisation and signing off at the AoC (Attestation of Compliance) of the SAQ. Whew! But still, now you need to get an ISA. It’s not cheap! And it’s also, to me, a really silly certification, but one that makes total Sen$e to the PCI-SSC.

In theory, option b) above is correctly still called ‘Self Assessment’ as it is still a first party audit in that sense.

Now the last bucket therefore is the truest first party audit. This usually applies to only Level 3 or Level 4 merchant, but sometimes we still find this existing in Level 2 Service Provider. Where the management say, “Screw it, let me sign it off and I don’t need any other signature on this” and the bank, customer or card scheme accepts it.

So this is the first step of your compliance – find out your type. Because you could be overdoing it (Level 3 Merchant doing a ROC Certification) or you could be underdoing it (Level 1 Service Provider doing an SAQ D). If you overdo it, it’s fine from PCI-SSC perspective, but your boss/stakeholders/board/customers might not be too happy when you have spent half the company’s budget and 8 months on the PCI program doing a full Level 1 RoC on all the 340++ subrequirements – and the vacation trainee points out that you only have to do a self signed SAQ A which takes about 1 day to complete. If you under-do it, likewise, you might be in an awkward position to explain to someone that your SAQ D-SP is not enough to convince your acquirer to start connecting to them, as they need a QSA signed ROC.

So how do we know?

Well – the easiest is to really, ask the ones who are pushing you for PCI? If you get the answer : “Ah, just get compliant!”, then you have more leeway to understand your business, and you might be tempted to just go for the easy way out. Don’t! Assess your business – if you are a merchant, then follow the number of transactions to determine which level you are at. Easy remembering:= 6 million and above for level 1, 1 – 6 million for level 2 and the rest level 3 and 4. I don’t differentiate 3 and 4 because there doesn’t seem to be a squat a difference to what you are supposed to do. It’s the same, they just classify it differently where level 3 is focused on e-commerce and level 4 is more on traditional transactions.

For service provider, it’s simpler. Level 1 is above 300,000 volume of card transactions and level 2 is below. There is no other levels for Service Providers. There is also only SAQ D available for Service Providers so you don’t need to think so much.

The next round, we will explore deeper into how do we get our scoping questions sorted out.

 

PCI-DSS and the Retailer Conundrum

October 18, 2016 / / 0 Comments

pci-compliance

Over the past six years, we have had our share of PCI-DSS experiences across different verticals. Unlike other standards, companies each have their own unique PCI journey to compliance, due to the type of business they have in regards to storing, processing and transmitting credit card information.

Payment gateways usually have a challenge in securing stored credit card information. Here we identify the areas and types of storage and the option for securing this data – usually with encryption. The good news is that most payment gateways do not have many physical locations in scope, so we are generally looking at maybe one main site and one DR site, or two at most. This helps significantly.

BPOs or outsourced companies are another animal altogether. These are generally multi site projects, with various types of interactions with credit card information – usually phone, or MOTO (mail order, telephone order).

Banks are probably the top of the food chain in terms of complexity. Not only do they have hundreds of sites which are in scope, they also have storage of card data all over, as well as ATMs in scope in different branches.

Somewhere in between, we have the retailers. Not the e-commerce only retailers but traditional retailers. And here, in this layer of retailers, choke full of credit card and personal information, the hackers ply their trade.

Target (ironically the target of one of the largest information heist in history), Neiman Marcus, Home Depot, PF Chang’s, even Wendy’s – these were all hit with credit card breaches, resulting in millions upon millions of credit card information siphoned off into the jungles of the Dark Web. Why?

In general, hackers view Retailers (and hospitals) as easy targets. One example is where hackers ship a box full of new POS (point of sales) devices to the retailer outlets with a note from the Chief Operating Officer that these are devices to be installed and used from here on due to security or upgrade concerns – and once installed, these POS devices start hijacking credit card information in behalf of the hackers. A similar vector of attack is to infect the POS updates with malware and once the malware (like BlackPOS) is installed, it’s open season.

For the Target case, 40 million credit/debit cards were lost through POS. The reality was that the hackers breached Target’s main network first and accessed the database. Thanks to PCI, their database were encrypted and instead of hacking the keys, the hackers decided to go to the source (the POS devices). If the data in the databases was not encrypted, the damage would have been much, much more (we are looking at 70+ million).

PCI has stringent considerations for the security of POS, including software and hardware checks, as well as physical location checks. This is why retailers going through PCI is facing such a hard time. Some of the main issues are:

a) Retailers are underfitted for security. I am not sure if there is such a word underfitted – but in most cases, budgetary concerns are usually the reason why there is so little investments in security systems for retailers. The focus is on efficient transactions, and often efficiency and security are strange bedfellows. While millions are spent on customer relationship management tools, and systems to predict customer buying habits and big data solution, the backend hardware are outdated – we have seen XP and its variants still going strong in some retailers.

b) Inventory is haphazard. Some retailers grow, and in growing they do not keep stock of their internal inventory of systems. Some customers we go into have a very rudimentary excel sheet dated back to 2009 for their systems inventory, that is inherited several times by different IT administrators who seem to be going in and out of the company.

c) Like b, IT admin staff in retailers generally do not stay long. While some of the have good intentions in implementing certain structures and projects, these get lost along the way as new staff replaces them.

d) Location, location, location. In security, more locations, more problems. We see main branches carrying out good security practices but replicating along 85 branches in the country is a different story. In most attacks, hackers might infiltrate through a smaller branch with less focus on security and less education on preventing breaches.

e) Technical considerations. Most retailers we see have rudimentary effort in securing the network. Perimeter wise, we have seen a conglomerate of firewalls from yesteryears that no longer have any updates – and a plethora of free security software that does not have any auto-updates on signatures and in some cases, are spyware themselves. The network itself is usually flat (because of efficiency) and this brings in a huge amount of scope when your database is next to your ERP and accounting system that is being connected by a 100 of junior staffs with their desktops running XP.

There are many reasons why retailers are now prime target for PCI breaches. How do we avoid these breaches?

Well, you can’t. You can deter, but you cannot fully remove the risk of breaches. PCI helps a lot but as of now, there is no silver bullet to resolve security completely, except to unplug everything and set up a pen and paper store like back in the Wild West. But where PCI comes in – physical location security, POS security, network and database security – these are all critical areas where retailers can start with. Some first steps for retailers:

– Set up a proper inventory of systems: In my University in Western Australia, there is a huge engraving on one of the main halls: KNOW THYSELF. We generally use that advice a fair bit especially when we have had a fair bit of alcohol in the Beer Parties, while stumbling back to our dorms. But in order to know what we are up against, we need a proper inventory of what we have and set about securing these systems.

– Secure the perimeter: Firewalls and IDS/IPS are important here to ensure that attacks are sorted out and abnormal traffic behaviour is properly caught.

– Segment the network: While Segmenting is not for everyone, the security benefit here is considerable. Databases which are critical systems should not reside on the same network as your junior associate’s desktop, especially one who spends half his/her time downloading music or watching youtube. An analogy here is simple: when you put a healthy person in a room with a sick person, the sick person doesn’t get well, the healthy person gets sick.

–  Eyes on everything: We can’t iterate enough how important monitoring is in retailers. A good security information and event monitoring (SIEM) system is KEY to their security. Because of the lack of security personnel, the SIEM takes away a lot of these manual responsibility in tracking down strange and abnormal events. If a SIEM was set up properly in the Target case, they would have realised that one of their printer spooler device was sending out FTP packets out from the network into another system in the internet.

– Test, test and retest: Test your systems for vulnerabilities. You don’t need to spend truckloads on penetration testing if you don’t want to. Scanning using a Nessus scanner or even OpenVas will be useful as a first step. If a system is not patched, patch it. If you are still using Windows XP, seriously consider upgrading it.

– Finally, educate the users: While this has become a mantra for consultants and trainers, it’s still true. The weakest link in the security killchain is between the keyboard and chair. That’s the person. Security awareness training is key. While firewalls, email filters and Intrusion detection systems can go a long way, the security infrastructure is compromised by one executive clicking on an email attachment with the word: “Watch this Cat play the piano!”. Boom. Welcome malware, welcome ransomware, welcome sleepless nights for IT.

In summary, PCI-DSS establishes good and practical security practices for retailers. It might not be cheap, but once you have been hit by a ransomware or have your data pilfered, the fallout costs would be even more significant. For retailers looking to start off your PCI journey, or who need assistance on your ongoing one, please email us at pcidss@pkfmalaysia.com and we will get back to you immediately.

The Obfuscation of PCI Standards

August 14, 2016 / / 0 Comments

pci-compliance

When you go through the PCI-DSS standard, while in most part, the sections are clear, there are some that just annoys the heck out of me, for good reasons.

Stateful inspection and Anti-spoofing in firewalls – I know these are useful features, but it is extremely rare these days to encounter clients going for PCI-DSS that own firewalls without these capabilities inbuilt. Even the humble ScreenOS running on your tiny SGs (Juniper) are enabled by default. While this isn’t an issue, we’ve faced vexing times when our clients are sometimes asked by their QSA, to show the firewall rules that prove that Stateful inspection and anti-spoofing is turned on. We have to come in and explain to them that its already enabled by default, and they insist on us testing and showing them traffic captures. Sometimes, I just show them the manual and entitle my email “RTFM: Stateful Inspection was first introduced in 1994.” You would think that PCI would do something better than to ask this question.

AntiVirus and AntiMalware – the researchers at Imperva, a couple of years back, did a study of effectiveness of antiviruses.They collected 82 new computer viruses and ran the malware against antiviruses from some of the largest companies like Symantec, Kaspersky, McAfee. The results: initial threat detection rate was 5 percent. That’s detection. This means 95% of malware is undetected. I don’t know how strong this hypothesis is, but frankly, we have known for years antiviruses, while there are limited uses, presents to us a false sense of security. Just because the antivirus says, “ALL IS SECURED” doesn’t really mean anything. The annoyance here is not that PCI has antivirus as part of their controls, they dedicated an entire requirement to it. It’s not effective – move on!

Confusion of application testing – Requirement 6.6 states:

For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

a) Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes

b) Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.

Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.

Now, we need to clarify this because this is obfuscation. Note the nice caveat they put into 11.2. Now, if you go to 11.2, you get a whole bunch of requirements for vulnerability scans, quarterly ASV etc.This is understood, right

So the above, you would surmise this: if I have a WAF (web application firewall), I do not need to do any web applications review, correct? What IS a web application review anyway? In a lot of instance, QSA will interpret it as web application testing, covering OWASP top 10. In pentest world this is called WEB APP PENTEST. This tests issues like cross site scripting, validation etc. You can find more here

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

A web app PT can set you back around RM10 – 25K depending on your web app and the provider. I’ve seen web applications go into the RM50 – 80K regions before for massive applications, but in general for a web application payment system, you would get that range (unless the provider is looking to rip you off, in which case I suggest you give us a buzz).

So if you have 10 – 20 Web App, that would set you back a mile, so the suggestion is to “Let’s invest in WAF”, where you pay a license and every year you don’t have that WEB APPLICATION testing headache siting on your books. In the long run, it makes more sense if you have a lot of web applications to test.

Now, here is the PCI problem.

Requirement 11.3 – Implement a methodology for penetration testing that includes the following:

blah blah blah

 – Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5

Unfortunately the presence of 11.3 renders the earlier requirement choice useless, because now QSA interprets at despite having invested in WAF, they are still insisting on getting 11.3 passed, which requires this application layer PT!

My question to the PCI-SSC, why don’t you include this 11.3 caveat in the earlier 6.6 requirement instead of the useless 11.2 caveat which anyone knows how to read? And if my interpretation is wrong, I am going to war against some of these QSAs because they basically said, it’s nice to have WAF, but you still need to do App PT. In fact, one of them actually said: “Well, the advantage is that you are more secure.” Yes – but our client’s goal was to pass PCI. If they wanted financial modelling and investment advise from you, they would ask it, if not, just do our job and interpret the standards properly! Will someone from PCI-SSC actually clarify this because I’ve talked to some QSAs on either side of this opinion – some say WAF OR APP PT, some say, APP PT regardless of WAF.

To be safe – get your QSA to interpret this before making a decision to invest in WAF, because this is a major roadblock in a lot of cases we are in.

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑