Most organizations are aware that penetration testing is an important part of cybersecurity. Whether you have to pass certifications, meet regulatory requirements, or stay compliant with PCI DSS or other standards, you need pentesting. Increasingly, organizations are investing in pentest-as-a-service, where pentests are delivered on a recurring basis throughout the year.
This is beneficial in many ways. For example, rather than spending time and budget sourcing a pentester to fill in compliance requirements, those same organizations can spend that budget on more pentesting and improved security. At the same time, you’ll have to align pentests with your schedule, with budget, and with development or other planning to ensure that pentesting is most effective and that you do get the most out of every pentest.
And, of course, pentesting can be part of future objectives and strategy without need to plan it immediately.
You Understand Your Assets
When you request a pentest, you set the scope of the test. That means asking the pentester to check a list of assets like websites, IP addresses, servers, etc. You have to have a clear idea of your environment, what dependencies exist, how assets are connected, etc.
That might mean:
- APIs
- Web Apps
- Networks
- Websites
- Servers
- Production OR Test/Dev/Demo Environment
- Processes
- System Infrastructure
- Client-side software
- IoT devices (routers, modems, printers, etc.)
If you understand how those items map in your environment, you can prioritize them based on risk and determine when and how to pentest them. When you have that detail and scope set, you can run pentests with better coverage and better results.
Teams are Prepared
In any case where you run a pentest, it’s highly likely that vulnerabilities will be found. Your team has to be in a position where they can allocate resources to remediating those vulnerabilities. That means:
- Teams are aligned on remediation processes, on goals, and on having the pentest done. If you have buy-in from everyone, they can contribute to planning, scoping, and ensuring remediation afterwards. If not, you may have issues where vulnerabilities are found but never remediated, etc. This also holds true for managing the pentest – as pentesters may need time in which they can operate where it’s okay if website or web application performance lags. That requires alignment with development and maintenance teams.
- The team has time and can prioritize remediating vulnerabilities when and as they are found. That often means setting aside time in the sprint following expected pentest results so that teams can take action. While it can be difficult to prioritize something when you don’t know what will be found, ensuring teams have time and budget is important. That may mean immediately setting aside time to fixing critical vulnerabilities and having a process to integrate other fixes into your roadmap. It may also mean dedicating the full next sprint to remediating issues.
- You’ve remediated or taken action on vulnerabilities found in a previous pentest or by scanners. If you do so before the next pentest, you can save your pentester time because they don’t have to waste time on known vulnerabilities. Of course, if you can’t remediate those vulnerabilities quickly, it’s not a good idea to postpone your next pentest indefinitely, because other major and larger risks could slip through. The goal should be to fix as much as possible as it’s found – but eventually, if your pentester finds known vulnerabilities, they’re also confirming those vulnerabilities and their severity. However, if you have fixed known vulnerabilities, your pentester can retest those fixes, ensuring that the fix worked and that the fix didn’t create new vulnerabilities.
Reasons You Might Not Want to Pentest Right Now:
- You’re still in the development phase and want a stable release before pentesting. Of course, for big projects, using code review or pentesting along the way can reduce costs by catching vulnerabilities early. Most small development projects leave pentesting to the end of the development phase.
- You’re running a server/network/environment migration. It doesn’t make sense to pentest an environment you’ll soon stop using. However, you can run a pentest phase on the application layer only in case you want to asses web apps and websites now. This is often crucial, as major providers like Azure and AWS don’t allow you to directly pentest their services. So, for most businesses, application layer pentesting is separate from server pentesting anyway.
- You’re redesigning code and intend to make major changes in the near future. While you may still want to pentest now if you want to see old vulnerabilities to steer new development, it might otherwise be a waste of time to do so. You can then plan in the pentest for the new release.
- You don’t yet have budget or finances in place to have a penetration test completed. In this case, you can either choose a security assessment instead or opt for scanners to give you a light indication of what might be wrong so you can fix those surface level problems. However, scanners will never go beyond surface vulnerabilities, so they don’t offer the same level of security. You’ll still want to budget in a full pentest later. Integrating code scanners and security scanners into web applications is also just good security practice and you should consider doing it regardless.
- You’re about to start a certification or compliance process that will require a pentest. Of course, pentesting in advance of doing audits will help to ensure you can fix any issues found. That will streamline the process, so you have a higher chance of passing it right away. However, if budget is low and more important than passing the audit, waiting to pentest until the pentest during the audit is a good idea.
- Cybersecurity risks are extremely low, because you don’t have any assets, don’t have expected financial gains, or don’t have custom code. In this case, you’ll still want to use scanners and implement the security scanners from your servers.
Getting Started with Pentesting
Eventually, the most effective time to pentest is when pentests align with development and update schedules, when teams are prepared to take on the work, and when you fully understand what needs to be pentested.
Once you have that in place, you can pentest and then immediately shift focus to remediation, ensuring your assets stay secure. And, of course, pentesting should be recurring. If you can map pentests to your development schedule throughout the year, fill that pentest schedule out with regular scans, and immediately react and allocate work to remediate as vulnerabilities are found you are making the most out of your pentests.
Cyver is a pentest-as-a-service team delivering recurring pentests through our pentest management platform, Cyver Core. We deliver pentests with traditional reports, as well as vulnerability findings as tickets, which you can export to Jira for better management and faster remediation. Plus, with metrics and a security dashboard included as part of our service, you can see, at a glance, where vulnerabilities are in your organization. If you’d like to learn more, contact us for a demo.