[WEB SECURITY] Formal Pentesting 'test plan/s' projects?

Pete Herzog lists at isecom.org
Tue Jul 21 15:22:31 EDT 2009

robert at webappsec.org wrote:
> Is anyone aware of a project/initiative for the creation of security test plans for use by penetration testers?

We did one in OSSTMM 3 and completed in the last re-write to make it 
more useable. Here's a snippet of the chapter entitled "What You Need 
to Do"

Where do you start? Testing is a complicated affair and with anything 
complicated, you approach it in small, comprehensible pieces to be 
sure you don't make mistakes.

Conventional wisdom says complexity is an enemy of security. However, 
it is only at odds with human nature. Anything which is made more 
complex is not inherently insecure. Consider a computer managing 
complex tasks. The problem as we know it is not that the computer will 
make mistakes, confuse the tasks, or forget to complete some. As more 
tasks are added to the computer, it gets slower and slower, taking 
more time to complete all the tasks.  People, however, do make 
mistakes, forget tasks, and purposely abandon tasks which are either 
not important or required at the moment. So when testing security, 
what you need to do is properly manage any complexity. This is done by 
properly defining the security test.

2.1 Defining a Security Test
These 7 steps will take you to the start of a properly defined 
security test.

1.Define what you want to secure. These are the assets. The protection 
mechanisms for these assets are the targets you will test.
2.Identify the area around the assets which includes the protection 
mechanisms and the processes or services built around the assets. This 
is where interaction with assets will take place. This is your 
engagement zone.
3.Define everything outside the engagement zone that you need to keep 
your assets operational.  This may include things you may not be able 
to directly influence like electricity, food, water, air, stable 
ground, information, legislation, regulations and things you may be 
able to work with like dryness, warmth, coolness, clarity, 
contractors, colleagues, branding, partnerships, and so on. Also count 
that which keeps the infrastructure operational like processes, 
protocols, and continued resources. This is your test scope.
4.Define how your scope interacts within itself and with the outside. 
Logically compartmentalize the assets within the scope through the 
direction of interactions such as inside to outside, outside to 
inside, inside to inside, department A to department B, etc. These are 
your vectors.  Each vector should ideally be a separate test to keep 
each compartmentalized test duration short before too much change can 
occur within the environment.
5.Identify what equipment will be needed for each test. Inside each 
vector, interactions may occur on various levels. These levels may be 
classified in many ways, however here they have been classified by 
function as five channels.  The channels are Human, Physical, Wireless 
Communications, Telecommunications, and Data Networks. Each channel 
must be separately tested for each vector.
6.Determine what information you want to learn from the test. Will you 
be testing interactions with the assets or also the response from 
active security measures? The test type must be individually defined 
for each test, however there are six common types identified here as 
Blind, Double Blind, Gray Box, Double Gray Box, Tandem, and Reversal.
7.Assure the security test you have defined is in compliance to the 
Rules of Engagement, a guideline to assure the process for a proper 
security test without creating misunderstandings, misconceptions, or 
false expectations.


Obviously it goes into much more detail than I can send here. But it's 


Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn

More information about the websecurity mailing list