PKF AvantEdge

Tag: penetration testing

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

April 29, 2021 / / 0 Comments
pci-compliance

So, continuing the Real Myths of PCI-DSS, lets move down the list.

Real Myth 5: All PCI-DSS services must be outsourced

Now, this is a very important myth to clear up. Because it directly relates to the usually biggest concern of all: cost. A while ago, we provided an idea on how to cost PCI-DSS, and break it up into certification/advisory costing and implementation cost. While the certification-advisory cost is easier to gauge based on locations, processes, card storage, activities covered , implementation cost is harder to gauge. Because number one – you don’t know your scope yet. This means, you may have 10 or you may have 200 systems in scope, you don’t know. Some go, “Ah but we know, because we have already decided our scope!” and we go, “Ah, but that’s the Real Myth 7, that you can decide your own scope…read on, intrepid adventurer of PCI!”

In any case, one way to cap a cost or save cost is to in-source your work, i.e have your own people provide the implementation services. There are no “PCI-certified” company to actually do the implementation services. All services – except for ASV scans – can be performed by your own, if you are qualified enough to do it (more on that later). I’ll throw in some services that for a typical PCI project, is a must:- Penetration testing, Internal Vulnerability assessment, secure code review and code training, patching, logging and monitoring and daily review of logs, card data scan, application testing, systems hardening, segmentation penetration testing, encryption, key management etc. These are fairly typical activities you will find in PCI – and you can do it all on your own if you have the resources and knowledge to do it. So, don’t feel cornered by any firms or consultants stating that these services must be done by them in order to pass PCI-DSS!

Real Myth 6: All service providers MUST be certified to do implementation services

This is an extension of Real Myth 5. So once the company decides to outsource the PCI services, in the case where they do not have the resources to do it internally – they go about requiring “PCI qualified” service providers to do these services. We’ve seen this requirement before where the requirement was to be a “QIR – Qualified Integrator and Reseller” to do services like penetration testing and code reviews and such. QIR isn’t created for that. QIR is created for implementing merchant payment systems and has nothing to do with the services mentioned. Aside from that, there is a growing call for PCI services to be only performed by “Certified Penetration Testing Companies” with CREST or individuals with certifications like Certified Ethical Hacker etc. Now, while these are all well and good, and certainly mentioned even by the PCI-DSS as a guidance in selecting your vendors, these are by no means a requirement by the standard. Meaning, the QSA cannot enforce all your testing to be done by the above said certified entities if you have ready, qualified and experienced personnel on your end to do it. Again – this doesn’t mean any Tom, Dick and Harry, Joe and Sally can perform testing or activities in your environment. The above certs and qualifications obviously carry weight and we should not dismiss the fact that if an organisation takes the trouble to go through CREST, versus a company that was set up two days ago, and employ 2 testers working in Elbonia – which you should prefer or which one will the QSA has less of an issue of – that’s pretty obvious. What I am stating here is that, we’ve seen many veterans who are far more efficient or experienced in systems testing and security testing than we can ever hope to be and for whatever reason, they don’t bother much about these paper chase or certifications.

At the end, the QSA may raise a query on who carried out the test and may choose to check the credentials of the testers, but in most cases, if the testing seems to be in order, most QSAs are OK with it.

Real Myth 7: PCI scope and application of controls can be determined by the customer

This one is my favourite. Because it played out like an episode of a slapstick comedy. I was called one day by one of our clients who had a new group handling their PCI-DSS program. You see, we’ve been doing their program for four plus years and we’ve been servicing them fine for years – but the new group handling PCI now isn’t well versed with PCI. It’s frustrating because no matter how many “knowledge transfer” sessions we gave, we still ended up with the same questions. We realised we were stuck in a Groundhog Day scenario, where things never change no matter what we do. The group wasn’t technical, which was an obstacle but overall, I think maybe they just have too many things on their plate.

So on this call, they said they were going to compare our quote to other providers this time around and I said, yeah, it’s fine. They then proceeded to give me a scope to quote and I commented, “Hold on, this is the wrong scope. This is the list of assets two years back. You have now changed your scope, and there is a new list of assets under scope for PCI.”

From there, the proverbial excretion hit the fan. They maintained how did I know their scope? I said, well, we helped you guys work it out. Your operations team is aware of it, that every year we help you validate your scope (as per PCI-DSS guidance). And they went: “Why must the scope come from you? We are the owners of the environment and the project, so we decide the scope!”

Aha. This is where our points diverge. You see, while the organisation does have the overall responsibility in setting the scope for PCI, PCI-DSS also has a guidance document “Guidance-PCI-DSS-Scoping-and-Segmentation” that defines how that scope should include assets and networks and therefore affecting how and where services should be implemented. So for illustration:

