The past article
The basis of this article comes from here: http://www.51testing.com/html/49/n-225449.html;
I wrote this article in 2010. The original blog has died in the hard disk, so I can only find a format editor that is good to post.
The whole article is messy, many operation ideas are threshold or immature, and there are some differences between the direction and this time, but its foundation is the same as this article.
Take a look if you are interested. If you are too lazy to read it, it's the same with this one.
What to write this time
I wanted to highlight the words "operable" in the title, but later I felt it was a risky activity.
After all, the realistic sense of bone can't hold the ideal fullness.
Things that can be operated often have to be compromised due to problems that people or material resources can't wait for. I'm afraid that many people can't accept this compromise. So in order to avoid being shot too hard at the beginning of an article, or to remove these three words, but in terms of content, I'm still more inclined to be "operable" and try to give what I tried or what I tried The operational thinking that can be imagined.
Current problems
Because the essence of infiltration is loopholes, I start with loopholes.
Based on some common vulnerability evaluation indicators or models, it can be summarized as follows: at present, the dimensions used to quantify vulnerability evaluation are as follows:
- Usability
Usability
- Ease of use
Ease of use
- Exposing
Exposing
- Local / remote
Local / remote
- Certification (certification required or not)
Certification (certification required or not)
- Influence range (server side or client side)
Influence range (server side or client side)
- Possible loss (direct or indirect dimensions)
Possible loss (direct or indirect dimensions)
I've condensed some overlaps together. Maybe what you understand will be different, but the overall deviation should not be too serious.
The obvious problem here is that such indicators are difficult to make a secondary evaluation of the environment to which the vulnerability belongs, so the evaluation results are often distorted. This is the reason why many technical evaluation finally make simple and rough evaluation based on the authority or influence range.
Moreover, due to the lack of secondary evaluation indicators of the environment to which the vulnerability belongs, there will also be no "liquidity" of the vulnerability in the business environment. Since there is no liquidity, the final result will inevitably be no "sustainability". A system without sustainability will not be able to let "real-time" play a role in its internal.
So, I think it's necessary to choose a new delivery mode to break these.
One is to break the secondary evaluation in the environment, the other is to break the internal and external docking, and the third is the real-time docking - in fact, these three issues are complementary and inseparable.
So here are two solutions:
- The definition of internal and external evaluation and its connection and transformation
The definition of internal and external evaluation and its connection and transformation
- External threat intelligence (real time)
External threat intelligence (real time)
Transformation based on infiltration
Why should penetration test be the object of transformation?
It's mainly because of penetration. Now penetration testing is a service mode that is most misunderstood and widely used. Many manufacturers regard penetration as a delivery highlight, while many users think penetration is a verification means to ensure the security of the target system.
But in fact, infiltration is only a means to verify the overall security of the system, and its essence is "point to point". Although at present some models similar to crowd testing have the ambition to clean up all loopholes at once, in theory, this mining method based on known means is still impossible to be comprehensive, and how to demonstrate it is just a "point to end" method.
Based on this kind of Misreading and current situation, it is necessary to transform this service to fit the misreading status of this service.
There is so much nonsense in the above. In fact, the following processes are dismantled:
Process 1: Excavation
- Identification and discovery business
Identification and discovery business
- Comb based on business or data and output "test flow"
Comb based on business or data and output "test flow"
Process 2: Threat Intelligence (external)
- Large and comprehensive external source to internal transformation
Large and comprehensive external source to internal transformation
- Pack and push (Threat Intelligence = threat + general evaluation index)
Pack and push (Threat Intelligence = threat + general evaluation index)
Process 3: assessment / penetration / verification
- Combining the above two mechanisms to form an evaluable test (verification) path
Combining the above two mechanisms to form an evaluable test (verification) path
- Evaluate the impact, ease of use, and exposure of the test path itself
Evaluate the impact, ease of use, and exposure of the test path itself
The above three aspects are combined into a "penetration service" or "threat mining (Discovery) and tracking service", whose core lies in business, data, real-time and Sustainability
The whole process should be as follows:
Next, we need to split up several processes and discuss the unfinished closed-loop in the three processes
However, I haven't slept well for several days. Let's write these first today
(to be continued)