PKF AvantEdge

Tag: ISMS (Page 2 of 2)

PCI Pentesting and ASV Scans

May 24, 2021 / / 0 Comments

Back in the days (as in when we started PCI more than 10 years ago), when it came to testing and scans, there were probably very gray lines on it. We saw a lot of reports that came out under the guise of ‘penetration testing’ that was straight out lifted from an automated Nessus Scan or one of the free Acunetix scans available. The problem was exacerbated when these penetration testing reports were further accepted by regulatory bodies like our regulatory bank and passed by other internal/external auditors. They basically just looked at a report and if it sounded and looked technical enough then it was technical enough.

Now, PCI got the hint and released a few versions of the Penetration Testing Guidance document, the latest iteration on 2017. A big part of it talks about scoping, clarifying on qualifications and requirement 11. But one of the key features of the document is highlighted in 2.1:

This came about to stem the misconception that as long as you have completed the vulnerability scan, you can use that to pass off as a penetration testing. We still see customers going down this route, in whatever creative ways they can conjure to avoid the penetration testing exercise.

An example was this response on their external PT report stating:

“We have conducted the PT exercise based on the recently passed ASV scan report by the QSA. Since the ASV scan has passed, the penetration testing report is also considered to be passed as there are no vulnerabilities to test.”

Which is basically the philosophy that as long as the scans do not yield any high or medium vulnerabilities, i.e a passing scan, there is no longer a need to conduct any penetration testing. Their concept was simple and fairly understandable: since there are no “vulnerabilities” in the scan, there is nothing for us to ‘test’.

Of course, this was rejected by the QSA.

While there are many arguments on this matter, the simple case against this is: the scan produces potential vulnerabilities and may even miss some out that may not be reported. False negatives do exist even in commercial scanners such Qualys or Nessus (two common auto-scanners). Additionally, a passing scan does not mean no vulnerabilities, it just means there are no medium/high vulnerabilities based on a non-contextual scan to the environment. A non-contextual scan means a lot of scanners already use internal libraries in their scanning database to categorise vulnerabilities without the definition of the actual environment risk it is scanning. So to equate CVSS to the actual risk of the organisation may be too broad an assumption as some low vulnerabilities may still be able to be exploited manually. The classic example here is when we check a simple form entry password and find it is well protected and designed, technically. However, a pentester may then go out into the organisation’s forum and discover that the admin regularly upkeeps a password file in Google Drive and shares it to the entire world inadvertently. The scanner won’t discover things like that.

Therefore to simply state, just because there is a passing ASV scan, it equates to penetration testing passing, is not going to get a free pass in PCI.

Another question that many organisations come back to us, when they have their team of penetration testers doing internal testing is: Well, then how do you do a penetration test, then, if you state we cannot use the ASV report to also pass our external penetration testing?

And it would seem weird, that when I look at them and answer: wouldn’t your penetration testers be able to answer that, instead of us? So from the auditor perspective, we look at 3 things: Tools, Technique, Team.  

The tools being used are important, but not all for pentest. Just by stating you have Kali or Metasploit doesn’t necessarily mean you know how to operate it. Technique (or method) is important to document. This is key for PCI and a key difference between hackers and pentesters. A pentester would know how to document each step, inform their client and normalize and not destroy the environment. A hacker (or let’s use the more correct term cracker) would simply go in and cause as much damage as possible, depending on his/her objective. You would rarely come across crackers developing comments and detailed reports/documents to their victims and executive summaries to the Audit Committee justifying their methods, the scope of coverage and the time and date of engagement. And finally, PCI looks at the personnel (or team) conducting the exercise. They may be certified (or not), but they should at least be qualified. In this case, if the pentester has no idea how to start a pentest, then the normal assumption would be — he’s not a pentester. A chef doesn’t ask people how to start cooking. He may require an input or two to understand what he needs to cook, or how spicy the broth should be for the customer; but if the he’s asking how do we start the cooking process or what is a wok, then that should be a red flag.