Company A says, “Well, we have a payment gateway and a payment switch business. We also have a call center and a merchant business that accepts credit cards through kiosks or direct POS acceptance in our outlets. Now, getting our merchant environment to be certified is going to be a pain. We have decided to just certify our payment switch environment which is isolated in a cloud, and not related to our payment gateway at all which we are just about to launch a few months from now, so there are no transactions yet.”

So there you go, Company A has set their scope and from the outset, it kinda looks fine. Yeah, if these are all isolated environment, it’s ok. In any case, in the report of compliance, the QSA would detail any services offered by the company that are NOT assessed, making clear what are the services NOT PCI compliant for that company.

However, what Company A cannot decide are the services and the assets involved in their scope. There is a method to scoping defined by PCI-DSS and we have written at length in this article here.   There are a few ways to minimise the scope by segmentation and so on, but for instance if you run a flat network and insist on it being flat, then everything within that network comes into scope – be it it’s your payment gateway, your merchant business servers, your call center laptops etc. So you can ‘define’ your scope, but what gets sucked into your scope to do hardening, pentesting, patching and all the PCI controls – that is already defined by the PCI on how it’s done. And we just have to identify these assets and systems and networks that get sucked into scope. PCI is a like a giant vortex or blackhole. Everything that is sitting on the same network or touches the systems in CDE, gets pulled into scope.

So there you have it. We will be exploring the final 3 Real Myths of PCI soon, but for now, if you have any queries on PCI-DSS, or ISMS or Theory of Relativity and Blackholes, drop us a note at pcidss@pkfmalaysia.com. Till then, be safe!

Penetration Testing and Vulnerability Scans

March 27, 2018 / / 0 Comments

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

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

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

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

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

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

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

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

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

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

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

The Obfuscation of PCI Standards

August 14, 2016 / / 0 Comments

pci-compliance

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

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

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

Confusion of application testing – Requirement 6.6 states:

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

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

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

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

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

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

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

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

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

Now, here is the PCI problem.

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

blah blah blah

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

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

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

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

Penetration Testing: What to Expect?

January 25, 2013 / / 0 Comments

After a relatively quiet 2012 on the penetration testing (PenTest) front, we’ve got quite a number of requests on our penetration testing services in the first month. A lot of clients we speak to don’t really have an idea of what a penetration testing exercise should be. Many of them expect us to do stress testing, load testing and basically all the scope that a QA/QC group should be doing for their software development. We do that as well, but that’s slightly different from a penetration test. Slightly here means, related, but with different objectives. Some pentest scope does have stress test elements, such as breaking the system with DDOS. In other words, the objective is to expose weaknesses and vulnerabilities, as well as to create exploitations, either through a conceptual or practical standpoint on these vulnerabilities.

The first thing to do is to define the objectives and scope. Most companies we’ve dealt with prefers a quick assessment to see immediate weaknesses. While there is nothing wrong with this, as pentesters, we must make our clients realise that this is simply a snapshot vulnerability and it’s not a catch-all. Scoping is usually done with a meeting with the business owners. IT infrastructure can be very large and complex. To pentest the entire infrastructure is obviously not practical, so we need to define a narrower scope based on risks and sensitivity of data. It’s a lot like our IT audits. We establish our audit universe and our incoming points, and then run our pentest exercise against it. Another scope is to establish the type of pentest. We’ve done pentest emulating disgruntled employee with authorised access looking to escalate privileges or remove data. We’ve simulated as script kiddies aiming for a take down on resources and DOS attacks. We’ve simulated concentrated attacks on a group of IP addresses, utilising OSSTMM methodology. Recently we just completed an OWASP Top Ten Web app penetration testing. We’ve had another where multiple attack vectors were looked into, such as HR weaknesses, process weaknesses and a vulnerable FTP server where other attacks can be launched from.

Mostly, the scope will be determined by cost and time. Due to the non-regulated world we live in, most companies won’t want to spend too much on a penetration testing exercise. This is unfortunate, because usually, only after we give our presentation of report, do people realise, “Man, we have all these problems??”

Another point is to define the rules of engagement. Unlike other engagements, penetration test is high risk. It’s controlled, but it’s still simulating an attack. In many apps we’ve tested, we’ve found that they have NEVER gone through any QA/QC testing in the first place. In one engagement, our benign scan brought down the whole HA cluster. Luckily, our Rules of Engagement was already in place, to do testing in a non-peak hour and had a standby team, and we brought back up the systems with no significant impact. Still, it highlights the criticality of treating the pentest exercise with utmost seriousness. We cannot determine how systems will react to our exercise 100%, but we can draw boundaries. For instance, in one project, we were only allowed to create a benign file to demonstrate compromised access. In another, we were permitted to put in a keylog software to demonstrate the ineffectiveness of both host controls and network controls. Most of all COMMUNICATION is the most important thing. We are not a bunch of dark-cloaked hackers out to destroy our client’s credibility. We inform our clients on progress daily, and in some instance, as we go through a critical exercise, step by step, through Skype of Gtalk. The client must feel secure and the only way is through properly diseminated information.

