Why be interested in audits as a pentester?
Security audits seem unpopular with penetration testing, but why? These missions are actually a significant source of information for a pentester and allow to take a lot of distance on the constraints encountered by customers.
Why did I become a pentester?
To be completely honest, my very first vision of pentest came down to the ability to do cool things with a computer. However, this was a long time ago, long before entering the world of work. That’s right, let’s not lie, penetration testing is fun; If you like puzzles, puzzles and other challenges, making pentest your job is far from boring. But in reality, this is not the reason that pushed me to become a pentester. My main motivation was to be able to do useful work, which really helps people. At the time, in 2017, the media was talking more and more about computer attacks and companies paralyzed by ransomware. It is therefore quite natural that I turned to this profession: to help, while combining the useful with the pleasant. My vision of pentest has changed a lot since I arrived at Advens. Although I am as passionate about penetration tests as I did on the first day, I do not lose sight of the main objective of these missions, which is to support our customers in securing their applications, infrastructures and other connected objects.
The challenges of penetration testing
Penetration testing exposes security vulnerabilities through realistic attacks. Thus, in general, little data is provided to us on the targeted perimeter. The goal is indeed to get as close as possible to the conditions in which an attacker would find himself facing the target. For example, a pentester can start an application penetration test with an access URL only. It then slips into the shoes of an attacker and tries to obtain valid login credentials. Any flaws that may help him in this regard are then reported to the customer.
But a penetration test can’t just be limited to finding vulnerabilities by playing hackers. Although it is a crucial part of our work, it is extremely important to be able to provide concrete solutions to overcome the flaws thus discovered in the form of an action plan. However, we lack certain essential concepts for the formulation of recommendations adapted to the customer, such as possible technological or business constraints. It is also difficult to take a step back from the tests performed in order to provide the client with an appropriate action plan based on their situation.
In reality, I myself did not fully realize these limitations before carrying out other types of missions, audits.
The little-known part of the job: audits!
But what is an audit? Concretely, there are several types:
- Code audits: The source code of an application is analyzed to identify any security vulnerabilities.
- Configuration audits: The configuration of a system or network equipment is provided to us. We then compare this data to official repositories (CIS, ANSSI guides, etc.) to identify any compliance discrepancies.
- Architecture audits: We verify the robustness of the architecture of an information system in the face of different threats. This is done from customer architecture and interview documents.
- Organizational audit: We verify the organization set up by the client from a security point of view, from the creation of a team dedicated to incident management, from the available documents and interviews with the client.
For a pentester, it is true that at first glance, it can be a little scary. I admit to having had some apprehension before my first code audit and asked myself many questions. In particular, how to successfully understand the code developed by another person, and emerge from it possible vulnerabilities?
A configuration audit? Compare configurations sent by the customer with repositories? What’s the point? With experience, and enough hindsight, I now know that these a priori complicated and boring tasks are necessary and rewarding.
A more global vision
I realized the importance of these missions during an organizational audit that particularly marked me. Yes, an organizational audit, the least technical audit among those presented here. More seriously, in addition to the documentary aspect, this audit required a lot of exchanges with the client and his teams. I understood that a remediation that seems trivial to us as a pentester can have serious consequences for the client. Imagine a company using a third-party, production-critical, and irreplaceable application. Unfortunately, this application is not compatible with a recent operating system. Recommending only to update the system would therefore not be relevant for the customer, since such an action is simply not feasible.
This audit opened my eyes and allowed me to take a much step back for the construction of the action plans related to penetration tests. I now always ask myself the question “is this remediation proposal really easy to implement and relevant?”.
I also realized that all the technical information observed during my many audits now allows me to better direct my attacks and provide much more complete recommendations. Note that ANSSI [1] recommends the implementation of audits in parallel with penetration tests on the same perimeter and it is true that combining these two types of missions is a real advantage for the pentester and for the client. Indeed, the completeness in the evaluation of a level of security and a risk of intrusion is reinforced.
Audits can therefore not only strengthen the technical knowledge of pentesters, but also provide them with the necessary perspective to provide a complete and adapted work to the customer.
