Category: Risk Management (Page 2 of 4)

PCI-DSS and the problem of Email

When we first started with PCI-DSS many years ago, most of our clients were service providers – payment gateways, financial institutions, and two banks. They had their challenges – in some cases, their scope were containable (payment gateways) due to the limitation of locations – and in the bank’s cases, at least they understood the massive headaches they faced in getting their entire environment compliant (with ATMs etc all in scope).

We saw a shift over to service providers OF service providers – hosting companies, Data Centers, BPO, outsourced call centers etc. Their challenges were somewhat different – call centers especially, because of their central hub of connectivity – their telephony system, and another big problem: Email. Email issues in PCI are longstanding and absolutely difficult to resolve – and it reaches to most businesses – travel agencies, hospitality, healthcare, insurance and so on .

When email first came out in the late 60s and early 70s, I can almost imagine how excited the users were. I wasn’t born then. But I recall back in the Uni days, early days when IRC/ICQ first came out, the level of excitement we had in communicating with an actual human being a thousand miles away INSTANTANEOUSLY was so mind numbingly out of this world. Back then, we spend countless hours in the school lab, playing these text based dungeons and dragons online called Multi-User Dungeons or MUDs for short, and completely almost failing all our subjects in the process. But the excitement was there: communication.

In that sense, email is almost half a century old and is still going strong. Primary communications are still through email, for business and personal communications. Email was never built to be secure. In fact, like the wonderfully robust (but now phasing out) SMS, when it was first used, no one imagined it would become the backbone of world communication as it is today. Nobody decided back then: hey, let’s prioritise security! Hey, let’s ensure that nobody can tap into this email of ours and see our messages! Email was like the conversation in the bar. Anyone could be standing around you, or sitting next to you and listening in to your conversation — and it was ok.

Until now, it isn’t.

Well, at least from PCI-DSS perspective.

“Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, SMS, chat, etc.” – Requirement 4.2 (PCI v3.2)

Unfortunately, a lot of business utilises email as the primary channel for PCI information. Hotels we deal with, travel agencies we have worked with – call centers etc – email is sent with card data because of the convenience and the efficiency of the whole process. When we enter these environments and suggest them to look for alternatives to e-mail, we invariably face a force so strong, it’s like hitting the stone wall of Helm’s Deep: Business.

Try as we might, we often end up talking about how we can use email AND pass PCI-DSS.

Now, it’s not impossible. But by the time we are done, we are basically looking at something so extraordinarily difficult or so expensive we invariably end up taking the path of least resistance (and least cost).

But how would you have EMAIL AND PCI-DSS?

First of all, we need to understand that like water, email exist in many forms. Or rather many locations.

First of all, it’s on the endpoints. This is where the email containing card data is sent and received. So, you have data at rest. All endpoints, whether agents or cashiers, or call center workstations are in scope as CDE (card data environment). All endpoints need to have their data encrypted. You could opt for a full disk encryption, folder encryption or simply data encryption: either way, your key needs to be managed appropriately as well. If you allow devices like iPads or phones to access, you are in a world of hurt, because basically it becomes impossible to secure these devices.

The second form is in transmission. Because email isn’t point to point, it hops through multiple relays, and multiple routing points to get to where it needs to be. At any point of the journey, your email could be sniffed, or leaked. Thankfully, many email services like Office 365 is able to encrypt TLS1.2 on transmission. Obviously this helps a lot – but that’s still only on transmission.

The third form is on the interim server(s) – mail servers, relays or anything else in between before the message ends up in the recipient’s mail boxes. Whether you are running your own mailserver or using a separate provider’s, the challenge is the same. How do you ensure that the messages at rest, be it temporary or permanent, are protected?

