PKF AvantEdge

Page 18 of 40

PCI-DSS – So Why Aren’t We QSA?

June 29, 2017 / / 0 Comments

We have faced this question many times before over the course of 7 years working on PCI-DSS in this region. Many customers have asked us, why haven’t we become QSA (Qualified Security Assessor), considering the amount of PCI work we have been involved in, as well as the PCI-DSS knowledge that we are having?

The answer is simply – we choose not to.

Don’t get me wrong. QSAs certainly have their place in our world, and the fact that we work closely with one, as well as representing them in our country states the importance of having a solid auditing foundation in every project that we go in.

But here are the main reasons why we have decided that being a QSA would hinder us, rather than assist us:

a) Conflict of Interest

This is a huge reason why we maintain our consulting and implementation practice, while choosing not to become an auditor. Our business is not just PCI-DSS. We have a huge chunk of consulting practices in ISMS (ISO27001), training as well as upcoming compliances like SOC1,2, Personal Data Protection Act etc. QSAs and the question conflict of interest has been around for a long time. It is also addressed in Provision 2.2.2 in the PCI-DSS validation requirements for QSA

The QSA must describe the company’s practices to maintain and assure auditor independence, including, but not limited to, practices, organizational structure/separation, and employee education in place to prevent conflicts of
interest in a variety of scenarios, such as the following:

The QSA customer uses products or applications developed or manufactured by the QSA company.
The QSA customer uses products or applications managed or configured by the QSA company.
The description must include details with respect to compliance with the Specified Independence Requirements called out in Section 2.1 above.

The thing is, we do a fair bit of work for our clients – including development of policies, reviewing their security, implementing policies and logging products etc – because we are good at it. Before PCI, we were operational guys, guiding SOCs and NOCs, troubleshooting routers and switches, deploying firewalls and SIEMs etc. We weren’t bred as auditors from the start, so most of us have an inherent instinct to just go in and get the job done for our clients. Now, the problem is once we do wear the auditor’s hat, there are a lot of grey areas. We make this demarcation very distinct in our IT general Controls audit – the moment we implement something for our client, we cannot audit or assess it. We can’t audit our own work. This is not just for PCI, this goes across the board for anything we do.

PCI gets around this by ensuring that the QSA has proper internal segregation – meaning it is generally accepted that policies be put into place that mandate a separation of duties between QSA Auditors and QSAs, or other individuals within a QSA certified company who provide remediation support. So generally, any QSA company should have its consulting group separated from its audit group. Now, PCI-SSC doesn’t specifically state that QSA Companies cannot provide remediative services – after all, if the QSAs know what it takes to pass PCI-DSS wouldn’t they be the best source of knowledge to clients after all (and they often are) – but QSAs need to be very aware that they cannot push their products or services as the only option for compliance. Customers must have the options on the table, the knowledge that there are other options in order for them to make informed decisions.

It’s made trickier due to our DNA as a CPA company. PKF wasn’t born an IT company or a security firm – our roots are in accounting and auditing, and most of our partners hail from Big 4 (PWC, KPMG, EY, Deloitte) and even ex-AA. In fact, I am the only non-audit guy in the partner table and my jokes are often not understood. Due to this background, inherently we have this default position whereby if there are any grey areas, it’s safer to err on the side of caution and not do it unless proper conditions are clear. So while in PCI the arrangement of QSACs providing remediation works are allowed with certain conditions, the very memory of how an 89 year old accounting firm had to surrender its CPA license due to the largest auditing scandal in history still lives on in our industry.

b) We Hate Auditing

