Usually a pentest is considered to belong to the realm of technical, geeky activities and is supposed to answer the question: “can my company be breached?” Unless you’ve been living under a rock during the last 10 years, you’ll know the answer is a simple “yes.” It’s just a question of the attacker’s time spent and ability.
There are a lot of pentests available on the market and now is a good time to book one, either to end the year with your security vulnerabilities identified and remediated, or to start next year on the right footing. To ensure you book the right type of pentest, you need to be clear what a good pentest can do for your organization.
Almost all security companies have a “pentest” services in their portfolio; those that don’t usually employ a third party to do a pentesting engagement for them. Note that I have received many strange requests, including for a pain-test. This requires an altogether different skill set… Anyway, I digress. Over the last years I’ve seen so many pentest reports, embedding thousands of lines of scripts and logs, highlighting tons of vulnerabilities in huge tables with red flags, some of which are described as potentially critical for the company.
But now here is the interesting question: does the report really present a relevant reality? What can the company do with such report? Are the findings actionable? At first glance, as most of the report focuses on prioritized key elements, you might say “yes, it is.” And that’s true, having priorities listed in a pentest report is good practice. But dig a little deeper and you’ll see that most of the time, unfortunately, the priorities reflect the severity of the vulnerability. Herein lies the real pain point. Relying just on severity level does not translate into real relevance to the company.
Much more needs to be taken into account when defining a priority. Here’s a simple example that illustrates why: is a critical vulnerability on a test server that is disconnected from the rest of the network really critical? Although a vulnerability is critical, the level of priority should not be defined as high, as the impact on the business will be low or zero. Another example: would it be worthwhile for the client to read a top-1 priority remediation related to a critical vulnerability that indicates that thousands of machines should be upgraded to the latest OS version? Again, although vulnerability is critical, the business context should be considered to present the best remediation actions and the related effort, because – as anyone knows – it is far from simple to upgrade the whole company’s IT.
The risk-based approach to pentesting is something different altogether. Its different approach can be summarized in a few words: to present concrete, actionable and realistic information, it is essential to gather a good understanding of the Client. And when we say “Client”, we mean a point of contact who does not focus on the technical elements of an organization’s security, but rather someone with a broader understanding of the company, its business, its activities and its risk position and appetite. This also means that the most important part of such pentest engagement is the preparation phase during which several discussions with the Client take place in order to understand the business of the company, the company’s risk posture, its concerns, and its assets. In summary, the context.
With such information to hand, the pentest engagement can be performed differently. It is no longer a geeky activity for a geeky Client. It demands that the pentester has a Client-oriented vision, able to understand what a risk is, how they should invest their time during engagement, and even more importantly, how to report a vulnerability and how to classify it in the order of priority.
This approach to pentesting delivers a radically different result. The report of a risk-based approach to pentesting will be different to that delivered by a regular pentesting approach.
No more tons of logs or scripts, no more lists of thousands of vulnerabilities; all this content will appear in the appendices and used as a support to create the actual report where the added value is present. It is not that all this content is unnecessary, these activities need to be executed but they should not to be exposed as such. They should be deeply analyzed and contextualized to provide valuable content.
This is the difference between a vulnerability assessment (which is almost exclusively raw data and mostly performed by automated tools) and a genuine pentest engagement. I’m not saying vulnerability assessments are never appropriate. They have their time, place, and benefits, including the fact that they are (or should be) very inexpensive and that they can provide a gap analysis if done on a weekly or monthly basis. But they will not provide the Client with information on the relevant risks as they affect the business.
The final deliverable in a risk-based approach will consider the context and will contain text, a many humanly-readable text that will not come from an automated report generator. The content will be based on risk analysis, business context, and will present realistic and prioritized vulnerabilities and remediation. It could also show how several vulnerabilities, which in and of themselves are not critical, could be chained together in a real-world attack to have a critical impact.
Finally, a pentest built on a risk-based approach is not much more expensive than a vulnerability assessment-type pentest. It is just the time investment that is different. A significant portion of the time will be invested in the preparation of the engagement, in discussion with the Client and in reporting activities. Then, the execution part will be optimized and will focus on the most important elements and areas. This will also reduce the potential impact on the Client’s operation as the engagement is more controlled, targeted and its duration is reduced.
It is therefore important to keep in mind that if a Client wants to have an actionable output, time will have to be invested in discussion with the pentest provider. If your pentest provider does not ask for it, you will receive a less actionable vulnerability assessment rather than a realistic pentest.
Make your choice.
With the end of year looming, Kudelski Security believes that it’s a good moment for security professionals to take stock of their programs and reflect openly about what works and what could be improved upon. If you are interested in understanding more about how a risk-based pentest can help improve your security posture, we can talk.