The Pentesting Framework
What is a framework? Moreover, how does it apply to attacking a system? Finally, is a framework a methodology? A framework is collection of measurable tasks, whereas a methodology is a specific set of inputs, processes, and their outputs. A framework provides a hierarchy of steps, taking into consideration the relationships that can be formed when executing a task given a specific method.
For example, this book presents a framework of steps with options within each, and they appear as chapters, headings, and so forth. The context within each section of this book introduces methods for performing certain tasks, heeding the value represented by other points within the framework. When combined, an entire process geared toward value can be presented.
By formatting penetration testing (pentesting) in a framework, as opposed to simply a collection of methods and tactics, elements can be easily removed and added to accommodate specific requirements of the test. Of course, the removal of a particular element within the framework can have repercussions when the goal of the entire framework is promoting value.
How this applies to penetration testing is in ensuring the value of the test is realized. Given that a penetration test is part of a larger security program, one must include other characteristics of security to align the test appropriately to the demands driving it. Moreover, a framework highlights each phase, drawing relationships between them to make sure you are on track with the objectives. In addition, each step in the phase helps you take into account the nuances of performing a controlled attack. For example, there are limitations, inherent and imposed, that will have effects on each phase translating into varying degrees of value. Finally, it provides operational structure to the test. Knowing how and when to perform a task is as important as the task itself.
The mission of the framework is to explain the steps and their relation to other points within the performance of a test, and to expose the impact on value when excluding various methods within each. In the simplified Figure 3.1, we see each primary phase of the framework with points within each representing a task or value element. Some circles are larger than others, signifying more potential value. Depending on what tasks are not employed, some downstream elements may not be available simply because the required information or results from previous elements do not exist. Given that the framework is founded on related processes that span phases, the use (or omission) of a process will limit the availability or effectiveness of other processes.
Figure 3.1 Determining the impact on value based on selected options.
Of course, for your specific goals of the test, the unselected or unavailable elements may prove to be of little or no value and therefore the impact is nonexistent. It is important to evaluate which elements are needed to meet your goals and understand that there may be an inherent relationship to another point within the framework, which you have not considered or do not want to be exercised. The ability to gain visibility into the affiliation between one phase and another is the value a framework brings to the entire process.
While in its infancy, penetration testing meant simply attacking a network and exploiting any vulnerability presenting itself; that was the goal-get in. And, quite frankly, this is still the MO for many engagements today. The tools have changed, the techniques are much more sophisticated, the knowledge of the consumers is much more comprehensive, but the essence of the test has remained much the same.
Technique and tools are important and provide a strong foundation for further evolution, but with regard to security, the environment is too dynamic to base success on technique and tools alone. With the absence of continuity, value rests on the shoulders of the tester and the framework that is followed. The ability to assess the situation and make quick determinations based on similar experiences is an attribute of a successful attack by today's standards.
On the other side of the equation is the recipient of these tests attempting to make value decisions based on his impression of a planned attack, an impression fed by security consultants, magazines, friends, and employees and not from extensive experience in being the target of hundreds of tests.
I liken it to asking a regular person to purchase food for a restaurant. They know what food is and have an understanding of value and use, but buying 250 pounds of meat, 10 gallons of mayonnaise, 25 pounds of cheese, and 8 boxes of detergent would challenge anyone not familiar with the process.
After performing and being involved with many penetration-testing engagements, there is a theme that begins to surface. People are not fully aware of the options available to them and how to apply those options to their environment. Many characteristics have varying degrees of intensity and requirements, such as information and limitations that will influence other areas of the test and how they relate to the value of the test in an overall security program.
 |
|
Share This Article
|