Well not really. We are auditors after all! We do have a fair bit of audit and assessments as part of our work. But boy, have you ever been in an audit as an auditor? Everyone just hates you. I remember auditing for a very large BPO company for their IT general controls and software development. The head of software looked like he was going to put live electric eels down our pants halfway through our interview. And we weren’t even antagonistic. Asking for documentation of his software practices was like asking for the what Edward Snowden had. Another company had their head of operations sit with us in the room for 1 hour and throughout the entire session, he refused to answer anything without legal in the same room. It was like we were interrogating him for murder instead of just asking if he had a change management procedure. It’s not all like this of course, we do have excellent clients who are on the same page as us mostly and we do feel the whole auditing process is enriching to our professional lives. Really. Even with that, the follow up audits, the report writing and quality assurance process etc, the evidence gathering and formatting into the proper report, the cycle of obtaining management comments etc. It’s just very taxing on the guys. Report writing takes up a chunk. And guess what – in PCI, a normal Report on Compliance (ROC) for level 1 onsite assessments can stretch up to a thousand pages. Yes. A. Thousand. Or more. It’s like asking us to become Leo Tolstoy and start writing War and Peace every single assignment.

c) Cost vs Benefit

Being a QSA is a great achievement. But there is a huge outlay for the company as well. Not only there are fees you need to pay to become QSA, there are fees you need to pay to operate in particular regions as well. Then you have training fees for your QSAs, yearly maintenance etc. It’s a lot of money to run a QSA company and because of that, you need to get your bacon from all over. For instance, if you have license in Asia-Pacific, then you probably want to tackle the China market. Or else, focus on the SEA region and get your QSAs to fly between countries. Focusing on a single country isn’t going to make up for the cost of maintaining your QSA company, at least from our point of view and our brief calculations. Now because of this, we need to fan out. To fan out, we need to expand the company. To expand, we need to hire and get jobs. I’m all for it, but its a matter of being a big fish in a small pond or a small fish in a big pond. As of this moment, our strategy is not to overstretch ourselves too much and to establish ourselves with the clients we have. It’s not as if PKF is in a hurry to IPO or go anywhere. We’re here for the long run, and in Standard Chartered slogan: We are here for good.

d) Stretching is not fun

We tried it before.

As in not physically, but in terms of a company. We grew our tiny little professional services firm to 16 people once upon a time, with dedicated R&D and Project Management group only to get kicked in the butt by a guy called “No Jobs”. We grew so fast, we didn’t get the sales in to keep up and after the initial projects were done, we were left with a lot of people on the bench playing Pokemon-go. We stretched. But we over did it. It’s not to say we are now not being ambitious. We still are, but we need to be realistic with our goals. If we target to get 10 – 15 tier one customers to keep our benefit more than our cost – how many QSAs do we need to do that? After that, how many consultants to do the remediation work?

Additionally, even if we had 10 QSAs for instance, these guys will be scrambling all over the region doing audits. They won’t have time for operational work. They won’t have time for consulting or providing technical services. They will either be auditing a customer, or they will be on a plane somewhere, or they will be writing or reviewing one of those 1000 pages tomes called the ROC.

e) We Want to Stick with our Customers

The bottom line is this. If we hadn’t found a trusted QSA whom we can work with and who are mostly on the same page as us, we would have gone and gotten our QSA ourselves and went another direction. I think we have enough legs and enough entrenchment in the region and global to do that. But we found a great partner. We found a QSA that we could work with and didn’t do any BS work. We found a QSA that had similar philosophies (although we are still working in synching our concept of deadlines, but hey, that’s like marriage, ain’t it) – and for 7 years, we have been working great together. They like what we do, that they can hands off a lot of the remediation advisory to us and don’t have to get on conference calls all the time or have to fly in and out of our client’s offices for weekly meetings. We like that we can work with our customer, look after our client’s interest and not worry to much about whether we are overstepping our limits as advisors or consultants versus auditors. We can stick with our customers and give them all we have. We can spend a whole day in our customer’s premise working with them without worrying that we need to head off for an audit for 2 weeks in Timbaktu. We don’t have to fly in and out of countries or tell our clients we can only meet 2 weeks later. If you want us within 24 hours, we will have someone there. Best of all, it’s very clear that once auditing starts, we are sitting on the side of our client, and ensuring that our client have what it takes to pass PCI-DSS.

Of course, this is simply our view at this current time. We are well aware of the flowing and ebbing of different forces in our industry and it might come a time whereby this model doesn’t work anymore. But for now, honestly, we just want to get cracking at troubleshooting your Cisco ASA as opposed to writing a War and Peace Novel. Drop us a note at pcidss@pkfmalaysia.com for more information!

