Pen-testing can be a daunting task.  Where do I start, what do I test, and what is important are often questions I hear from people starting this adventure for the first time.  This is a common feeling, and one that I felt as well.  I have compiled a list of 5 of my favorite pen-testing best practices that I have observed as well as learned from others.

Proper Scope

Like any project, clearly defining your scope of work is critical for its success.  This is very much true for your penetration testing as well. You want to make sure you clearly define what you are planning on testing.  This may be a specific network segment, business function or even a single application.  Specifying a time frame and sticking to it is key.  I have seen too many situations where you start off with a certain test type or certain network segment you want to test against, and scope creep starts to happen based on what you are finding.  This will lead to either a pen-test that never ends, or one that is significantly over time and budget.  The last item to include in your scope is any desired outcomes or specifics that management or the business as a whole is looking for.  Making the test as valuable to the business as possible is key to a successful pen-test.

Use a consistent risk rating scale throughout

If you have ever looked around at penetration testing results, you will notice that everyone tends to have a slightly different risk rating scale.  This is perfectly acceptable.  But, what you don’t want to do is to use different scales throughout the duration of the test.  This can cause inconsistencies in the results as well as confusion for the reader. Having a consistent scale will allow the stakeholders to be confident of the results and therefore know what remediation’s will need be tackled first.

Get Management Buy-in

Management buy-in may not seem important, or just add additional delay to getting the process going, but it is truly one of the most important best practices to consider.  Having support from management means that the project is important to the business, which hopefully means you will not only have budget and resources for the testing itself, but as well as the remediation that will need to start occurring shortly after the testing phase ends.  This is crucial, as you want to make sure that anything you find that needs remediation, will get that necessary love and attention it so desires.  Lastly, having management buy-in can also potentially save your job.  Pen-testing is not always predicable.  Sometimes things can go wrong in a test, horrible wrong. Applications and/or servers may be taken down, databases may get corrupted or even wiped.  The last think you want to do is to have to explain to management what you were doing.  That can, and will often be, a career limiting mistake.

Try not to fix issues during testing

One of the hardest tasks not to do is to fix issues that arise during the test.  Fixing issues found can definitely mess up any results that you have obtained from earlier tests, and could potential change the scope and timeframe.  Obviously, if the risk to the business is high enough, definitely don’t delay, as you can’t perform a pen-test for a company that is no longer in business.

Make the reports your own

How you display your results in your final report is incredibly important.  It could make the difference between management reading the results and formulating a remediation plan versus having a quick glance and filed away never to be heard of again.  The important lesson here is to make the results your own.  Don’t just take the output of the tool and put it into the report. Take the relevant data, put in readable terms for the intended audience, and create a meaningful report.  The stakeholders may not have a lot of time to spend on reading the report, so making the reports clearly define the issues you have found, along with their business relevance and associated risk will help them quickly understand what the current exposure is.  I have seen way too many people just take the output of a tool and put in straight into the report.  Many of these tools output very technical information that isn’t always presented in a clear manner to a non-technical person.  This is an easy way to have your report not get the attention it should

Hopefully these 5 best practices when performing a pen-test have been helpful to you.  If there are any additional ones you want to bring to light, feel free to share in the comments.  Thanks for reading!