So, while the coverage of penetration testing and vulnerability scanning in the entire document is not the the purpose of this article, it is keenly important to know the difference between both (penetration test vs vulnerability scan), and not use one to justify the inaction of the other. Your QSA may bounce back that vulnerability scan attempting to disguise itself as a penetration test and waste precious compliance timeline in the process.

Drop us a note at pcidss@pkfmalaysia.com for any queries you have for PCI-DSS or ISMS and we will get back to you straight away! Stay Safe!

The Biggest (Real) Myths of PCI-DSS: Part 3

May 10, 2021 / / 0 Comments
pci-compliance

OK, we are down to the final 3 Real Myths of PCI-DSS, so here we go!

Real Myth 8: PCI-DSS gets easier and cheaper every year

This is quite understandable, seeing that the idea behind PCI-DSS , to many is to do once and be done with it. And in a sense, this is actually borderline correct. If you learn how to ride a bike at the start, you may need to get your Dad to teach you how to ride it so he is holding you for a while. After a while (sometimes, for some, maybe six years), you are able to ride the bike on your own and you don’t need your Dad hanging around anymore. So it’s the same. Except, replace the bike with PCI activities and your Dad with outsourced consultants or implementers.

The great thing about PCI-DSS is that it doesn’t dictate you to go out and purchase expensive services. In fact, the more you “in-source” the less costly your PCI will cost you (in terms of money going out of your company). If for the first year, you paid maybe 20K for all your penetration testing services – after 2 or 3 years, you decide to set up an internal InfoSec team to do these activities – done. You don’t have that 20K output anymore, and you have a team of pentesters to do it. (Of course, the question comes – how much are you paying your pentesters’ salary?)

However, whether it becomes easier/cheaper is probably not the case. You see, the first time you go through PCI-DSS, you are in what we call, First Time Certification stage. In this part, some of the requirements, such as quarterly ASV scan, quarterly IVA, half yearly firewall reviews, 12 months of log archives etc does not apply. And you go, huh? Why? Because you get a free pass, that’s why. In the first time cert, you simply have to do one iteration of these activities. For instance, the ASV scan, you just need to demonstrate one cycle of scan for all in scope systems. Your first time cert time range should be around 6 months…so, in this case, you could run an ASV scan one time, submit that as evidence for certification and get certified.

Once you are certified, keep an eye on the date when you signed off your AoC. 12 months from that date is your expiry, so that is your maintenance year. Your maintenance year is then divided into 4 quarters and you will need to ensure your annual, quarterly, bi-weekly, weekly, daily activities are done accordingly. So instead of ONE ASV scan, you now have 4. For each of your IP. Instead of one Internal VA, you have 4. Instead of one segment PT, you have 2. Instead of 1 Firewall Review, you now have 2. You get the gist. So for those who wonder if it gets easier in the second, third, fourth year, there is a rude shock. Furthermore, your scope may increase based on your growth so instead of testing 10 systems, your second year may test 20. Additionally, knowledge may also not be kept because there your IT team or compliance team may leave. That’s reality, so you are typically back where you started. So now you know. PCI-DSS is not unlike a marriage. You need to keep working on it to make it work.

Real Myth 9: A company is considered PCI compliant even after the expiry of certification, due to 90 days grace period from the council

I know what you are thinking. You are thinking, this myth is way too specific and it sounds as if this is a real life scenario that actually occurred. You are right. Because this was exactly what we faced not long ago. You see, we had a financial institution we were chasing for a PCI renewal. They outsourced their datacenter to another company (which is common), so therefore, in accordance to PCI requirements, that datacenter needs to be included in their PCI-DSS, either demonstrating their (DC’s) own AoC or to participate with my client’s. The DC chose the former, to show their own AoC. So far, it’s ok. But then, our client’s PCI-DSS expiry is on February. The DC over the years have always managed to renew their own PCI-DSS cert on time (about a month or so before our client) so we have always had a compliant report from them (the DC). Until recently.