IATA PCI-DSS: Who is doing what?

June 9, 2017 / / 0 Comments

pci-compliance

We have been receiving a ton of emails and inquiries lately ever since we started marketing our services for PCI-DSS to travel agencies. It has to be noted that some of these travel agencies were our clients to begin with. PKF has a very large set of customers because we do the entire end to end corporate services. We are not just one technology advisory firm. We have tax advisory, business advisory, internal audit, external audit, outsourced, accounting, corporate finance, forensics accounting etc. So over the course of 20+ years we have amassed a ton of clients and many of them are travel agencies, whether in technology group or in others. This is where our main queries stem from. Existing travel agencies are querying us and in turn they are letting others know about us, so much so that we are now compiling an FAQ to address all questions being thrown at us on PCI-DSS.

One common question we get asked is: WHO is initiating this PCI-DSS?? We even get accused of being the ones initiating this PCI-DSS on them and planting a deadline of March 2018 for them.

So let’s get the story here straight. For this, it is necessary to go from the beginning to the brief history of PCI.

a)  PCI-DSS began its life in 2004 but only in 2006, PCI Council was formed to govern this standard. The council is now made out of card brands Mastercard, Visa, Amex, JCB and Discover/Diners. The purpose was to ensure there was a standard way that merchants/service providers can secure their credit card interacting systems to, instead of to each individual card brand’s compliance. It’s a good thing. Basically the whole idea is to ensure the whole ecosystem where credit/debit card is used/processed/stored/transmitted is secured.

b) IATA’s story probably began back in 2015 when, according to GDS Amadeus, VISA Europe issued a deadline to acquiring banks using its network that all airline merchants should be PCI-DSS compliant by 31 December 2017. So the airlines got into a huff and took a look at their processes, which is like any other merchant – they have their acquiring bank to do the authorisation, clearing and settlement. So far ok.

c) However, the airlines had one problem: Indirect distribution channel. This is where airline tickets are distributed via travel agents, either through walkin, MOTO or internet. Travel agents use a GLOBAL DISTRIBUTION SYSTEM (GDS) that link to airlines to check for ticket and also to financial institutions for authorisation. And these finally link to IATA. Why? IATA has the Bank Settlement Plan (BSP) to – yup you got it – facilitate the clearing and settlement. BSP allows many travel agents to connect to many airlines, allowing a one stop shop to ensure everyone gets what they want, instead of travel agents separately dealing with airlines and vice versa. It’s orderly and it helps the industry.

d) However, the BSP, due to its connectivity to the Airlines now needs to ensure its downstream connecting parties are also PCI-DSS. Cue, travel agents and this is where IATA tells the travel agents, look, get your act together because the airlines need to be certified, so we need to be compliant, so you need to be compliant.

So in conclusion, it is IATA initiating it to the agencies – because there is an upstream push for them to be compliant. It’s common as well – many times payment gateways are asked to be compliant by their bank – we hardly see any entity embarking on PCI-DSS just because they feel that it’s the best thing to do for them. But the overall initiator of PCI still remains the card brands – whether it is VISA, Mastercard or Amex etc.

Now the question here is this – because IATA is considered a processor (with their BSP), they are enforcing a deadline of March 2018. At the same time, they also need to provide a way for agencies to submit the compliance document.

It’s a bit confusing here, because Agencies are also merchants in their own sense. They also have their own channels to collect payments, and some payments are made directly to their merchant account, and they settle with IATA through cheque/cash/bank in etc, not via card. Everytime a card is entered in the BSP, the agency is acting in behalf of the airlines using the airlines merchant ID. Everytime a card is used in the merchant’s own environment such as POS, EDC or Internet, the agent is the merchant, and they do authorisation, settlement etc through their own bank. IATA/BSP is not involved in the credit card flow in this case.