Pretty Good Privacy (PGP) has been often offered as a solution by kindly QSAs to assist in this matter. The problem with PGP is numerous. One, it’s very old. And more importantly, it’s very difficult to use. To make it easier, some email clients had tried to simplify it, but in doing so may render it vulnerable to attacks (see the recent EFAIL attacks here: And what if we don’t send over our public key? Or forget to encrypt the communication? At best, it’s similar to the problem that QSAs have with the manual muting int telephony systems. In theory, it might work (if vulnerabilities are removed, and if users use text-based only encrypted messages), but practically is a different story. Even before the recent researches to PGP’s vulnerabilities, everyone basically knows that PGP doesn’t encrypt meta-data (the information needed to route email) – so subject lines etc are all visible. It may not look like much, but a resourceful hacker will find these information gold.

If PGP is not used – how about some of the recommended secure messaging systems like Signal or Telegram? The problem is that these are not email technologies and these have issues of their own. How do you filter out Signal? If you do receive Signal/Telegram messages on your phone, it brings your devices all in scope. How do you run a PANScan on your phone? How do you secure every phone device there as per PCI requirement?

So how do we use Email for PCI?

The only solution it seems now, is to have a PCI-DSS service provider for Email and to use them. As we don’t represent any service provider, we won’t list them down here, but a simple google search will give you some alternatives. Be aware though, to go through their AoC and ensure that their email service is fully certified. It may be likely as well for the QSA to request more information on the encryption and key management as well, as to whether keys are managed by clients on (likely, such as in the case of cloud services), managed by the provider, or they can provide a client-managed key cloud solution.

That’s only half the solution (if that manages to pass). The second problem you have is to limit the endpoints accessing the PCI compliant service as these are considered CDE. Now remember, everything connecting to the CDE becomes PCI scope. So for the rest of the organisation using email for other purposes or needing email on their phone etc (let’s call this corporate email, vs the secure email for PCI) – the corporate email needs to be segregated from the secure email. This means separate solution. This means separate emails for corporate and secure – in most cases, meaning separate email addresses. While theoretically you can split email through subdomains, the main domain still needs to accept the initial email before forwarding – so for instance if you want to have come to your specific secure email provider, unfortunately, it will still hit the MX record (Mail Exchange) of, which means your corporate email gets into scope. It’s an endgame there. Once corporate email is in scope, it’s over. Everything else becomes impossible to be compliant.

So you need to have for secure email. It doesn’t seem too difficult and it might be possible – but let’s say you have 10,000 agents or clients or service providers in the field – how do you re-educate an entire workforce to get them to resend? Remember, you can’t incrementally ‘migrate’ – i.e continually use the old email and then forward it over to the secure email – you need to completely move over to the new email service and shut down processing card on the old email. This means a lot of lost business, a lot of customer experience issues, a lot of complaints – all adding up to business issues.

After that, isolating receiving end points becomes an issue as well. All endpoints come in scope so depending on your business, this could be a secure room with only a few systems, or a distributed nightmare if you have 200 branches or outlets receiving these emails. This isolated segment is CDE, so anything it touches becomes NON-CDE in scope. Yes. It’s a nightmare. Any shared services will be pulled into non-CDE but in scope. If you want them to also use their corporate email, corporate email comes in scope. All endpoints subjected to full PCI controls. On top of that, most QSAs will likely require additional controls like data loss prevention to be present in the gateway or endpoints if let’s say the CDE systems are hooking on to another potential channel to send email (like the corporate email). Key management also comes in play for the full-disk, folder encryption at rest in the endpoints.

Overall, the massiveness of using email for PCI is difficult. I think the whole point that business wants to use email for PCI data is either the ease of use, or not changing the current way of doing business. Both are not on the cards – even if email is continually being used, the ease of use is no longer there for PCI. Also, the customer experience and frustration could be ten times worse that searching for another solution like secure repository or customer portal, or tokenisation or something. The amount of complaints foreseen in implementing new procedures, new techniques, new solutions etc – these are not just operational security nightmare, it’s a business nightmare. Plus your entire business becomes hinged on the service provider being PCI certified. What if they decided not be? Or they fail their next audit? Or they get acquired by a competitor?

If a business is willing to embark on the complexity of getting email in scope for PCI, a humble suggestion we have would be to look for alternate solutions and have them on the table as well. Because once everything is scrutinised and risk is assessed, then they would have the full picture of what they are dealing with.

For more information on PCI-DSS or any compliance or IT advisory, please drop us an email at

Penetration Testing and Vulnerability Scans

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:

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 and we can quickly assess your needs and advice you on your next options to take.

We are Minerals being Mined

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:

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 or advertisements and other content served by or on behalf of 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 The only thing we are collecting from you is whatever you tell us on that email. That’s our term of services!



The SAQ Bs and how they apply to you


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

Cheers for now!

FREAK Vulnerability on Windows


As we do our penetration testing, we have to continue to get updated on some of the latest issues affecting systems out there. SSL seems to get the mother of all shares of vulnerability, with Heartbleed and then POODLE, and now, FREAK.

FREAK is found in detail at, which is basically a MiTM attack exploiting weak 512-bit keys. It affects OpenSSL, and upgrading to v1.0.2 fixes the flaw.

Basically, if you have weak cipher suites supported or SSL/TLS RSA-Export less than 512-bits, then get rid of it.

Resolution: We have always advocated to remove weak ciphers. Nobody really understood why, but now there is a vulnerability to include in our report.

If you need some assistance in vulnerability assessment, penetration testing or security audit to cover FREAK and other vulnerabilities, drop us an email at and we’ll get a team to you.

A writeup on the recent FREAK vulnerability.

Hundreds of millions of Windows PC users are vulnerable to attacks exploiting the recently uncovered “Freak” security vulnerability, which was initially believed to only threaten mobile devices and Mac computers, Microsoft Corp warned.

News of the vulnerability surfaced on Tuesday when a group of nine security experts disclosed that ubiquitous Internet encryption technology could make devices running Apple Inc’s iOS and Mac operating systems, along with Google Inc’s Android browser vulnerable to cyber attacks.

Microsoft released a security advisory on Thursday warning customers that their PCs were also vulnerable to the “Freak” vulnerability.

The weakness could allow attacks on PCs that connect with Web servers configured to use encryption technology intentionally weakened to comply with U.S. government regulations banning exports of the strongest encryption.

If hackers are successful, they could spy on communications as well as infect PCs with malicious software, the researchers who uncovered the threat said on Tuesday.

The Washington Post on Tuesday reported that and were among the sites vulnerable to these attacks, but that the government had secured them. (

Security experts said the vulnerability was relatively difficult to exploit because hackers would need to use hours of computer time to crack the encryption before launching an attack.

“I don’t think this is a terribly big issue, but only because you have to have many ducks in a row,” said Ivan Ristic, director of engineering for cybersecurity firm Qualys Inc.

That includes finding a vulnerable web server, breaking the key, finding a vulnerable PC or mobile device, then gaining access to that device.

Microsoft advised system administrators to employ a workaround to disable settings on Windows servers that allow use of the weaker encryption. It said it was investigating the threat and had not yet developed a security update that would automatically protect Windows PC users from the threat.

Apple said it had developed a software update to address the vulnerability, which would be pushed out to customers next week.

Google said it had also developed a patch, which it provided to partners that make and distribute Android devices.

“Freak” stands for Factoring RSA-EXPORT Keys.

– Source from Reuters

« Older posts Newer posts »

© 2021 PKF AvantEdge

Up ↑