7 Steps to Building a Yearly Pentest Plan

Pentesting is a great way to check your security posture and is an essential part of an application security program. However, for fast-growing, agile organizations, planning pentests can be painful and time-consuming. On the other hand, effective planning is key for optimizing time and budget. To make things easier, I wanted to share 7 steps for building an efficient annual pentest plan.

1. Objective

First of all, it is important to know what the objective of doing the pentests is. A few possible objectives could be:

1. Ensure testing of all apps requiring compliance (e.g. PCI)

2. Ensure all apps with sensitive data are tested

3. Ensure the most business critical apps are tested

4. Ensure all major critical releases are tested

Getting buy-in to the objective from the rest of the organization can help drive budget and input.

Criticality of an app and its data can be hard to define. For smaller companies a hack of the main web app can result in severe business damage. For larger organizations with multiple apps there are more parameters to consider, some of them are:

1. PR damage

2. Customer impact

3. Cost of recovery

However, juggling these parameters is not an easy task. PR damage, sounds rough, but hacks are getting more common in the news, it’s almost expected that a big organization will get hacked at one point. For example, consumers still shop at Target, despite the hack. Thus it might be that PR damage actually costs less than the recovery of a hack exposing sensitive information such as credit cards and business data. If that is the case one should prioritize the apps with biggest customer impact and cost of recovery.

You can use the same measure for criticality of releases, but here you can also go more granular and say that you e.g. want to have a main focus on releases that touches authentication/authorization and/or payment workflows.

2. Create Overview of your App Portfolio and Release plans

If your organization only has a few applications it is easier to get an overview, but for larger companies it can be difficult to get an overview of all the apps. A good way to start is by having a spreadsheet listing the apps. Some of the important info to capture is:

• Are any larger/critical releases being done this year?

• When was the application last tested?

• How complex is the app (dynamic vs. static pages, # workflows and # user types)

• What kind of data is the application storing? Is it sensitive?

• Is testing of this app required as part of compliance (e.g. PCI)?

• What would happen if the site/app was compromised?

• Identify the development teams for the applications

While a spreadsheet is a good start, this will likely be a living document, which requires a more modern approach. E.g. at Cobalt we are building central repo for all pentests, which gives you part of this overview automatically, we are also working on other cool things to help with the entire planning process.

3. Engage the development teams

Knowing the teams who are building an app is just as essential as knowing about the app itself. Planning pentests without taking the capacity and cultures of the development teams into account will likely fail. Some teams are very agile and security centric, and want to get security input as frequently as possible, while others might be releasing less often or have less focus on security. For some legacy apps, there might not even be a development team, which also needs to be addressed.

My recommendation is to involve the product teams as early as possible in the pentest planning and get an idea of their thoughts on scope, timing, and frequencies of testing. By having their buy-in early it will hopefully help drive their attention to fixing issues found in the pentests.

4. Prioritize

When you have the objective and overview of apps and teams, you can start prioritizing the testing. You should prioritize based on your organization’s specific needs. You can e.g. use a simple 1–5 prioritization scheme. Based on the prioritization you can identify the preferred security measure, e.g. a priority 5 application might only require a basic security scan, whereas a priority 1 or 2 application ideally should go through security design reviews + manual pentesting.

5. Budget

Unfortunately most companies do not have endless resources, so budget will be a part of the pentesting planning. But by having a clear objective and prioritization you can hopefully easier justify the spend and descope where needed.

6. Sourcing Pentesters

Before you start making the final plan for your pentesting it makes sense to have an idea of how you will source the pentesters. E.g. will you be using internal/external testers? If you are using external you should engage with them in the beginning of the year. It is likely they can help you build out a schedule for testing and also give input on how to prioritize. You will likely also get a better price if you plan upfront.

7. Scheduling/Planning

When you have the prioritization, sourcing and budget in place you can start building a plan. There are different methods to go about this listed below:

• Release driven

• Fixed schedule

• Continuous

• Pentester availability

Which one you pick depends on your organization and especially the culture within your dev teams and how fast they can fix issues.

Release driven pentesting makes a lot of sense, but it also requires you to stay on the toes of the dev teams and understand how the releases are coming along. With a fixed schedule you have a clear plan, but developers might come back and say that it does not fit with their releases. A good middleway could be to make a fixed schedule based on release plans + a buffer for potential delays.

Continuous testing would be fantastic for apps with a lot of releases. But the team owning the app also needs to be ready to fix, otherwise you will just end up building a huge backlog of findings and spending time and money on finding the same things again and again.

Pentester availability is a very annoying factor to consider in planning. But unfortunately most external testing companies have limited time/resources. By dipping into platforms like Cobalt, you can avoid this by always having on-demand access to a large pool of skilled security researchers.

I hope this blog post is helpful. I would love any input on how you plan your pentests and if there is anything missing from these 7 steps. Further, explore how a Pentest as a Service (PtaaS) platforms empowers teams to execute pentesting with a more agility.

Esben

*How much of your pentesting budget are you wasting? Learn how you can better optimize your pentesting budget in a new analyst report by Dr. Chenxi Wang.