However, because IATA is requesting PCI to be adopted by agencies, agencies also need to look into their other channels that do not involve IATA! So imagine, an agency does their SAQ C/C-VT and sends it over to IATA, but to cover their EDC or terminal business, they do an SAQ B – who on earth do they send this over to? Well they send it over to their own acquiring bank. Their bank asks: Hey, what the heck is this? Well, it’s our PCI Compliant SAQ/AoC, Mr Bank. And Mr Bank is happy but somewhat confused and asks: Why are you doing it anyway? I didn’t ask you to do it yet because you only do 1 – 2 transactions with us. (Please note, even if it’s 1 – 2 transactions, you are still considered a Level 4 merchant, but most banks are ensuring their large volume merchants are compliant first). So therefore, agencies have two upstream processors to send their PCI documents to – IATA (for IATA channel) and their own bank, for others.

In the next post, we will explore on the validation requirements and why its so important to know what validation requirements apply to you and how. Do drop us a note at pcidss@pkfmalaysia.com. We are having a bunch of queries, but we will answer you ASAP.

PCI-DSS and how we messed up the scope

June 4, 2017 / / 0 Comments

pci-compliance

Reflecting on challenges of a recent PCI-DSS project for a client and the key learning points for an effective implementation

People team challenges – having a team to champion the project

When we started the PCI project, we were faced with multiple changes in the client’s project manager and so the project was like a car unable to start on a cold morning (for those old enough to remember there were such cars back in the 80s!).

Eventually, by working with the client, the musical chairs stopped and we had a stable project team to champion the PCI-DSS project.

The importance of the scope

By then, so many changes had been made in the systems and people that we were asked to rescope the work.  Now, scope in any PCI-DSS project is absolute key. If you start wrongly, you will definitely go down the rabbit hole and never come out.

(Mis)Understanding the process flows

The client described how the credit card data was fed into their system through the credit card terminals connected to their POS systems in their nationwide store network.

Initially, we were quite surprised that credit card data would be flowing back into the retailer’s system so they could do their reconciliation.  Our experience suggested that retailers would simply transit credit card information through the credit card terminals to the acquiring bank and then receive back a transaction ID or approval code.

Further enquiries got the same answer and we were assured that the information would be ‘encrypted’ and stored in ‘encrypted’ form.

On the basis of their answers, the client expected to undergo an onerous Self-Assessment Questionnaire, consisting of over 320++ questions!

Managing information

Our team took their word for it, and began the project by asking them to draw out their process flows so we could assist them in scoping their systems and completing an asset inventory (a key part of the PCI-DSS programme) together.

And this was where things got a little messy.

Because they insisted the credit card terminals that were interacting with the cards belonged to the acquiring bank and they had no influence over it, they did not have an asset list.

Also, with a significant number of branches it was difficult to provide an asset list to cover all relevant hardware and software across the portfolio.

The pushback caused the project to once again grind to a halt. Without a scope confirmation, we could not start any PCI implementation for them, in case we over-committed or under-committed on the plan.

Benefits of documenting process flows

The project was being worked out at management level for a long time before it was brought up to the director level, but once it did, things began to move.

We decided to go on the ground to a few of the store locations to really see what was going on.

What we found out surprised everyone:

Credit card information indeed never flowed back into the client’s system!

Getting the terminology right

The so-called ‘encrypted’ credit card information from the bank that was supposedly sent back to the client after the authorization, was in fact, ‘truncated’, not ‘encrypted’.

Apparently, the client had thought these were the same thing.

In PCI speak, encrypt means to protect credit card details by making the information unreadable with a key. The main reason is that there is a need to ‘de-crypt’ the information back again.

Truncation, on the other hand, meant that the card number itself, when sent has already its numbers ‘X’ed out. This is different in a sense that truncated card information is NOT card information because the critical numbers have already been X’ed out, leaving (usually) just first six and last four numbers of the credit card number visible.

Immediately, it was like a light being flipped on.

The team worked hard to optimize the scope by confirming the other flows and observing live transactions take place.