So while checking requirement 9 Physical Security, we noted that the AoC provided to us from the DC had already expired about two months back, and our client’s expiry is in about a month’s time. So we rightly requested them to provide us an updated AoC. Instead we received a response stating that even though their AoC has ‘expired’, as per PCI, their compliance status is still valid for 90 days (3 months) grace period, and they will be conducting an audit sometime within these 3 months.

Oh-kay.

Firstly, just to be clear, PCI-DSS doesn’t give any 90 days grace period or what not. As in, it’s not part of the standard, or part of the PCI Council’s policy. Any grace period is given by the card brands to those under their contract and that even if they choose to do so. It’s those sort of thing that is like a ‘privilege not a right’. However, since this data center has NOTHING to do with the card brands (they are directly providing service to an Financial institution, and not connected to the card brands), how did the card brands provide this 90 day grace period to them? It’s definitely not the QSA who can provide any grace period. So where did it come from?

Secondly – a grace period is a grace period against something that you did not meet. In this case, it’s the PCI standard that you did not meet, i.e you are NON COMPLIANT with an expired AoC. That’s why it’s called a grace period. Whatever the penalty or action is, that 90 days is the ‘grace period’ you have before the hammer of justice falls. The fact is, the deadline has already been missed. You are now under ‘grace’. The meaning of grace is ‘undeserved favor’ (evangelicals like to use this terminology, but I digress). You don’t deserve it, because you are non-compliant and you have missed the deadline. But the card brand is giving you a favor before they implement PCI-DSS penalties or fees on you. 90 days, get your act together, else boom.

Now, obviously, if this data center gives this response as a justification of not producing a compliant AoC, how can our QSA accept that as a proof of compliance? Unless you are saying, our client should also be delayed 3 months from their compliance date just because this data center decides to take advantage of this so called ‘grace period’? You see where the problem is. The grace period isn’t stating the company is still compliant to PCI (they are no longer compliant without a valid AoC) – it’s stating, that’s the period of time the card brands will give before they smack you with penalties according to their contract.

Real Myth 10: If the company is an ISMS certified company, they have already complied to 90% of PCI-DSS

We get this a lot. And again, it’s very understandable why people think of such. And to be honest, there is some truth here. Being ISMS certified DOES help you become PCI compliant. And vice versa. They are both IT security standards/guidelines and seen as a distant cousin of each other. However, we do get potential customers arguing to us that because they are already ISMS certified, then we should only charge them 10% of what we normally charge for PCI.

That’s a head scratcher for sure. It’s like if I had a driving license from Malaysia and I apply to get my license in Australia and I demand the Australian government (or whoever runs their driving license department) to give me the Australian driving license for 10% of the fee. How? The audit for PCI needs to be done regardless of whether you are ISMS or not. Where you will likely save up money is in the remediation stage where you may end up implementing less controls. But the audit has to be done in the same manner as any other audit.

Additionally, while both ISMS and PCI deals with the same subject – Information Security – the philosophy is different. ISMS hinges on the Statement of Applicability and the risk assessment process. That’s key. In fact many of the controls and their implementation will be based on the risk process – and furthermore, how the ISMS can be improved in every iteration. It is a ‘system’ after all.

PCI is different. While there is a ‘token’ risk assessment in there, you need to understand that PCI-DSS is a risk-based standard…only, not your risks. But the card brand’s. It’s the result of a risk assessment, which has already been done by the card brands. That’s why they decide to impose these standards – logical security, audit and monitoring, secure software development etc on you. There’s not much disaster recovery or backup requirements because that’s a business risk. It’s not a risk to credit card confidentiality. So is a risk assessment still useful? I think it still is. A whole article can be written on how useful or superfluous one may find the risk assessment requirement is for PCI, but let’s leave it for another day.

Summary

Even from the start of writing this series till now, I’ve been beset with new enquiries and PCI interpretations that has left me flabbergasted. Some of these interpretations are not unlike theories of the flat world, where it can be easily explained. Others have found little tiny crevices in the standard itself that I myself after reading the standard a dozen times over would never think of. So, to say, we are still learning a lot about PCI-DSS and how different entities see it and interpret it, so these myths may not age well. There could be a whole new list of 10 Real Myths in about a year or so. Till then, drop us any enquiries at pcidss@pkfmalaysia.com and we will do our best to guide you through PCI-DSS and the infinity that lies beyond.

