Penetration Testing can be at the state-of-art level, or, conversely, disappointing. Much depends on your expectations, which are formed by previous experience.
Penetration testing (or, briefly, pentest) is one of those topics that has been heatedly debated for many years. A variety of points of view suggests that this service is still difficult to perceive by a wide market and is still waiting for its understanding and standardization.
When you order a cartoon from a street artist, you can only imagine the result in general terms. It can be at the state-of-art level, or, conversely, disappointing. Much depends on your expectations, which are formed by previous experience.
One of the problems of the pentest is the complexity of its presentation as a service. In the minds of an average customer, a pentest is a set of actions, as a result of which an executor gains access to the organization’s resources using the vulnerabilities found. Simply put, carries out a “hack”. When discussing planned work, few customers enter into the testing methodology, limiting themselves to superficial agreement on the model of the alleged attacker. The extent to which the customer discusses his vision of the work with the performer is almost no different from how the street artist works with the client. Is it worth wondering about the variegated results?
To recall what the “real pentest” was supposed to be, let’s take a brief digression into history. The emergence of pentest as an independent discipline is associated with the concept of “security testing”, which arose even before the era of personal computers and assumed a practical assessment of the applied security measures. Safety testing has gained popularity thanks to the advent of the British standard BS 7799-1: 1995.
A few years later, BS 7799-2 was released, which introduced the concept of a cyclic PDCA model into the security world, which considered systematic monitoring of security status as an integral part of the process. The boom in software vulnerabilities that occurred around the turn of the millennium highlighted a huge problem in the software industry and took hold of the agenda for years to come. Pentestas began to be mentioned in reports at specialized conferences, and at the beginning of two thousandth publications on this subject, organizations such as the SANS Institute were noted.
With the increase in the number of information systems and the increase in the amount of code, the number of software vulnerabilities also increased. The concept of permanent vulnerability has become a new standard of life, and the issue of ensuring the software and hardware security of information systems has been reduced to the task of identifying and eliminating the most dangerous attack vectors.
By analogy with “evidence-based medicine”, a need arose for a reasoned justification for the need to eliminate certain vulnerabilities. The answer to this need was the emergence in 2005 of vulnerability scoring methodology – CVSS, which allowed to take into account a number of risk factors, including the vulnerability exploitability factor. For many reasons, CVSS has not become a standard in this area, and the obligation to prove the feasibility of specific attack vectors has shifted to practice. Published in the same 2005, the PCI DSS standard identified pentests as an independent application and determined the basic rules for their implementation.
In fairness, it should be noted that this was not done by the standard itself, but by the market, to the extent of its understanding of the task. Methodologies that would determine the principles for carrying out such work appeared some time later.
That’s how we know the Pentest service today. Their main goal is to confirm or deny the possibility of unauthorized access to protected information using the vulnerabilities found. And the main principle of implementation is to provide the necessary evidence by applying techniques and methods used by attackers.
An attacker is a central concept in the field of pentests. The final result largely depends on what model of the fraudster is taken as the basis during the work. Most often, two main characteristics of an attacker are considered: awareness (awareness) and qualification. But this is not enough, since in such a two-dimensional world it is quite difficult to distinguish a dismissed employee from a working administrator, and a single hacker from a representative of a criminal group.
It is advisable to add the “level of equipment” and “motivation” to the characteristics of the alleged attacker, which will allow you to take into account what means the attacker can use, and how purposeful he is in his actions.
Another important point concerns the conceptual limitations of the pentest. When performing a search and analysis of vulnerabilities, the executor always considers only known vulnerabilities. The search for unknown vulnerabilities and the development of fundamentally new attack techniques is a separate research task that other people with the appropriate training and resources should deal with. Pentest is a purely practical discipline, not a research one, unless the customer is willing to pay for both.
However, it is wrong to perceive the pentest as a mechanical work to identify vulnerabilities with the subsequent selection of suitable means of their exploitation. If everything was so simple, the pentest would have been automated a long time ago. And it requires the performer to do serious analytical work, a deep understanding of the nature of the detected vulnerabilities and readiness to adapt existing methods and techniques for conducting attacks under a specific environment.
Critics argue that most pentests are limited to simple scenarios, and therefore the results are not reliable enough. One could agree with this, if not for one “but”. The basis of the choice of attack methods, among all other circumstances, is the principle of simplicity.
The simpler and more reliable a particular attack scenario is, the more predictable the result will be and the more often it will be applied. If we leave aside large corporations that invest significant forces and means in information security, it turns out that complex scenarios are not required to compromise average organizations. Critical vulnerabilities are often on the surface. Statistics of successful pentests are proof of this.
To reinforce all of the above with a practical example, consider the typical situation in which each pen tester finds himself, and which will help to trace the logic of his actions.
Assume that during the analysis of a public web service, the pen tester detected a critical overflow vulnerability in the version of PHP used. He also found out that for this vulnerability in the public domain, only PoC (proof-of-concept) code is provided that implements a relatively harmless functionality. What should be done in this case?
The answer to this question depends on two things:
1) what model of the alleged attacker is considered in the framework of this pentest, and
2) are there simpler attack vectors for the web service with similar potential.
If other attack vectors are not visible, and the “dark hacker” is selected as the alleged attacker, with sufficient time and perseverance, but limited in resources, the pen tester should study this vulnerability more closely to find the answer to the question whether it is possible to create based on the available data functional exploit for remote code execution.
Now let’s ask ourselves: how will the situation change if, instead of the public web server where the vulnerability was discovered, the pen tester will deal with the organization’s internal web server? Firstly, the model of the alleged attacker will change, and secondly, other promising attack vectors will appear with high probability. In this situation, the alleged internal attacker is unlikely to be interested in a vulnerability with unknown prospects. The pen tester should be guided by the same logic.
Let’s try to complicate the formulation of the problem. Assume that the vulnerability has a high exploitation potential and therefore was sold on the black market. What should a pen tester do in this case? Again, much depends on the model of the alleged attacker. If the attacked web server is of significant interest to alleged cybercriminals, who consider an organized criminal group to hunt, for example, by stealing and selling bank card numbers, it should be assumed that such a group can have all the necessary tools to exploit this vulnerability.
But the average pen tester doesn’t have the same thing. Therefore, all he can do is to collect as much information about the attack vectors on this vulnerability as possible, and state the details known to him in the report, providing an evidence base for his conclusions.
For dessert, consider a situation in which a pen tester is dealing with a vulnerability that requires a MitM attack to be exploited. Often, such attacks require the application of social engineering practices for employees of the attacked organization. Does this mean that the pen tester should go the same way? There is no definite answer to this question.
If the potential attacker is less time-limited, then the pen tester is strictly limited by the scope of the contract, including temporary. Although, frankly, with a well-thought-out organization of work and the availability of the necessary infrastructure, the additional costs of a social engineering company are small.
One way or another, the choice of additional Pentest options is always up to the customer.
Members of the Special Interest Group (PCI SSC SIG) came to a similar conclusion while working on the Penetration Testing Guidance document. None of the alternatives considered by the group allows us to determine the minimum set of test scenarios that are equally applicable to any customer. Thus, the profiling of the pentest, the definition of a specific methodology for the performance of work is determined individually in each case.
The examples discussed above affect only some situations that pen testers face in their daily work. The logic that guides specific performers in this process is often opaque and incomprehensible to customers, and decision criteria are not specified. Numerous restrictions and assumptions that accompany most pentests leave a feeling of understatement and cast a shadow on the result.
So how is it advisable to transform modern pen tests in order to bring honesty and transparency to this business?
First of all, the customer and the contractor must come together to choose the model of the alleged attacker. This model should be sufficiently detailed and as close as possible to reality. Given what services and what data are included in the scope of work, it is necessary to determine the profile of the potential attacker and his likely targets.
The terms of work must always be determined by the customer. It should be remembered that the model of the alleged attacker determines the maximum level of complexity of the pentest. The lower limit is the already mentioned principle of simplicity, according to which, when performing work, the performer moves from simpler attack vectors (for example, selecting primitive and standard administrative passwords) to more complex ones (for example, social engineering using specially prepared malicious code).
Penetration scenario testing policies should also be mentioned in the contract. A common practice is when a pentester stops working if, by testing one of the scenarios, a positive result is achieved (the goal of the pentest is achieved). It seems logical that increasing the level of complexity is necessary only if simpler attack vectors have not led to the desired result.
The composition of the implemented attack scenarios for a specific model of the alleged attacker is the internal kitchen of the performer. The future of pentests lies in the development of this particular approach.
The improvement of the scenario approach is connected both with the evolving model of the attacker, and with new attack techniques, as well as with the level of technology development in general. If simple attack scenarios remain practically unchanged, then the execution of complex attacks carried out by the most dangerous attackers is an objective necessity for the customer and a competitive advantage for the performer.