How to Build a Pentest-as-a-Service Pentest Program- Cyver

Pentesting functions to help organizations identify, manage, and mitigate risks in network and web environments. Yet, traditional pentesting, which typically involves a single pentest, does little to reduce long-term risks. Every organization is in a constant state of change, applications are updated, new features are built, and backend software changes. Those organizations need continuous pentesting, also known as pentest-as-a-service, to ensure findings associated with updates, new features, and changes are identified and managed. A good Pentest program is an essential part of setting that up.

Pentest-as-a-Service enables this, with features like automatically rescheduled pentests, long-term vulnerability finding management, and threat analysis. Cyver delivers pentests using this model, via a secure online portal, where developers can easily log in, view tickets, and work on remediation. But, building that “set and forget” pentest-as-a-service program means creating a strong baseline of a basic pentest that meets the security needs for your organization.

What is a Pentest-as-a-Service Program?

Pentest-as-a-Service, as offered by firms like Cyver allows you to build a pentest program, set it, and allow it to run. Every time you run a pentest, an identical one is automatically scheduled at a set interval. On your side, a pentest program is designed to systematically identify vulnerabilities so you can remediate them. It’s normally mapped to planned changes, regular feature updates, and to sprints. These allow you to ensure pentesting happens after major updates, in line with sprints so that teams can immediately pick up changes, and to ensure full coverage of assets even as those assets change.

What’s involved in a Pentest-as-a-Service Program?

There are 6 basic stages in building a pentest-as-a-service program:

1. How often are applications updated?
2. Are there upcoming major changes?
3. How frequently do devs push new features?
4. What is the security risk for each asset?

Most pentest program plans are annual or bi-annual. High-risk industries might want to choose monthly or quarterly pentests instead. The more frequently you introduce changes, the more often you should pentest.

1. Security or threat risk (industry, company size, etc.)
2. Compliance needs (e.g., if you’re testing for PCI DSS, you need Level 2)

The scope stage also means choosing compliance frameworks, choosing any standards you’d like to test with, and adding resources. For example, Cyver allows you to upload access details into a secure, encrypted portal.

1. Schedule — You schedule the first pentest, Cyver takes over from there. Vulnerability findings show up in the portal as they are ready.
2. Remediate — We deliver findings as tickets, so you can deliver tickets directly to dev teams, in our portal, moving fixes forward as part of the sprint. We also offer free tools, like time-to-fix metrics, so you can always see when vulnerabilities become critical.
3. Retest — Cyver offers free retesting to ensure everything is resolved and you stay secure.
4. Reschedule — Your pentest is automatically re-scheduled at the requested frequency, with the same assets, scope, and frameworks. The only time you have to intervene is when access details change.

Benefits of a Pentest Program

There are many reasons to use a pentest-as-a-service program instead of traditional pentesting. The two most pressing are:

• Continuous testing means continuous coverage for assets
• It’s much more likely that vulnerabilities will be identified and resolved before they become problematic

Building a pentest-as-a-service program means integrating cybersecurity into development. That means using a DevSecOps approach of making security and vulnerability fixes part of your sprints. You’re not pentesting to pass a compliance check, you’re pentesting to hand devs the tickets they need to resolve vulnerabilities in their code.

Traditional pentesting normally means a single pentest, typically conducted in line with compliance or audit needs. You get a static document, which can be pushed to development and IT to fix. This process can take months.

At the same time, most websites, applications, and assets are updated dynamically. Rolling and continuous updates constantly introduce change to the system. Assets, patches, and new code introduce new vulnerabilities. Continuous testing means continuously identifying those issues.

Ongoing pentesting also means building relationships, creating a better picture of your cybersecurity landscape, and managing threats long-term. A pentester working with your assets on a one-time basis has no real idea what they’re working with. A team coming back to check those assets again and again understands how the application has changed, what might be a risk, and what previous vulnerabilities were. This can result in:

• Insight into recurring issues
• Long-term profiles of vulnerable areas
• Long-term vulnerability management
• Vulnerability finding libraries you can manage and check over time

How to Build a Strong Pentest Program with Pentest as a Service

Any time you start a pentest, you have to set objectives, determine scope, etc. This is especially important with pentest-as-a-service because the idea is that your pentest keeps running. If there are mistakes or items missing from the initial pentest, you’ll keep repeating that until you notice. This means it’s better to take more time during the research and setup stage, so everything works as intended.

Set Objectives — Objectives should include internal outcomes, or what you want to achieve. In some cases, you will have more than one objective. For example:

• Harden web application B
• Maintain compliance for web application B
• Pass SOC2 Compliance (yearly)
• Ensure all major releases are pentested shortly after release

Set Assets — Setting assets is part of planning and part of objectives. Which assets do you want to test? Logically, you eventually want to test all assets, but some are more critical than others. Assets which are updated more frequently, which are more business critical, or which are higher risk should be tested more frequently. Lower-risk assets can be tested at a reduced schedule.

Set Schedules — Pentest-as-a-Service schedules should be determined based on frequency of changes, risk level, and infrastructure changes. Schedules should be mapped to:

• Sprints, devs should be able to immediately roll pentest results into a sprint
• Planned/scheduled updates
• Major compliance requirements
• Significant codebase rollouts
• Infrastructure (cloud app, software, etc.) changes

Set Scope — Your scope should involve logistics, pentest level, and access level. Chances are, you might want advice from your pentester when setting this information.

• What assets do Pentesters need?
• What access levels do pentesters need (Will this be white, grey, or blackbox testing?) For example, if objectives include internal vulnerabilities like finding potential privilege escalation issues, even leveraged by an external threat actor, you’d want to offer access.
• What level of pentesting do you need? How thoroughly should assets be checked? This normally depends on business and industry risks, data sensitivity, etc.

Pentest-as-a-Service and pentest programs allow you to build long-term ongoing pentesting plans. These deliver ongoing security, mapped to updates, agile sprints, and features. It also allows you to build a library of vulnerabilities, to map changes, over time, and to improve over time. Working with the same pentest team means building a library of findings, learning how to implement vulnerability fixes, learning which areas of the business are vulnerable, and where to focus attention.

If you want to learn more, visit our How it Works page, or request a quote now to get started.

Originally published at https://cyver.io on April 13, 2021.