PCI and the art of scoping

May 5, 2018 / / 0 Comments

A lot of people we have met had told us this: “Since we are ISO27001, PCI should be a piece of cake, right?”

The context of this is because ISO27001 and PCI are often seen as distant cousins. They are both very relevant in our country and region (unlike other compliance like HIPAA), both deal with information security, and the overlaps between the Annex A controls of ISMS and PCI are evident. Therefore, the natural conclusion is ISO27001 is either a superset or a subset of PCI-DSS.

The problem with this assumption begins right at the start. In ISO, the scoping is largely determined by information that matters to your business. Before the iteration of 2013, scoping was generally done in a cowboy sort of manner. We met a company who had tons of sensitive information and told us they were ISO27001 compliant – and their scope was the security of their printing documents. Yes. How they literally secured the hard copies of the printouts. That was their scope statement.

Now 2013 version of ISO27001 had tried to stem these shenanigans by introducing interfaces and dependencies. Basically now the scope needs to cover information that are deemed important enough to protect from business perspective. This would cover the products and services relevant to the context of the organisation. Overall, scope determination of the ISMS can be a prolonged matter if you have a large organisation, and is often subjected to the business side of the organisation.

PCI scope?

It’s determined by the information that matters to the payment card brands, not your organisation. Credit Card Information. Primary Account Number. That’s it.

If you store, transmit and process PAN, PCI applies. If you don’t do any of these, and you do not influence any transactions in the payment card flow, then PCI doesn’t apply.

Often, people express utter shock that PCI doesn’t have any business continuity requirements. In terms of the holy trinity of information security – Confidentiality, Integrity and Availability (CIA), PCI primarily focuses on Confidentiality. Integrity is only focused in terms of its relation to confidentiality (Integrity of logs, integrity of system changes, system files etc), and there is no concern on Availability. Which makes sense. Between you closing down your business for one week versus you losing credit card information of your customers, the latter is viewed as more critical to the payment brands than the former. Although from a business perspective, a loss of business for a merchant is a loss of business for the entire data flow, upstream or downstream, so PCI not really caring about your RTO or RPO may be counter productive – but that’s an argument for another day.

At the end PCI scope boils down to you storing, transmitting or processing card holder data (CHD). Even if you don’t do any of these 3, you might still be in scope if you influence the security – an example would be those SAQ A e-commerce merchants that redirects requests to another PCI service provider. Even though they don’t deal with the CHD, they influence the transaction through their redirects, therefore, some parts of the requirements need to be met.

So – before we start our PCI journey, it is  very important to know what is the scope that is covered in your PCI environment. We may not want to take the whole environment as IN SCOPE – for cost, quality and timeline purposes. Our normal practice here is to reduce the scope as much as we can, a process we consultants term as “Scope Optimisation” simply because it sounds grand. I mean it sounds better than “Reduce your scope” which generally is interpreted to “reduce your price”.

In general, there are six things that we have to compile before we truly initiate the PCI journey.

a) Location and Address of the PCI scope. This is simple enough. Usually your data center is in scope. Depending on whether you store, transmit or process card data in your other offices, those come in scope as well. A question here would be – what about HQ, where our administrators access the PCI systems in DC, via a VPN connection? Ah. The secret sauce of putting things out of scope in a remote location where there is no storage, transmission or processing (lets just shorten these to STP from here on) of card data but there is access from an admin systems – multi-factor authentication. As long as this is in place, while the admin system is in scope, the location itself is then put out of scope. So you can connect from Starbucks, your home, or Timbuktu, and you would not have these locations dragged into your precious scope.

