Pentesting in production

Pentesting in production has risks. I remember a story of a pentester who ran an automatic scanner to spider a site. After some minutes scanning and spidering, it found a path to a list of items that had a delete button next to each of them. The spidering process clicked all these buttons and deleted all the items in production.

Another issue that I have had with automatic scanners, and while spidering, it’s that the scanner reached a contact form and while fuzzing it, the marketing team received dozens of bogus emails. After this happened to me more than one time, I learned to mark contact forms as a target to ignore in automatic scanners or I made sure that the contact form was not working in the environment I was testing.

Another typical case is that, while fuzzing, the performance of the site drops almost causing a DoS.

Pentesting in production has risks, but it also has many benefits that make it worth it when the company is mature enough in this area, and ready.

For example, if you don’t pentest in production you won’t me pentesting the real system, and you might be missing important security issues. The necessary difference between production and any other environment is the main reason to try to pentest in production.

I once worked with a company that had made a huge investment to have a preproduction environment identical to the production environment. They even used to change the production workloads from the production environment to the preproduction environment each four months. A complete datacenter migration each 4 months just to guarantee that the preproduction was ready and in sync with the production environment. Even in that case, the preproduction environment was not exactly the same: the data, the workload, and some minor changes were different at some moments.

The more the pentest environment differs from production, the less valuable are the results.

Pentesting in production is only possible for highly mature companies in relation to security. It requires to be sure that the production environment is resilient enough against random fuzzing and repetitive massive requests from one source. It also requires that the company has processes in place to recover fast in case of unplanned events.

From a business point of view, it also requires that the security awareness in the company is high enough for it to understand the value of pentesting in production, and accept potential impacts because of this.

Never a pentest in a different environment than production is going to be as reliable and complete as a pentest in production. Depending on your maturity and risk appetite maybe you don’t have that option to pentest in production, but it could be a good security objective for the future. If you are already pentesting in environments that are not production, maybe it is worth reflecting on what you can be missing.

Please, rate this post:
[Total: 0 Average: 0]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.