Understanding the Driving Factors of a Pen Test

There are many reasons for conducting a penetration test and your company’s specific driving factors can help guide the goals and the approach of your assessment. Whether a pen test is “successful” or not often depends on how these goals are set and communicated. Doing solid technical work is of course important, but if it’s not focused in the right place, that effort can go to waste.

This article will explain some of the most common drivers of security testing that we see at Bishop Fox and what you likely want to focus on (and communicate to your pen testers) to make the most of your security investment.

TECHNICAL DRIVERS FOR AN ENGAGEMENT

Suppose the product you’re working on is about to be released, or a new feature of an existing product is almost ready to be launched. These scenarios are excellent technical drivers for conducting a pen test because it will proactively allow you to fix any serious security issues before the product goes live.

Let’s look at each of these scenarios in a little more detail:

Launching a New Application

Launching a new application can be a scary and exciting time. On top of trying to keep everything up and running in those first few days and weeks, you don’t want to have to worry about security bugs ruining the experience for your users. We’re all told to include security early in the software development lifecycle, but how and where does a pen test fit in?

The key determining factor for whether it’s too soon for a pen test is whether your application is feature-complete –think minimum viable product (MVP). The UI doesn’t have to be pretty and all the kinks don’t need to be worked out yet, but the system needs to function in all its core ways in order for a security test to really be effective and worth the cost. The security team will need to exercise all the major functionality in the application to find out what issues may be lurking within. If important segments of the application are taped over with TODOs, then perhaps it’s wiser to wait until the application is more complete.

In a perfect world, the product would take the form of a release-candidate build — something that is potentially ready to deliver to customers but hasn’t yet gone through the rigors of QA testing. But alpha builds are fine, too, as long as they represent a complete (if unpolished) final product.

But the most important thing here is to clearly communicate the goal of the assessment to the assessment team: to find as many bugs as possible before release. This might sound obvious, but not every engagement is structured that way. So, don’t let it go unspoken.

Adding a New Feature to an Existing Application

Software in the modern era is rarely released with its full and final feature set all in place. Users expect new features over time and this additional functionality can introduce potential security issues. Some new features are so large that they’re practically a new application launch of their own. It’s important to get a handle on the security of these large code changes, but what should you do when features come in little by little instead of all at once?

For most developers, especially at smaller and mid-size companies, it’s impractical to have a pen test for every minor new feature. What makes much more sense in these cases is a periodic check-in, not unlike a routine annual health checkup with your doctor. An annual pen test has a similar purpose: to ensure that security is maintained over time and to identify any recurring patterns of issues that need to be addressed. Communicate to your pen test team that you’ve already had previous tests performed, and that the emphasis should be on the new features.

In both cases, the pen test will ideally occur before real users are exposed to the new system so that any identified bugs can be fixed before real risk occurs. Additionally, when testing happens before changes are launched, the test can focus much more on design and architecture issues than if the system is already live. Changing some important design choices may not be feasible after launch.

Internal Technology Rollout

Sometimes, a major technology initiative is actually not for public consumption but rather a company-wide rollout of some new internal system. A change like this can have a big effect, especially in large organizations where the user base may be many thousands of employees.

This can entail anything from switching HR software, to changing video conferencing systems, to migrating backend hosting providers. Before the rollout takes place, it may be prudent to check the new system for vulnerabilities.

The focus here is often on identifying regressions. Invariably, the new software will integrate, interoperate, or interdepend with many other corporate systems and you’ll want to make sure you’re upgrading your security posture, not downgrading.

BUSINESS DRIVERS FOR AN ENGAGEMENT

Business events such as acquisitions, breaches, and compliance requirements can happen out of sync with your technical delivery schedule and require a dedicated assessment. In these cases, it’s especially important to communicate what those business drivers are so that the assessment team can work to accomplish your goals. Let’s walk through a few of the most common scenarios we see at Bishop Fox and identify some things you can do to make the process as effective as possible:

Acquisition

When a company acquires another business, the parent company will often want to perform a pen test on the technology they’re purchasing. This makes a lot of sense since you want to have as much information as possible when making such a big decision and you’re now responsible for the security of the technology you now own. Everyone gets a home inspection before buying a house and whole companies are much more expensive than that. In this scenario, it’s really important to get a general sense of the company’s overall state of security. Finding and fixing one-off bugs is great, but the focus should really be on the big picture. You’ll want to know what you’re getting yourself into with this acquisition. Does it need only minor cosmetic changes, or does the whole roof need to be replaced? It’s not even uncommon for a pen test to affect the terms of ongoing negotiation.

In the acquisition scenario, ask your pen testers to focus on design-level issues and identify any insecure patterns or troubling indicators of prior compromise. These are things that may be difficult to fix, or worse yet, may be persistent security issues laid into the foundation of the technology.

Breach

Sometimes pen tests are motivated by a security incident. While an engagement may come about because of a breach, remember not to confuse a pen test with a proper incident response process. Make sure you’ve identified the issue that caused the breach and addressed it before seeking out a pen test.

Once you’ve completed your incident response process, you’ll want to have the assessment team focus on issues similar to those that occurred in the breach. A discovered security bug is often just the tip of a vulnerability iceberg: A single SQL injection flaw can indicate that the application does not have a comprehensive approach to database security. We often find that other more serious bugs that were not exploited in the public breach are lurking in the application. It’s these issues that you want to make a priority.

Compliance / Customer Requirements

Sometimes you’re obligated to perform a pen test by either legal regulations or industry requirements. Or maybe your application is entering into a third-party ecosystem like the Google Partner Program, which requires security checks.

In these cases, there are likely specific technical goals associated with the compliance requirements. Be sure to state those explicitly to the assessment team so they don’t overlook coverage of those areas. There may be some interesting leads to follow in the front end, but testing that area doesn’t help much if you’re required to check the authentication system by regulation.

Additionally, while it may be tempting to skimp on this sort of engagement and go for the minimum amount of effort to remain compliant, using this as an opportunity to get serious about security and dive deep has been an increasingly popular option. Where this is the case, let your testers know to go above and beyond the specific compliance requirements.

CONCLUSION

Performing a penetration test is a key component to your overall security strategy, so ensure that you’re making the most of this investment by establishing clear and explicitly communicated goals of the assessment. How a pen tester will approach an assessment and what sorts of things they will attack greatly depends on what’s important to the client from a business risk perspective. Being armed with the context necessary to strike at the heart of the business risk will allow your pen test team to provide real value.