b) Applications that STP CHD. Store, transmit or process card holder data. Many queries have been like – oh, do we need to use PA-DSS applications? Well, if you do use PA-DSS certified applications, it would be very useful. However, even if you do not, you can still access that application as part of your scope under Requirement 6. In fact, some applications may not even be able to be PA-DSS for many reasons, such as it not being part of the authorisation or settlement flow but still storing card data. A custom CRM for example would be one that cannot be PA-DSS but still in scope for card data application. OTC (off the counter) products that store card data are still in scope, however, they need to be assessed properly to determine if there are any security issues that may influence the confidentiality of card information.

c) Network Diagram – an updated network diagram is a must. And a network diagram needs to be detailed enough to be able to differentiate the PCI and non-PCI zones. The important thing we need to take note on the network diagram is the proper demarcation of PCI zones, so we know what are:

  1. Card data environment in scope (CDE-IN-SCOPE) – ZONE A
    1. Any system that store or process or transmit CHD
    2. For example, application server, Database server
  2. Non-Card data environment in scope (NON-CDE-INSCOPE) – ZONE B
    1. Any system that require to communicate with CHD
    2. For example, patch server, anti-virus server
  3. Out of Scope – ZONE C
    1. System not related and has no communication with CHD – but might communicate with NON CDE IN SCOPE.
    2. For example, CCTV server in your office environment

d) Asset List for PCI – the asset list is critical because this relates directly to the effort and remediation costs of your PCI program. There is a huge difference in doing pentest for 200 systems versus 20 systems. So in this case, we don’t care about your assets considered not in scope, we want to know the assets in CDE and in NON-CDE in scope (Zone A and B).

e) Public IP addresses – this is needed because of ASV scans required. ASV scans are security scans done by the ASV (Approved Scan Vendors) of PCI. You can’t do it yourself, you need to get an ASV to do this for you.

f) Data Flow Diagram – This shows the card data flow in your organisation. Basically every channel where credit card enters into your environment, stored and process and exits. This details the lifecycle of CHD in your organisation whether it ends up being stored in a database for seven years, or passed out to another service provider. It’s essential to understand this – and if you have multiple channels where card is being entered (e.g e-commerce, POS, MOTO, Call Centers, KIOSKS etc) you need to document each of these from start to end.

So there you have it. PCI scoping at your fingertips. Drop us an email at pcidss@pkfmalaysia.com and we can have a free session with your organisation on what could be your possible scope, which likely may not be just your printouts coming out of your printer!

PCI DSS and the Problem of Scoping

June 5, 2016 / / 0 Comments

pci-compliance

I recall in an actual case a few years back when I received a call from a company requesting us to do a certification for PCI for them. So I met them and drew out their PCI plan starting with a gap assessment, remediation and certification audit.

They said they have already done their own gap assessments internally by their ISMS guys. And they will be doing all their remediation on their own and they just needed me to quote for certification audit because “PCI is forcing us to be certified by a third party, which we believe we can do it better than you can”.

There was nothing much to talk to them about, but I did mention that if we find major NC (non compliances, in ISMS speak), we would then use that ‘certification audit’ as our own gap assessment and that we might be required to come back again to verify.

The company truly believed that PCI was a subset of ISMS and they handled it as such.

So we came in for the certification and found out that their entire scope was completely messed up. For instance, there was another out of scope network and systems connecting into their CDE for monitoring. Because card data wasn’t passing through, they marked it as out of scope. Unfortunately, PCI doesn’t see it that way. This would be considered an Non CDE In Scope, and systems within this network will need to be secured as well, and hardened as per PCI. The logic is that if these systems are compromised, there is a path into the CDE that can be exploited.

They made a huge fuss on this, claiming that they are willing to absorb the risk and that their management signs off on the risk assessment.

ISMS is a best practice/guideline at best – it’s a great marker for security, but PCI is a standard. If you can’t meet it, then you don’t meet it. Of course, there are ways around this particular issue, but they insisted we passed them simply because their management accepted the risk.

Here’s another idea: PCI-DSS generally doesn’t really care about your business. It’s not about you. It’s about card data. Visa/Mastercard and the Jedi PCI council are not concerned about your business – they are concerned about the confidentiality and integrity of card data. That’s why you will not find any BCM or DRP requirement in PCI. RTO and RPO? Pfft. They don’t care. Your business can go down for 10 weeks but as long as card data is safe, it’s good.