At the end of a 2 day onsite scoping assessment, we concluded that this client was eligible for a much reduced – only around 80 questions – assessment and then by filtering further, we pared down their compliance questions to only 40 reducing the scale of this compliance project by more than 85%.

Key messages

The takeaway here, from our experience would be:

  1. All PCI-DSS assignments require a stable and strong project team – get the right people, in the right place, with the right focus
  2. Understand the client’s terminology and descriptions and then check and check again. Ensure that you start from the best position, and not chasing the wrong end of the stick.
  3. For PCI-DSS merchant compliance it is essential to explore if the client is eligible for any reduction in the scope and don’t just go with the default. The time and cost elements of getting this wrong could be very substantial.
  4. Nothing beats being onsite and to undertake live walkthroughs of the actual processes. In this case, the earlier the better, so the assignment can be properly scoped.  A different set of eyes might be able to unlock the project obstacle – and in our case, it was essential to have the onsite scoping exercise.

Finally, because of these findings, the compliance is now ongoing and finally we are seeing the light at the end of the tunnel.

If you have any queries on your scope or compliance on PCI-DSS, drop us an email at pcidss@pkfmalaysia.com and we will get back to you ASAP.

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.

Tonight, I Wanna Cry

May 14, 2017 / / 0 Comments

There is a country song that goes:

I’ve never been the kind to ever let my feelings show,
And I thought that being strong meant never losin’ your self control
But I’m just drunk enough, to let go of my pain,
To hell with my pride, let it fall like rain, from my eyes,
Tonight I wanna cry.

And cry they did. Almost 75,000 and counting, over 99 countries hit by one of the largest ransomware attacks of all time, “WannaCry” and the other Wanna* variants.

Wannacry was released on the 12th of May 2017. The irony of it all was that we were invited as one of the speakers in a Ransomware event in Putrajaya under Panda Security the day before and we were just warning those in attendance that the next wave of ransomware is due to hit and within 24 hours, bam, we have Wannacry. In Malaysia, there seems to be already infection, thanks to the guys at

https://intel.malwaretech.com/botnet/wcrypt/?t=24h&bid=all

There have been reports of large telecommunication companies, banks and telcos are being affected. Tens of thousands of networks worldwide have been hit and the attacks do not appear to be targeted to any specific region or industry. Once infected, victims are asked to pay approximately $300 by Bitcoin. For the curious, you can check

https://bitref.com/13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94

This means there is around 5.8348 bitcoins paid already to this. Which translates to around RM46,000 paid so far – which isn’t so much if you think the average of ransom payment is around RM10,000 – RM11,000 for other ransoms.

So what is this?

Wannacry is using the file extension .wncry, and it also deletes the Shadow Copies (which is normal for ransomwares, like Locky) which is a technology introduced into the Microsoft platforms as far back as Windows XP and Windows Vista as the Volume Shadow Copy service. This means that even backup copies produced by this service, such as Windows Backup and System Restore will be screwed. That’s mean. Here is the command executed.

cmd.exe /c vssadmin delete shadows /all /quiet & wmic shadowcopy delete & bcdedit /set {default} bootstatuspolicy ignoreallfailures & bcdedit /set {default} recoveryenabled no & wbadmin delete catalog -quiet (PID: 2292)

The following file is also created in the affected systems: @Please_Read_Me@.txt

How it gets in is just like any other ransomware: email either phishing or spear phshing. Basically, don’t click on any email attachments that are suspicious! It’s easier said than done, especially if you see one coming in stating that you are behind in your payments for your credit card. Resist the urge. One of the things to check on email:

The return email – most phishing doesn’t even attempt to spoof their email, and you will get emails coming from strange domains like maaybank or clmbclicks. Bad language is also a hallmark of a phishing email. “All your base are belong to us” type of english. Anyone asking for passwords, or click on a link etc is nonsense. Don’t click on email links. Don’t click on the attachments, above all.

Back to Wannacry. It exploits a known Microsoft Windows vulnerability to spread. This vulnerability was released as part of the Shadow Brokers leaks back in April. It hits the SMB (Server Message Block) – some people pronounce it as SAMBA, which technically is not so correct, as SAMBA is the SMB implementation on Linux. It basically allows the sharing of files and printers in networked environment. Which means, if one gets infected, the infection spreads through network shares even to systems without connectivity to the internet.

