Pentesting should be performed on a regular basis, with results feeding into development, bug fixes, and IT teams updating security and settings.
But, how often should you be pentesting? And, does that change from asset to asset? Or should you be testing every environment the same amount?
Understanding Your Options
Pentesting is designed to supplement your normal cybersecurity processes by offering third-party assessments of your environments, from the perspective of a hacker. A pentest is an in-depth attempt to hack your systems and use anything we find to see how much we can exploit and access. That’s in contrast to a vulnerability assessment, which is a much lighter look at surface vulnerabilities – without attempting to exploit anything we do find. Both are an important part of normal cybersecurity practices, and you should make space for both.
Utilizing Scanners
In addition, most organizations should use and rely on vulnerability scanners, like SAST, DAST, and even code scanning. Having tools in place to automatically scan and spot easy-to-catch vulnerabilities not only helps to secure your environment by reducing the chance those issues will be exploited, but also benefits you in other ways. For example, your developers will have processes built around resolving vulnerability findings and tickets, because they’ll use those scanners as part of normal development. So, when your pentester delivers vulnerability findings, you’ll have processes in place to immediately move those into teams as tickets, with processes in place to assess and remediate them quickly. Essentially, scanners help you to truly integrate secure-by-design principles. Scanners also mean your pentester will have to spend less time catching and fixing those obvious options and can spend more time investigating less-obvious issues. You’ll get more out of your pentest and a more secure environment.
Setting Up a Pentest Schedule
Your pentest schedule should normally be based on two primary factors. The first is your risk assessment and the second is your cybersecurity budget. Here, it’s important to balance both to achieve the most secure environment possible withing the bounds of budget and feasibility for devs and IT teams.
Risk factors might include:
- Compliance needs (normally these require a yearly pentest)
- Risk factors (how high profile is the company? How high value is the target? Have you had recent media exposure, etc.)
- Company press exposure
- Software you use (e.g., open-source software may be more vulnerable to attacks)
- Frequency of updates to infrastructure or applications, how frequently do you push new features? Are there upcoming major changes? What is the release schedule?
The higher your risk profile, the more often you need to pentest. However, not all assets will have the same level of risk. Therefore, you can often group assets by likelihood of attack and set up pentest schedules accordingly.
From there, you can set pentest frequency. For example, if you can group assets into two groups of low and medium risk, you can set a pentest schedule for those assets. E.g.
Low Risk – Pentest once per year as part of compliance check. Use a vulnerability assessment in case of major updates to the platform. Utilize scanners on a bi-weekly basis to inform sprint workloads.
Medium Risk – Pentest quarterly and pentest major updates and code releases. Utilize code review to double check the security of those releases. Add vulnerability assessments and scanners at the same frequency as the lower risk assets.
High Risk – Pentest monthly and use red teaming on a quarterly or bi-yearly basis to supplement pentests.
Essentially, you can build a pentest schedule that makes sense for your budget and for your assets.
When you work with Cyver, we ask you to set up a pentest schedule, and then automatically retest your assets on a recurring basis. You can manage the assets, vulnerabilities, and scope of the pentest in our pentest management portal, update details as they change, and track our findings as they come in. Then, when we pentest, we upload findings as tickets, where your teams can immediately roll them into sprints or export into Jira for management on their own platforms. That allows you to work those pentest schedules into sprints, so your assets stay as secure as possible – no matter how frequent the pentest.
If you need help deciding how often to pentest, we can help. If you’d like to see our platform and how we use it to offer pentest scheduling and recurring pentests, contact us for a demo.