And that’s why, scoping is HUGELY important. Many people might think that a gap assessment is a waste of time. It is, if it’s done incorrectly. I recently witnessed a ‘gap assessment’ report that was a complete mess. It just detailed the PCI twelve requirements and in each requirement gave an overview of the company’s controls and what they should be doing: ripped off almost verbatim from the actual standard itself. That can be downloaded for free.

A gap assessment needs to bring you from one place to another and needs to provide these:

a) A clear understanding of your scope, including a writeup on your network, and processes that have been assessed. It should also be clear what is out of scope. This initial scope usually is not set in stone as remediation would sometimes change what is in scope and what is not in scope. But at least you have something concrete to start with.

b) If possible, an asset register. For PCI. If this is not possible (for many reasons, e.g they have not purchase some assets required for a control), then the asset inventory needs to be prioritised a quickly as possible to see what is scoped and not. Asset should be clear on: Public ips, internal devices, servers, network devices, people involved, desktops, databases etc.

c) Network in scope and out of scope. This is key as companies are required to identify segments scoped out, and do segmentation testing. Also, CDE is clearly marked, NON-CDE IN SCOPE (we call it NCIS) must also be identified. Systems in NCIS could be monitoring system, SIEM, AD etc. Any system that connects to the CDE, but does not store, transmit or process credit card data are considered NCIS. NCIS must be scoped for testing, quarterly scans, hardening and such.

d) Clear roadmap for remediation and recommendations to proceed, specific to the organisation. These ‘gaps’ should all have a corresponding solution(s).

If the gap assessment doesn’t give you any of these, then it’s pretty useless. If it doesn’t move you forward or provide you with the information to move forward, it’s not a gap assessment. It’s an expensive training session.

So back to the first example of a customer. It wasn’t possible for us to certify them no matter how they argued, because simply they were not compliant (there were also many issues that they did not comply, for instance storage of card data in text files and sending via emails).

As a lesson – don’t neglect the proper scoping. It’s hard work, but as I always say: Start wrongly, do wrongly, finish wrongly. And that’s 6 – 8 months down the drain, with thousands of ringgit gone in investing, and job on the line. The second example is pertinent also. There is always a chance to OVERSCOPE as there is to UNDERscope.

An overscoping example would be to purchase all sort of snazzy security systems worth thousands of ringgit only to find that these were not needed, or that current controls were sufficient. It’s nice to have – but most of our customers, no matter how big they are, always have a trigger on the budget and cost optimisation is the topmost in their priority.

If you want us to help you in your PCI-DSS scoping, drop us a note at avantedge@pkfmalaysia.com and we can get you started with the initial understanding straight away!

Sunway ITSSC is ISO27001 certified

May 22, 2014 / / 0 Comments

Sunway Logo

Congratulations Sunway for being ISMS certified!

The certification link is here.

When we were approached in 2011 to first broach the subject on making Sunway ITSSC ISO27001 (ISMS) certified, it was a daunting task ahead. They had many groups, with a potentially large and challenging scope. Through teamwork and persistence, PKF and Sunway started work in 2012, and in less than a year, they were certified in 2013. Without the amazing tenacity of their employees, it would not have happened, and it was certainly a joy and privilege to be able to be the ISMS consultants during the implementation and gap assessment stage of the project. This is a testimony that with grit and hardwork, along with an unwavering focus on the objectives, nothing is impossible.

PKF offers a catalogue of services for your ISMS needs. We have done gap assessments, implementation advisory, risk management services and even served as independent internal auditors to fulfill the ISMS requirements. Contact us at avantedge@pkfmalaysia.com for more information on how we can help you achieve your ISMS goals.

It was indeed an amazing experience working with such a motivated team from Sunway. Of course, the celebratory dinner and karaoke session was pretty fun too!

 

Newer posts »

© 2024 PKF AvantEdge

— Up ↑