Will A Penetration Test Disrupt My Business?

When working with a customer who hasn’t had regular penetration testing before, one of their primary concerns is usually “will a penetration test disrupt my business?” They may be required to get a penetration test completed in order to meet a compliance requirement, because a larger organization is asking them to, or simply because they want to make their security better. With that being said, a lot of organizations are hesitant to pull the trigger on a penetration test because they are worried about the business impacts. In this blog, we will go over what the potential impacts of a penetration test could be and some easy ways to avoid them.

Will a Penetration Test Disrupt Business Operations?

The answer to this in the vast majority of cases is no, a penetration test will not disrupt your day-to-day business operations. In most instances, you won’t even know testing is going on. You may notice subtle spikes in bandwidth during some automated portions, but unless you are having bandwidth issues (for example if you are already having problems during peak business hour), it won’t not be enough to cause any additional issues. Experienced penetration testers have conducted this same battery of tests on hundreds of companies, and do everything in their power to avoid disruptions. Additionally, your penetration tester should be accessible at any point during the test, so that if you do notice something, they can stop it immediately. Roughly 95% of penetration tests will be conducted without any impact whatsoever.

What about that 5%?

The truth is, even with experienced penetration testers, the answer to “will a penetration test disrupt my business?” has to be “it can.” Even in the best situations, a penetration test is emulating an attack on the network, and therefore, things can go wrong. Check out our blogs on what can go wrong during an external penetration test and what can go wrong during an internal penetration test for some examples, but in general, here are a few things to consider:

• Spike in Bandwidth: As mentioned above, during automated scanning, you can see a spike in the bandwidth. While this is only really an issue if you are near capacity, it can cause an application or network to experience additional latency.
  • If this happens: Call your penetration tester, and work with them to throttle or move scans to off-peak hours.
  • Ways to avoid: If you know you are close to a limit, ask for after-hour scanning. Additionally, if this type of traffic is causing issues, it’s probably a good idea to work on increasing that throughput of your network!
• Form Submissions: During some types of automated web application scanning, all input fields are tested. While experienced penetration testers know generally which fields to not scan (registration forms, contact us forms, etc.), if there is a non-obvious back-end function that gets triggered, such as internal emails to employees, these scans can cause some headaches.
  • If this happens: Call your penetration tester and have them stop web application scans until it is sorted out.
  • Ways to avoid: Provide the penetration test team a list of web forms to avoid during the automated portion of testing, due to the importance of database integrity or to avoid being subjected to an email denial-of-service.
• Account Lockouts: During a penetration test, any login screen is tested for weak/default passwords. Just like an attacker, we want to see if we can break in through that login screen. Unlike an attacker, we try to avoid business impacts when doing this, so we try to avoid client/customer login screens and avoid anything we know will cause a lockout. With that being said, if we can’t determine your lockout policy or you have an extremely strict lockout policy, it can result in locking out accounts.
  • If this happens: Call your penetration tester to stop current password attacks and avoid locking out any more accounts.
  • Ways to avoid: During the kickoff call, we will go over what the lockout policy is for your organization and cover what our standard password attack rate is.
• System Crashes: This is probably the most unlikely, but it is something to be aware of. Sometimes, and usually it happens to really old systems, an exploit attempt or scan can bring a system down.
  • If this happens: Call your penetration tester. They will help let you know what caused it and can avoid that activity on similar systems in the environment, or for future assessments. It’s still useful to know what kinds of activities can cause that significant of a disruption to your environment (availability is an important aspect of security as well).
  • Ways to avoid: During the kickoff call, make sure to cover any systems that are old, fragile, particularly sensitive, or that you’ve had problems with in the past. The penetration test team can work with you to test those with the “white glove” treatment, potentially testing them after-hours or with someone on your side available to help if a system does go down.

As mentioned above, we have blogs covering each type of penetration test and what can go wrong with them. Give those a read as well. If you have any questions, we would love to hear from you!