Microsoft released a patch for MS17-010 on March 14th 2017. Obviously, a lot of systems – especially those in healthcare still runs on Windows XP. The case has been deemed so serious that Microsoft has taken the step to release patches for systems already dead like XP! This shows how unusually dangerous this ransomware is.

OK, so if you have been hit, what do you do?

Well, you can pay. Around 41 transactions have been made so you could make the number, but don’t expect too much out of it. In fact, we probably do not recommend this course of action. You need to remove Wannacry and there are plenty of sites that gives details on that. The problem with ransomware is not so much of removing it, its a matter of recovering your files. Here’s a site you can check if there is a decryptor available:

https://www.nomoreransom.org/crypto-sheriff.php

Please be careful – some so called ‘decryptors’ are disguised as further malware and gets you a double whammy of sorts, so you need to ensure these are proper tools and not something you download from torrent.

As an advisory to all our clients, especially PCI-DSS here’s what you can do to protect yourself:

a) PATCH

https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

Now we see how important it is to patch your systems. Most PCI clients struggle on this and the examples can come from: Our servers are not connected to the internet, or If I patch, my application breaks. Well, if your application breaks then you need to get a warranty from your developers or get them to upgrade and improve.

b) Backup

While PCI doesn’t really focus much on backup or BCP (after all PCI’s interest is in the confidentiality of credit card and not the availability of your business) – it’s still good practice to backup your system. And not just online as ransomware hits shadow copies firstly – but offline backup and ensure your restoration has been tested. Remember those grandfather-father-son backup scheme you learnt in college and university? Yup, it can be applied.

c) Antivirus and Antimalware Updates

While it’s known Antivirus is missing a chunk of malware out there, it’s still for many systems the last line of defence and most vendors have released protection signatures for the ransomware so get it updated. It’s like having the final militia protecting against an invasion. It will probably not hold out forever, but at least it buys your administrators some time.

d) Remove SMB v1 support

https://support.microsoft.com/en-us/help/2696547/how-to-enable-and-disable-smbv1,-smbv2,-and-smbv3-in-windows-vista,-windows-server-2008,-windows-7,-windows-server-2008-r2,-windows-8,-and-windows-server-2012

Simply, for Windows 8 for instance, you need to run Powershell in administrator mode and then just issue

Set-SmbServerConfiguration -EnableSMB1Protocol $false

to disable SMBv1

e) Network segmentation

While this is helpful, it still doesn’t save everyone. Segmentation helps because it isolates computers. Vector of attacks usually comes into the access network (where end users access) and if you segment this from the critical systems, you will need the malware to traverse through your firewall or a filtering device in between which leads us to:

f) IDS, SIEM, IPS or any protection systems you have!

If you don’t have any IDS, IPS or SIEM deployed in your environment, it’s time you get one and this is a good argument for your business budget. IDS/IPS are usually available features in most firewalls these days, so if you segregate your networks, you can then enable these features and it should detect or prevent malware coming into your critical environment.

SIEM is critical. Security Information and Event Management systems have been around since the dawn of time but most companies avoid these due to costs, ever relying on the good old free syslog services. No, not allowed anymore, as far as PCI is concerned. We need more visibility over these logs, malicious traffic and even outgoing traffic to check if there is any communications with a command and control (C&C) server, which is the normal operations of these ransomware. SIEM these days are also no longer that expensive, with a Gartner SIEM like Alienvault starting off at a little over RM25K to get it up and running. We recently deployed a very large SIEM deployment over AWS cloud and on-premise on a major airlines with a fraction of the cost compared to traditional SIEM deployments.

There you have it. WannaCry is a very serious outbreak and we will be monitoring this system and also making our visits to our clients to give a short talk and description over it. If you have any questions over this, or on PCI-DSS or SIEM, drop us a note at avantedge@pkfmalaysia.com.

Stay safe!

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