First of all, my title naturally is that, now the domestic penetration test has done not like the service, it is chaos like clusters, a high-end technical services finally became cabbage, it is sad. So, this is the only text.
Of course, everything is based on my experience, purely personal behavior and personal opinion, maybe after you read it, it's all nonsense.
1. Preface: Is this possible?
In 08, I came up with the idea of refining black-box testing methods and processes in a penetration test for nearly two weeks of its duration (but was not promoted at the end of the current situation, only for personal use);
In a 09 project, the business Layer logic security test, which was completed with the support of business carding data, let me verify the method of the Business white Box test from the theoretical level;
10, in a group of national training to explain the methodology and implementation of the process and other details, have been recognized, a number of city companies in the subsequent invitation to this project, but I went;
So, I think, it's possible.
2, the pen-test of Chinese cabbage Price: penetration test Domestic situation
According to the records of the project data, I participated in more than 40 penetration test projects, which as the main testers more than 60% of the project, and at least 50% of the project is in the early or late with the customer site communication, so I think I can be responsible for the status quo described below.
At present, the current situation of penetration testing in China presents the following characteristics:
A, in the risk Assessment project, the project manager or customer expects the revenue from the penetration test to occupy 50% or more of the technical part;
b, the penetration test as an example of the means to show;
c, rely on penetration testing to sell products;
D, a single relying on penetration testing means to complete a certain part of the network and even the technical evaluation work;
E, many testers are too dependent on the tools to carry out penetration testing;
F, especially in web-class testing, the depth and breadth of penetration testing is largely vague and ambiguous (i.e., lack of technical weights and Measures).
The above points, the 1th (ie, feature a) should be somewhat controversial, because each person's understanding of risk assessment is different, inevitably there are differences, so do not elaborate, this article is mainly aimed at solving some of the problems of B to F, but it will inevitably design to risk assessment, hope to see the beholder.
3. Embarrassment: What is the value of penetration testing?
From the traditional way of thinking, if there is danger, the first thing people consider is how to protect the problem, so safety is a protective product before testing products.
And with the progress of thought, protection of products to defend themselves, the lack of security experts need a tool to detect their own anti-theft door-so testing products and services born, but each anti-theft door brand is different, so there are some standardized things to guide the direction of testing services, And the concrete realization relies on each security expert's own understanding.
But it is in this, there is a very attractive thing-penetration test-this thing is to let the people with good quality to simulate the behavior of thieves to your anti-theft door to carry out various work, so as to determine whether your security door can protect against the attack of thieves.
But there are a few problems here.
In most cases, to try to break down which door the customer is sure of, that is, if you have three doors in your home, and you only think one of them is in danger and you only test the door, you have overlooked two other potential risk points.
In other cases, if there is only one door, and you also ask for the only one door to test, it seems no problem, but there is a kind of thief is feiyanzoubi, how did not consider it. For those of you who are unprofessional or do not know about the theft industry, you may not be able to imagine it, so the scope of the non-professional has made a mistake.
Of course, it may be said that the scope of the non-professional development error, the assessment team is not to first look at the weakness of the entire room. Before submitting the weakness to the tester for penetration testing. This is actually a different question, in many cases, penetration testing begins in parallel with traditional technical work and management work in risk assessment, and thus loses this opportunity; and penetration testers are more astute than those who work on management research and traditional technology, in other words, Non-testers in traditional technology testing and management research, and so on, may not be able to really dig out to the penetration tester's intermediate results, they can not even get the results into the proposed mode output to the penetration tester-that is, many risk assessment of internal work parallel, The independence of the people (especially the unclear understanding of each other's work) resulted in a few people fighting each other at work, so often can see the risk assessment work in the end, a few dial people's output is difficult to smooth stitching together, and finally have to follow the general template next life to move hard, and then calculate a risk value to the customer.
The last one is the most embarrassing condition for penetrating testers. Some sales or pre-sales for the sale of products, or because the customer's own security-related knowledge does not understand, resulting in the final production of such orders: for the XX system penetration testing, testing needs to find the system a level, B level, C-level vulnerabilities.
This is the case mentioned above, the penetration test as a comprehensive assessment of the hope that through penetration testing to dig out all the loopholes, but anyone who has the experience of the invasion is clear, who can clap his chest said he can dig clean a system of all loopholes.
So, I think, penetration testing is just a result of validating a risk assessment;
Or more precisely: the goal of risk assessment is to assess the likelihood of risk, while penetration testing is a way of simulating intrusion to verify one or more of the many possibilities, rather than the full possibilities. Because many of the factors in the risk are changing at any time, it is not an immutable destiny.
4. Reflection on traditional black box penetration test
First I need to define the black box penetration test according to my understanding (hereinafter referred to as "black Box Test").
Most of the penetration tests I've been exposed to are black-box penetration tests, black box penetration test for the early job requirements is not high, sales and pre-sales of the majority of black box testing is relatively easy to grasp-I have seen several manufacturers of sales and pre-sale of black box testing before the work from a limited content of the pre-sale document.
This traditional black box test project is actually a lot of drawbacks, including the previous one:
* Relying solely on penetration testing to complete the technical evaluation of some or all networks;
* Especially in Web-class testing, the depth and breadth of penetration testing is largely vague and ambiguous (i.e., lack of technical weights and measures);
One of the more serious problems that comes out of these questions is that the "penetration test is not a clear requirement".
In other words, what is the penetration test completed. The general contract is difficult to define clearly, so in most cases, "customer satisfaction" as the goal.
Whenever I and some of the pre-sales staff mention such a problem, most people also get scratching their heads because they really don't know how to do it. A standard for writing penetration tests into documents and contracts is clear-there is an endpoint for both the product and the traditional service, and the penetration test itself has the following characteristics:
* The first feature is what I have just summed up: penetration testing is only one or several of the possibilities of verifying a multitude of risks;
* The 2nd is also mentioned above: the penetration test scope is difficult to completely restrain;
These two features are related to the inability to confirm the "endpoint" of the penetration test service or the inability to explicitly agree on "achieving the goal". I'm taking it apart for a while.
First: Penetration testing is only one or several of the possibilities of verifying many risks;
Why the penetration test can only verify one or several of them. And why risk assessment can be relatively comprehensive in terms of "some degree".
In fact, various risk assessment methods can not guarantee complete coverage of all risks, so I said "to a certain extent relatively comprehensive coverage." However, the various methods of risk assessment at the end have a strong system or even the rules for its backing, although the specific risk identification can not be separated from people, but there is such a strong backing as a support, the result of nature will not be too much.
And as a black box test, what kind of system to support us. It is precisely because there is no such a thing as its theoretical basis, so as a service or as a product, naturally there is no boundary situation.
It's like the makers of anti-theft doors and thieves: anti-theft door manufacturers make anti-theft door has the theoretical requirements, such as: What kind of tools, in most minutes can not cut out a large hole is qualified; and the thief is not so, if a boss to his younger brother a task: you go to So-and-so room to steal goods, then, When a thief tries to unlock it here, must rely on their own experience and strength, if not open, go back and boss report, the boss asked the details, he is nothing but the method and tools they use to enumerate, and not like the anti-theft door manufacturers-just tell the tester we passed the XX certification test.
Second: The penetration test scope is difficult to restrain;
In most cases, penetration testing is a powerful and imaginative work;
For example: In 05, when a high secrecy requirement research unit did intranet testing, the requirement is to invade the intranet a server that stores sensitive information; I spent the morning to test the server for routine, no fruit, before lunch I went into the intranet another server, and started sniffer (of course, opened the filter), After lunch, I filtered several PCs from the results, and one of them happened to have permission to login to the sensitive server, so I completed this intranet test as a springboard.
In this testing process, there are actually a lot of work that falls outside the scope of the requirements:
* Another server's IP is I scan the intranet after analysis;
* Sniff to multiple PC client data analysis, this is unexpected;
* The most time-consuming work is the analysis of the internal network topology results.
In general, the calculation of project hours does not count the time spent on these unexpected jobs, so that many times the test is halfway through when the tester is still struggling outside.
So, I think that black box testing requires several key indicators:
A, test breadth: that is, test scope, mainly used to estimate the workload and time;
b, test depth: For each test content to establish a test milestone, that is, in advance to agree on what kind of effect can explain what kind of vulnerability;
C, test content: The specific implementation of the test, in addition to guiding the test content, but also mainly responsible for explaining the hazards of each loophole, as a prerequisite for mutual agreement;
Test breadth:
In general, it is easy to calculate, as long as the number of associated systems into which, the general my estimation method is: If the association system does not exceed 5, the estimated work additional 1 days;
Test Depth & test content:
These two indicators have a strong correlation, and I think the focus of refining black box testing, so put together.
First of all, we need to understand what to test what kind of content, that is, we need to have a principled guidance content, for example: we can choose owasp Top 10, also can choose Fortify Coding error, it doesn't matter, but I personally think owasp top 10 (hereinafter referred to as "TOP10") is a good choice, its high degree of identification, especially the PCI DSS to its adherence to the more reflect its value.
But if you choose TOP10, you need to have a split job, that is to put these 10 concrete to the test item, and the specific writing of the test item is naturally need to have the rich experience person to participate in, so this is an expert process, essential, if this step fails, the back is failed; This is also a key point to pull apart the gap between the different manufacturers.
Now there are 10 categories (ie TOP10), 10 categories with the test point, then, you can start to define its harm and scoring, there are two levels of methods, one is for specific test items, one is for 10 categories, if the harm and scores are hit in the specific test items, there is a problem , the display result of each test item is different to the user's sensory experience. Users may struggle with the same score for two different test items in the same category, and the test items are not static and are updated with the technology, so I think the score and the hazard should be the attributes of the TOP10 10 categories.
It is also precisely because of the attribute of classifying fractions and harms as a layer, so also need an algorithm, such as: three test items in a class are validated during the test, and my rating for this category is 5, then the final score should be three cumulative 15 or only one. In fact, I think there is a point, but the most crucial possibility is to introduce another indicator, which is similar to the "possibility" in risk assessment, that is, ease of use.
Why is ease of use. In fact, strictly speaking, I think the "possibility" of this indicator should be composed of four parts: 1, Exposure, 2, whether the disclosure, 3, Ease of use, 4, the degree of harm. But since the leak has been dug up, there is no need to say much about the exposure, for exploitable vulnerabilities, it is naturally disclosed (especially for web-class vulnerabilities, and it is important to exploit a particular vulnerability rather than specific vulnerability details, so as long as the method is generic, it should be considered disclosed), and "degree of harm" We're going to put it in the back of the discussion, so there's only "ease of use" for the time being. Ease of use is mainly considered from two angles, one is the simple way of using, the other is if the use of complex, then there is a higher degree of automation tools to replace the artificial.
In combination, I think it's possible to define "three test items in a class that are validated" with a similar principle:
If the classification risk score is 5, then three test items are also 5, and then according to ease of use for each test item to do a percentage calculation, the final score by addition, then, get an "intermediate score."
The last point, the "degree of harm" of the vulnerability, this also requires a clear definition, and this is a direct relationship to the classification of the points of the problem, so, the above only defines a "middle score", because this intermediate score also need to do a calculation with the results here, in order to relatively objectively reflect the extent of a vulnerability.
We can use the simplest XSS as an example to discuss the following situations:
* Only to achieve the window, that is, perhaps the principle of some restrictions, only alert, then, it boils down to the filter is not strict and the lowest hazard level;
* Non-storage type, the construction of a large number of content in the URL to create a certain harm, this situation is relatively easy to expose, although the threat level is high, but relatively difficult to implement, so the comprehensive level can only be reached;
* Storage type, directly post JavaScript to a page, visitors can be directly stolen sensitive data, this time should be the highest score in XSS level.
The above levels and corresponding points, I defined them as "implementation level", the implementation level of the score and the above "intermediate score" for two times to calculate, is the final score, so that there is probably such a form:
Note: The above is only an example, the specific algorithm and weight, score, etc., according to the division of the test items and the definition of the large classification to do the refinement
Of course, this is only a simple form, but also to continue to improve, for example: test items corresponding to the detection tools, corresponding reference materials, CVE links, and so on, can be done in which, so that testers only need a table to have complete test guidance, and for users, as long as the table of some test items, ease of use, Implementation level and so on, you can understand what the test work included, the content of the test what harm is, the final score is how to calculate and so he is concerned about the problem.
BTW: If you have the conditions, it's best to be able to form or form, attach a use case library for each test item, and the use case library, in addition to the initial addition, should refine the existing use case library after each test, based on the specific project situation, and when the use case library reaches a certain level, according to each project goal, You can classify the use case library as an industry, and by that time the industry direction of penetration testing is clearly visible in the use case library.
5, based on the business of the white box penetration test
In fact, I finally want to say that the focus should be all in that part, in the Black Box test section, no matter how meticulous from the technical level, it is difficult to completely close to the user's real business situation, and the result is only a pure technical figures, only to the technical layer played a "universal" guidance, it is difficult to pull a certain height , so I think that refining the existing penetration test technology process and technical level is a necessary process, but it is only an intermediate process, in the current "can improve the scope", based on the business of the white box penetration test should be a final penetration test is an inevitable direction.
So, how to conduct "based on the business of the white box penetration test" (hereinafter referred to as "white box test") it.
Step One: Understand business features and familiarize yourself with business processes
In this need to do the following work: A, carding business flow; b, carding business logic; C, confirm business node; d, use business flow and business logic to concatenate business nodes.
In fact, this is what I wrote before the "technical chaos: The last few steps in the second half of the article on Business System assessment and protection from client to business system, that is, if a similar assessment is done based on the business, then actually those outputs are already available as input for this step.
Step two: Import management risk
Management Research This part, everyone practice is different, so it is difficult to have a common form or tool to do centralized import.
However, for those who have experience in risk assessment, it is not difficult to do a case-by-case thing, my general thinking is as follows:
* The node vulnerability on the serial service stream, after the node and the business flow in tandem completed (the following can be referred to the technical Chaos: from client to business system, the vulnerability on a node can also be concatenated in a similar way, for example, the concatenation of a business flow to a node is: A-b (TCP 80)- C (TCP 1521), that is, to initiate access from a, to TCP 80 of B as a technical metric, and then to TCP 1521, which jumps from B to C nodes, so that a business process completes, and of course, the reverse, no longer enumerates.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