I spoke to a client before who had hired someone from the net to do a pentest. Not only was the pentest successful, but he suspects some data was even taken. Because there was no communication or rules of engagement, he couldn’t get a proper report out and because he did not know what has been compromised, he had to completely change his security passwords and such.

We’re not saying we’re the best in the world. We’re saying that in whatever we do, our best interest must be the client’s best interest. As a company, there is absolutely very little benefit in us destroying our reputation by doing a shoddy job or stealing information, and putting our business at risk.

If you want to know more about what we do, drop us a line at avantedge@pkfmalaysia.com and we will get one of our consultants to get back to you directly.

In the meantime, here’s to a great 2013 ahead to all!

 

Stopping Insider Scans

November 27, 2012 / / 0 Comments

I’ll admit it. I’ve knocked on doors before, while sitting at Starbucks.

“Knocking on doors” here means running port scanners like Nmap, or vulnerability scanners like Nessus or Nexpose, to see if that guy in the suit across the room is using a laptop that’s vulnerable to exploits. I was much younger then. WiFi was just introduced, and to a guy born with a curious mind like mine, this was exciting stuff. I wasn’t a hacker or cracker by any means, neither did I dwell too much in doing malicious scripts, but it was just curiosity that got me going.

I did find myself on the good side of the law soon, running DHL’s global security group in Asia, and there faced monumental challenges like random denial of services,and naughty scans from external.

However, it is usually the insiders that do us in.

I’m sure you heard before, a secured perimeter is only as strong as its weakest link. And the weakest link is usually inside. A disgruntled employee. A corporate spy. A curious, idle employee with too much time on his hands, and reading too much Network Security Online articles. Whatever the case, every company will have its day in the sun. It’s just a matter of when.

For instance, we ran our penetration testing services for a network. We usually don’t have too much issues in the scanning phase, where we enumerate services and probe a little for vulnerabilities. Our standard process was to inform our client when we were doing exploits. One thing we’ve learnt in almost every project we’ve done.

Not everything goes according to plan.

It was an internal penetration testing, but we weren’t given much details on the network or servers as agreed and we ran several IPs scan at once. Soon, our technical client came back to inform that their servers were not doing too well, and one of the virtual servers running HA has rebooted. We immediately stopped the scans and realised that the IPs given were all running on VM. Nessus and VM does not play nice. Do a search on nessus on communities.vmware.com and pick your poison.

Thankfully, nothing serious occurred, which shows us again how important it was to have people ready and standby especially in PenTest and to follow certain set procedures and standards. We continued the pentest exercise with greater care, taking into account the vulnerabilities of Nessus and VM, and using alternative scanners.

Which shows, how simple it is for someone to DOS (Denial of Service) a network, with just a vanilla Nessus running. What can a company do about it?

Well several options are there:

1) IPS/IDS (Intrusion Prevention/Detection System). These babies usually run on the network points and works wonders to detect scans and stop them, among other thing. We used to run Tipping Point a lot in my previous companies. The problem here is that for a flat network, how do we want to run this? The server needs to be segregated into its own server segment, and an IPS laid out in front of the network point. In a flat network where everything is plugged into a single IP address space, it still can be done, I suppose, but probably not the best way.

2) HIPS/HIDS (Host IPS/IDS). It’s like a mini gun compared to a gatling gun. It runs on critical servers and works about the same way, except that the network interface gets hit before the intrusion prevention services kicks in. It’s pretty effective and we ran a lot of Symantec previously.

3) If those don’t do the trick, then we could probably secure every end point. If we want to secure internal attacks, the best way is to properly guard your asset. Control all your laptops through proper asset management, no administrative capability to install Nessus and an asset scan to ensure nothing naughty has been somehow installed on by enterprising employees. You might want to control/choke up the USB ports as well.

4) Finally, set corporate policies. Many companies fail to do this and we don’t know why. Document what will happen if activities like scanning is done. Make sure employees understand their obligations to the company and sign acceptable use policies before giving them corporate-owned assets, bought by corporate owned money. Sometimes a little awareness works better at prevention.

There are probably other ways I’ve missed out, but generally this would be how we’d deal with idle employees with too much time on their hands scanning our network. That, and putting them on a cold-storage project to wash out their curiosity, maybe.

© 2024 PKF AvantEdge

— Up ↑