Tag: pentest

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: 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.

Penetration Testing: What to Expect?

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!

 

© 2020 PKF AvantEdge

Theme by Anders NorenUp ↑